From sip-bounces@ietf.org Fri Dec 01 01:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq1Qu-0004cX-Pp; Fri, 01 Dec 2006 00:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq1Qt-0004cH-3V for sip@ietf.org; Fri, 01 Dec 2006 00:59:35 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq1Qm-0000ZO-Ci for sip@ietf.org; Fri, 01 Dec 2006 00:59:35 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4A477189; Fri, 1 Dec 2006 06:59:11 +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, 1 Dec 2006 06:59:11 +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] Re: issue with oubound and the used transport protocol Date: Fri, 1 Dec 2006 06:59:05 +0100 Message-ID: <7374777208BDC7449D5620EF94232567AF8504@esealmw113.eemea.ericsson.se> In-Reply-To: <953beacc0611301516v611db212tc1b9f786293db283@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccU1YVePLgs4XJLSVuYz4tDgXH1cwANzV9w From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 01 Dec 2006 05:59:11.0076 (UTC) FILETIME=[D252FA40:01C7150D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: sip@ietf.org, rohan@ekabal.com, 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 Hi,=20 In my case the UA DOES realize that the TCP connection has died, and creates a new TCP connection. So, since the UA already knows that a new TCP connection (and therefor a new NAT binding) has to be created the XOR-MAPPED-ADDRESS is not needed. My issue was whether the UA uses the XMA information for something else than detecting that the binding has changed, but for outbound it seems like it doesn't, so there is no outbound functionality "suffering" if the UA doesn't get the XMA. Regards, Christer > A NAT won't create a new TCP binding unless it sees a SYN. =20 > If the NAT reboots, the client will detect that the=20 > connection has died, and won't be able to send any traffic=20 > (SIP or STUN) until it opens a new connection explicitly. An=20 > XOR-MAPPED-ADDRESS attribute over TCP is completely useless. >=20 > thanks, > -rohan >=20 > On 11/30/06, Christer Holmberg (JO/LMF)=20 > wrote: > > > > Hi, > > > > >I still need to test this, but I suspect that the STUN=20 > response won't=20 > > >even arrive over TCP when the NAT has rebooted and uses a=20 > different=20 > > >source port for forwarding it. The server then cannot=20 > match it with=20 > > >an existing 5-tuple socket connection and will probably send a RST > > > > Maybe I missunderstood, but won't the STUN request create a new=20 > > binding, in case the NAT has rebooted? > > > > Regards, > > > > Christer > > > > > > > > > > > > > > Regards, > > > Jeroen > > > > > > Christer Holmberg (JO/LMF) wrote: > > > > Hi, > > > > > > > > A question for clarification: > > > > > > > > The STUN response provides the UA with certain useful=20 > information=20 > > > > (XOR-ADDRESS etc), which the UA can use to see whether=20 > a NAT has=20 > > > > rebooted etc. I assume that information is not needed when > > > using TCP? > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Francois Audet [mailto:audet@nortel.com] > > > >> Sent: 30. marraskuuta 2006 19:45 > > > >> To: sip@ietf.org > > > >> Cc: rohan@ekabal.com > > > >> Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport=20 > > > >> protocol > > > >> > > > >> Didn't we agree way back NOT to use PING, CRLF, etc., and use=20 > > > >> STUN instead? > > > >> > > > >> Why is this debate being re-opened? > > > >> > > > >> Remember: I favored the non-STUN TCP approach. However, if > > > we can't > > > >> stick to a decision, we'll debate this forever. It already > > > feels like > > > >> it. > > > >> > > > >>> -----Original Message----- > > > >>> From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl] > > > >>> Sent: Thursday, November 30, 2006 08:02 > > > >>> To: Christer Holmberg (JO/LMF); Rohan Mahy;=20 > > > >>> Erkki.Koivusalo@nokia.com Cc: sip@ietf.org; rohan@ekabal.com > > > >>> Subject: RE: [Sip] Re: issue with oubound and the=20 > used transport=20 > > > >>> protocol > > > >>> > > > >>> Having implemented STUN over TCP/TLS I can now say that > > > it does add > > > >>> significant complexity while providing little benefit=20 > over CRLF > > > >>> > > > >>> STUN allows one to detect NAT reboot, but a CRLF will also > > > >> trigger a > > > >>> connection reset in such a case. STUN breaks framing in > > > >> case the other > > > >>> side does not support it. It uses significantly more > > > bandwidth than > > > >>> CRLF. It requires a lot of text to describe. > > > >>> > > > >>> In summary, I support CRLF for TCP, and would suggest to do > > > >> STUN only > > > >>> for UDP (i.e. its original purpose). STUN for TCP is=20 > a bad idea > > > >>> > > > >>> Regards, > > > >>> Jeroen > > > >>> > > > >>> PS Edge proxy choosing the mechanism: not a good idea > > > >> either, better > > > >>> to simply define 1 mechanism (STUN for UDP, CRLF for TCP) > > > >>> > > > >>> -----Oorspronkelijk bericht ----- > > > >>> Van: "Christer Holmberg (JO/LMF)"=20 > > > >>> > > > >>> Aan: "Rohan Mahy" ; > > > Erkki.Koivusalo@nokia.com > > > >>> CC: sip@ietf.org; rohan@ekabal.com > > > >>> Verzonden: 30-11-06 13:56 > > > >>> Onderwerp: RE: [Sip] Re: issue with oubound and the used > > > transport > > > >>> protocol > > > >>> > > > >>> > > > >>> Hi, > > > >>> > > > >>> Why don't we let the edge proxy choose which keep-alive > > > >> mechanism to > > > >>> use? > > > >>> > > > >>> The outbound spec should now say (I haven't had time to > > > >> check, but I > > > >>> hope me and Rohan agreed to add it :) that the edge proxy > > > >> can insert > > > >>> the keepalive parameter in the Path header. > > > >>> > > > >>> So, we define a "CRLF" value for the parameter, and the > > > >> edge proxy can > > > >>> then use that value for TCP flows. > > > >>> > > > >>> Of course, if the UA is not mandated to implement all kind of=20 > > > >>> keep-alives, it will also have to be able to indicate to the=20 > > > >>> edge proxy which keep-alive mechanisms it support. > > > >>> > > > >>> Regards, > > > >>> > > > >>> Christer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> 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=20 > application of=20 > > > >>> 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=20 > 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=20 > 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 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 Dec 01 01:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq1yM-0006Dx-HC; Fri, 01 Dec 2006 01:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq1yK-0006Dj-Mp for sip@ietf.org; Fri, 01 Dec 2006 01:34:08 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq1yI-0007ym-Qk for sip@ietf.org; Fri, 01 Dec 2006 01:34:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Dec 2006 06:34:03 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3672@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccU1YVePLgs4XJLSVuYz4tDgXH1cwANzV9wAAFdKqg= From: "Attila Sipos" To: "Christer Holmberg (JO/LMF)" , "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sip@ietf.org, rohan@ekabal.com, Francois Audet Subject: [Sip] CRLF draft? 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="===============1624440923==" Errors-To: sip-bounces@ietf.org --===============1624440923== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KRXZlcnkgbm93IGFuZCB0aGVuIEkgImhlYXIiIHBlb3BsZSBtZW50aW9uIENSTEYuDQpJcyB0 aGVyZSBhIGRyYWZ0IGZvciB0aGlzPw0KT3IgYSBkcmFmdCB3aGljaCBtZW50aW9ucyB0aGlzPw0K SSBhc3N1bWUgaXQncyBzb21ldGhpbmcgd2hlcmUsIGluc3RlYWQgb2YgYSBmdWxsIFNJUA0KbWVz c2FnZSwganVzdCBhIENSTEYgaXMgc2VudCB0byBrZWVwIGEgTkFUIGJpbmRpbmcgb3Blbi4NCklz IGl0IG9ubHkgbWVhbnQgZm9yIFVEUCBvciBqdXN0IGZvciBUQ1Agb3IgYm90aD8NClJlZ2FyZHMs DQpBdHRpbGENCiANCg== --===============1624440923== 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 --===============1624440923==-- From sip-bounces@ietf.org Fri Dec 01 02:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq38u-0000Ng-9U; Fri, 01 Dec 2006 02:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq38s-0000NO-HL for sip@ietf.org; Fri, 01 Dec 2006 02:49:06 -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 1Gq38p-0001CN-Ql for sip@ietf.org; Fri, 01 Dec 2006 02:49:06 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J9L00G334DSPU@siemenscomms.co.uk> for sip@ietf.org; Fri, 01 Dec 2006 07:49:04 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 01 Dec 2006 07:48:56 +0000 Content-return: allowed Date: Fri, 01 Dec 2006 07:48:55 +0000 From: "Elwell, John" Subject: RE: [Sip] Issue: Expiration of temp-gruu To: Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A76B390@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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: SIP IETF 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, My general concern is about the unpredictability of temporary GRUUs. If the community is happy that this is good enough for use cases they have in mind, I can live with it. I just wanted to see whether I was alone in having these concerns. Concerning the specific problem you raised at the start of this thread, one solution might be, when returning a temporary GRUU in a 2xx to a REGISTER request, to include an integer (as a Contact parameter) that indicates the number of temporary GRUUs assigned. So if you refresh but too late, you would see that only one is assigned and that older ones have been lost. This would avoid subscription to the registration event package, although the registration event package would bring additional benefits (alerting you immediately without waiting for the next refresh). John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 30 November 2006 19:27 > To: Elwell, John > Cc: SIP IETF > Subject: Re: [Sip] Issue: Expiration of temp-gruu > > > > Elwell, John wrote: > > I guess some of my concerns about temporary GRUUs are > starting to creep back > > again. > > Is your renewed concern related to this particular issue I posted? It > doesn't seem to be. > > Your concern seems to be that temporary gruus are, well, *temporary*. > > > It is a question of how they are used. If a UA gives a > temporary GRUU > > out as a contact on a dialog and expects it to be used only > during the > > lifetime of that dialog, then refreshing the target if the > temporary GRUU is > > lost would get around the problem in most cases. There will > of course be > > race conditions, e.g., the UA sends out a target refresh > but the remote UA > > has already sent a REFER request to the old target. > > Yes. In most cases this won't be an issue. And I expect that many > implementations will simply assume that they stay registered > and don't > need to deal with the doing a target refresh because the gruu > has been lost. > > > What concerns me more is if there are use cases where a > remote UA might want > > to use a received temporary GRUU long after the dialog has > terminated. If > > the local UA keeps refreshing its subscription correctly > and successfully, > > then the temporary GRUU will remain valid. But if it is lost through > > circumstances beyond the control of the local UA, then it > has no means to > > inform the remote UA that it is no longer valid and that a different > > temporary GRUU must be used. > > Yes, this is the case. Frankly I find it hard to imagine a > case where a > temp-gruu, used for anonymity, is to be used for something long after > the dialog has terminated. I guess there could be cases, but perhaps > they aren't so interesting. > > Any kind of scheme that allowed temp gruus to live arbitrarily beyond > the life of a registration would need some other mechanism to support > their longevity, and also would presumably need some kind of > revocation > mechanism. It would I think need state to be kept in the network. > > There may be some use for such a thing. But I think it probably calls > for a different mechanism. One that probably isn't suitable > for everyday > anonymous calls. So I think supporting that mechanism can be > viewed as > an independent problem. > > > One example given in gruu-11 is the use of a GRUU on a web > page. If a > > temporary GRUU were to be used (presumably on a temporary > web page), similar > > considerations would apply. > > I guess it depends on how temporary the web page is. > > > Another concern is if I want to give out a different > temporary GRUU to > > different remote UAs, so that I can easily turn off > individual temporary > > GRUUs if I no longer wish to receive requests from the > parties concerned. > > When I first register I have only one temporary GRUU, so if > I want to give > > out several temporary GRUUs I would need to refresh my > subscription several > > times to obtain these GRUUs. > > > > I just have an uneasy feeling that the temporary GRUU > mechanism might be > > somewhat orthogonal to possible use cases, although I am > having difficulty > > articulating particular real life use cases. > > I think we already hashed these particular issues. There are some > unavoidable tradeoffs here. > > Paul > > > John > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 29 November 2006 23:21 > >> To: SIP IETF > >> Subject: [Sip] Issue: Expiration of temp-gruu > >> > >> After some study, I have encountered a potential difficulty in > >> determining when temp-gruus expire. After discussing this > >> with Jonathan > >> we decided to bring it to the list for discussion. > >> > >> As now defined, when you first register you may get a > >> temp-gruu, which > >> will remain valid as long as the registration does not > expire or be > >> removed. (Removal is a special case of expiration.) Each > time the UA > >> refreshes the registration it may get a new temp-gruu which > >> also remains > >> valid for the life of the registration. The UA can accumulate > >> all these > >> temp-gruus and use them as it sees fit until they expire. > >> > >> The problem is: how does the UA know when the registration > >> has ended and > >> the temp-gruus associated with it rendered invalid? > >> > >> This seems like a simple question, and in some cases it is > >> simple, but > >> not in all cases. The following are at least some of the ways > >> that the > >> registration can be ended, causing the invalidation of temp-gruus: > >> 1) the UA that originally registered may explicitly deregister > >> 2) the UA the originally registered may simply permit the > >> registration to expire without attempting to refresh it > >> 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 > >> > >> In each of these cases the previously assigned temp-gruus become > >> invalid. If the UA continues to use them, bad things will > >> happen. This > >> is true both for calls that are active when the > >> deregistration occurs, > >> and calls that are established later. What kinds of bad > things happen? > >> - requests addressed to the gruu, both in-dialog and out-of-dialog > >> will be undeliverable. (For instance a reINVITE or BYE in an > >> existing call, or an out-of-dialog INVITE/Replaces for > a transfer.) > >> > >> - request originated by the UA using the invalid gruu will fail > >> immediately because the gruu is invalid. > >> > >> - if the UA subsequently reregisters, receives an incoming > call, and > >> uses one of the old temp-gruus as its contact, then the > call will > >> be established, but subsequent in- and out-of-dialog requests to > >> the contact will fail. > >> > >> So clearly it is important for the UA to stop using > >> temp-gruus that have > >> become invalid. How can it know to do that in all of the > above cases? > >> > >> 1) is straightforward. The UA knows it is deregistering, and should > >> discard any cached temp-gruus. If it has a dialog with > one of the > >> temp-gruus as a contact, then it should do a target refresh and > >> supply some working contact. (It really should do this *before* > >> deregistering, and for a pub-gruu as well.) > >> > >> 2) the UA should take all the actions mentioned for (1) at > or before > >> the expiration time. This should be done a bit early to guard > >> against clock skew problems. > >> > >> 3) in this case, it may be impossible for the UA to know whether > >> the REGISTER arrived in time to be a reREGISTER or if > it arrived > >> late and was treated as a new REGISTER after the expiration of > >> the old one. (The response to the REGISTER includes > nothing that > >> distinguishes the two cases.) About the best that can > be done in > >> this case is to check the time at which the response to the > >> REGISTER is received. If it falls after the expected expiration > >> time for the registration, act as if the old registration had > >> expired. > >> > >> 4) This is a major problem. Of course, regardless of GRUU, the UA > >> won't be able to receive incoming calls until it decides it is > >> time to refresh the registration. In addition, until the > >> registration reestablished, calls originated with one of its > >> existing gruus will fail. Once the registration is > reestablished, > >> it still won't know its old temp-gruus are invalid. The only > >> remedy for this is to subscribe to the "reg" event package, > >> and use the resulting notifications to identify when it has > >> been unregistered. If it does that, it can invalidate all its > >> old temp-gruus, and then presumably reregister. > >> > >> 5) this is functionally equivalent to (4), except that perhaps > >> attempts to reregister may fail. > >> > >> 6) this is also functionally equivalent to (4). > >> > >> The "reg" event does provide a fairly complete solution to > >> this problem, > >> for those that are willing and able to use it. It is not > >> however a 100% > >> reliable solution. Consider case (3), where the UA has a reg event > >> subscription. All is well if the registration expires and a > >> notification > >> is sent indicating that, and then the reregistration occurs and a > >> notification is sent about that. But if they happen very > closely in > >> time, it may be that only one notification is sent, reflecting the > >> result of the reregistration. In that case the UA will not be > >> aware that > >> it had been unregistered for a period of time. > >> > >> A *complete* solution would, IMO, involve changing REGISTER > >> so that it > >> returns an indication of whether this was a new registration, or a > >> refresh. This could take many forms. For instance the > >> timestamp of the > >> initial registration could always be returned with each > >> contact, as well > >> as the expiration time. > >> > >> The big question is whether this is a big enough issue to > require a > >> solution now, as part of GRUU, or if it can be ignored as > >> insignificant > >> or postponed to future work. > >> > >> I'd appreciate hearing what others think about this. At the > >> moment I am > >> leaning toward doing nothing, at least for now. > >> > >> 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 > >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 01 06:58:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq70n-0002GO-ML; Fri, 01 Dec 2006 06:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpHi5-0006Fo-AC for sip@ietf.org; Wed, 29 Nov 2006 00:10:17 -0500 Received: from web7601.mail.in.yahoo.com ([202.86.4.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpHi2-0004D5-9W for sip@ietf.org; Wed, 29 Nov 2006 00:10:17 -0500 Received: (qmail 75717 invoked by uid 60001); 29 Nov 2006 05:10:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=DTfKF+IxUTFX3aMPnQKTYC6AJU4CDat6ZYl4G8gnpIxlYp+zNHik9RhjbEjccuHsBlaZhGyWdqW83FqJhzWs9nhCJGragesTYQAdCBrMKOeeAMF0ivzpNNiXRY4aWm1k8y1kGxlhx0CUpiw0YnT5FND6hS4gIv9W4+22U5up0L4= ; Message-ID: <20061129051003.75715.qmail@web7601.mail.in.yahoo.com> Received: from [220.227.165.120] by web7601.mail.in.yahoo.com via HTTP; Wed, 29 Nov 2006 10:40:03 IST Date: Wed, 29 Nov 2006 10:40:03 +0530 (IST) From: Sreenath Kulkarni To: Raj , SIP forum , sip@ietf.org, sip-implementors@cs.columbia.edu MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 01 Dec 2006 06:56:58 -0500 Cc: Subject: [Sip] Re: [Sip-implementors] Forking INVITE SIP message - regarding 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="===============1439008752==" Errors-To: sip-bounces@ietf.org --===============1439008752== Content-Type: multipart/alternative; boundary="0-1346572428-1164777003=:75290" --0-1346572428-1164777003=:75290 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Hi Raj,=0A=0AThis scenario can happen only in case of parallel forking. I d= on't beleive that all the 2xx responces will reach the server at the same t= ume. If it so then i think the server will forward the 2xx response on some= priority basis.=0A=0A/Sree=0A=0A----- Original Message ----=0AFrom: Raj =0ATo: SIP forum ; sip@ietf.org; sip-impl= ementors@cs.columbia.edu=0ASent: Tuesday, 28 November, 2006 10:47:02 PM=0AS= ubject: [Sip-implementors] Forking INVITE SIP message - regarding=0A=0AHel= lo,=0A =0A Consider the following situation.=0A =0A Adam = wants to call Bob, let=A2s say that Bob is registered at three locations, t= hat is, at home, at head office and at his branch office. Hence, when Adam = makes a call, INVITE request is forked by the proxy and it reaches all the = three destinations. Hence, three 200 OK SIP response will be sent back to A= dam. =0A =0A Consider the situation, when Bob=A2s friends an= swer the call at all the three locations at the same time, what will happen= ? Either three media channel will be established between them or which two = will be discarded.=0A =0A Can anyone please clear this?=0A = =0A With regards=0A Raj.=0A=0A =0A---------------------------------=0AEv= eryone is raving about the all-new Yahoo! Mail beta.=0A____________________= ___________________________=0ASip-implementors mailing list=0ASip-implement= ors@cs.columbia.edu=0Ahttps://lists.cs.columbia.edu/cucslists/listinfo/sip-= implementors=0A=0A=0A=0A=0A=0A=0A=0A=09=09=0A______________________________= ____________________________=0AYahoo! India Answers: Share what you know. L= earn something new=0Ahttp://in.answers.yahoo.com/ --0-1346572428-1164777003=:75290 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hi Raj,

This scenario can happen only in cas= e of parallel forking. I don't beleive that all the 2xx responces will reac= h the server at the same tume. If it so then i think the server will forwar= d the 2xx response on some priority basis.

/Sree

--= --- Original Message ----
From: Raj <ponrajit@yahoo.com>
To: SI= P forum <sip@vovida.org>; sip@ietf.org; sip-implementors@cs.columbia.= edu
Sent: Tuesday, 28 November, 2006 10:47:02 PM
Subject: [Sip-implem= entors] Forking INVITE SIP message - regarding

Hello,
 = ; 
  Consider the following situation.
  
           &nbs= p;  Adam wants to call Bob, let=A2s say that Bob is registered at= three locations, that is, at home, at head office and at his branch office= . Hence, when Adam makes a call, INVITE request is forked by the proxy and = it reaches all the three destinations. Hence, three 200 OK SIP response wil= l be sent back to Adam.
  
     =          Consider the situatio= n, when Bob=A2s friends answer the call at all the three locations at the s= ame time, what will happen? Either three media channel will be established = between them or which two will be discarded.
  
 &nbs= p;            C= an anyone please clear this?
  
  With regards  Raj.


---------------------------------
Everyon= e is raving about the all-new Yahoo! Mail beta.
___________________________________= ____________
Sip-implementors mailing list
Sip-implementors@cs.columb= ia.edu
https://lists.cs.columbia.edu/cucslists/list= info/sip-implementors


=0A=09=0A=0A= =09=0A=09=09
=0AFind out what India is talking about on = - Yahoo! Answers India
=0ASend FREE SMS to your friend's mo= bile from Yahoo! Messenger Version 8. Get it NOW= --0-1346572428-1164777003=:75290-- --===============1439008752== 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 --===============1439008752==-- From sip-bounces@ietf.org Fri Dec 01 06:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq73c-0005kv-ID; Fri, 01 Dec 2006 06:59:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gplwg-0006oh-QS for sip@ietf.org; Thu, 30 Nov 2006 08:27:22 -0500 Received: from mtssgway1.multitech.co.in ([202.54.39.98] helo=multitech.co.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gplwc-0004oQ-H4 for sip@ietf.org; Thu, 30 Nov 2006 08:27:22 -0500 Received: (qmail 19363 invoked by uid 507); 30 Nov 2006 13:28:40 -0000 Received: from vinodk@multitech.co.in by mtsslvpngway by uid 504 with qmail-scanner-1.16 (avp: 4.0.2.2. Clear:. Processed in 0.844751 secs); 30 Nov 2006 13:28:40 -0000 Received: from unknown (HELO multitech.co.in) (192.168.10.1) by 0 with SMTP; 30 Nov 2006 13:28:39 -0000 Received: from [192.168.51.151] (Vinod_Kagalkar [192.168.51.151])(authenticated)by multitech.co.in with ESMTP id kAUDfi4K021638; Thu, 30 Nov 2006 19:11:45 +0530 Message-ID: <456EDC22.7040706@multitech.co.in> Date: Thu, 30 Nov 2006 18:56:58 +0530 From: vinodk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raj References: <326330.41992.qm@web52913.mail.yahoo.com> In-Reply-To: <326330.41992.qm@web52913.mail.yahoo.com> X-Synonym: Copied by Synonym (http://www.modulo.ro/synonym) to: archive X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Fri, 01 Dec 2006 06:59:52 -0500 Cc: SIP forum Subject: [Sip] Re: [Sip-implementors] Signalling and media path of 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: , Content-Type: multipart/mixed; boundary="===============0220952633==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0220952633== Content-Type: multipart/alternative; boundary="------------010902020703080000050405" This is a multi-part message in MIME format. --------------010902020703080000050405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Raj, For first problem, I don't think there is any protocol to find out the optimal Media Path. The SDP contact address which they share in INVITE and 200 OK will be used for Media transmission. For second, If you want to send BYE in the same path where your previous packets traversed you should have enabled Record-Route at the proxy servers. Else BYE will go directly to the contact address which came in 200 OK of INVITE(at UAC) and ACK(at UAS). Regards Vinod Kagalkar Senior Project Leader MultiTech Software Systems Bangalore Raj wrote: >Hello, > > Recently I read from an article that signalling path of SIP is different from the path of media. When two end points want to communicate using SIP, the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path? > > Moreover, when the session has to be terminated, SIP enabled end point has to send the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or a different one. I am considering the stateless proxies to be in the network. > > with regards > Raj. > > >--------------------------------- >Everyone is raving about the all-new Yahoo! Mail beta. >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > --------------010902020703080000050405 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Raj,
For first problem, I don't think there is any protocol to find out the optimal Media Path. The SDP contact address which they share in INVITE and 200 OK will be used for Media transmission.

For second, If you want to send BYE in the same path where your previous packets traversed you should have enabled Record-Route at the proxy servers. Else BYE will go directly to the contact address which  came in 200 OK of INVITE(at UAC)  and ACK(at UAS).

Regards
Vinod Kagalkar
Senior Project Leader
MultiTech Software Systems
Bangalore
 

Raj wrote:
Hello,
   
                Recently I read from an article that signalling path of SIP is different from the path of media. When two end points want to communicate using SIP, the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path?
   
               Moreover, when the session has to be terminated, SIP enabled end point has to send the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or  a different one. I am considering the stateless proxies to be in the network.
   
  with regards
  Raj.

 
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
--------------010902020703080000050405-- --===============0220952633== 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 --===============0220952633==-- From sip-bounces@ietf.org Fri Dec 01 07:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq758-0008Oo-NC; Fri, 01 Dec 2006 07:01:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpYZC-000779-Ku for sip@ietf.org; Wed, 29 Nov 2006 18:10:14 -0500 Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpYZ9-0004gF-VR for sip@ietf.org; Wed, 29 Nov 2006 18:10:14 -0500 Received: from smtp1.nec.com.au (unknown [172.31.8.18]) by ns2.nec.com.au (Postfix) with ESMTP id 686843B6B2 for ; Thu, 30 Nov 2006 10:10:05 +1100 (EST) Received: from [147.76.209.173] (unknown [147.76.209.173]) by zeus.neca.nec.com.au (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 940224E400E; Thu, 30 Nov 2006 10:10:03 +1100 (EST) Message-ID: <456E2152.3060202@nec.com.au> Date: Thu, 30 Nov 2006 11:09:54 +1100 From: Warren Crossing User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raj References: <20061129153953.27048.qmail@web52910.mail.yahoo.com> In-Reply-To: <20061129153953.27048.qmail@web52910.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Fri, 01 Dec 2006 07:01:26 -0500 Cc: SIP forum , sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Signalling time - regarding 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 Latency depends on a number of factors Raj, Network speed, Message size, Server processing We are running a broardband based carrier network here with an IMS application server. A typical invite costs about 25kb and takes ~500ms to call setup. Regards, Warren Crossing. Raj wrote: > Hello to all, > > I read an article about Skype and it was stated that it takes 2 to 3 seconds for session establishment. Can anyone tell me how long will it take for SIP for session establishment? > > with regards > Raj > > > --------------------------------- > Want to start your own business? Learn how on Yahoo! Small Business. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 01 07:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq768-0000vF-DY; Fri, 01 Dec 2006 07:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPz5-0007qQ-5S for sip@ietf.org; Wed, 29 Nov 2006 09:00:23 -0500 Received: from egress-del1.induslogic.com ([221.134.71.171] helo=ex1-del1.synapse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPyu-0007jf-Tf for sip@ietf.org; Wed, 29 Nov 2006 09:00:23 -0500 Received: from ex1-del1.synapse.com ([192.168.0.74]) by ex1-del1.synapse.com with InterScan Message Security Suite; Wed, 29 Nov 2006 19:30:41 +0530 Received: from [172.16.45.106] ([172.16.45.106]) by ex1-del1.synapse.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 19:30:41 +0530 Message-ID: <456E4FD6.7010206@globallogic.com> Date: Wed, 29 Nov 2006 19:28:22 -0800 From: Vivek Gupta User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Raj References: <326330.41992.qm@web52913.mail.yahoo.com> In-Reply-To: <326330.41992.qm@web52913.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2006 14:00:41.0655 (UTC) FILETIME=[C19FFC70:01C713BE] X-imss-version: 2.044 X-imss-result: Passed X-imss-approveListMatch: *@globallogic.com X-Spam-Score: 2.4 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Fri, 01 Dec 2006 07:02:29 -0500 Cc: SIP forum Subject: [Sip] Re: [Sip-implementors] Signalling and media path of 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 SDP (session description protocol) information carried in the message body of the SIP messages(usually INVITE and its 200 OK response) exchanged b/w the two endpoints, explains the terminal capabilities of an endpoint to its peer. This SDP also includes the IP address and UDP port that will be used for the media packet flow. So once the signaling is through, flow of media packets is end to end. Once the dialog is established, two endpoints communicate directly through the URI received in the contact headers. Hence, the bye request is sent directly end to end bypassing any proxy. Raj wrote: > Hello, > > Recently I read from an article that signalling path of SIP is different from the path of media. When two end points want to communicate using SIP, the signalling takes place according to the operation of SIP, but once the signalling is over and when the media channel has to be established, which protocol is used to find the optimal media path? > > Moreover, when the session has to be terminated, SIP enabled end point has to send the BYE request, in this case, whether it takes the same path of INVITE request(which initiated the session) or a different one. I am considering the stateless proxies to be in the network. > > with regards > Raj. > > > --------------------------------- > Everyone is raving about the all-new Yahoo! Mail beta. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- Noida Office Vivek Gupta Lead Technology Globallogic The Leader in Outsourced Product Development B-34/1, Sector 59 Noida, UP, 201301 Phone: +91-120-4342965 Fax: +91-120-2585721 vivek.gupta@globallogic.com www.globallogic.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 Dec 01 07:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GP-0005dC-BU; Fri, 01 Dec 2006 07:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7GN-0005cV-Pq for sip@ietf.org; Fri, 01 Dec 2006 07:13:07 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq7GN-0002tk-04 for sip@ietf.org; Fri, 01 Dec 2006 07:13:07 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kB1CCqAg004440; Fri, 1 Dec 2006 14:12:54 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:12:27 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:12:25 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 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: issue with oubound and the used transport protocol Date: Fri, 1 Dec 2006 14:12:25 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F019756C1@esebe103.NOE.Nokia.com> In-Reply-To: <953beacc0611291030r7b072b6mecfabb28a24245ec@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccT7WMs5WR4wOAPTVycPcIXZ6pf1wBS4ALA From: To: X-OriginalArrivalTime: 01 Dec 2006 12:12:25.0739 (UTC) FILETIME=[F6955DB0:01C71541] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061201141255-1132DBB0-65C0B4BA/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: sip@ietf.org, rohan@ekabal.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, You asked me to clarify my CRLF proposal, so I try to do it here. I have been exploring ways of rescoping drafts related to Outbound and simplifying the mechanisms within them since the limitations of using UDP flows became apparent in this thread. I could vote for a number of different approaches and would be happy the WG to agree with at least one of them. Those approaches in my=20 preference order are: 1. Outbound draft to re-scope itself to "Outbound TCP connection" draft without any support to UDP, STUN or multiple registrations. Multiple registrations and mid-dialog failover (using either TCP or UDP) to be specified within another draft. - This proposal as such did not raise any discussion=20 on the list, probably because it would be a dramatic change at a quite late stage of the draft. - Remarkable changes needed (but I already outlined the "Outbound TCP connection" draft within my earlier mail :). http://www1.ietf.org/mail-archive/web/sip/current/msg17495.html 2. Outbound draft to replace STUN keepalive over TCP with CRLF keepalive over TCP. (No impact to UDP support of Outbound) - This option is equivalent to your formulation, which I can very much agree on: > Clearly you are suggesting that we make CRLF mandatory to implement > for TCP. There would be no longer any need to do STUN over TCP and > therefore no need implement code to deal with stream-based demuxing. > The text about sigcomp over TCP and STUN over TLS over TCP could > also go away. - Some WG members already expressed their support for this option - Minor changes needed to the draft 3. Outbound draft to introduce a third optional keepalive method for TCP: CRLF (in addition to STUN and TCP keepalives) - This option would be the _last resort_ to get at least some benefit for TCP-based UA implementation, even if it would not help the proxies. Proxies would still have to support STUN over TCP.=20 - Minimal changes needed to the draft > To clarify are you suggesting that an edge proxy can implement > outbound without support for UDP flow tokens, without support for STUN > keepalives over UDP, both, or neither? My proposals were born "UA centric" as I am from the UA vendor camp. Anyway if Outbound will specify both UDP and TCP as transport options, I would believe the proxies still have to support both since the selection of the transport is basically an UA decision (even if assisted by DNS SRV) as it depends on if the proxy URI configured to the UA has a transport parameter. If the proxy would not support=20 UDP & STUN, how could it tell it to the UA ? Outbound would at=20 least need a mechanism for that e.g. a specific response code,=20 option tag or something else. Or is this yet another thing where Outbound would rely on the UA and DNS configuration to tell the UA to avoid using UDP ? Considering the option to drop UDP & STUN support from Outbound draft: I would agree that combination of UDP and STUN keepalives does not seem to provide a practical way for NAT traversal. Keeping UDP flows alive with STUN seems not to add value in comparison to persistent TCP flows and I could agree dropping UDP flows from the draft. The only problem I see here that Outbound covers also the multiregistration mechanism, which could still be useful with UDP e.g. in cellular access context without NAT/FWs. That is why I have been proposing re-scoping of the drafts: - Flow keepalive mechanisms to be specified only for TCP (one draft) - Protocol agnostic multiregistration mechanism with mid-dialog failover support (another draft) Regards, Erkki > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com] > Sent: 29 November, 2006 20:30 > To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > Cc: sip@ietf.org; rohan@ekabal.com > Subject: Re: [Sip] Re: issue with oubound and the used transport > protocol >=20 >=20 > Hi Erkki, >=20 > Clearly you are suggesting that we make CRLF mandatory to implement > for TCP. There would be no longer any need to do STUN over TCP and > therefore no need implement code to deal with stream-based demuxing. > The text about sigcomp over TCP and STUN over TLS over TCP could > also go away. >=20 > To clarify are you suggesting that an edge proxy can implement > outbound without support for UDP flow tokens, without support for STUN > keepalives over UDP, both, or neither? >=20 > thanks, > -rohan >=20 > On 11/29/06, Erkki.Koivusalo@nokia.com=20 > wrote: > > > > Hi, > > > > >about STUN keepalive usage and discovery, since double=20 > CRLF is fully > > >backwards compatible with even RFC 2543 implementations. I am > > >bringing this up on the list because I hope the WG can look back on > > >this and not make the mistake of snowballing complexity to preserve > > >UDP parity again in the future. > > > > Rohan is making a valid point here and I believe in Outbound there > > is still room for change to cater for CRLF keepalives as an option > > to STUN keepalives over TCP. > > > > I am calling the WG to look back on the keepalive decision made > > earlier for TCP and proposing that Outbound should also cover > > CRLF keepalive option. > > > > Reasons for this proposal: > > > > >The problem I see is that we have two separate communities=20 > using the > > >outbound draft: > > > > > >1) folks that want to get through NATs and Firewalls in the public > > >Internet at large - they want to use TCP and TLS with=20 > double CRLF for > > >keepalives. One "flow" is always one connection. The milestone for > > >this would read "Make TCP and TLS work in the Internet". > > > > I agree with the intents of this community. However this is not what > > the current Outbound provides. Outbound specifies two options for > > keepalives for reliable connections: TCP keepalive and STUN. > > > > These options were agreed in IETF 65, a cite from the minutes: > > > > Proposal: > > Do STUN for TCP and UDP > > Do CRLF for TCP and STUN for UDP > > TCP KeepAlive if supported, 1 or 2 otherwise > > > > Resolutions: > > OS TCP KeepAlive should be used if the client supports it. > > Need something more because OS TCP KeepAlive is not supported in > > every > > client OS. > > Consensus to use STUN for UDP > > Consensus to use STUN for TCP, with use of OS TCP keep=20 > alive above. > > > > In that meeting the basic assumption was that every Outbound > > compliant client should implement both UDP and TCP even if that > > is not explicitely mentioned in the draft. However latest -06 > > version now makes that debatable by stating: > > > > Use of outbound with UDP flows typically prevents messages larger > > than 1300 bytes from being delivered using TCP as described in > > Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP > > flows in environments where requests are expected to be=20 > larger than > > this size is therefore NOT RECOMMENDED. > > > > In practice this seems to justify implementing "TCP only" UAs > > what comes to the Outbound support. In that case the basic=20 > assumption > > with STUN keepalive (implement it for TCP as it is anyway needed for > > UDP as well) would become obsolete. For implementations which can > > not use TCP keepalive, CRLF would obviously provide a great benefit > > without significant increase of complexity to Outbound. > > > > > > P.S. Last week I made a proposal for "stripped Outbound" without > > UDP, STUN keepalives and multiple registrations. As that proposal > > did not receive any comments, I decided to propose this minimal > > addition to Outbound as an alternative that might be a bit easier > > to accept but still achieve some of the benefits. > > > > 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 > > >=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 Dec 01 08:37:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8YD-000707-Rz; Fri, 01 Dec 2006 08:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8YB-0006zz-Ux for sip@ietf.org; Fri, 01 Dec 2006 08:35:35 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq8Y6-0000OJ-EW for sip@ietf.org; Fri, 01 Dec 2006 08:35:35 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B831A98; Fri, 1 Dec 2006 14:35: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, 1 Dec 2006 14:35: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] Re: issue with oubound and the used transport protocol Date: Fri, 1 Dec 2006 14:35:21 +0100 Message-ID: <7374777208BDC7449D5620EF94232567B5E5EC@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E37A0FF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Kevin Johns" , "Fredrik Thulin" X-OriginalArrivalTime: 01 Dec 2006 13:35:23.0311 (UTC) FILETIME=[8D7293F0:01C7154D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org, rohan@ekabal.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 >My point was that the keep-alive didn't matter since any=20 >option will work, and you don't need one in the first place=20 >because the UDP/IPsec already has one. Exactly. So, do we really need to specify what other keepalive mechanisms than STUN can be used then? Can't we simply say that one shall use STUN unless another mechanism is provided by the transport/security layer? >But it just occured to me... I'm thinking VPN, and you are=20 >probably thinking 3GPP. And I don't know anything about how=20 >that works. :-) I was thinking 3GPP, yes :) Regards, Christer =20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, November 30, 2006 13:49 > > To: Audet, Francois (SC100:3055); Kevin Johns; Fredrik Thulin > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > >=20 > > Hi, > >=20 > > >I would think that UDP encapsulated IPsec would have it's own=20 > > >keep-alive. > > >So they wouldn't need Outbound in the first place. > >=20 > > They may want to use outbound in order to support multiple=20 > simultanous=20 > > registrations. > >=20 > > So, if there would also be NATs, the question is what=20 > keep-alive they=20 > > should use. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > >=20 > > > But even if they didn't then the CRLF thing would still work. > > >=20 > > > > -----Original Message----- > > > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > > > Sent: Thursday, November 30, 2006 12:47 > > > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > > > Cc: sip@ietf.org; rohan@ekabal.com > > > > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport=20 > > > > protocol > > > >=20 > > > > Not all architectures use TLS/TCP, some use UDP > > encapsulated IPsec. > > > > Would a TCP session via UDP encapsulated IPsec be impacted > > > by this? I > > > > do not think it would, but just wanted to double check... > > > >=20 > > > > Kevin > > > >=20 > > > > -----Original Message----- > > > > From: Fredrik Thulin [mailto:ft@it.su.se] > > > > Sent: Thursday, November 30, 2006 11:21 AM > > > > To: Francois Audet > > > > Cc: sip@ietf.org; rohan@ekabal.com > > > > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport=20 > > > > protocol > > > >=20 > > > > Francois Audet wrote: > > > > > Didn't we agree way back NOT to use PING, CRLF, etc., and > > > use STUN > > > > > instead? > > > > >=20 > > > > > Why is this debate being re-opened? > > > >=20 > > > > Because it seems more and more (to me at least) that > > > Outbound with UDP > > > > will just suck. > > > >=20 > > > > If Outbound UA's have to get their act together and > > > implement TLS/TCP, > > > > then we can simplify Outbound even further by skipping the > > > whole STUN > > > > keepalive thing, and go with CRLF over TLS/TCP. > > > >=20 > > > > I am very much in favor of cutting both UDP and STUN > > > keepalives out of > > > > Outbound. I think that would lead to faster deployment, and > > > also make > > > > the world a better place by eliminating some SIP over UDP. > > > >=20 > > > > /Fredrik > > > >=20 > > > > PS. By the way, when people say CRLF keepalives, do you > > > mean CRLF sent > > > > only from the UA, or CRLF from UA to edge proxy followed > > by CRLF in > > > > the reverse direction too? > > > >=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=20 > current sip Use=20 > > > > 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=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 >=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 Dec 01 08:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8qx-0001ZP-9d; Fri, 01 Dec 2006 08:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8qv-0001Vh-7W for sip@ietf.org; Fri, 01 Dec 2006 08:54:57 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq8qp-0004Bo-Sd for sip@ietf.org; Fri, 01 Dec 2006 08:54:57 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 564381020; Fri, 1 Dec 2006 14:54:22 +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, 1 Dec 2006 14:54: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: [Sip] Re: issue with oubound and the used transport protocol - decide whether to send keep-alive in the first place Date: Fri, 1 Dec 2006 14:54:21 +0100 Message-ID: <7374777208BDC7449D5620EF94232567B5E6C1@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567B5E5EC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol - decide whether to send keep-alive in the first place Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPAAEHJUMA== From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Kevin Johns" , "Fredrik Thulin" X-OriginalArrivalTime: 01 Dec 2006 13:54:22.0269 (UTC) FILETIME=[3451C6D0:01C71550] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, rohan@ekabal.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, No matter how we do the keep-alive, I think STUN is a good tool for the UA to figure out whether it's located behind a NAT in the first place, by checking the XMA value etc. Again, outbound can be used also in no-NAT scenarios, so the UA can use the STUN response information to decide whether it needs to send keep-alives in the first place. 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 Dec 01 09:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9Hg-0001Ps-3n; Fri, 01 Dec 2006 09:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9He-0001Pk-Vx for sip@ietf.org; Fri, 01 Dec 2006 09:22:34 -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 1Gq9Hc-0000FB-J5 for sip@ietf.org; Fri, 01 Dec 2006 09:22:34 -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 kB1EM8Ci010478; Fri, 1 Dec 2006 16:22:27 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 16:22:23 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Dec 2006 16:22:23 +0200 Message-ID: <45703AA0.20007@nokia.com> Date: Fri, 01 Dec 2006 16:22:24 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> In-Reply-To: <456E15CD.60805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 14:22:23.0115 (UTC) FILETIME=[1E2E85B0:01C71554] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061201162227-28B1BBB0-117CD105/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: SIP IETF 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 For issue 3, I would say that the solution is to avoid the situation, e.g., by registering way in advance before the registration expires. Doesn't RFC 3261 recommends to re-register half time before the registration timer expires. Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the GRUU draft have a recommendation on the usage of the reg event to solve them? /Miguel Paul Kyzivat wrote: > After some study, I have encountered a potential difficulty in > determining when temp-gruus expire. After discussing this with Jonathan > we decided to bring it to the list for discussion. > > As now defined, when you first register you may get a temp-gruu, which > will remain valid as long as the registration does not expire or be > removed. (Removal is a special case of expiration.) Each time the UA > refreshes the registration it may get a new temp-gruu which also remains > valid for the life of the registration. The UA can accumulate all these > temp-gruus and use them as it sees fit until they expire. > > The problem is: how does the UA know when the registration has ended and > the temp-gruus associated with it rendered invalid? > > This seems like a simple question, and in some cases it is simple, but > not in all cases. The following are at least some of the ways that the > registration can be ended, causing the invalidation of temp-gruus: > 1) the UA that originally registered may explicitly deregister > 2) the UA the originally registered may simply permit the > registration to expire without attempting to refresh it > 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 > > In each of these cases the previously assigned temp-gruus become > invalid. If the UA continues to use them, bad things will happen. This > is true both for calls that are active when the deregistration occurs, > and calls that are established later. What kinds of bad things happen? > - requests addressed to the gruu, both in-dialog and out-of-dialog > will be undeliverable. (For instance a reINVITE or BYE in an > existing call, or an out-of-dialog INVITE/Replaces for a transfer.) > > - request originated by the UA using the invalid gruu will fail > immediately because the gruu is invalid. > > - if the UA subsequently reregisters, receives an incoming call, and > uses one of the old temp-gruus as its contact, then the call will > be established, but subsequent in- and out-of-dialog requests to > the contact will fail. > > So clearly it is important for the UA to stop using temp-gruus that have > become invalid. How can it know to do that in all of the above cases? > > 1) is straightforward. The UA knows it is deregistering, and should > discard any cached temp-gruus. If it has a dialog with one of the > temp-gruus as a contact, then it should do a target refresh and > supply some working contact. (It really should do this *before* > deregistering, and for a pub-gruu as well.) > > 2) the UA should take all the actions mentioned for (1) at or before > the expiration time. This should be done a bit early to guard > against clock skew problems. > > 3) in this case, it may be impossible for the UA to know whether > the REGISTER arrived in time to be a reREGISTER or if it arrived > late and was treated as a new REGISTER after the expiration of > the old one. (The response to the REGISTER includes nothing that > distinguishes the two cases.) About the best that can be done in > this case is to check the time at which the response to the > REGISTER is received. If it falls after the expected expiration > time for the registration, act as if the old registration had > expired. > > 4) This is a major problem. Of course, regardless of GRUU, the UA > won't be able to receive incoming calls until it decides it is > time to refresh the registration. In addition, until the > registration reestablished, calls originated with one of its > existing gruus will fail. Once the registration is reestablished, > it still won't know its old temp-gruus are invalid. The only > remedy for this is to subscribe to the "reg" event package, > and use the resulting notifications to identify when it has > been unregistered. If it does that, it can invalidate all its > old temp-gruus, and then presumably reregister. > > 5) this is functionally equivalent to (4), except that perhaps > attempts to reregister may fail. > > 6) this is also functionally equivalent to (4). > > The "reg" event does provide a fairly complete solution to this problem, > for those that are willing and able to use it. It is not however a 100% > reliable solution. Consider case (3), where the UA has a reg event > subscription. All is well if the registration expires and a notification > is sent indicating that, and then the reregistration occurs and a > notification is sent about that. But if they happen very closely in > time, it may be that only one notification is sent, reflecting the > result of the reregistration. In that case the UA will not be aware that > it had been unregistered for a period of time. > > A *complete* solution would, IMO, involve changing REGISTER so that it > returns an indication of whether this was a new registration, or a > refresh. This could take many forms. For instance the timestamp of the > initial registration could always be returned with each contact, as well > as the expiration time. > > The big question is whether this is a big enough issue to require a > solution now, as part of GRUU, or if it can be ignored as insignificant > or postponed to future work. > > I'd appreciate hearing what others think about this. At the moment I am > leaning toward doing nothing, at least for now. > > 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 > -- 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 Dec 01 11:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBDT-0008NE-IH; Fri, 01 Dec 2006 11:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBDR-0008KO-GD for sip@ietf.org; Fri, 01 Dec 2006 11:26:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBDO-0005OZ-Rw for sip@ietf.org; Fri, 01 Dec 2006 11:26:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 08:26:16 -0800 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 kB1GQF69017578; Fri, 1 Dec 2006 11:26:15 -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 kB1GQFDM004000; Fri, 1 Dec 2006 11:26:15 -0500 (EST) 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); Fri, 1 Dec 2006 11:26:15 -0500 Received: from [10.86.241.161] ([10.86.241.161]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:26:14 -0500 Message-ID: <457057A6.4020804@cisco.com> Date: Fri, 01 Dec 2006 11:26:14 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> In-Reply-To: <45703AA0.20007@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 16:26:14.0699 (UTC) FILETIME=[6BC03FB0:01C71565] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7052; t=1164990375; x=1165854375; 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]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20 |To:=20Miguel=20Garcia=20; bh=ArPIyNvqcdjuQIz7IrC/Xhg8yNu7NgRdagKQYHZ+MHs=; b=jPzAVLhIURg/25DTiGAv789SICifiEs5XrLtowcAsYydo1A7zdwZQSAk3N73LA+hEpez58jn 7TO/8UVFdLssrJcbuvYYiwlxFec9YgkmNLnE+oYECLb7BwN1/ZaDTVTR; 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: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: SIP IETF 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 Miguel, So to summarize, it seems you are of the belief that the cases where these measures may be inadequate are sufficiently obscure to ignore, and that new measures to cover the obscure cases are unnecessary. Is that right? Paul Miguel Garcia wrote: > For issue 3, I would say that the solution is to avoid the situation, > e.g., by registering way in advance before the registration expires. > Doesn't RFC 3261 recommends to re-register half time before the > registration timer expires. > > Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the GRUU > draft have a recommendation on the usage of the reg event to solve them? > > /Miguel > > Paul Kyzivat wrote: >> After some study, I have encountered a potential difficulty in >> determining when temp-gruus expire. After discussing this with >> Jonathan we decided to bring it to the list for discussion. >> >> As now defined, when you first register you may get a temp-gruu, which >> will remain valid as long as the registration does not expire or be >> removed. (Removal is a special case of expiration.) Each time the UA >> refreshes the registration it may get a new temp-gruu which also >> remains valid for the life of the registration. The UA can accumulate >> all these temp-gruus and use them as it sees fit until they expire. >> >> The problem is: how does the UA know when the registration has ended >> and the temp-gruus associated with it rendered invalid? >> >> This seems like a simple question, and in some cases it is simple, but >> not in all cases. The following are at least some of the ways that the >> registration can be ended, causing the invalidation of temp-gruus: >> 1) the UA that originally registered may explicitly deregister >> 2) the UA the originally registered may simply permit the >> registration to expire without attempting to refresh it >> 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 >> >> In each of these cases the previously assigned temp-gruus become >> invalid. If the UA continues to use them, bad things will happen. This >> is true both for calls that are active when the deregistration occurs, >> and calls that are established later. What kinds of bad things happen? >> - requests addressed to the gruu, both in-dialog and out-of-dialog >> will be undeliverable. (For instance a reINVITE or BYE in an >> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >> >> - request originated by the UA using the invalid gruu will fail >> immediately because the gruu is invalid. >> >> - if the UA subsequently reregisters, receives an incoming call, and >> uses one of the old temp-gruus as its contact, then the call will >> be established, but subsequent in- and out-of-dialog requests to >> the contact will fail. >> >> So clearly it is important for the UA to stop using temp-gruus that >> have become invalid. How can it know to do that in all of the above >> cases? >> >> 1) is straightforward. The UA knows it is deregistering, and should >> discard any cached temp-gruus. If it has a dialog with one of the >> temp-gruus as a contact, then it should do a target refresh and >> supply some working contact. (It really should do this *before* >> deregistering, and for a pub-gruu as well.) >> >> 2) the UA should take all the actions mentioned for (1) at or before >> the expiration time. This should be done a bit early to guard >> against clock skew problems. >> >> 3) in this case, it may be impossible for the UA to know whether >> the REGISTER arrived in time to be a reREGISTER or if it arrived >> late and was treated as a new REGISTER after the expiration of >> the old one. (The response to the REGISTER includes nothing that >> distinguishes the two cases.) About the best that can be done in >> this case is to check the time at which the response to the >> REGISTER is received. If it falls after the expected expiration >> time for the registration, act as if the old registration had >> expired. >> >> 4) This is a major problem. Of course, regardless of GRUU, the UA >> won't be able to receive incoming calls until it decides it is >> time to refresh the registration. In addition, until the >> registration reestablished, calls originated with one of its >> existing gruus will fail. Once the registration is reestablished, >> it still won't know its old temp-gruus are invalid. The only >> remedy for this is to subscribe to the "reg" event package, >> and use the resulting notifications to identify when it has >> been unregistered. If it does that, it can invalidate all its >> old temp-gruus, and then presumably reregister. >> >> 5) this is functionally equivalent to (4), except that perhaps >> attempts to reregister may fail. >> >> 6) this is also functionally equivalent to (4). >> >> The "reg" event does provide a fairly complete solution to this >> problem, for those that are willing and able to use it. It is not >> however a 100% reliable solution. Consider case (3), where the UA has >> a reg event subscription. All is well if the registration expires and >> a notification is sent indicating that, and then the reregistration >> occurs and a notification is sent about that. But if they happen very >> closely in time, it may be that only one notification is sent, >> reflecting the result of the reregistration. In that case the UA will >> not be aware that it had been unregistered for a period of time. >> >> A *complete* solution would, IMO, involve changing REGISTER so that it >> returns an indication of whether this was a new registration, or a >> refresh. This could take many forms. For instance the timestamp of the >> initial registration could always be returned with each contact, as >> well as the expiration time. >> >> The big question is whether this is a big enough issue to require a >> solution now, as part of GRUU, or if it can be ignored as >> insignificant or postponed to future work. >> >> I'd appreciate hearing what others think about this. At the moment I >> am leaning toward doing nothing, at least for now. >> >> 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 >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 01 13:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDMa-0000n8-91; Fri, 01 Dec 2006 13:43:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDMY-0000my-7p for sip@ietf.org; Fri, 01 Dec 2006 13:43:54 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GqDMW-0007An-LX for sip@ietf.org; Fri, 01 Dec 2006 13:43:54 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB1Iafu17453; Fri, 1 Dec 2006 13:36:41 -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] Re: issue with oubound and the used transport protocol Date: Fri, 1 Dec 2006 12:43:47 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E3DA57B@zrc2hxm0.corp.nortel.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F019756C1@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccT7WMs5WR4wOAPTVycPcIXZ6pf1wBS4ALAAA/ipYA= From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: sip@ietf.org, rohan@ekabal.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 OK with either 1 or 2. The difference is that with 1 we make it obvious that TCP is better. With 2, the reader has to figure it out by himself.=20 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: Friday, December 01, 2006 04:12 > To: rohan.mahy@gmail.com > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > Hi, >=20 > You asked me to clarify my CRLF proposal, so I try to do it here. >=20 > I have been exploring ways of rescoping drafts related to=20 > Outbound and simplifying the mechanisms within them since the=20 > limitations of using UDP flows became apparent in this=20 > thread. I could vote for a number of different approaches and=20 > would be happy the WG to agree with at least one of them.=20 > Those approaches in my preference order are: >=20 > 1. Outbound draft to re-scope itself to "Outbound TCP connection" > draft without any support to UDP, STUN or multiple registrations. > Multiple registrations and mid-dialog failover (using either TCP > or UDP) to be specified within another draft. >=20 > - This proposal as such did not raise any discussion=20 > on the list, probably because it would be a dramatic > change at a quite late stage of the draft. > - Remarkable changes needed (but I already outlined the > "Outbound TCP connection" draft within my earlier mail :). > http://www1.ietf.org/mail-archive/web/sip/current/msg17495.html >=20 > 2. Outbound draft to replace STUN keepalive over TCP with CRLF > keepalive over TCP. (No impact to UDP support of Outbound) >=20 > - This option is equivalent to your formulation, which I > can very much agree on: >=20 > > Clearly you are suggesting that we make CRLF mandatory to implement=20 > > for TCP. There would be no longer any need to do STUN over TCP and=20 > > therefore no need implement code to deal with stream-based demuxing. > > The text about sigcomp over TCP and STUN over TLS over TCP=20 > could also=20 > > go away. >=20 > - Some WG members already expressed their support for this > option > - Minor changes needed to the draft >=20 > 3. Outbound draft to introduce a third optional keepalive method > for TCP: CRLF (in addition to STUN and TCP keepalives) >=20 > - This option would be the _last resort_ to get at least some > benefit for TCP-based UA implementation, even if it would > not help the proxies. Proxies would still have to support > STUN over TCP.=20 > - Minimal changes needed to the draft >=20 >=20 > > To clarify are you suggesting that an edge proxy can implement=20 > > outbound without support for UDP flow tokens, without=20 > support for STUN=20 > > keepalives over UDP, both, or neither? >=20 > My proposals were born "UA centric" as I am from the UA vendor camp. >=20 > Anyway if Outbound will specify both UDP and TCP as transport=20 > options, I would believe the proxies still have to support=20 > both since the selection of the transport is basically an UA=20 > decision (even if assisted by DNS SRV) as it depends on if=20 > the proxy URI configured to the UA has a transport parameter.=20 > If the proxy would not support UDP & STUN, how could it tell=20 > it to the UA ? Outbound would at least need a mechanism for=20 > that e.g. a specific response code, option tag or something=20 > else. Or is this yet another thing where Outbound would rely=20 > on the UA and DNS configuration to tell the UA to avoid using UDP ? >=20 > Considering the option to drop UDP & STUN support from Outbound > draft: I would agree that combination of UDP and STUN=20 > keepalives does not seem to provide a practical way for NAT=20 > traversal. Keeping UDP flows alive with STUN seems not to add=20 > value in comparison to persistent TCP flows and I could agree=20 > dropping UDP flows from the draft. The only problem I see=20 > here that Outbound covers also the multiregistration=20 > mechanism, which could still be useful with UDP e.g. in=20 > cellular access context without NAT/FWs. That is why I have=20 > been proposing re-scoping of the drafts: >=20 > - Flow keepalive mechanisms to be specified only for TCP (one draft) > - Protocol agnostic multiregistration mechanism with mid-dialog > failover support (another draft) >=20 > Regards, >=20 > Erkki >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com] > > Sent: 29 November, 2006 20:30 > > To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) > > Cc: sip@ietf.org; rohan@ekabal.com > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > >=20 > > Hi Erkki, > >=20 > > Clearly you are suggesting that we make CRLF mandatory to implement=20 > > for TCP. There would be no longer any need to do STUN over TCP and=20 > > therefore no need implement code to deal with stream-based demuxing. > > The text about sigcomp over TCP and STUN over TLS over TCP could=20 > > also go away. > >=20 > > To clarify are you suggesting that an edge proxy can implement=20 > > outbound without support for UDP flow tokens, without=20 > support for STUN=20 > > keepalives over UDP, both, or neither? > >=20 > > thanks, > > -rohan > >=20 > > On 11/29/06, Erkki.Koivusalo@nokia.com =20 > > wrote: > > > > > > Hi, > > > > > > >about STUN keepalive usage and discovery, since double > > CRLF is fully > > > >backwards compatible with even RFC 2543 implementations. I am=20 > > > >bringing this up on the list because I hope the WG can=20 > look back on=20 > > > >this and not make the mistake of snowballing complexity=20 > to preserve=20 > > > >UDP parity again in the future. > > > > > > Rohan is making a valid point here and I believe in=20 > Outbound there=20 > > > is still room for change to cater for CRLF keepalives as=20 > an option=20 > > > to STUN keepalives over TCP. > > > > > > I am calling the WG to look back on the keepalive decision made=20 > > > earlier for TCP and proposing that Outbound should also=20 > cover CRLF=20 > > > keepalive option. > > > > > > Reasons for this proposal: > > > > > > >The problem I see is that we have two separate communities > > using the > > > >outbound draft: > > > > > > > >1) folks that want to get through NATs and Firewalls in=20 > the public=20 > > > >Internet at large - they want to use TCP and TLS with > > double CRLF for > > > >keepalives. One "flow" is always one connection. The=20 > milestone for=20 > > > >this would read "Make TCP and TLS work in the Internet". > > > > > > I agree with the intents of this community. However this=20 > is not what=20 > > > the current Outbound provides. Outbound specifies two options for=20 > > > keepalives for reliable connections: TCP keepalive and STUN. > > > > > > These options were agreed in IETF 65, a cite from the minutes: > > > > > > Proposal: > > > Do STUN for TCP and UDP > > > Do CRLF for TCP and STUN for UDP > > > TCP KeepAlive if supported, 1 or 2 otherwise > > > > > > Resolutions: > > > OS TCP KeepAlive should be used if the client supports it. > > > Need something more because OS TCP KeepAlive is not=20 > supported in=20 > > > every > > > client OS. > > > Consensus to use STUN for UDP > > > Consensus to use STUN for TCP, with use of OS TCP keep > > alive above. > > > > > > In that meeting the basic assumption was that every Outbound=20 > > > compliant client should implement both UDP and TCP even=20 > if that is=20 > > > not explicitely mentioned in the draft. However latest=20 > -06 version=20 > > > now makes that debatable by stating: > > > > > > Use of outbound with UDP flows typically prevents=20 > messages larger > > > than 1300 bytes from being delivered using TCP as described in > > > Section 18.1.1 RFC 3261. Use of outbound in=20 > conjunction with UDP > > > flows in environments where requests are expected to be > > larger than > > > this size is therefore NOT RECOMMENDED. > > > > > > In practice this seems to justify implementing "TCP only"=20 > UAs what=20 > > > comes to the Outbound support. In that case the basic > > assumption > > > with STUN keepalive (implement it for TCP as it is anyway=20 > needed for=20 > > > UDP as well) would become obsolete. For implementations which can=20 > > > not use TCP keepalive, CRLF would obviously provide a=20 > great benefit=20 > > > without significant increase of complexity to Outbound. > > > > > > > > > P.S. Last week I made a proposal for "stripped Outbound" without=20 > > > UDP, STUN keepalives and multiple registrations. As that proposal=20 > > > did not receive any comments, I decided to propose this minimal=20 > > > addition to Outbound as an alternative that might be a=20 > bit easier to=20 > > > accept but still achieve some of the benefits. > > > > > > Regards, > > > > > > Erkki > > > > > > _______________________________________________ > > > 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=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 Dec 01 13:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDL4-000738-5n; Fri, 01 Dec 2006 13:42:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDL2-0006z2-JO for sip@ietf.org; Fri, 01 Dec 2006 13:42:20 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDL1-0002pk-6t for sip@ietf.org; Fri, 01 Dec 2006 13:42:20 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB1IgDX10529; Fri, 1 Dec 2006 13:42:14 -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] Re: issue with oubound and the used transport protocol Date: Fri, 1 Dec 2006 12:42:02 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E3DA572@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF94232567B5E5EC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPAAGoz9MA== From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Kevin Johns" , "Fredrik Thulin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: sip@ietf.org, rohan@ekabal.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 think we are in violent agreement. I'm not even sure we need to say anything here. Seems to me it's a 3GPP-specific non-issue...=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, December 01, 2006 05:35 > To: Audet, Francois (SC100:3055); Kevin Johns; Fredrik Thulin > Cc: sip@ietf.org; rohan@ekabal.com > Subject: RE: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > Hi,=20 >=20 > >My point was that the keep-alive didn't matter since any option will=20 > >work, and you don't need one in the first place because the=20 > UDP/IPsec=20 > >already has one. >=20 > Exactly. >=20 > So, do we really need to specify what other keepalive=20 > mechanisms than STUN can be used then? Can't we simply say=20 > that one shall use STUN unless another mechanism is provided=20 > by the transport/security layer? >=20 > >But it just occured to me... I'm thinking VPN, and you are probably=20 > >thinking 3GPP. And I don't know anything about how that works. :-) >=20 > I was thinking 3GPP, yes :) >=20 > Regards, >=20 > Christer >=20 >=20 > =20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, November 30, 2006 13:49 > > > To: Audet, Francois (SC100:3055); Kevin Johns; Fredrik Thulin > > > Cc: sip@ietf.org; rohan@ekabal.com > > > Subject: RE: [Sip] Re: issue with oubound and the used transport=20 > > > protocol > > >=20 > > >=20 > > > Hi, > > >=20 > > > >I would think that UDP encapsulated IPsec would have it's own=20 > > > >keep-alive. > > > >So they wouldn't need Outbound in the first place. > > >=20 > > > They may want to use outbound in order to support multiple > > simultanous > > > registrations. > > >=20 > > > So, if there would also be NATs, the question is what > > keep-alive they > > > should use. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > >=20 > > > > But even if they didn't then the CRLF thing would still work. > > > >=20 > > > > > -----Original Message----- > > > > > From: Kevin Johns [mailto:K.Johns@CableLabs.com] > > > > > Sent: Thursday, November 30, 2006 12:47 > > > > > To: Fredrik Thulin; Audet, Francois (SC100:3055) > > > > > Cc: sip@ietf.org; rohan@ekabal.com > > > > > Subject: RE: [Sip] Re: issue with oubound and the used > > transport > > > > > protocol > > > > >=20 > > > > > Not all architectures use TLS/TCP, some use UDP > > > encapsulated IPsec. > > > > > Would a TCP session via UDP encapsulated IPsec be impacted > > > > by this? I > > > > > do not think it would, but just wanted to double check... > > > > >=20 > > > > > Kevin > > > > >=20 > > > > > -----Original Message----- > > > > > From: Fredrik Thulin [mailto:ft@it.su.se] > > > > > Sent: Thursday, November 30, 2006 11:21 AM > > > > > To: Francois Audet > > > > > Cc: sip@ietf.org; rohan@ekabal.com > > > > > Subject: Re: [Sip] Re: issue with oubound and the used > > transport > > > > > protocol > > > > >=20 > > > > > Francois Audet wrote: > > > > > > Didn't we agree way back NOT to use PING, CRLF, etc., and > > > > use STUN > > > > > > instead? > > > > > >=20 > > > > > > Why is this debate being re-opened? > > > > >=20 > > > > > Because it seems more and more (to me at least) that > > > > Outbound with UDP > > > > > will just suck. > > > > >=20 > > > > > If Outbound UA's have to get their act together and > > > > implement TLS/TCP, > > > > > then we can simplify Outbound even further by skipping the > > > > whole STUN > > > > > keepalive thing, and go with CRLF over TLS/TCP. > > > > >=20 > > > > > I am very much in favor of cutting both UDP and STUN > > > > keepalives out of > > > > > Outbound. I think that would lead to faster deployment, and > > > > also make > > > > > the world a better place by eliminating some SIP over UDP. > > > > >=20 > > > > > /Fredrik > > > > >=20 > > > > > PS. By the way, when people say CRLF keepalives, do you > > > > mean CRLF sent > > > > > only from the UA, or CRLF from UA to edge proxy followed > > > by CRLF in > > > > > the reverse direction too? > > > > >=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 Use > > > > > sipping@ietf.org for new developments on the=20 > 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=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=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 From sip-bounces@ietf.org Fri Dec 01 14:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDk3-00052r-9N; Fri, 01 Dec 2006 14:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDk0-00050s-QA for sip@ietf.org; Fri, 01 Dec 2006 14:08:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDjy-0003q7-2U for sip@ietf.org; Fri, 01 Dec 2006 14:08:08 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 11:08:05 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1J850v006440; Fri, 1 Dec 2006 11:08:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB1J80ix026404; Fri, 1 Dec 2006 11:08:05 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:08:01 -0800 Received: from [10.32.241.153] ([10.32.241.153]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:08:00 -0800 Message-ID: <45707D8A.8020001@cisco.com> Date: Fri, 01 Dec 2006 14:07:54 -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: Paul Kyzivat Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com> In-Reply-To: <457057A6.4020804@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 19:08:01.0078 (UTC) FILETIME=[05342560:01C7157C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8906; t=1165000085; x=1165864085; c=relaxed/simple; s=sjdkim1002; 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=Q+Gf5gt/Lc2JxfmDsvyPzrKmiLInjtErKqm+v9AbhDQ=; b=U42uI6zzjMa6aw/vkc30jG+vfob3ExjFL1b4OdF58D6fenL348ZXBMdywho430sSVZ/YiAwd J1paqTtrrUBrW+ui3NqZXRtkeLtduhFTfu2qPsXuR1UXIQDUYCX98M4Y; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Miguel Garcia , SIP IETF 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 main question is really to decide on one of two mechanisms: 1. use reg-event if you are worried about use cases where this race condition can occur (4-6 in Paul's original email) 2. add a parameter to Contact in the register response. Specifically, I'd recommend a Contact header field parameter which indicates the time at which the first contact with a given instance ID was registered to that AOR. This value gets linked with each temp gruu, and when the value changes, all of those temp-gruu get invalidated. Solution (2) is much simpler, but not needed if you think you'll always have reg-event anyway. I don't think there is widespread support for reg-event on endpoints yet. It is required by IMS. I am somewhat on the fence on this one. I do worry that reg-event is genreally a very heavy solution, and may not see much usage. Option 2 is really trivially done, either in gruu or elsewhere. The main issue is that it is another late change. -JOnathan R. Paul Kyzivat wrote: > Miguel, > > So to summarize, it seems you are of the belief that the cases where > these measures may be inadequate are sufficiently obscure to ignore, and > that new measures to cover the obscure cases are unnecessary. Is that > right? > > Paul > > Miguel Garcia wrote: > >> For issue 3, I would say that the solution is to avoid the situation, >> e.g., by registering way in advance before the registration expires. >> Doesn't RFC 3261 recommends to re-register half time before the >> registration timer expires. >> >> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the GRUU >> draft have a recommendation on the usage of the reg event to solve them? >> >> /Miguel >> >> Paul Kyzivat wrote: >> >>> After some study, I have encountered a potential difficulty in >>> determining when temp-gruus expire. After discussing this with >>> Jonathan we decided to bring it to the list for discussion. >>> >>> As now defined, when you first register you may get a temp-gruu, >>> which will remain valid as long as the registration does not expire >>> or be removed. (Removal is a special case of expiration.) Each time >>> the UA refreshes the registration it may get a new temp-gruu which >>> also remains valid for the life of the registration. The UA can >>> accumulate all these temp-gruus and use them as it sees fit until >>> they expire. >>> >>> The problem is: how does the UA know when the registration has ended >>> and the temp-gruus associated with it rendered invalid? >>> >>> This seems like a simple question, and in some cases it is simple, >>> but not in all cases. The following are at least some of the ways >>> that the registration can be ended, causing the invalidation of >>> temp-gruus: >>> 1) the UA that originally registered may explicitly deregister >>> 2) the UA the originally registered may simply permit the >>> registration to expire without attempting to refresh it >>> 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 >>> >>> In each of these cases the previously assigned temp-gruus become >>> invalid. If the UA continues to use them, bad things will happen. >>> This is true both for calls that are active when the deregistration >>> occurs, and calls that are established later. What kinds of bad >>> things happen? >>> - requests addressed to the gruu, both in-dialog and out-of-dialog >>> will be undeliverable. (For instance a reINVITE or BYE in an >>> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >>> >>> - request originated by the UA using the invalid gruu will fail >>> immediately because the gruu is invalid. >>> >>> - if the UA subsequently reregisters, receives an incoming call, and >>> uses one of the old temp-gruus as its contact, then the call will >>> be established, but subsequent in- and out-of-dialog requests to >>> the contact will fail. >>> >>> So clearly it is important for the UA to stop using temp-gruus that >>> have become invalid. How can it know to do that in all of the above >>> cases? >>> >>> 1) is straightforward. The UA knows it is deregistering, and should >>> discard any cached temp-gruus. If it has a dialog with one of the >>> temp-gruus as a contact, then it should do a target refresh and >>> supply some working contact. (It really should do this *before* >>> deregistering, and for a pub-gruu as well.) >>> >>> 2) the UA should take all the actions mentioned for (1) at or before >>> the expiration time. This should be done a bit early to guard >>> against clock skew problems. >>> >>> 3) in this case, it may be impossible for the UA to know whether >>> the REGISTER arrived in time to be a reREGISTER or if it arrived >>> late and was treated as a new REGISTER after the expiration of >>> the old one. (The response to the REGISTER includes nothing that >>> distinguishes the two cases.) About the best that can be done in >>> this case is to check the time at which the response to the >>> REGISTER is received. If it falls after the expected expiration >>> time for the registration, act as if the old registration had >>> expired. >>> >>> 4) This is a major problem. Of course, regardless of GRUU, the UA >>> won't be able to receive incoming calls until it decides it is >>> time to refresh the registration. In addition, until the >>> registration reestablished, calls originated with one of its >>> existing gruus will fail. Once the registration is reestablished, >>> it still won't know its old temp-gruus are invalid. The only >>> remedy for this is to subscribe to the "reg" event package, >>> and use the resulting notifications to identify when it has >>> been unregistered. If it does that, it can invalidate all its >>> old temp-gruus, and then presumably reregister. >>> >>> 5) this is functionally equivalent to (4), except that perhaps >>> attempts to reregister may fail. >>> >>> 6) this is also functionally equivalent to (4). >>> >>> The "reg" event does provide a fairly complete solution to this >>> problem, for those that are willing and able to use it. It is not >>> however a 100% reliable solution. Consider case (3), where the UA has >>> a reg event subscription. All is well if the registration expires and >>> a notification is sent indicating that, and then the reregistration >>> occurs and a notification is sent about that. But if they happen very >>> closely in time, it may be that only one notification is sent, >>> reflecting the result of the reregistration. In that case the UA will >>> not be aware that it had been unregistered for a period of time. >>> >>> A *complete* solution would, IMO, involve changing REGISTER so that >>> it returns an indication of whether this was a new registration, or a >>> refresh. This could take many forms. For instance the timestamp of >>> the initial registration could always be returned with each contact, >>> as well as the expiration time. >>> >>> The big question is whether this is a big enough issue to require a >>> solution now, as part of GRUU, or if it can be ignored as >>> insignificant or postponed to future work. >>> >>> I'd appreciate hearing what others think about this. At the moment I >>> am leaning toward doing nothing, at least for now. >>> >>> 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 >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- 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 Fri Dec 01 19:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqIoM-00087Q-AL; Fri, 01 Dec 2006 19:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqIoL-000827-09 for sip@ietf.org; Fri, 01 Dec 2006 19:32:57 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqIoJ-0006By-KC for sip@ietf.org; Fri, 01 Dec 2006 19:32:56 -0500 Received: by ug-out-1314.google.com with SMTP id 72so2240416ugd for ; Fri, 01 Dec 2006 16:32:54 -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=IcbjMScNpKI/rIymYbAoSwDeHl3JSRTAToFj8oYtalxq4N9iye1pdBrdr1czo/76Avy8rvHB+xemUfS0HGXDf1TFPGOCypp1A3RyXUAyF0j3JNZuofI/dA3kqXNTu9PdW3ayYjow6OIVHZ5A25Bsgdb1dBp8vW3agqn0Br1255k= Received: by 10.78.128.15 with SMTP id a15mr5491138hud.1165019574340; Fri, 01 Dec 2006 16:32:54 -0800 (PST) Received: by 10.78.120.15 with HTTP; Fri, 1 Dec 2006 16:32:54 -0800 (PST) Message-ID: <953beacc0612011632s7f2f717ai25825dd795e00022@mail.gmail.com> Date: Fri, 1 Dec 2006 16:32:54 -0800 From: "Rohan Mahy" To: "Attila Sipos" In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0012A3672@veg-brk-svr-pri.vegastream> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8F1F2062CA7D754A838F0E66097D23A0012A3672@veg-brk-svr-pri.vegastream> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sip@ietf.org, rohan@ekabal.com, Francois Audet , "Christer Holmberg \(JO/LMF\)" Subject: [Sip] Re: CRLF draft? 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 Attila, This was described in an earlier version of the outbound draft. The text from the last version it appeared is below: thanks, -rohan
If the SIP server is acting as the TCP client and initiated the TCP connection (meaning that this host did the active open), then the SIP server MUST NOT perform any of the processing in this section. The following only applies when the SIP server is acting as the TCP server (meaning that this host did the passive open). When the server receives a CRLF before the start line of a message on a flow, it MUST send some data back on that same flow within 3 seconds. If no message is actively being sent, it SHOULD send back a CRLF after waiting at least 1 second. The reason for waiting at least 1 second is that if the other end has an incorrect implementation and incorrectly echoes the CRLF, this will stop the flow from going into a live-lock state.
On 11/30/06, Attila Sipos wrote: > > Every now and then I "hear" people mention CRLF. > Is there a draft for this? > Or a draft which mentions this? > I assume it's something where, instead of a full SIP > message, just a CRLF is sent to keep a NAT binding open. > Is it only meant for UDP or just for TCP or both? > Regards, > Attila > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 03 12:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqudv-0006Wo-0C; Sun, 03 Dec 2006 11:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqudt-0006Wh-WE for sip@ietf.org; Sun, 03 Dec 2006 11:56:42 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqudo-00080u-JM for sip@ietf.org; Sun, 03 Dec 2006 11:56:41 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kB3GuEC5023792; Sun, 3 Dec 2006 10:56:18 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 10:56:14 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 17:56:12 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Re: SIPS and the PSTN Date: Sun, 3 Dec 2006 17:56:12 +0100 Message-ID: <5D1A7985295922448D5550C94DE291808D671C@DEEXC1U01.de.lucent.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60FEB3D28@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: SIPS and the PSTN Thread-Index: AccTPNuiHcDprT12TGqkqbICsqtdOQABwKjwAADLZ7AAGPQX0AABLqNgAMoGh3A= From: "Drage, Keith \(Keith\)" To: "Samir Srivastava" , "Francois Audet" , "Jonathan Rosenberg" X-OriginalArrivalTime: 03 Dec 2006 16:56:12.0470 (UTC) FILETIME=[F021D560:01C716FB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: SIP WG , 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 We don't vote, we operate by rough consensus. We have rough consensus as a result of IETF#66 and the subsequent approval of the proceedings to proceed with an informative document. That means that to overturn that, you need rough consensus in entirely the opposite direction. Given that there is at least a body of people interested in completing this document, you seem to have a significant hurdle to overcome. Regards Keith > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com]=20 > Sent: 29 November 2006 12:13 > To: Drage, Keith (Keith); Francois Audet; Jonathan Rosenberg > Cc: SIP WG; Dean Willis > Subject: RE: [Sip] Re: SIPS and the PSTN >=20 > I would like to have the chair's permission for the voting on=20 > the need of this document on the list. Who would like to see=20 > this document to progress ? >=20 > Thx > Samir=20 >=20 > >-----Original Message----- > >From: Drage, Keith (Keith) [mailto:drage@lucent.com] > >Sent: Wednesday, November 29, 2006 3:45 AM > >To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055);=20 > >Jonathan Rosenberg > >Cc: SIP WG; Dean Willis > >Subject: RE: [Sip] Re: SIPS and the PSTN > > > >(As WG chair) > > > >If you wish the IETF rules allow you to do this. > > > >To make very clear the position: > > > >If you wish to achieve what you want, which is deprecation=20 > of various=20 > >requirements in RFC 3261, then you have already been asked=20 > to provide=20 > >the appropriate discussion material to this internet-draft.=20 > Part of the=20 > >output of the internet-draft is to make recommendations on=20 > improvement,=20 > >which can include deprecation. But we want to see the WG making an=20 > >informed decision, based on a clear understanding of what is=20 > the impact=20 > >on existing implementations, why the existing mechanism=20 > causes damage=20 > >in the community, and so on. > > > >The scope of the internet-draft is made very clear in the slides > >(http://www3.ietf.org/proceedings/06nov/slides/sip-2.pdf) -=20 > see slide=20 > >2. > > > >Regards > > > >Keith > > > >> -----Original Message----- > >> From: Samir Srivastava [mailto:samirsr@nortel.com] > >> Sent: 28 November 2006 23:45 > >> To: Francois Audet; Jonathan Rosenberg > >> Cc: SIP WG; Drage, Keith (Keith); Dean Willis > >> Subject: RE: [Sip] Re: SIPS and the PSTN > >>=20 > >>=20 > >> IMHO, after SIPS we are committing one more mistake. After knowing=20 > >> SIPS is completely broken, we are attempting to justify=20 > the need on=20 > >> the charter. I am failing to see the value of any these documents. > >> Rather go to IESG directly and get this milestone removed from the=20 > >> charter. All this is merely wastage of cycles. BTW, I=20 > don't want to=20 > >> open the complete ranting mode now. > >>=20 > >> Thx > >> Samir > >>=20 > >> > -----Original Message----- > >> > From: Audet, Francois (SC100:3055) > >> > Sent: Tuesday, November 28, 2006 3:23 PM > >> > To: Jonathan Rosenberg > >> > Cc: SIP WG; Drage, Keith (Keith); Dean Willis > >> > Subject: RE: [Sip] Re: SIPS and the PSTN > >> >=20 > >> > Yeah, except that I've been instructed by the Chairs that this > >> document > >> > is 'informational' only. > >> >=20 > >> > I assume that it means that I can't make normative > >> statements of any > >> > kind. Is this true? > >> >=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 From sip-bounces@ietf.org Mon Dec 04 01:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7Kf-0001hX-6P; Mon, 04 Dec 2006 01:29:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7Kd-0001hP-P3 for sip@ietf.org; Mon, 04 Dec 2006 01:29:39 -0500 Received: from nz-out-0506.google.com ([64.233.162.239] helo=nz-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr7Kc-0001Ov-FH for sip@ietf.org; Mon, 04 Dec 2006 01:29:39 -0500 Received: by nz-out-0102.google.com with SMTP id z6so1916256nzd for ; Sun, 03 Dec 2006 22:29: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=ozHPqaIwPxf80mpoltopp7D0rIze+p3yFpD0t7uapBcZhnesf2+ZL67aDLgG+o6H1Zs5bGSf78BF7fhFR+zy2RQKbSdaIjnEFNxnvYLr3rWhN47DtQMUYvTp731ghB+1180xQD8y2XL73MMCuxH5oejuqhsl3HX1YY+aLclCLOw= Received: by 10.65.84.5 with SMTP id m5mr12255547qbl.1165213777888; Sun, 03 Dec 2006 22:29:37 -0800 (PST) Received: by 10.65.119.17 with HTTP; Sun, 3 Dec 2006 22:29:37 -0800 (PST) Message-ID: <603d60750612032229p7d239cd1u799fa2a5b0d9b585@mail.gmail.com> Date: Mon, 4 Dec 2006 11:59:37 +0530 From: "bruce wayne" To: sip@ietf.org 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] sip, doMessage 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, im a newbie. im trying out some stuff with xlite. can anyone tell me how to implement the doMessage method for instant messaging? an example code would be very helpful. Im trying to implement it in the findme example that comes with the weblogic sip server. thank you in advance. best regards, Cal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 04 04:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAaQ-0001mZ-Ij; Mon, 04 Dec 2006 04:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrAaP-0001mU-V1 for sip@ietf.org; Mon, 04 Dec 2006 04:58:09 -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 1GrAaO-0001Hg-GY for sip@ietf.org; Mon, 04 Dec 2006 04:58:09 -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 kB49vX8T025000; Mon, 4 Dec 2006 11:57:47 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:57:52 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:57: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: [Sip] Re: issue with oubound and the used transport protocol -decide whether to send keep-alive in the first place Date: Mon, 4 Dec 2006 11:57:51 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03145D8C@esebe103.NOE.Nokia.com> In-Reply-To: <7374777208BDC7449D5620EF94232567B5E6C1@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol -decide whether to send keep-alive in the first place Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPAAEHJUMACOi9CQ From: To: , , , X-OriginalArrivalTime: 04 Dec 2006 09:57:51.0699 (UTC) FILETIME=[A951E230:01C7178A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, rohan@ekabal.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, >No matter how we do the keep-alive, I think STUN is a good tool for the >UA to figure out whether it's located behind a NAT in the first place Please remember that UA could figure that out also with rport. It should work both for UDP and TCP as well. >by checking the XMA value etc. Again, outbound can be used also in >no-NAT scenarios, so the UA can use the STUN response information to >decide whether it needs to send keep-alives in the first place. Generically STUN does not help for that, since keepalives are also needed due to firewalls and STUN can not help the UA to detect the presence of firewall. In my understanding muxing STUN with SIP seemed as a good idea for UDP flows. However if the value of UDP flows is rather questionable, I would claim the same applies also to STUN keepalives, too. 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 Mon Dec 04 06:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrCDE-0005aj-66; Mon, 04 Dec 2006 06:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrCDC-0005aP-JS for sip@ietf.org; Mon, 04 Dec 2006 06:42:18 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrCDB-0001Dv-DF for sip@ietf.org; Mon, 04 Dec 2006 06:42:18 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 903FE6C017; Mon, 4 Dec 2006 06:42:02 -0500 (EST) Subject: Re: [Sip] Issue: Expiration of temp-gruu From: Scott Lawrence To: Paul Kyzivat In-Reply-To: <456E15CD.60805@cisco.com> References: <456E15CD.60805@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 03 Dec 2006 21:50:34 -0500 Message-Id: <1165200634.3607.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP IETF 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, 2006-11-29 at 18:20 -0500, Paul Kyzivat wrote: [assorted ambiguous cases that make it unclear whether or not a temp-gruu is still valid] > The "reg" event does provide a fairly complete solution to this problem, > for those that are willing and able to use it. It is not however a 100% > reliable solution. A UA that wants to determine whether or not a temp-gruu it has for itself is still valid can do that test any time: send an OPTIONS request to the domain of the gruu addressed to that temp-gruu. If you get the request back, it's still good. No change is needed to gruu, and no support for the reg event package is needed by either the UA or 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 Dec 04 09:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEQ6-0003R9-B2; Mon, 04 Dec 2006 09:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEQ5-0003R3-H1 for sip@ietf.org; Mon, 04 Dec 2006 09:03:45 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrEQ0-0001q5-1A for sip@ietf.org; Mon, 04 Dec 2006 09:03:45 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2AE161945BB for ; Mon, 4 Dec 2006 15:03:30 +0100 (CET) Received: from [192.168.1.65] ([192.168.1.65]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 15:03:16 +0100 In-Reply-To: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> References: <953beacc0611211159g35ab5230j4ece503dfaaa5952@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0aea1c9df9a9480866013ac7ae6a8ff2@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] strawman text for FASTEST proposal in outbound Date: Mon, 4 Dec 2006 15:03:01 +0100 To: "Rohan Mahy" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 04 Dec 2006 14:03:16.0294 (UTC) FILETIME=[F1DCC660:01C717AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: SIP WG , Rohan Mahy , Cullen Jennings 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 word "prevents" sounds like it is a feature and a good thing. It's more like a side effect. I propose changing that word to "prohibits". Also, I want to second Markus on his comment. If outbound is supposed to work with presence and IM or any event package for that matter, then recommending not to use outbound is not a solution. Hisham On Nov 21, 2006, at 8:59 PM, Rohan Mahy wrote: > Hi, > > To make the discussion about the outbound transport issues more > concrete, here is some strawman text for the "FASTEST" direction. > > thanks, > -rohan > > PROPOSED TEXT: > Use of outbound with UDP flows prevents messages larger than 1300 > bytes from being delivered using TCP as described in Section 18.1.1 > RFC 3261. Use of outbound in conjunction with UDP flows in > environments where requests are expected to be larger than this size > is therefore NOT RECOMMENDED. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 04 09:33:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrErq-0006VQ-0C; Mon, 04 Dec 2006 09:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEro-0006VA-4z for sip@ietf.org; Mon, 04 Dec 2006 09:32:24 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrErm-0005rD-Nq for sip@ietf.org; Mon, 04 Dec 2006 09:32:24 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id F3FB91945C6 for ; Mon, 4 Dec 2006 15:32:21 +0100 (CET) Received: from [192.168.1.65] ([192.168.1.65]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 15:32:06 +0100 In-Reply-To: <1164029015.7482.23.camel@macbuster.research.nokia.com> References: <7374777208BDC7449D5620EF942325676E7C67@esealmw113.eemea.ericsson.se> <1164029015.7482.23.camel@macbuster.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99a19022ee38d2911da26860e7cb46cb@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 4 Dec 2006 15:31:52 +0100 To: Aki Niemi X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 04 Dec 2006 14:32:06.0673 (UTC) FILETIME=[F93FA810:01C717B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" , "ext 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 Nov 20, 2006, at 2:23 PM, Aki Niemi wrote: > ma, 2006-11-20 kello 10:02 +0100, ext Christer Holmberg (JO/LMF) > kirjoitti: >>> >>> Please enumerate the cases. >>> >>> Unless there are concrete cases where TCP simply does not >>> work, I would strongly recommend we drop UDP from outbound >>> altogether. Remember, UDP already kind of works in presence >>> of NAT; this is why we have for instance rport. >> >> Outbound is not an alternative to rport. Outbound provides you with >> keep-alives, and multiple flows (in case one fails), which rport >> doesn't. rport simply tells you where to send some stuff. > > I never said it was a replacement. However, the world is full of > deployments that use UDP and work through NAT just fine (kind of); some > use rport, some use something else. Clearly, these folks aren't holding > out their deployments waiting for outbound to finish. No, but we do so by breaking SIP rules. Something we want to move away from. Hisham > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 04 09:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEyg-0003Cc-M3; Mon, 04 Dec 2006 09:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrEye-0003Bm-I1 for sip@ietf.org; Mon, 04 Dec 2006 09:39:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrEyc-0006WI-6i for sip@ietf.org; Mon, 04 Dec 2006 09:39:28 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 06:39:25 -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 kB4EdP9u010980; Mon, 4 Dec 2006 06:39:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB4EdIdE025099; Mon, 4 Dec 2006 06:39:18 -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); Mon, 4 Dec 2006 06:39:18 -0800 Received: from [192.168.1.3] ([10.21.112.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 06:39:18 -0800 In-Reply-To: <1164042311.2868.14.camel@sukothai.pingtel.com> References: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> <1164042311.2868.14.camel@sukothai.pingtel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53AE7332-D75B-4F45-86C7-E7ED03A64DFF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D on handling large UDP responses Date: Mon, 4 Dec 2006 06:39:32 -0800 To: Scott Lawrence X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Dec 2006 14:39:18.0453 (UTC) FILETIME=[FA9C0E50:01C717B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1363; t=1165243165; x=1166107165; 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]=20I-D=20on=20handling=20large=20UDP=20responses |Sender:=20; bh=vrNeg99BwUKFxdHiPExfh9d97WeN93ExZx6a1HE7seI=; b=Zk00p7zkMG1Rh0rzNMDsSwFRgFzu2vA2BPuv4Xl4A2PnQfQnt5SL2/m/WFGYZz1ESKFAJ7JN GADlVodo+x6cx7lwaNQhJ8NNZE/nBBBsGAkx/UWvYgSoGsxzQ+uSjQ9Z; 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , "Vijay K. Gurbani" , 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 Hmm - clearly whatever Scott and I had agreed might work is probably irrelevant at this point since it clearly was not something we all agreed to or can even remember. It was just an hallway conversation between Scott and I. BTW, my vague recollection of it was I thought we had agreed that saying the response body would not be included unless it was less the total message was less than 1500 octets and provide advice on how to trim it down to be that size. On Nov 20, 2006, at 9:05 AM, Scott Lawrence wrote: > On Mon, 2006-11-13 at 11:20 +0100, Drage, Keith (Keith) wrote: >> Question repeat, as it does not seem to have been answered. > >>> From: Drage, Keith (Keith) [mailto:drage@lucent.com] >>> Sent: 04 October 2006 19:46 >>> To: Cullen Jennings; Dean Willis >>> Cc: IETF SIP List; Vijay K. Gurbani >>> Subject: RE: [Sip] I-D on handling large UDP responses >>> >>> Can you tell us what you agreed on. The proceedings seem to >>> have missed it, and I don't remember it appearing on the list. > > I am not at all sure that we agreed on anything with respect to this. > > -- > Scott Lawrence tel:+1-781-938-5306;ext=162 or > sip:slawrence@pingtel.com > sipXpbx project coordinator - SIPfoundry http:// > www.sipfoundry.org/sipX > Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Mon Dec 04 09:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFDe-0001sc-5R; Mon, 04 Dec 2006 09:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFDc-0001sI-7X for sip@ietf.org; Mon, 04 Dec 2006 09:54:56 -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 1GrFDY-00004y-EJ for sip@ietf.org; Mon, 04 Dec 2006 09:54:56 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB4EsJLV006346; Mon, 4 Dec 2006 16:54:35 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:54:26 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Dec 2006 16:54:18 +0200 Message-ID: <457436A3.50606@nokia.com> Date: Mon, 04 Dec 2006 16:54:27 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com> <45707D8A.8020001@cisco.com> In-Reply-To: <45707D8A.8020001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2006 14:54:18.0340 (UTC) FILETIME=[12FBEA40:01C717B4] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061204165435-18BBABB0-51343115/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 I just checked the latest SIPit report, and it seems that only 5 implementations supported reg event, as opposed to 29 that supported refer, 23 message-summary, or 14 presence. Well, this probably indicates that reg-event is not widely deployed to justify a solution based on it. Therefore, I don't mind Jonathan's solution #2 /Miguel Jonathan Rosenberg wrote: > The main question is really to decide on one of two mechanisms: > > 1. use reg-event if you are worried about use cases where this race > condition can occur (4-6 in Paul's original email) > > 2. add a parameter to Contact in the register response. Specifically, > I'd recommend a Contact header field parameter which indicates the time > at which the first contact with a given instance ID was registered to > that AOR. This value gets linked with each temp gruu, and when the value > changes, all of those temp-gruu get invalidated. > > Solution (2) is much simpler, but not needed if you think you'll always > have reg-event anyway. I don't think there is widespread support for > reg-event on endpoints yet. It is required by IMS. > > I am somewhat on the fence on this one. I do worry that reg-event is > genreally a very heavy solution, and may not see much usage. Option 2 is > really trivially done, either in gruu or elsewhere. The main issue is > that it is another late change. > > -JOnathan R. > > > > Paul Kyzivat wrote: > >> Miguel, >> >> So to summarize, it seems you are of the belief that the cases where >> these measures may be inadequate are sufficiently obscure to ignore, >> and that new measures to cover the obscure cases are unnecessary. Is >> that right? >> >> Paul >> >> Miguel Garcia wrote: >> >>> For issue 3, I would say that the solution is to avoid the situation, >>> e.g., by registering way in advance before the registration expires. >>> Doesn't RFC 3261 recommends to re-register half time before the >>> registration timer expires. >>> >>> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the >>> GRUU draft have a recommendation on the usage of the reg event to >>> solve them? >>> >>> /Miguel >>> >>> Paul Kyzivat wrote: >>> >>>> After some study, I have encountered a potential difficulty in >>>> determining when temp-gruus expire. After discussing this with >>>> Jonathan we decided to bring it to the list for discussion. >>>> >>>> As now defined, when you first register you may get a temp-gruu, >>>> which will remain valid as long as the registration does not expire >>>> or be removed. (Removal is a special case of expiration.) Each time >>>> the UA refreshes the registration it may get a new temp-gruu which >>>> also remains valid for the life of the registration. The UA can >>>> accumulate all these temp-gruus and use them as it sees fit until >>>> they expire. >>>> >>>> The problem is: how does the UA know when the registration has ended >>>> and the temp-gruus associated with it rendered invalid? >>>> >>>> This seems like a simple question, and in some cases it is simple, >>>> but not in all cases. The following are at least some of the ways >>>> that the registration can be ended, causing the invalidation of >>>> temp-gruus: >>>> 1) the UA that originally registered may explicitly deregister >>>> 2) the UA the originally registered may simply permit the >>>> registration to expire without attempting to refresh it >>>> 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 >>>> >>>> In each of these cases the previously assigned temp-gruus become >>>> invalid. If the UA continues to use them, bad things will happen. >>>> This is true both for calls that are active when the deregistration >>>> occurs, and calls that are established later. What kinds of bad >>>> things happen? >>>> - requests addressed to the gruu, both in-dialog and out-of-dialog >>>> will be undeliverable. (For instance a reINVITE or BYE in an >>>> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >>>> >>>> - request originated by the UA using the invalid gruu will fail >>>> immediately because the gruu is invalid. >>>> >>>> - if the UA subsequently reregisters, receives an incoming call, and >>>> uses one of the old temp-gruus as its contact, then the call will >>>> be established, but subsequent in- and out-of-dialog requests to >>>> the contact will fail. >>>> >>>> So clearly it is important for the UA to stop using temp-gruus that >>>> have become invalid. How can it know to do that in all of the above >>>> cases? >>>> >>>> 1) is straightforward. The UA knows it is deregistering, and should >>>> discard any cached temp-gruus. If it has a dialog with one of the >>>> temp-gruus as a contact, then it should do a target refresh and >>>> supply some working contact. (It really should do this *before* >>>> deregistering, and for a pub-gruu as well.) >>>> >>>> 2) the UA should take all the actions mentioned for (1) at or before >>>> the expiration time. This should be done a bit early to guard >>>> against clock skew problems. >>>> >>>> 3) in this case, it may be impossible for the UA to know whether >>>> the REGISTER arrived in time to be a reREGISTER or if it arrived >>>> late and was treated as a new REGISTER after the expiration of >>>> the old one. (The response to the REGISTER includes nothing that >>>> distinguishes the two cases.) About the best that can be done in >>>> this case is to check the time at which the response to the >>>> REGISTER is received. If it falls after the expected expiration >>>> time for the registration, act as if the old registration had >>>> expired. >>>> >>>> 4) This is a major problem. Of course, regardless of GRUU, the UA >>>> won't be able to receive incoming calls until it decides it is >>>> time to refresh the registration. In addition, until the >>>> registration reestablished, calls originated with one of its >>>> existing gruus will fail. Once the registration is reestablished, >>>> it still won't know its old temp-gruus are invalid. The only >>>> remedy for this is to subscribe to the "reg" event package, >>>> and use the resulting notifications to identify when it has >>>> been unregistered. If it does that, it can invalidate all its >>>> old temp-gruus, and then presumably reregister. >>>> >>>> 5) this is functionally equivalent to (4), except that perhaps >>>> attempts to reregister may fail. >>>> >>>> 6) this is also functionally equivalent to (4). >>>> >>>> The "reg" event does provide a fairly complete solution to this >>>> problem, for those that are willing and able to use it. It is not >>>> however a 100% reliable solution. Consider case (3), where the UA >>>> has a reg event subscription. All is well if the registration >>>> expires and a notification is sent indicating that, and then the >>>> reregistration occurs and a notification is sent about that. But if >>>> they happen very closely in time, it may be that only one >>>> notification is sent, reflecting the result of the reregistration. >>>> In that case the UA will not be aware that it had been unregistered >>>> for a period of time. >>>> >>>> A *complete* solution would, IMO, involve changing REGISTER so that >>>> it returns an indication of whether this was a new registration, or >>>> a refresh. This could take many forms. For instance the timestamp of >>>> the initial registration could always be returned with each contact, >>>> as well as the expiration time. >>>> >>>> The big question is whether this is a big enough issue to require a >>>> solution now, as part of GRUU, or if it can be ignored as >>>> insignificant or postponed to future work. >>>> >>>> I'd appreciate hearing what others think about this. At the moment I >>>> am leaning toward doing nothing, at least for now. >>>> >>>> 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 >>>> >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Mon Dec 04 09:58:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFGp-0005qq-KA; Mon, 04 Dec 2006 09:58:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFGo-0005l2-3M for sip@ietf.org; Mon, 04 Dec 2006 09:58:14 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrFGm-0000TF-QR for sip@ietf.org; Mon, 04 Dec 2006 09:58:14 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 186B1194542 for ; Mon, 4 Dec 2006 15:58:12 +0100 (CET) Received: from [192.168.1.65] ([192.168.1.65]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 15:57:58 +0100 In-Reply-To: <002f01c70a6c$be4c0fb0$0601a8c0@BEMBUSTER> References: <784A66466728424D93027C59B6478B9E0101E380@MCHP7I5A.ww002.siemens.net> <002f01c70a6c$be4c0fb0$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 4 Dec 2006 15:57:44 +0100 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 04 Dec 2006 14:57:58.0553 (UTC) FILETIME=[963DC090:01C717B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org, "Leis, Peter" 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 like this proposal, although I would not use MUST. Either of these is optional. Both is recommended. Hisham On Nov 17, 2006, at 6:20 PM, Jeroen van Bemmel wrote: > The outbound draft needs to say: "if a UA establishes a flow using an > unreliable transport, it MUST also establish one over a reliable > transport" (to support switch over). Moreover, I would suggest to add > "it is RECOMMENDED that the UA establishes a flow using a reliable > transport" > > Regards, > Jeroen > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 04 10:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFMN-0005IO-UK; Mon, 04 Dec 2006 10:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFMM-0005IH-Es for sip@ietf.org; Mon, 04 Dec 2006 10:03:58 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrFMH-0001Br-Ln for sip@ietf.org; Mon, 04 Dec 2006 10:03:58 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id D2C716C018; Mon, 4 Dec 2006 10:03:38 -0500 (EST) Subject: Re: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Cullen Jennings In-Reply-To: <53AE7332-D75B-4F45-86C7-E7ED03A64DFF@cisco.com> References: <5D1A7985295922448D5550C94DE291807B5931@DEEXC1U01.de.lucent.com> <1164042311.2868.14.camel@sukothai.pingtel.com> <53AE7332-D75B-4F45-86C7-E7ED03A64DFF@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Mon, 04 Dec 2006 10:03:49 -0500 Message-Id: <1165244629.2976.24.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , "Vijay K. Gurbani" , 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 Mon, 2006-12-04 at 06:39 -0800, Cullen Jennings wrote: > Hmm - clearly whatever Scott and I had agreed might work is probably > irrelevant at this point since it clearly was not something we all > agreed to or can even remember. It was just an hallway conversation > between Scott and I. BTW, my vague recollection of it was I thought > we had agreed that saying the response body would not be included > unless it was less the total message was less than 1500 octets and > provide advice on how to trim it down to be that size. That matches my recollection regarding the handling of hop limit responses (and any other similar diagnostic responses), but I didn't think that was the current question. I was referring to a general rule for what to do with _any_ large response on a path that includes UDP. My recollection is that there are essentially three points of view on this: * Do Nothing - let UDP either work or not (there seemed to be important disagreement on how often this is a problem), and if it doesn't work, don't do anything different to make it easier to detect why not. * Diagnostic Provisional Response - add a small 1xx response or responses (as described in draft-gurbani-sip-large-udp-response-00) to aid in diagnosis of failures. This ran into objections from some people with respect to non-INVITE transactions, and from others who seemed to object on broader grounds. * Always Return Error - instead of returning whatever final response you were going to return (whether positive or negative), return an error indicating that the response would be too large. Alas, I think we've only gotten as far as the 'Rough' in 'Rough Consensus' on this. Obviously, I prefer some form of Diagnostic Provisional response. I do believe this is a significant problem. I prefer the diagnositc approach because it allows things to work if the large UDP response actually gets through, but gives you some hint as to why not when it doesn't. I think that the relative cost of the extra 1xx is acceptable when compared to the cost of the retransmissions when things are broken. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Mon Dec 04 11:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGoO-0001Fc-F0; Mon, 04 Dec 2006 11:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGoM-0001El-RO for sip@ietf.org; Mon, 04 Dec 2006 11:36:58 -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 1GrGoL-0006Fr-CL for sip@ietf.org; Mon, 04 Dec 2006 11:36:58 -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 kB4Ga1sI030087; Mon, 4 Dec 2006 18:36:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 12:26:51 +0200 Received: from 4FIL15472 ([172.17.192.174]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Dec 2006 12:26:52 +0200 From: "Aki Niemi" To: "'ext Christer Holmberg \(JO/LMF\)'" , "'Francois Audet'" , "'Kevin Johns'" , "'Fredrik Thulin'" Subject: RE: [Sip] Re: issue with oubound and the used transport protocol -decide whether to send keep-alive in the first place Date: Mon, 4 Dec 2006 12:26:50 +0200 Message-ID: <000601c7178e$b5b0db90$529cb70a@NOE.Nokia.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: <7374777208BDC7449D5620EF94232567B5E6C1@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPAAEHJUMACPbngw X-OriginalArrivalTime: 04 Dec 2006 10:26:52.0139 (UTC) FILETIME=[B6B3F3B0:01C7178E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, rohan@ekabal.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 >No matter how we do the keep-alive, I think STUN is a good >tool for the UA to figure out whether it's located behind a >NAT in the first place, by checking the XMA value etc. Again, >outbound can be used also in no-NAT scenarios, so the UA can >use the STUN response information to decide whether it needs >to send keep-alives in the first place. I disagree; that will generally not work. Many networks deploy stateful firewalls that do connection tracking. They will not show up as NAT, but will require keepalives. I've seen these especially in mobile networks, but I would imagine many enterprises deploy similar stuff. My experience has been that if you want robust connectivity for your SIP app, use TCP (you get 30x more performance from middleboxes) and *always* use keepalives, with their frequency tuned towards the lowest common keepalive interval found in the field. Clearly, YMMV. 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 Mon Dec 04 11:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGvJ-0006M8-1o; Mon, 04 Dec 2006 11:44:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGvH-0006M2-5C for sip@ietf.org; Mon, 04 Dec 2006 11:44:07 -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 1GrGvG-0007Jf-5U for sip@ietf.org; Mon, 04 Dec 2006 11:44:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB4GhQfo029528; Mon, 4 Dec 2006 18:43:52 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:49:17 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Dec 2006 16:49:09 +0200 Message-ID: <4574356E.10404@nokia.com> Date: Mon, 04 Dec 2006 16:49:18 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com> In-Reply-To: <457057A6.4020804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2006 14:49:09.0058 (UTC) FILETIME=[5AA33A20:01C717B3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: SIP IETF 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 Correct. I think so. /Miguel Paul Kyzivat wrote: > Miguel, > > So to summarize, it seems you are of the belief that the cases where > these measures may be inadequate are sufficiently obscure to ignore, and > that new measures to cover the obscure cases are unnecessary. Is that > right? > > Paul > > Miguel Garcia wrote: >> For issue 3, I would say that the solution is to avoid the situation, >> e.g., by registering way in advance before the registration expires. >> Doesn't RFC 3261 recommends to re-register half time before the >> registration timer expires. >> >> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the GRUU >> draft have a recommendation on the usage of the reg event to solve them? >> >> /Miguel >> >> Paul Kyzivat wrote: >>> After some study, I have encountered a potential difficulty in >>> determining when temp-gruus expire. After discussing this with >>> Jonathan we decided to bring it to the list for discussion. >>> >>> As now defined, when you first register you may get a temp-gruu, >>> which will remain valid as long as the registration does not expire >>> or be removed. (Removal is a special case of expiration.) Each time >>> the UA refreshes the registration it may get a new temp-gruu which >>> also remains valid for the life of the registration. The UA can >>> accumulate all these temp-gruus and use them as it sees fit until >>> they expire. >>> >>> The problem is: how does the UA know when the registration has ended >>> and the temp-gruus associated with it rendered invalid? >>> >>> This seems like a simple question, and in some cases it is simple, >>> but not in all cases. The following are at least some of the ways >>> that the registration can be ended, causing the invalidation of >>> temp-gruus: >>> 1) the UA that originally registered may explicitly deregister >>> 2) the UA the originally registered may simply permit the >>> registration to expire without attempting to refresh it >>> 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 >>> >>> In each of these cases the previously assigned temp-gruus become >>> invalid. If the UA continues to use them, bad things will happen. >>> This is true both for calls that are active when the deregistration >>> occurs, and calls that are established later. What kinds of bad >>> things happen? >>> - requests addressed to the gruu, both in-dialog and out-of-dialog >>> will be undeliverable. (For instance a reINVITE or BYE in an >>> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >>> >>> - request originated by the UA using the invalid gruu will fail >>> immediately because the gruu is invalid. >>> >>> - if the UA subsequently reregisters, receives an incoming call, and >>> uses one of the old temp-gruus as its contact, then the call will >>> be established, but subsequent in- and out-of-dialog requests to >>> the contact will fail. >>> >>> So clearly it is important for the UA to stop using temp-gruus that >>> have become invalid. How can it know to do that in all of the above >>> cases? >>> >>> 1) is straightforward. The UA knows it is deregistering, and should >>> discard any cached temp-gruus. If it has a dialog with one of the >>> temp-gruus as a contact, then it should do a target refresh and >>> supply some working contact. (It really should do this *before* >>> deregistering, and for a pub-gruu as well.) >>> >>> 2) the UA should take all the actions mentioned for (1) at or before >>> the expiration time. This should be done a bit early to guard >>> against clock skew problems. >>> >>> 3) in this case, it may be impossible for the UA to know whether >>> the REGISTER arrived in time to be a reREGISTER or if it arrived >>> late and was treated as a new REGISTER after the expiration of >>> the old one. (The response to the REGISTER includes nothing that >>> distinguishes the two cases.) About the best that can be done in >>> this case is to check the time at which the response to the >>> REGISTER is received. If it falls after the expected expiration >>> time for the registration, act as if the old registration had >>> expired. >>> >>> 4) This is a major problem. Of course, regardless of GRUU, the UA >>> won't be able to receive incoming calls until it decides it is >>> time to refresh the registration. In addition, until the >>> registration reestablished, calls originated with one of its >>> existing gruus will fail. Once the registration is reestablished, >>> it still won't know its old temp-gruus are invalid. The only >>> remedy for this is to subscribe to the "reg" event package, >>> and use the resulting notifications to identify when it has >>> been unregistered. If it does that, it can invalidate all its >>> old temp-gruus, and then presumably reregister. >>> >>> 5) this is functionally equivalent to (4), except that perhaps >>> attempts to reregister may fail. >>> >>> 6) this is also functionally equivalent to (4). >>> >>> The "reg" event does provide a fairly complete solution to this >>> problem, for those that are willing and able to use it. It is not >>> however a 100% reliable solution. Consider case (3), where the UA has >>> a reg event subscription. All is well if the registration expires and >>> a notification is sent indicating that, and then the reregistration >>> occurs and a notification is sent about that. But if they happen very >>> closely in time, it may be that only one notification is sent, >>> reflecting the result of the reregistration. In that case the UA will >>> not be aware that it had been unregistered for a period of time. >>> >>> A *complete* solution would, IMO, involve changing REGISTER so that >>> it returns an indication of whether this was a new registration, or a >>> refresh. This could take many forms. For instance the timestamp of >>> the initial registration could always be returned with each contact, >>> as well as the expiration time. >>> >>> The big question is whether this is a big enough issue to require a >>> solution now, as part of GRUU, or if it can be ignored as >>> insignificant or postponed to future work. >>> >>> I'd appreciate hearing what others think about this. At the moment I >>> am leaning toward doing nothing, at least for now. >>> >>> 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 >>> >> -- 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 Mon Dec 04 12:58:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI3p-00038e-0B; Mon, 04 Dec 2006 12:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI3n-00038V-53; Mon, 04 Dec 2006 12:56:59 -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 1GrI3m-0000w6-DP; Mon, 04 Dec 2006 12:56:59 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB4Hu1w5031971; Mon, 4 Dec 2006 19:56:38 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 12:28:08 +0200 Received: from 4FIL15472 ([172.17.192.174]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Dec 2006 12:28:09 +0200 From: "Aki Niemi" To: , Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 4 Dec 2006 12:28:07 +0200 Message-ID: <000701c7178e$e3bc1ea0$529cb70a@NOE.Nokia.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: <8B1D53AEF7B03449A6D3771B3B7F850F019756C1@esebe103.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccT7WMs5WR4wOAPTVycPcIXZ6pf1wBS4ALAAJV5utA= X-OriginalArrivalTime: 04 Dec 2006 10:28:09.0379 (UTC) FILETIME=[E4BDD730:01C7178E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: sip@ietf.org, rohan@ekabal.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 for #1 >-----Original Message----- >From: ext sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] >Sent: 01 December, 2006 14:12 >To: rohan.mahy@gmail.com >Cc: sip@ietf.org; rohan@ekabal.com >Subject: RE: [Sip] Re: issue with oubound and the used >transport protocol > > >Hi, > >You asked me to clarify my CRLF proposal, so I try to do it here. > >I have been exploring ways of rescoping drafts related to >Outbound and simplifying the mechanisms within them since the >limitations of using UDP flows became apparent in this thread. >I could vote for a number of different approaches and would be >happy the WG to agree with at least one of them. Those >approaches in my preference order are: > >1. Outbound draft to re-scope itself to "Outbound TCP connection" > draft without any support to UDP, STUN or multiple registrations. > Multiple registrations and mid-dialog failover (using either TCP > or UDP) to be specified within another draft. > > - This proposal as such did not raise any discussion > on the list, probably because it would be a dramatic > change at a quite late stage of the draft. > - Remarkable changes needed (but I already outlined the > "Outbound TCP connection" draft within my earlier mail :). > http://www1.ietf.org/mail-archive/web/sip/current/msg17495.html > >2. Outbound draft to replace STUN keepalive over TCP with CRLF > keepalive over TCP. (No impact to UDP support of Outbound) > > - This option is equivalent to your formulation, which I > can very much agree on: > >> Clearly you are suggesting that we make CRLF mandatory to implement >> for TCP. There would be no longer any need to do STUN over TCP and >> therefore no need implement code to deal with stream-based demuxing. >> The text about sigcomp over TCP and STUN over TLS over TCP >could also >> go away. > > - Some WG members already expressed their support for this > option > - Minor changes needed to the draft > >3. Outbound draft to introduce a third optional keepalive method > for TCP: CRLF (in addition to STUN and TCP keepalives) > > - This option would be the _last resort_ to get at least some > benefit for TCP-based UA implementation, even if it would > not help the proxies. Proxies would still have to support > STUN over TCP. > - Minimal changes needed to the draft > > >> To clarify are you suggesting that an edge proxy can implement >> outbound without support for UDP flow tokens, without >support for STUN >> keepalives over UDP, both, or neither? > >My proposals were born "UA centric" as I am from the UA vendor camp. > >Anyway if Outbound will specify both UDP and TCP as transport >options, I would believe the proxies still have to support >both since the selection of the transport is basically an UA >decision (even if assisted by DNS SRV) as it depends on if the >proxy URI configured to the UA has a transport parameter. If >the proxy would not support UDP & STUN, how could it tell it >to the UA ? Outbound would at least need a mechanism for that >e.g. a specific response code, option tag or something else. >Or is this yet another thing where Outbound would rely on the >UA and DNS configuration to tell the UA to avoid using UDP ? > >Considering the option to drop UDP & STUN support from Outbound >draft: I would agree that combination of UDP and STUN >keepalives does not seem to provide a practical way for NAT >traversal. Keeping UDP flows alive with STUN seems not to add >value in comparison to persistent TCP flows and I could agree >dropping UDP flows from the draft. The only problem I see here >that Outbound covers also the multiregistration mechanism, >which could still be useful with UDP e.g. in cellular access >context without NAT/FWs. That is why I have been proposing >re-scoping of the drafts: > >- Flow keepalive mechanisms to be specified only for TCP (one draft) >- Protocol agnostic multiregistration mechanism with mid-dialog > failover support (another draft) > >Regards, > >Erkki > >> -----Original Message----- >> From: ext Rohan Mahy [mailto:rohan.mahy@gmail.com] >> Sent: 29 November, 2006 20:30 >> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >> Cc: sip@ietf.org; rohan@ekabal.com >> Subject: Re: [Sip] Re: issue with oubound and the used transport >> protocol >> >> >> Hi Erkki, >> >> Clearly you are suggesting that we make CRLF mandatory to implement >> for TCP. There would be no longer any need to do STUN over TCP and >> therefore no need implement code to deal with stream-based demuxing. >> The text about sigcomp over TCP and STUN over TLS over TCP could >> also go away. >> >> To clarify are you suggesting that an edge proxy can implement >> outbound without support for UDP flow tokens, without >support for STUN >> keepalives over UDP, both, or neither? >> >> thanks, >> -rohan >> >> On 11/29/06, Erkki.Koivusalo@nokia.com >> wrote: >> > >> > Hi, >> > >> > >about STUN keepalive usage and discovery, since double >> CRLF is fully >> > >backwards compatible with even RFC 2543 implementations. I am >> > >bringing this up on the list because I hope the WG can >look back on >> > >this and not make the mistake of snowballing complexity >to preserve >> > >UDP parity again in the future. >> > >> > Rohan is making a valid point here and I believe in Outbound there >> > is still room for change to cater for CRLF keepalives as an option >> > to STUN keepalives over TCP. >> > >> > I am calling the WG to look back on the keepalive decision made >> > earlier for TCP and proposing that Outbound should also cover CRLF >> > keepalive option. >> > >> > Reasons for this proposal: >> > >> > >The problem I see is that we have two separate communities >> using the >> > >outbound draft: >> > > >> > >1) folks that want to get through NATs and Firewalls in >the public >> > >Internet at large - they want to use TCP and TLS with >> double CRLF for >> > >keepalives. One "flow" is always one connection. The >milestone for >> > >this would read "Make TCP and TLS work in the Internet". >> > >> > I agree with the intents of this community. However this >is not what >> > the current Outbound provides. Outbound specifies two options for >> > keepalives for reliable connections: TCP keepalive and STUN. >> > >> > These options were agreed in IETF 65, a cite from the minutes: >> > >> > Proposal: >> > Do STUN for TCP and UDP >> > Do CRLF for TCP and STUN for UDP >> > TCP KeepAlive if supported, 1 or 2 otherwise >> > >> > Resolutions: >> > OS TCP KeepAlive should be used if the client supports it. >> > Need something more because OS TCP KeepAlive is not >supported in >> > every >> > client OS. >> > Consensus to use STUN for UDP >> > Consensus to use STUN for TCP, with use of OS TCP keep >> alive above. >> > >> > In that meeting the basic assumption was that every Outbound >> > compliant client should implement both UDP and TCP even if that is >> > not explicitely mentioned in the draft. However latest -06 version >> > now makes that debatable by stating: >> > >> > Use of outbound with UDP flows typically prevents >messages larger >> > than 1300 bytes from being delivered using TCP as described in >> > Section 18.1.1 RFC 3261. Use of outbound in >conjunction with UDP >> > flows in environments where requests are expected to be >> larger than >> > this size is therefore NOT RECOMMENDED. >> > >> > In practice this seems to justify implementing "TCP only" UAs what >> > comes to the Outbound support. In that case the basic >> assumption >> > with STUN keepalive (implement it for TCP as it is anyway >needed for >> > UDP as well) would become obsolete. For implementations which can >> > not use TCP keepalive, CRLF would obviously provide a >great benefit >> > without significant increase of complexity to Outbound. >> > >> > >> > P.S. Last week I made a proposal for "stripped Outbound" without >> > UDP, STUN keepalives and multiple registrations. As that proposal >> > did not receive any comments, I decided to propose this minimal >> > addition to Outbound as an alternative that might be a bit >easier to >> > accept but still achieve some of the benefits. >> > >> > 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 >> > >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Dec 04 14:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ7J-0005l0-Gv; Mon, 04 Dec 2006 14:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ7I-0005kv-Ql for sip@ietf.org; Mon, 04 Dec 2006 14:04:40 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJ7C-0002kM-7b for sip@ietf.org; Mon, 04 Dec 2006 14:04:40 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9636123; Mon, 4 Dec 2006 20:04:33 +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, 4 Dec 2006 20:04: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: issue with oubound and the used transport protocol-decide whether to send keep-alive in the first place Date: Mon, 4 Dec 2006 20:04:04 +0100 Message-ID: <7374777208BDC7449D5620EF942325674B2442@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol-decide whether to send keep-alive in the first place Thread-Index: AccUrIirPpgcFVzAS6K0iiHf8SWuOwAE71dQAAICJ/AAADX1oAAAm/lwABCZuPAAEHJUMACPbngwABJdzaE= References: <000601c7178e$b5b0db90$529cb70a@NOE.Nokia.com> From: "Christer Holmberg \(JO/LMF\)" To: "Aki Niemi" , "Francois Audet" , "Kevin Johns" , "Fredrik Thulin" X-OriginalArrivalTime: 04 Dec 2006 19:04:33.0497 (UTC) FILETIME=[08B70C90:01C717D7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, rohan@ekabal.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 Aki, =20 You are correct regarding firewalls. I was only thinking about NATs. =20 Regards, =20 Christer =20 =20 ________________________________ From: Aki Niemi [mailto:aki.niemi@nokia.com] Sent: Mon 04/12/2006 11:26 To: Christer Holmberg (JO/LMF); 'Francois Audet'; 'Kevin Johns'; = 'Fredrik Thulin' Cc: sip@ietf.org; rohan@ekabal.com Subject: RE: [Sip] Re: issue with oubound and the used transport = protocol-decide whether to send keep-alive in the first place=20 >No matter how we do the keep-alive, I think STUN is a good >tool for the UA to figure out whether it's located behind a >NAT in the first place, by checking the XMA value etc. Again, >outbound can be used also in no-NAT scenarios, so the UA can >use the STUN response information to decide whether it needs >to send keep-alives in the first place. I disagree; that will generally not work. Many networks deploy stateful firewalls that do connection tracking. = They will not show up as NAT, but will require keepalives. I've seen these especially in mobile networks, but I would imagine many enterprises = deploy similar stuff. My experience has been that if you want robust connectivity for your SIP app, use TCP (you get 30x more performance from middleboxes) and = *always* use keepalives, with their frequency tuned towards the lowest common keepalive interval found in the field. Clearly, YMMV. 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 iohcbtwqrge@ouvaton.net Mon Dec 04 16:43:27 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrLax-0002YX-OW for sip-archive@lists.ietf.org; Mon, 04 Dec 2006 16:43:27 -0500 Received: from 82-39-170-227.cable.ubr05.newy.blueyonder.co.uk ([82.39.170.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrLaw-0003X5-7o for sip-archive@lists.ietf.org; Mon, 04 Dec 2006 16:43:27 -0500 Message-ID: <000501c717ed$350d98c0$00000000@sarah> From: "page gamers" To: sip-archive@lists.ietf.org Subject: have features Date: Mon, 4 Dec 2006 21:43:16 -0000 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: 2.5 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 1026 From sip-bounces@ietf.org Mon Dec 04 17:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrM5t-0007YU-R1; Mon, 04 Dec 2006 17:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrM5s-0007YP-P1 for sip@ietf.org; Mon, 04 Dec 2006 17:15:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrM5q-0002eG-DH for sip@ietf.org; Mon, 04 Dec 2006 17:15:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 14:15:20 -0800 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 kB4MFJaW010989; Mon, 4 Dec 2006 17:15:19 -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 kB4MFJDM029646; Mon, 4 Dec 2006 17:15:19 -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, 4 Dec 2006 17:15:19 -0500 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 17:15:19 -0500 Message-ID: <45749DF6.7040803@cisco.com> Date: Mon, 04 Dec 2006 17:15:18 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) 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> In-Reply-To: <1165200634.3607.3.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2006 22:15:19.0162 (UTC) FILETIME=[AEDCEDA0:01C717F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1764; t=1165270519; x=1166134519; 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]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20 |To:=20Scott=20Lawrence=20; bh=10ag+DEdFSZbeh4l5rT9WZpsUdKRyEjOAECnqtmNB2I=; b=MYPImCpu6NbiHQJXXcZ8umLKK6WVq3MvgpzrXIS7fusjcHn6bS+rRt0kZsUL0tVGaxMqXM8Q 9gY0JoZdTGxxbEAOkIIlCmET+5a49OxQZS4ZdQZTDsXwhm6YBzavqM05; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: SIP IETF 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 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. Paul Scott Lawrence wrote: > On Wed, 2006-11-29 at 18:20 -0500, Paul Kyzivat wrote: > > [assorted ambiguous cases that make it unclear whether or not a > temp-gruu is still valid] > >> The "reg" event does provide a fairly complete solution to this problem, >> for those that are willing and able to use it. It is not however a 100% >> reliable solution. > > A UA that wants to determine whether or not a temp-gruu it has for > itself is still valid can do that test any time: send an OPTIONS request > to the domain of the gruu addressed to that temp-gruu. If you get the > request back, it's still good. No change is needed to gruu, and no > support for the reg event package is needed by either the UA or 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 Dec 04 18:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrNQE-0004zt-Dx; Mon, 04 Dec 2006 18:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrNQB-0004z1-BM for sip@ietf.org; Mon, 04 Dec 2006 18:40:27 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrNQ9-0008GY-UU for sip@ietf.org; Mon, 04 Dec 2006 18:40:27 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kB4NXCJ23378 for ; Mon, 4 Dec 2006 18:33:12 -0500 (EST) 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_01C717FD.9123CC2B" Date: Mon, 4 Dec 2006 17:40:22 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E45A32D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-sip-sips-00.txt thread-index: AccX5fYAUzT/WvzPSSy8Ba14jnRvXgAFXc9g From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Sip] FW: I-D ACTION:draft-ietf-sip-sips-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C717FD.9123CC2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The SIPS Guidelines Working Group draft has just been issued. All the changes agreed to in the mailing list and in San Diego, as well as have been=20 incorporated.=20 The process as outlined in San Diego has been followed: - The document is now an Informational document that clarifies RFC 3261 (as opposed to modify it). - There is a new section 3.1 that attempts to capture the consensus of the group that SIPS is valid within SIP. What happens outside of SIP (e.g., PSTN) is out-of-scope. People can review that section and comment on it. That was the agreement in response to Dean's Point #4. - There is a new section 3.2 clarifying Best-effort use of TLS (i.e., don't use SIPS for best-effort just use SIP transported over TLS). That was Dean's Point #3. - Section 4.1's title has been changed to make it obvious that SIPS is hop-by-hop and not end-to-end. - Appendix A has been added to discuss Further Steps in Specification. This section consist of brief discussion of areas that we believe may eventually require further specifications. It is expected that this section will require beefing-up. Please comment on it. It currently list 2 areas: - Deprecation of Last Hop Exception, reflecting the agreement from the San Diego meeting. That was Dean's point #2. - True end-to-end security. - Appendix B "To be done": Please have a look at this section. =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Monday, December 04, 2006 12:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-ietf-sip-sips-00.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Guidelines for the use of the SIPS=20 > URI Scheme in the Session Initiation Protocol (SIP) > Author(s) : F. Audet > Filename : draft-ietf-sip-sips-00.txt > Pages : 39 > Date : 2006-12-4 > =09 > This document providing clarifications and guidelines=20 > concerning the > use of SIPS URI scheme in the Session Initiation Protocol=20 > (SIP). It > does not make normative changes to SIP. This document=20 > also provides > discussion of possible future steps in specification, and the pros > and cons of making such changes. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > 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=20 > "get draft-ietf-sip-sips-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or 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-sips-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=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 > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01C717FD.9123CC2B Content-Type: application/octet-stream; name="draft-ietf-sip-sips-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-sip-sips-00.URL Content-Disposition: attachment; filename="draft-ietf-sip-sips-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNpcC1zaXBzLTAwLnR4dA0K ------_=_NextPart_001_01C717FD.9123CC2B 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_01C717FD.9123CC2B-- From sip-bounces@ietf.org Tue Dec 05 02:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrUKe-0005zB-9e; Tue, 05 Dec 2006 02:03:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrUKc-0005wb-Rg for sip@ietf.org; Tue, 05 Dec 2006 02:03:10 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrUKc-0004Vt-96 for sip@ietf.org; Tue, 05 Dec 2006 02:03:10 -0500 Received: from [206.176.144.212] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kB566r10020717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Dec 2006 00:06:58 -0600 In-Reply-To: <457436A3.50606@nokia.com> References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com> <45707D8A.8020001@cisco.com> <457436A3.50606@nokia.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: Dean Willis Subject: Re: [Sip] Issue: Expiration of temp-gruu Date: Tue, 5 Dec 2006 01:02:45 -0600 To: Miguel Garcia X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 Would a third party observing multiple uses of temp-gruu be able to correlate them from this time-stamp and therefore make a reasonable deduction that all the temp-gruus were bound to the same Contact and therefore used by the same user? Would we care? -- Dean On Dec 4, 2006, at 8:54 AM, Miguel Garcia wrote: > I just checked the latest SIPit report, and it seems that only 5 > implementations supported reg event, as opposed to 29 that > supported refer, 23 message-summary, or 14 presence. > > Well, this probably indicates that reg-event is not widely deployed > to justify a solution based on it. Therefore, I don't mind > Jonathan's solution #2 > > /Miguel > > Jonathan Rosenberg wrote: >> The main question is really to decide on one of two mechanisms: >> 1. use reg-event if you are worried about use cases where this >> race condition can occur (4-6 in Paul's original email) >> 2. add a parameter to Contact in the register response. >> Specifically, I'd recommend a Contact header field parameter which >> indicates the time at which the first contact with a given >> instance ID was registered to that AOR. This value gets linked >> with each temp gruu, and when the value changes, all of those temp- >> gruu get invalidated. >> Solution (2) is much simpler, but not needed if you think you'll >> always have reg-event anyway. I don't think there is widespread >> support for reg-event on endpoints yet. It is required by IMS. >> I am somewhat on the fence on this one. I do worry that reg-event >> is genreally a very heavy solution, and may not see much usage. >> Option 2 is really trivially done, either in gruu or elsewhere. >> The main issue is that it is another late change. >> -JOnathan R. >> Paul Kyzivat wrote: >>> Miguel, >>> >>> So to summarize, it seems you are of the belief that the cases >>> where these measures may be inadequate are sufficiently obscure >>> to ignore, and that new measures to cover the obscure cases are >>> unnecessary. Is that right? >>> >>> Paul >>> >>> Miguel Garcia wrote: >>> >>>> For issue 3, I would say that the solution is to avoid the >>>> situation, e.g., by registering way in advance before the >>>> registration expires. Doesn't RFC 3261 recommends to re-register >>>> half time before the registration timer expires. >>>> >>>> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't >>>> the GRUU draft have a recommendation on the usage of the reg >>>> event to solve them? >>>> >>>> /Miguel >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> After some study, I have encountered a potential difficulty in >>>>> determining when temp-gruus expire. After discussing this with >>>>> Jonathan we decided to bring it to the list for discussion. >>>>> >>>>> As now defined, when you first register you may get a temp- >>>>> gruu, which will remain valid as long as the registration does >>>>> not expire or be removed. (Removal is a special case of >>>>> expiration.) Each time the UA refreshes the registration it may >>>>> get a new temp-gruu which also remains valid for the life of >>>>> the registration. The UA can accumulate all these temp-gruus >>>>> and use them as it sees fit until they expire. >>>>> >>>>> The problem is: how does the UA know when the registration has >>>>> ended and the temp-gruus associated with it rendered invalid? >>>>> >>>>> This seems like a simple question, and in some cases it is >>>>> simple, but not in all cases. The following are at least some >>>>> of the ways that the registration can be ended, causing the >>>>> invalidation of temp-gruus: >>>>> 1) the UA that originally registered may explicitly deregister >>>>> 2) the UA the originally registered may simply permit the >>>>> registration to expire without attempting to refresh it >>>>> 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 >>>>> >>>>> In each of these cases the previously assigned temp-gruus >>>>> become invalid. If the UA continues to use them, bad things >>>>> will happen. This is true both for calls that are active when >>>>> the deregistration occurs, and calls that are established >>>>> later. What kinds of bad things happen? >>>>> - requests addressed to the gruu, both in-dialog and out-of-dialog >>>>> will be undeliverable. (For instance a reINVITE or BYE in an >>>>> existing call, or an out-of-dialog INVITE/Replaces for a >>>>> transfer.) >>>>> >>>>> - request originated by the UA using the invalid gruu will fail >>>>> immediately because the gruu is invalid. >>>>> >>>>> - if the UA subsequently reregisters, receives an incoming >>>>> call, and >>>>> uses one of the old temp-gruus as its contact, then the call >>>>> will >>>>> be established, but subsequent in- and out-of-dialog requests to >>>>> the contact will fail. >>>>> >>>>> So clearly it is important for the UA to stop using temp-gruus >>>>> that have become invalid. How can it know to do that in all of >>>>> the above cases? >>>>> >>>>> 1) is straightforward. The UA knows it is deregistering, and >>>>> should >>>>> discard any cached temp-gruus. If it has a dialog with one >>>>> of the >>>>> temp-gruus as a contact, then it should do a target refresh and >>>>> supply some working contact. (It really should do this *before* >>>>> deregistering, and for a pub-gruu as well.) >>>>> >>>>> 2) the UA should take all the actions mentioned for (1) at or >>>>> before >>>>> the expiration time. This should be done a bit early to guard >>>>> against clock skew problems. >>>>> >>>>> 3) in this case, it may be impossible for the UA to know whether >>>>> the REGISTER arrived in time to be a reREGISTER or if it >>>>> arrived >>>>> late and was treated as a new REGISTER after the expiration of >>>>> the old one. (The response to the REGISTER includes nothing >>>>> that >>>>> distinguishes the two cases.) About the best that can be >>>>> done in >>>>> this case is to check the time at which the response to the >>>>> REGISTER is received. If it falls after the expected expiration >>>>> time for the registration, act as if the old registration had >>>>> expired. >>>>> >>>>> 4) This is a major problem. Of course, regardless of GRUU, the UA >>>>> won't be able to receive incoming calls until it decides it is >>>>> time to refresh the registration. In addition, until the >>>>> registration reestablished, calls originated with one of its >>>>> existing gruus will fail. Once the registration is >>>>> reestablished, >>>>> it still won't know its old temp-gruus are invalid. The only >>>>> remedy for this is to subscribe to the "reg" event package, >>>>> and use the resulting notifications to identify when it has >>>>> been unregistered. If it does that, it can invalidate all its >>>>> old temp-gruus, and then presumably reregister. >>>>> >>>>> 5) this is functionally equivalent to (4), except that perhaps >>>>> attempts to reregister may fail. >>>>> >>>>> 6) this is also functionally equivalent to (4). >>>>> >>>>> The "reg" event does provide a fairly complete solution to this >>>>> problem, for those that are willing and able to use it. It is >>>>> not however a 100% reliable solution. Consider case (3), where >>>>> the UA has a reg event subscription. All is well if the >>>>> registration expires and a notification is sent indicating >>>>> that, and then the reregistration occurs and a notification is >>>>> sent about that. But if they happen very closely in time, it >>>>> may be that only one notification is sent, reflecting the >>>>> result of the reregistration. In that case the UA will not be >>>>> aware that it had been unregistered for a period of time. >>>>> >>>>> A *complete* solution would, IMO, involve changing REGISTER so >>>>> that it returns an indication of whether this was a new >>>>> registration, or a refresh. This could take many forms. For >>>>> instance the timestamp of the initial registration could always >>>>> be returned with each contact, as well as the expiration time. >>>>> >>>>> The big question is whether this is a big enough issue to >>>>> require a solution now, as part of GRUU, or if it can be >>>>> ignored as insignificant or postponed to future work. >>>>> >>>>> I'd appreciate hearing what others think about this. At the >>>>> moment I am leaning toward doing nothing, at least for now. >>>>> >>>>> 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 >>>>> >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 04:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWDw-0006WZ-E9; Tue, 05 Dec 2006 04:04:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWDv-0006WU-4U for sip@ietf.org; Tue, 05 Dec 2006 04:04:23 -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 1GrWDt-0000XE-L8 for sip@ietf.org; Tue, 05 Dec 2006 04:04:23 -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 kB593aMF012103; Tue, 5 Dec 2006 11:03:55 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:04:06 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:04:07 +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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 11:04:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccXzKD6kxTn6cizQEK6bBUDpV1I4wAfsysw From: To: , X-OriginalArrivalTime: 05 Dec 2006 09:04:07.0048 (UTC) FILETIME=[51B0F080:01C7184C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061205110356-2F1C8BB0-5AF8A534/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 don't see the point in this proposal. If the UA can establish a flow/connection for a reliable transport (TCP), why would it need the unreliable transport (UDP) flow in the first place? All traffic could be sent over TCP anyway.=20 Markus =20 >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 >Sent: 04 December, 2006 16:58 >To: Jeroen van Bemmel >Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org; Leis,Peter >Subject: Re: [Sip] Re: issue with oubound and the used=20 >transport protocol > >I like this proposal, although I would not use MUST. Either of=20 >these is optional. Both is recommended. > >Hisham > >On Nov 17, 2006, at 6:20 PM, Jeroen van Bemmel wrote: > >> The outbound draft needs to say: "if a UA establishes a flow=20 >using an=20 >> unreliable transport, it MUST also establish one over a reliable=20 >> transport" (to support switch over). Moreover, I would=20 >suggest to add=20 >> "it is RECOMMENDED that the UA establishes a flow using a reliable=20 >> transport" >> >> Regards, >> Jeroen >> >> > > >_______________________________________________ >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 Tue Dec 05 04:08:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWHb-0007zV-JK; Tue, 05 Dec 2006 04:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWHZ-0007yW-HZ for sip@ietf.org; Tue, 05 Dec 2006 04:08:09 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWHT-0001YD-Qi for sip@ietf.org; Tue, 05 Dec 2006 04:08:09 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 60A491944AB for ; Tue, 5 Dec 2006 10:07:57 +0100 (CET) Received: from [192.168.0.40] ([192.168.0.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 10:07:45 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 10:07:32 +0100 To: X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 05 Dec 2006 09:07:45.0291 (UTC) FILETIME=[D3C62DB0:01C7184C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 Because some service providers don't want to use TCP. Hisham On Dec 5, 2006, at 10:04 AM, wrote: > Hi, > > I don't see the point in this proposal. If the UA can establish a > flow/connection for a reliable transport (TCP), why would it need the > unreliable transport (UDP) flow in the first place? All traffic could > be > sent over TCP anyway. > > Markus > >> -----Original Message----- >> From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 04 December, 2006 16:58 >> To: Jeroen van Bemmel >> Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org; Leis,Peter >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> I like this proposal, although I would not use MUST. Either of >> these is optional. Both is recommended. >> >> Hisham >> >> On Nov 17, 2006, at 6:20 PM, Jeroen van Bemmel wrote: >> >>> The outbound draft needs to say: "if a UA establishes a flow >> using an >>> unreliable transport, it MUST also establish one over a reliable >>> transport" (to support switch over). Moreover, I would >> suggest to add >>> "it is RECOMMENDED that the UA establishes a flow using a reliable >>> transport" >>> >>> Regards, >>> Jeroen >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Dec 05 04:14:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWNb-0004OP-DP; Tue, 05 Dec 2006 04:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWNa-0004L2-8E for sip@ietf.org; Tue, 05 Dec 2006 04:14:22 -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 1GrWNX-00035a-OG for sip@ietf.org; Tue, 05 Dec 2006 04:14:22 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB59DljG024361; Tue, 5 Dec 2006 11:13:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:14:02 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:14:03 +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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 11:14:02 +0200 Message-ID: In-Reply-To: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYTN97GOFHNBZfSTa8dQrgB1aQYgAACLpA From: To: X-OriginalArrivalTime: 05 Dec 2006 09:14:03.0841 (UTC) FILETIME=[B5685310:01C7184D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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, The proposal says that the UA MUST open a reliable transport connection too. So, the service provider infra would need to support TCP connections from all UAs using outbound. So, if the service provider or the proxy vendor would be concerned about the number of TCP connections, this would not help. But are you saying that the issue would not the number of connections but the traffic over those connections? Can you elaborate this? Markus =20 >-----Original Message----- >From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 >Sent: 05 December, 2006 11:08 >To: Isomaki Markus (Nokia-SIR/Espoo) >Cc: peter.leis@siemens.com; fluffy@cisco.com;=20 >rohan@ekabal.com; sip@ietf.org; jbemmel@zonnet.nl >Subject: Re: [Sip] Re: issue with oubound and the used=20 >transport protocol > >Because some service providers don't want to use TCP. > >Hisham > >On Dec 5, 2006, at 10:04 AM, wrote: > >> Hi, >> >> I don't see the point in this proposal. If the UA can establish a=20 >> flow/connection for a reliable transport (TCP), why would it=20 >need the=20 >> unreliable transport (UDP) flow in the first place? All=20 >traffic could=20 >> be sent over TCP anyway. >> >> Markus >> >>> -----Original Message----- >>> From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: 04 December, 2006 16:58 >>> To: Jeroen van Bemmel >>> Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org; Leis,Peter >>> Subject: Re: [Sip] Re: issue with oubound and the used transport=20 >>> protocol >>> >>> I like this proposal, although I would not use MUST. Either=20 >of these=20 >>> is optional. Both is recommended. >>> >>> Hisham >>> >>> On Nov 17, 2006, at 6:20 PM, Jeroen van Bemmel wrote: >>> >>>> The outbound draft needs to say: "if a UA establishes a flow >>> using an >>>> unreliable transport, it MUST also establish one over a reliable=20 >>>> transport" (to support switch over). Moreover, I would >>> suggest to add >>>> "it is RECOMMENDED that the UA establishes a flow using a reliable=20 >>>> transport" >>>> >>>> Regards, >>>> Jeroen >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 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 Dec 05 04:22:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWUs-0007Eq-Vv; Tue, 05 Dec 2006 04:21:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWUr-0007BN-SV for sip@ietf.org; Tue, 05 Dec 2006 04:21:54 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWUq-0004wU-Jo for sip@ietf.org; Tue, 05 Dec 2006 04:21:53 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id B06C074186; Tue, 5 Dec 2006 10:21:31 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18343-01-51; Tue, 5 Dec 2006 10:21:31 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id EF9AA74008; Tue, 5 Dec 2006 10:21:30 +0100 (CET) Message-ID: <457539FF.3080400@it.su.se> Date: Tue, 05 Dec 2006 10:21:03 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> In-Reply-To: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.647 tagged_above=-99 required=7 tests=[AWL=0.018, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 Hisham Khartabil wrote: > Because some service providers don't want to use TCP. Spending IETF working group time and efforts on making standards that try to cope with people implementing only the bits and pieces they seem fit from earlier standards is both irresponsible and stupid. I know you know that TCP+TLS is mandated for a proxy by RFC3261. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 04:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWXM-00089x-QD; Tue, 05 Dec 2006 04:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWXL-00089p-6S for sip@ietf.org; Tue, 05 Dec 2006 04:24:27 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWXJ-0005hq-L5 for sip@ietf.org; Tue, 05 Dec 2006 04:24:27 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id F0CF51944AB for ; Tue, 5 Dec 2006 10:24:24 +0100 (CET) Received: from [192.168.0.40] ([192.168.0.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 10:24:10 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70ec247c47cbbde951e0a50a3f27e7d5@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 10:23:56 +0100 To: X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 05 Dec 2006 09:24:10.0078 (UTC) FILETIME=[1EC0BFE0:01C7184F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 Dec 5, 2006, at 10:14 AM, wrote: > Hi, > > The proposal says that the UA MUST open a reliable transport connection > too. My proposal didn't say MUST. Hisham > So, the service provider infra would need to support TCP > connections from all UAs using outbound. So, if the service provider or > the proxy vendor would be concerned about the number of TCP > connections, > this would not help. But are you saying that the issue would not the > number of connections but the traffic over those connections? Can you > elaborate this? > > Markus > > >> -----Original Message----- >> From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 05 December, 2006 11:08 >> To: Isomaki Markus (Nokia-SIR/Espoo) >> Cc: peter.leis@siemens.com; fluffy@cisco.com; >> rohan@ekabal.com; sip@ietf.org; jbemmel@zonnet.nl >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> Because some service providers don't want to use TCP. >> >> Hisham >> >> On Dec 5, 2006, at 10:04 AM, wrote: >> >>> Hi, >>> >>> I don't see the point in this proposal. If the UA can establish a >>> flow/connection for a reliable transport (TCP), why would it >> need the >>> unreliable transport (UDP) flow in the first place? All >> traffic could >>> be sent over TCP anyway. >>> >>> Markus >>> >>>> -----Original Message----- >>>> From: ext Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>>> Sent: 04 December, 2006 16:58 >>>> To: Jeroen van Bemmel >>>> Cc: fluffy@cisco.com; Rohan Mahy; sip@ietf.org; Leis,Peter >>>> Subject: Re: [Sip] Re: issue with oubound and the used transport >>>> protocol >>>> >>>> I like this proposal, although I would not use MUST. Either >> of these >>>> is optional. Both is recommended. >>>> >>>> Hisham >>>> >>>> On Nov 17, 2006, at 6:20 PM, Jeroen van Bemmel wrote: >>>> >>>>> The outbound draft needs to say: "if a UA establishes a flow >>>> using an >>>>> unreliable transport, it MUST also establish one over a reliable >>>>> transport" (to support switch over). Moreover, I would >>>> suggest to add >>>>> "it is RECOMMENDED that the UA establishes a flow using a reliable >>>>> transport" >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Dec 05 05:10:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrXEZ-00075G-Rv; Tue, 05 Dec 2006 05:09:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrXEY-000743-Lw for sip@ietf.org; Tue, 05 Dec 2006 05:09:06 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrXET-0001JI-2z for sip@ietf.org; Tue, 05 Dec 2006 05:09:06 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B5E331944D7 for ; Tue, 5 Dec 2006 11:08:57 +0100 (CET) Received: from [192.168.0.40] ([192.168.0.40]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:08:45 +0100 In-Reply-To: <457539FF.3080400@it.su.se> References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <457539FF.3080400@it.su.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 11:08:32 +0100 To: Fredrik Thulin X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 05 Dec 2006 10:08:45.0688 (UTC) FILETIME=[598A6F80:01C71855] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: > Hisham Khartabil wrote: >> Because some service providers don't want to use TCP. > > Spending IETF working group time and efforts on making standards that > try to cope with people implementing only the bits and pieces they > seem fit from earlier standards is both irresponsible and stupid. Spoken like a true academic. This has nothing to do with implementation, but has a lot to do with deployment. You can implement all the MUSTs you want, but you cannot mandate its use, TCP and TCP/TLS is one great example of that. If the IETF does not want to solve real life deployment problems but instead wants to solve academic ones, then service providers will start deploying proprietary solutions to fit their immediate needs and vendors will implement products that no service provider cares for. Thanks, Hisham > > I know you know that TCP+TLS is mandated for a proxy by RFC3261. > > /Fredrik > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 06:48:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYkz-0001va-5W; Tue, 05 Dec 2006 06:46:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYky-0001sR-8f for sip@ietf.org; Tue, 05 Dec 2006 06:46:40 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYkv-0005Wh-St for sip@ietf.org; Tue, 05 Dec 2006 06:46:40 -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 kB5Bk9Rj001973; Tue, 5 Dec 2006 05:46:12 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 05:45:38 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 12:45:36 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 12:45:35 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180919575@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYVmkP5th6SY3BTyW48mEnRGaPyAAC5lzA From: "Drage, Keith \(Keith\)" To: "Hisham Khartabil" , "Fredrik Thulin" X-OriginalArrivalTime: 05 Dec 2006 11:45:36.0452 (UTC) FILETIME=[E106A840:01C71862] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 While I would not necessarily have phrased it as Fredrik did, he is right. If you don't want to reflect the previous decisions of the SIP WG that already exist in published deliverables, then you should be seeking to change those published deliverables. For security, the way to do that is by discussing and including appropriate text in draft-ietf-sip-sips-00. I don't believe I have seen much Hisham sourced input. If we don't do this we end up down a compatibility discussions rathole from which the group will never emerge. Regards Keith > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 > Sent: 05 December 2006 10:09 > To: Fredrik Thulin > Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org;=20 > peter.leis@siemens.com; Markus.Isomaki@nokia.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: >=20 > > Hisham Khartabil wrote: > >> Because some service providers don't want to use TCP. > > > > Spending IETF working group time and efforts on making=20 > standards that=20 > > try to cope with people implementing only the bits and pieces they=20 > > seem fit from earlier standards is both irresponsible and stupid. >=20 > Spoken like a true academic. This has nothing to do with=20 > implementation, but has a lot to do with deployment. You can=20 > implement all the MUSTs you want, but you cannot mandate its=20 > use, TCP and TCP/TLS is one great example of that. >=20 > If the IETF does not want to solve real life deployment=20 > problems but instead wants to solve academic ones, then=20 > service providers will start deploying proprietary solutions=20 > to fit their immediate needs and vendors will implement=20 > products that no service provider cares for. >=20 > Thanks, > Hisham >=20 > > > > I know you know that TCP+TLS is mandated for a proxy by RFC3261. > > > > /Fredrik > > >=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 Tue Dec 05 07:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZ7s-0000Ne-7G; Tue, 05 Dec 2006 07:10:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZ7S-0008DL-Og for sip@ietf.org; Tue, 05 Dec 2006 07:09:54 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZ6J-0001YW-K4 for sip@ietf.org; Tue, 05 Dec 2006 07:08:46 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id BA5B03BF07; Tue, 5 Dec 2006 13:08:28 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02710-01-6; Tue, 5 Dec 2006 13:08:28 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id ABA8C3BEEE; Tue, 5 Dec 2006 13:08:19 +0100 (CET) Message-ID: <45756118.6020004@it.su.se> Date: Tue, 05 Dec 2006 13:07:52 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <457539FF.3080400@it.su.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.65 tagged_above=-99 required=7 tests=[AWL=0.015, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 Hisham Khartabil wrote: > > On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: > >> Hisham Khartabil wrote: >>> Because some service providers don't want to use TCP. >> >> Spending IETF working group time and efforts on making standards that >> try to cope with people implementing only the bits and pieces they >> seem fit from earlier standards is both irresponsible and stupid. > > Spoken like a true academic. This has nothing to do with implementation, > but has a lot to do with deployment. You can implement all the MUSTs you > want, but you cannot mandate its use, TCP and TCP/TLS is one great > example of that. > > If the IETF does not want to solve real life deployment problems but > instead wants to solve academic ones, then service providers will start > deploying proprietary solutions to fit their immediate needs and vendors > will implement products that no service provider cares for. After sending I realized that my words were a bit harsh, for which I apologize. I guess you mistake the university domain name of mine with academic reasoning, but the truth is that I am _not_ interested in SIP in an academic way. I'm actually trying to deploy SIP on Stockholm university. Even though I have implemented lots of things (including draft-outbound 03) my primary concern is deployment, I can assure you. If there is anything I need for deployment it is simplicity. Outbound with TCP/TLS is a piece of cake - Outbound with UDP clearly is not. It is not TCP/TLS that is adding complexity, but UDP. I mentioned in another e-mail that my code to deframe SIP messages received over streams were less than 130 lines of code. My STUN demuxing-responding code for UDP is about the double of that. I'm assuming that you are a provider of SIP service to end users who might often be behind NAT. Can you please explain how you see it as the most deployable solution to base it all on UDP instead of offering TCP/TLS in your service and even advocating the use of UACs that support TCP/TLS? /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 07:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZC7-0004Fb-N5; Tue, 05 Dec 2006 07:14:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZC6-0004FO-Gq for sip@ietf.org; Tue, 05 Dec 2006 07:14:42 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZC5-0002Hn-1E for sip@ietf.org; Tue, 05 Dec 2006 07:14:42 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 565E6762; Tue, 5 Dec 2006 13:14:38 +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, 5 Dec 2006 13:14:38 +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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 13:14:36 +0100 Message-ID: <7374777208BDC7449D5620EF94232567C44F8A@esealmw113.eemea.ericsson.se> In-Reply-To: <45756118.6020004@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYZpxlb6BVdD49QdKL+Fw683CHowAADoeA From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , "Hisham Khartabil" X-OriginalArrivalTime: 05 Dec 2006 12:14:38.0038 (UTC) FILETIME=[EF179760:01C71866] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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, I still fail to see all the "complexity" that UDP adds. Regards, Christer=20 > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se]=20 > Sent: 5. joulukuuta 2006 14:08 > To: Hisham Khartabil > Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org;=20 > peter.leis@siemens.com; Markus.Isomaki@nokia.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Hisham Khartabil wrote: > >=20 > > On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: > >=20 > >> Hisham Khartabil wrote: > >>> Because some service providers don't want to use TCP. > >> > >> Spending IETF working group time and efforts on making=20 > standards that=20 > >> try to cope with people implementing only the bits and pieces they=20 > >> seem fit from earlier standards is both irresponsible and stupid. > >=20 > > Spoken like a true academic. This has nothing to do with=20 > > implementation, but has a lot to do with deployment. You=20 > can implement=20 > > all the MUSTs you want, but you cannot mandate its use, TCP and=20 > > TCP/TLS is one great example of that. > >=20 > > If the IETF does not want to solve real life deployment=20 > problems but=20 > > instead wants to solve academic ones, then service providers will=20 > > start deploying proprietary solutions to fit their=20 > immediate needs and=20 > > vendors will implement products that no service provider cares for. >=20 > After sending I realized that my words were a bit harsh, for=20 > which I apologize. I guess you mistake the university domain=20 > name of mine with academic reasoning, but the truth is that I=20 > am _not_ interested in SIP in an academic way. I'm actually=20 > trying to deploy SIP on Stockholm university. >=20 > Even though I have implemented lots of things (including=20 > draft-outbound > 03) my primary concern is deployment, I can assure you. If=20 > there is anything I need for deployment it is simplicity.=20 > Outbound with TCP/TLS is a piece of cake - Outbound with UDP=20 > clearly is not. It is not TCP/TLS that is adding complexity,=20 > but UDP. I mentioned in another e-mail that my code to=20 > deframe SIP messages received over streams were less than 130=20 > lines of code. My STUN demuxing-responding code for UDP is=20 > about the double of that. >=20 > I'm assuming that you are a provider of SIP service to end=20 > users who might often be behind NAT. Can you please explain=20 > how you see it as the most deployable solution to base it all=20 > on UDP instead of offering TCP/TLS in your service and even=20 > advocating the use of UACs that support TCP/TLS? >=20 > /Fredrik >=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 Tue Dec 05 07:38:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZYT-00067P-AL; Tue, 05 Dec 2006 07:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZYS-000671-D0 for sip@ietf.org; Tue, 05 Dec 2006 07:37:48 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZYI-0006Uk-Eu for sip@ietf.org; Tue, 05 Dec 2006 07:37:48 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 728C074173; Tue, 5 Dec 2006 13:37:23 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17407-01-82; Tue, 5 Dec 2006 13:37:23 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 320F574099; Tue, 5 Dec 2006 13:37:10 +0100 (CET) Message-ID: <457567DA.8080709@it.su.se> Date: Tue, 05 Dec 2006 13:36:42 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <7374777208BDC7449D5620EF94232567C44F8A@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567C44F8A@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.647 tagged_above=-99 required=7 tests=[AWL=0.018, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.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 still fail to see all the "complexity" that UDP adds. From the top of my head, 1) requiring STUN keepalives and de-muxing 2) much more keepalives (every 29s instead of 120s) 3) having to do resends yourself (not specific to Outbound) 4) being insufficient in itself (having limitation of request size), therefor not adding any value when you _still_ have to do TCP/TLS as well as UDP /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 08:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grans-000507-Qn; Tue, 05 Dec 2006 08:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Granq-0004zz-SW for sip@ietf.org; Tue, 05 Dec 2006 08:57:46 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Granp-0001x4-2U for sip@ietf.org; Tue, 05 Dec 2006 08:57:46 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 05 Dec 2006 05:57:44 -0800 X-IronPort-AV: i="4.09,499,1157353200"; d="scan'208"; a="89775545:sNHT70172604" 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 kB5Dvi9t006686; Tue, 5 Dec 2006 05:57:44 -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 kB5DuwOl001063; Tue, 5 Dec 2006 05:57:38 -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); Tue, 5 Dec 2006 08:57:07 -0500 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 08:57:06 -0500 Message-ID: <45757AB1.4010200@cisco.com> Date: Tue, 05 Dec 2006 08:57:05 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Issue: Expiration of temp-gruu References: <456E15CD.60805@cisco.com> <45703AA0.20007@nokia.com> <457057A6.4020804@cisco.com> <45707D8A.8020001@cisco.com> <457436A3.50606@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2006 13:57:06.0482 (UTC) FILETIME=[3FD9B120:01C71875] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10627; t=1165327064; x=1166191064; 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=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20; bh=BmvkweEtFGZ57mLaHo6X3g8L9DVG8qQvVp9Srqkf3nU=; b=HZDsG0lZYnzx3yKYulCV0uHNc1ifjqyoDWJawmUimCF21Wp/vnRWPQD7xM0mA7tFt7fieL27 K1kCZureYeaGOHYpbx1Y9sOuIaB6vVuGXzuyp2PE64Xq3A3XTCpZZJnP; 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: bc6181926481d86059e678c9f7cb8b34 Cc: Miguel Garcia , SIP IETF 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 Willis wrote: > > Would a third party observing multiple uses of temp-gruu be able to > correlate them from this time-stamp and therefore make a reasonable > deduction that all the temp-gruus were bound to the same Contact and > therefore used by the same user? The timestamp is only in the response to REGISTER. It isn't embedded in the gruu itself and so isn't visible to those receiving the gruu as a remote target or whatever. (There is likely a timestamp *in* the gruu as well (along with the AOR and instance id), used to determine its validity. But when using that technique to construct temp gruus it will be necessary to encrypt all that info so that only the registrar/proxy can extract it. Paul > Would we care? > > -- > Dean > > > On Dec 4, 2006, at 8:54 AM, Miguel Garcia wrote: > >> I just checked the latest SIPit report, and it seems that only 5 >> implementations supported reg event, as opposed to 29 that supported >> refer, 23 message-summary, or 14 presence. >> >> Well, this probably indicates that reg-event is not widely deployed to >> justify a solution based on it. Therefore, I don't mind Jonathan's >> solution #2 >> >> /Miguel >> >> Jonathan Rosenberg wrote: >>> The main question is really to decide on one of two mechanisms: >>> 1. use reg-event if you are worried about use cases where this race >>> condition can occur (4-6 in Paul's original email) >>> 2. add a parameter to Contact in the register response. Specifically, >>> I'd recommend a Contact header field parameter which indicates the >>> time at which the first contact with a given instance ID was >>> registered to that AOR. This value gets linked with each temp gruu, >>> and when the value changes, all of those temp-gruu get invalidated. >>> Solution (2) is much simpler, but not needed if you think you'll >>> always have reg-event anyway. I don't think there is widespread >>> support for reg-event on endpoints yet. It is required by IMS. >>> I am somewhat on the fence on this one. I do worry that reg-event is >>> genreally a very heavy solution, and may not see much usage. Option 2 >>> is really trivially done, either in gruu or elsewhere. The main issue >>> is that it is another late change. >>> -JOnathan R. >>> Paul Kyzivat wrote: >>>> Miguel, >>>> >>>> So to summarize, it seems you are of the belief that the cases where >>>> these measures may be inadequate are sufficiently obscure to ignore, >>>> and that new measures to cover the obscure cases are unnecessary. Is >>>> that right? >>>> >>>> Paul >>>> >>>> Miguel Garcia wrote: >>>> >>>>> For issue 3, I would say that the solution is to avoid the >>>>> situation, e.g., by registering way in advance before the >>>>> registration expires. Doesn't RFC 3261 recommends to re-register >>>>> half time before the registration timer expires. >>>>> >>>>> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the >>>>> GRUU draft have a recommendation on the usage of the reg event to >>>>> solve them? >>>>> >>>>> /Miguel >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> After some study, I have encountered a potential difficulty in >>>>>> determining when temp-gruus expire. After discussing this with >>>>>> Jonathan we decided to bring it to the list for discussion. >>>>>> >>>>>> As now defined, when you first register you may get a temp-gruu, >>>>>> which will remain valid as long as the registration does not >>>>>> expire or be removed. (Removal is a special case of expiration.) >>>>>> Each time the UA refreshes the registration it may get a new >>>>>> temp-gruu which also remains valid for the life of the >>>>>> registration. The UA can accumulate all these temp-gruus and use >>>>>> them as it sees fit until they expire. >>>>>> >>>>>> The problem is: how does the UA know when the registration has >>>>>> ended and the temp-gruus associated with it rendered invalid? >>>>>> >>>>>> This seems like a simple question, and in some cases it is simple, >>>>>> but not in all cases. The following are at least some of the ways >>>>>> that the registration can be ended, causing the invalidation of >>>>>> temp-gruus: >>>>>> 1) the UA that originally registered may explicitly deregister >>>>>> 2) the UA the originally registered may simply permit the >>>>>> registration to expire without attempting to refresh it >>>>>> 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 >>>>>> >>>>>> In each of these cases the previously assigned temp-gruus become >>>>>> invalid. If the UA continues to use them, bad things will happen. >>>>>> This is true both for calls that are active when the >>>>>> deregistration occurs, and calls that are established later. What >>>>>> kinds of bad things happen? >>>>>> - requests addressed to the gruu, both in-dialog and out-of-dialog >>>>>> will be undeliverable. (For instance a reINVITE or BYE in an >>>>>> existing call, or an out-of-dialog INVITE/Replaces for a transfer.) >>>>>> >>>>>> - request originated by the UA using the invalid gruu will fail >>>>>> immediately because the gruu is invalid. >>>>>> >>>>>> - if the UA subsequently reregisters, receives an incoming call, and >>>>>> uses one of the old temp-gruus as its contact, then the call will >>>>>> be established, but subsequent in- and out-of-dialog requests to >>>>>> the contact will fail. >>>>>> >>>>>> So clearly it is important for the UA to stop using temp-gruus >>>>>> that have become invalid. How can it know to do that in all of the >>>>>> above cases? >>>>>> >>>>>> 1) is straightforward. The UA knows it is deregistering, and should >>>>>> discard any cached temp-gruus. If it has a dialog with one of the >>>>>> temp-gruus as a contact, then it should do a target refresh and >>>>>> supply some working contact. (It really should do this *before* >>>>>> deregistering, and for a pub-gruu as well.) >>>>>> >>>>>> 2) the UA should take all the actions mentioned for (1) at or before >>>>>> the expiration time. This should be done a bit early to guard >>>>>> against clock skew problems. >>>>>> >>>>>> 3) in this case, it may be impossible for the UA to know whether >>>>>> the REGISTER arrived in time to be a reREGISTER or if it arrived >>>>>> late and was treated as a new REGISTER after the expiration of >>>>>> the old one. (The response to the REGISTER includes nothing that >>>>>> distinguishes the two cases.) About the best that can be done in >>>>>> this case is to check the time at which the response to the >>>>>> REGISTER is received. If it falls after the expected expiration >>>>>> time for the registration, act as if the old registration had >>>>>> expired. >>>>>> >>>>>> 4) This is a major problem. Of course, regardless of GRUU, the UA >>>>>> won't be able to receive incoming calls until it decides it is >>>>>> time to refresh the registration. In addition, until the >>>>>> registration reestablished, calls originated with one of its >>>>>> existing gruus will fail. Once the registration is reestablished, >>>>>> it still won't know its old temp-gruus are invalid. The only >>>>>> remedy for this is to subscribe to the "reg" event package, >>>>>> and use the resulting notifications to identify when it has >>>>>> been unregistered. If it does that, it can invalidate all its >>>>>> old temp-gruus, and then presumably reregister. >>>>>> >>>>>> 5) this is functionally equivalent to (4), except that perhaps >>>>>> attempts to reregister may fail. >>>>>> >>>>>> 6) this is also functionally equivalent to (4). >>>>>> >>>>>> The "reg" event does provide a fairly complete solution to this >>>>>> problem, for those that are willing and able to use it. It is not >>>>>> however a 100% reliable solution. Consider case (3), where the UA >>>>>> has a reg event subscription. All is well if the registration >>>>>> expires and a notification is sent indicating that, and then the >>>>>> reregistration occurs and a notification is sent about that. But >>>>>> if they happen very closely in time, it may be that only one >>>>>> notification is sent, reflecting the result of the reregistration. >>>>>> In that case the UA will not be aware that it had been >>>>>> unregistered for a period of time. >>>>>> >>>>>> A *complete* solution would, IMO, involve changing REGISTER so >>>>>> that it returns an indication of whether this was a new >>>>>> registration, or a refresh. This could take many forms. For >>>>>> instance the timestamp of the initial registration could always be >>>>>> returned with each contact, as well as the expiration time. >>>>>> >>>>>> The big question is whether this is a big enough issue to require >>>>>> a solution now, as part of GRUU, or if it can be ignored as >>>>>> insignificant or postponed to future work. >>>>>> >>>>>> I'd appreciate hearing what others think about this. At the moment >>>>>> I am leaning toward doing nothing, at least for now. >>>>>> >>>>>> 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 >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 09:34:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrbMo-0004Sd-BV; Tue, 05 Dec 2006 09:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrbMm-0004SY-Mc for sip@ietf.org; Tue, 05 Dec 2006 09:33:52 -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 1GrbMl-0000bV-8b for sip@ietf.org; Tue, 05 Dec 2006 09:33:52 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB5EX8Yh006514; Tue, 5 Dec 2006 16:33:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 16:33:24 +0200 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 16:33:22 +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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 16:33:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYVmEt/K35vQt3Tg6+wdEMpLM4eQAIxOSQ From: To: , X-OriginalArrivalTime: 05 Dec 2006 14:33:22.0289 (UTC) FILETIME=[50BB7E10:01C7187A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, peter.leis@siemens.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 >If the IETF does not want to solve real life deployment=20 >problems but instead wants to solve academic ones, then=20 >service providers will start deploying proprietary solutions=20 >to fit their immediate needs and vendors will implement=20 >products that no service provider cares for. Can you pinpont exactly the real life deployment problems you mention with using TCP? Does it have something to do with server-side scalability? I personally believe going TCP-only would actually help deployment rather than hinder it, but I'd be really interested to be convinced otherwise. 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 Tue Dec 05 10:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcDn-0004pb-Uw; Tue, 05 Dec 2006 10:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcDm-0004pO-4q for sip@ietf.org; Tue, 05 Dec 2006 10:28:38 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrcDi-0002o0-Sc for sip@ietf.org; Tue, 05 Dec 2006 10:28:38 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20061205152833m1200sf8fre>; Tue, 5 Dec 2006 15:28:34 +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 kB5FSWuu027766 for ; Tue, 5 Dec 2006 10:28:32 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kB5FSWif027762; Tue, 5 Dec 2006 10:28:32 -0500 Date: Tue, 5 Dec 2006 10:28:32 -0500 Message-Id: <200612051528.kB5FSWif027762@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> (hisham.khartabil@telio.no) Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: Hisham Khartabil Because some service providers don't want to use TCP. Why? I think adding a little more detail to this statement would help. Stated this plainly, my mind appends "... because they are petulant". But if service providers are avoiding TCP because there is some genuine burden associated with using TCP, that must be expressible as a requirement, one which may well have been overlooked. So expressing the requirement in as much detail as possible will help us progress. Not knowing much about the subject, my guess would be that TCP has overheads, in that one must keep significant state about each connection and perhaps send keepalive packets periodically. But outbound seems to incorporate those already; I don't see how TCP could be more burdensome than UDP-with-outbound. 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 Dec 05 11:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrclS-0002Rv-In; Tue, 05 Dec 2006 11:03:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrclQ-0002Rp-VO for sip@ietf.org; Tue, 05 Dec 2006 11:03:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrclP-0005ne-HP for sip@ietf.org; Tue, 05 Dec 2006 11:03:24 -0500 Received: from [206.176.144.212] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kB5F7DwS023722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Dec 2006 09:07:20 -0600 In-Reply-To: <200612051528.kB5FSWif027762@dragon.ariadne.com> References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <200612051528.kB5FSWif027762@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: <8B658935-C258-4547-B748-84EB6A7E3EE9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 10:03:03 -0600 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) 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 On Dec 5, 2006, at 9:28 AM, Dale.Worley@comcast.net wrote: > From: Hisham Khartabil > > Because some service providers don't want to use TCP. > > Why? I think adding a little more detail to this statement would > help. Stated this plainly, my mind appends "... because they are > petulant". > > But if service providers are avoiding TCP because there is some > genuine burden associated with using TCP, that must be expressible as > a requirement, one which may well have been overlooked. So expressing > the requirement in as much detail as possible will help us progress. > > Not knowing much about the subject, my guess would be that TCP has > overheads, in that one must keep significant state about each > connection and perhaps send keepalive packets periodically. But > outbound seems to incorporate those already; I don't see how TCP could > be more burdensome than UDP-with-outbound. > The simplest answer, which we've discussed here previously, is that a naive implementation of a proxy using TCP is limited by the number of sockets provided by the OS, which is usually something less than the number of file handles and tends to be less than 64k. This caps the "fan out" of a proxy" at a number smaller than some operators would like. Of course, it's possible to write a more sophisticated proxy using select/poll that doesn't have this limitation, but only on OS that support it. There's another answer occasionally used that is far less supportable: many people in the mobile community have historically believed that TCP is less suitable than UDP for mobile networks, because the reliability and timing properties of those networks are different. These networks also don't use NAT or "outbound" per se, and therefore generally do not do keepalives at the IP level. Given this, UDP implementations are more air-efficient than naive TCP implementations because of TCP keepalive and retransmission. Of course, one can make a slightly smarter TCP implementation that does very little TCP keepalive, so once again we've learned how to mostly overcome this objection. One other thing that UDP makes easier is fault tolerance across a proxy farm with replicated state. Of course, we've also learned how to do this with TCP (and even with TLS) at reasonable levels of efficiency. In other words, to the best of my knowledge, the only good reason to keep using UDP is because you have it deployed already and don't want to change, because change is expensive and disruptive. Of course, if one is going to phase in "outbound", one is going to have to make similar changes. We should keep this in mind -- Change isn't mandatory. Neither is survival. But if you're unwilling to do the first, you're unlikely to achieve the second. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 11:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdBy-0005qA-KR; Tue, 05 Dec 2006 11:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdBw-0005oB-FR for sip@ietf.org; Tue, 05 Dec 2006 11:30:48 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdBu-0003nd-51 for sip@ietf.org; Tue, 05 Dec 2006 11:30:48 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 17EA66C017; Tue, 5 Dec 2006 11:30:28 -0500 (EST) Subject: Re: [Sip] Issue: Expiration of temp-gruu From: Scott Lawrence To: Paul Kyzivat In-Reply-To: <45749DF6.7040803@cisco.com> References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Tue, 05 Dec 2006 11:30:39 -0500 Message-Id: <1165336240.3208.72.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIP IETF 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, 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. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Dec 05 11:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdC3-00062G-D2; Tue, 05 Dec 2006 11:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdC2-0005yl-HU for sip@ietf.org; Tue, 05 Dec 2006 11:30:54 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdC0-0003nb-3o for sip@ietf.org; Tue, 05 Dec 2006 11:30:54 -0500 Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB5GU8217678; Tue, 5 Dec 2006 08:30:08 -0800 In-Reply-To: <5D1A7985295922448D5550C94DE29180919575@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180919575@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 08:30:12 -0800 To: "Drage, Keith \(Keith\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: fluffy@cisco.com, Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.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 Keith, I don't believe Hisham was objecting here to MUST implement. I think Hisham is objecting to adding a MUST use statement to outbound. thanks, -rohan On Dec 5, 2006, at 3:45, Drage, Keith ((Keith)) wrote: > While I would not necessarily have phrased it as Fredrik did, he is > right. > > If you don't want to reflect the previous decisions of the SIP WG that > already exist in published deliverables, then you should be seeking to > change those published deliverables. > > For security, the way to do that is by discussing and including > appropriate text in draft-ietf-sip-sips-00. I don't believe I have seen > much Hisham sourced input. > > If we don't do this we end up down a compatibility discussions rathole > from which the group will never emerge. > > Regards > > Keith > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 05 December 2006 10:09 >> To: Fredrik Thulin >> Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org; >> peter.leis@siemens.com; Markus.Isomaki@nokia.com >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> >> On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: >> >>> Hisham Khartabil wrote: >>>> Because some service providers don't want to use TCP. >>> >>> Spending IETF working group time and efforts on making >> standards that >>> try to cope with people implementing only the bits and pieces they >>> seem fit from earlier standards is both irresponsible and stupid. >> >> Spoken like a true academic. This has nothing to do with >> implementation, but has a lot to do with deployment. You can >> implement all the MUSTs you want, but you cannot mandate its >> use, TCP and TCP/TLS is one great example of that. >> >> If the IETF does not want to solve real life deployment >> problems but instead wants to solve academic ones, then >> service providers will start deploying proprietary solutions >> to fit their immediate needs and vendors will implement >> products that no service provider cares for. >> >> Thanks, >> Hisham >> >>> >>> I know you know that TCP+TLS is mandated for a proxy by RFC3261. >>> >>> /Fredrik >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Dec 05 11:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdBy-0005qA-KR; Tue, 05 Dec 2006 11:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdBw-0005oB-FR for sip@ietf.org; Tue, 05 Dec 2006 11:30:48 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdBu-0003nd-51 for sip@ietf.org; Tue, 05 Dec 2006 11:30:48 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 17EA66C017; Tue, 5 Dec 2006 11:30:28 -0500 (EST) Subject: Re: [Sip] Issue: Expiration of temp-gruu From: Scott Lawrence To: Paul Kyzivat In-Reply-To: <45749DF6.7040803@cisco.com> References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Tue, 05 Dec 2006 11:30:39 -0500 Message-Id: <1165336240.3208.72.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIP IETF 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, 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. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Dec 05 11:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdC3-00062G-D2; Tue, 05 Dec 2006 11:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdC2-0005yl-HU for sip@ietf.org; Tue, 05 Dec 2006 11:30:54 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdC0-0003nb-3o for sip@ietf.org; Tue, 05 Dec 2006 11:30:54 -0500 Received: from [131.161.248.88] (open-131-161-248-88.cliq.com [131.161.248.88]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB5GU8217678; Tue, 5 Dec 2006 08:30:08 -0800 In-Reply-To: <5D1A7985295922448D5550C94DE29180919575@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180919575@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 08:30:12 -0800 To: "Drage, Keith \(Keith\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: fluffy@cisco.com, Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.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 Keith, I don't believe Hisham was objecting here to MUST implement. I think Hisham is objecting to adding a MUST use statement to outbound. thanks, -rohan On Dec 5, 2006, at 3:45, Drage, Keith ((Keith)) wrote: > While I would not necessarily have phrased it as Fredrik did, he is > right. > > If you don't want to reflect the previous decisions of the SIP WG that > already exist in published deliverables, then you should be seeking to > change those published deliverables. > > For security, the way to do that is by discussing and including > appropriate text in draft-ietf-sip-sips-00. I don't believe I have seen > much Hisham sourced input. > > If we don't do this we end up down a compatibility discussions rathole > from which the group will never emerge. > > Regards > > Keith > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 05 December 2006 10:09 >> To: Fredrik Thulin >> Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org; >> peter.leis@siemens.com; Markus.Isomaki@nokia.com >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> >> On Dec 5, 2006, at 10:21 AM, Fredrik Thulin wrote: >> >>> Hisham Khartabil wrote: >>>> Because some service providers don't want to use TCP. >>> >>> Spending IETF working group time and efforts on making >> standards that >>> try to cope with people implementing only the bits and pieces they >>> seem fit from earlier standards is both irresponsible and stupid. >> >> Spoken like a true academic. This has nothing to do with >> implementation, but has a lot to do with deployment. You can >> implement all the MUSTs you want, but you cannot mandate its >> use, TCP and TCP/TLS is one great example of that. >> >> If the IETF does not want to solve real life deployment >> problems but instead wants to solve academic ones, then >> service providers will start deploying proprietary solutions >> to fit their immediate needs and vendors will implement >> products that no service provider cares for. >> >> Thanks, >> Hisham >> >>> >>> I know you know that TCP+TLS is mandated for a proxy by RFC3261. >>> >>> /Fredrik >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Dec 05 11:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdGm-0001Pu-Q2; Tue, 05 Dec 2006 11:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdGk-0001Pp-IH for sip@ietf.org; Tue, 05 Dec 2006 11:35:46 -0500 Received: from rvil-eframer.radvision.com ([80.74.106.104] helo=eframer.radvision.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdGi-0004AE-Rn for sip@ietf.org; Tue, 05 Dec 2006 11:35:46 -0500 Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id kB5Gcf1u020199 for sip@ietf.org; Tue, 5 Dec 2006 18:38:41 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id kB5GceWJ020193 for ; Tue, 5 Dec 2006 18:38:40 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Dec 2006 18:37:13 +0200 Message-ID: <7579E2B4F92E89429C01EA57E4E6DBBB437CCD@rvil-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: watcher XML: why package parameter in watcher-list Thread-Index: AccXh82535gbOaZoSs6f53oAABBQyw== From: "Tamar Barzuza" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Sip] watcher XML: why package parameter in watcher-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="===============1234864021==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1234864021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7188B.9E2803A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7188B.9E2803A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, A NOTIFY request containing watcher XML contains also an Event header that indicates the event package this NOTIFY relates to. However, RFC3858 instructs us to add a mandatory "package" parameter to each watcher list of the watcher XML.=20 Why should there be a "package" parameter in every watcher-list? Why is the event package of the Event header in the NOTIFY request insufficient?=20 Thank you, Tamar Barzuza. ------_=_NextPart_001_01C7188B.9E2803A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

A NOTIFY request containing watcher XML contains also an Event header that indicates the event package this NOTIFY relates to. However, RFC3858 = instructs us to add a mandatory "package" parameter to each watcher list = of the watcher XML.

Why should there be a "package" parameter in every watcher-list? = Why is the event package of the Event header in the NOTIFY request = insufficient?

Thank you,

Tamar Barzuza.

------_=_NextPart_001_01C7188B.9E2803A1-- --===============1234864021== 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 --===============1234864021==-- From sip-bounces@ietf.org Tue Dec 05 14:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrfsP-0005Wo-Qd; Tue, 05 Dec 2006 14:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrfsO-0005Wh-Ba for sip@ietf.org; Tue, 05 Dec 2006 14:22:48 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrfsH-00059p-TU for sip@ietf.org; Tue, 05 Dec 2006 14:22:48 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 0B3821944E2 for ; Tue, 5 Dec 2006 20:22:41 +0100 (CET) Received: from [10.150.30.74] ([212.17.141.53]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 20:22:27 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 20:22:10 +0100 To: X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 05 Dec 2006 19:22:28.0803 (UTC) FILETIME=[B40F7930:01C718A2] X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: fluffy@cisco.com, rohan@ekabal.com, ft@it.su.se, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.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 Dec 5, 2006, at 3:33 PM, wrote: > >> If the IETF does not want to solve real life deployment >> problems but instead wants to solve academic ones, then >> service providers will start deploying proprietary solutions >> to fit their immediate needs and vendors will implement >> products that no service provider cares for. > > Can you pinpont exactly the real life deployment problems you mention > with using TCP? Does it have something to do with server-side > scalability? > > I personally believe going TCP-only would actually help deployment > rather than hinder it, but I'd be really interested to be convinced > otherwise. I could ask you the converse. I'd really be interested to be convinced how TCP deployment improves scalability. Hisham > > 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 Tue Dec 05 14:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grfz2-0001Ch-2I; Tue, 05 Dec 2006 14:29:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grfz1-0001Cc-4E for sip@ietf.org; Tue, 05 Dec 2006 14:29:39 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grfyz-0006qU-UQ for sip@ietf.org; Tue, 05 Dec 2006 14:29:39 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2006120519281301100mmoc0e>; Tue, 5 Dec 2006 19:29:37 +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 kB5JSCuu012807 for ; Tue, 5 Dec 2006 14:28:12 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kB5JSCnu012803; Tue, 5 Dec 2006 14:28:12 -0500 Date: Tue, 5 Dec 2006 14:28:12 -0500 Message-Id: <200612051928.kB5JSCnu012803@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <8B658935-C258-4547-B748-84EB6A7E3EE9@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <200612051528.kB5FSWif027762@dragon.ariadne.com> <8B658935-C258-4547-B748-84EB6A7E3EE9@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: Dean Willis In other words, to the best of my knowledge, the only good reason to keep using UDP is because you have it deployed already and don't want to change, because change is expensive and disruptive. Which is actually a legitimate requirement, if the amount of money/trouble is economically significant in an industry. Of course, if one is going to phase in "outbound", one is going to have to make similar changes. It seems to me that that is the bottom line -- installing UDP-with-outbound-keepalives is going to be nearly as much work as installing TCP, so better to use TCP, which has better long-term prospects. I would, however, like to hear an analysis from someone who is forseeing trouble from TCP. 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 Dec 05 14:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grg4E-0003oS-33; Tue, 05 Dec 2006 14:35:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grg4D-0003oL-7i for sip@ietf.org; Tue, 05 Dec 2006 14:35:01 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grg4B-0008Ig-OF for sip@ietf.org; Tue, 05 Dec 2006 14:35:01 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B11ED1944D5 for ; Tue, 5 Dec 2006 20:34:58 +0100 (CET) Received: from [10.150.30.74] ([212.17.141.53]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 20:34:46 +0100 In-Reply-To: <200612051528.kB5FSWif027762@dragon.ariadne.com> References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <200612051528.kB5FSWif027762@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3f9af3b5cb86e8cce5fbe7adc1f62d27@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 20:34:31 +0100 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 05 Dec 2006 19:34:46.0413 (UTC) FILETIME=[6BB5D3D0:01C718A4] X-Spam-Score: 1.8 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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, Besides scalability issues, there are no technical issues. The issues are with having to throw all the infrastructure we currently have out of the window and start all over again. Having 110k+ customers live does not make is an easy and justifiable task. Why do we prefer to run away from the problem and ignore it pretending it does not "really" exist instead of trying to fix it? Hisham On Dec 5, 2006, at 4:28 PM, Dale.Worley@comcast.net wrote: > From: Hisham Khartabil > > Because some service providers don't want to use TCP. > > Why? I think adding a little more detail to this statement would > help. Stated this plainly, my mind appends "... because they are > petulant". > > But if service providers are avoiding TCP because there is some > genuine burden associated with using TCP, that must be expressible as > a requirement, one which may well have been overlooked. So expressing > the requirement in as much detail as possible will help us progress. > > Not knowing much about the subject, my guess would be that TCP has > overheads, in that one must keep significant state about each > connection and perhaps send keepalive packets periodically. But > outbound seems to incorporate those already; I don't see how TCP could > be more burdensome than UDP-with-outbound. > > 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 Dec 05 15:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrgqZ-0000G3-TE; Tue, 05 Dec 2006 15:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrgqY-0000Fx-1E for sip@ietf.org; Tue, 05 Dec 2006 15:24:58 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrgqV-0008Hr-Jn for sip@ietf.org; Tue, 05 Dec 2006 15:24:58 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7DFFA3BF3A; Tue, 5 Dec 2006 21:24:38 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21970-01-98; Tue, 5 Dec 2006 21:24:38 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 21A0B3BF2D; Tue, 5 Dec 2006 21:24:24 +0100 (CET) Message-ID: <4575D55B.8040200@it.su.se> Date: Tue, 05 Dec 2006 21:23:55 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.568 tagged_above=-99 required=7 tests=[AWL=0.097, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 Hisham Khartabil wrote: > > On Dec 5, 2006, at 3:33 PM, wrote: ... >> I personally believe going TCP-only would actually help deployment >> rather than hinder it, but I'd be really interested to be convinced >> otherwise. > > I could ask you the converse. I'd really be interested to be convinced > how TCP deployment improves scalability. To name two things where TCP would provide better scalability than UDP for a SIP service provider : 1) Say that your services maximum capacity for non-INVITEs is 1000 requests per second. If you get 2000 in a single second, you won't only have to deal with all those 2000 requests, but also with quite a few retransmissions sent after 500ms. With TCP, the wall isn't as dense. 2) UDP sockets have a shared receive buffer, most commonly around 64k I believe (even though the maximum seems to be 256k on FreeBSD at least). With SIP messages of perhaps 700 bytes on average, you have to be able to move messages out of that buffer pretty fast to keep it from filling up. A full buffer means dropped packets. I've also heard that on for example Linux, every packet actually occupies an even 2k (or was it 4k) in the buffer, so 64k buffer is actually at most 32 packets at a time. And then there are of course other aspects than scalability where UDP is an inferior solution, most notably security related things like for example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 16:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhW6-00065F-VF; Tue, 05 Dec 2006 16:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhW4-00064z-Uq for sip@ietf.org; Tue, 05 Dec 2006 16:07:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrhW3-00063q-I1 for sip@ietf.org; Tue, 05 Dec 2006 16:07:52 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 05 Dec 2006 13:07:50 -0800 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 kB5L7oLp019438; Tue, 5 Dec 2006 16:07:50 -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 kB5L7oDM003188; Tue, 5 Dec 2006 16:07:50 -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, 5 Dec 2006 16:07:50 -0500 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 16:07:49 -0500 Message-ID: <4575DFA4.5030000@cisco.com> Date: Tue, 05 Dec 2006 16:07:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2006 21:07:49.0768 (UTC) FILETIME=[6BA63080:01C718B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3028; t=1165352870; x=1166216870; 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=20[Sip]=20Issue=3A=20Expiration=20of=20temp-gruu |Sender:=20 |To:=20Scott=20Lawrence=20; bh=cAP2TzH6SCK31OBM2az04icfqGuR/FA03QdLt9D6A40=; b=RLzOD4KYQXL0l5PkCtC2QoSwJP0IXPjbV1RTxCGvlDG6eviQ9goOtLf+EcVl3GzjWHc1nFib +w1bj6Yphbf0PU85oV/KrnVDLC4++phA4NriLfjVVJBgd+SuGBL82CRY; 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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: SIP IETF 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 Scott, To paraphrase, it seems that you think we have enough mechanism now, and don't need any more to deal with the issues raised in this thread. Is that right? Paul 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. > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 16:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grhi7-0004tl-2b; Tue, 05 Dec 2006 16:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grhi6-0004tb-Ef for sip@ietf.org; Tue, 05 Dec 2006 16:20:18 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grhi4-0007hI-6l for sip@ietf.org; Tue, 05 Dec 2006 16:20:18 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 67DB16C01D; Tue, 5 Dec 2006 16:20:05 -0500 (EST) Subject: Re: [Sip] Issue: Expiration of temp-gruu From: Scott Lawrence To: Paul Kyzivat In-Reply-To: <4575DFA4.5030000@cisco.com> References: <456E15CD.60805@cisco.com> <1165200634.3607.3.camel@localhost.localdomain> <45749DF6.7040803@cisco.com> <1165336240.3208.72.camel@scott.skrb.org> <4575DFA4.5030000@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Tue, 05 Dec 2006 16:20:15 -0500 Message-Id: <1165353615.2968.2.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP IETF 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 Tue, 2006-12-05 at 16:07 -0500, Paul Kyzivat wrote: > Scott, > > To paraphrase, it seems that you think we have enough mechanism now, and > don't need any more to deal with the issues raised in this thread. Is > that right? Yes, that's correct. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Dec 05 16:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gri5j-0000oj-Vt; Tue, 05 Dec 2006 16:44:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gri5i-0000nB-Jy for sip@ietf.org; Tue, 05 Dec 2006 16:44:42 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gri5g-0001m0-57 for sip@ietf.org; Tue, 05 Dec 2006 16:44:42 -0500 Received: (qmail 11025 invoked by uid 0); 5 Dec 2006 21:44:08 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Dec 2006 21:44:08 -0000 Message-ID: <00b801c718b6$84185490$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Fredrik Thulin" , "Hisham Khartabil" References: <4575D55B.8040200@it.su.se> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 22:44:16 +0100 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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: fluffy@cisco.com, rohan@ekabal.com, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 Let's go back to the original topic - what should the draft say about the transport protocol in relationship with outbound The major use case for outbound is UAs behind NAT / firewalls. Many of such devices have known issues with UDP fragmentation, so for many environments TCP will need to be used for messages larger than the path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts the limit at 1300). If you start from the requirement "MUST only use UDP", then there is little room for constructive discussions. For UDP-only to work you will need to ensure that messages either stay below path MTUs, or disallow NAT. This implies significant limitations for your deployment environment. In any case, this is not a setup that outbound should focus on. In the general case, there are environments that have to deal with NAT and messages larger than path MTU. This is what outbound was written for. This also implies a UA that supports TCP. Given that the UA supports TCP and the fact that presence of devices like stateful firewalls cannot reliably be detected, the UA SHOULD use TCP (or another connection oriented transport). If in addition the UA supports TLS, it SHOULD use TLS. I think this is sufficient Regards, Jeroen Fredrik Thulin wrote: > Hisham Khartabil wrote: >> >> On Dec 5, 2006, at 3:33 PM, wrote: > ... >>> I personally believe going TCP-only would actually help deployment >>> rather than hinder it, but I'd be really interested to be convinced >>> otherwise. >> >> I could ask you the converse. I'd really be interested to be >> convinced how TCP deployment improves scalability. > > To name two things where TCP would provide better scalability than UDP > for a SIP service provider : > > 1) Say that your services maximum capacity for non-INVITEs is 1000 > requests per second. If you get 2000 in a single second, you > won't only have to deal with all those 2000 requests, but also > with quite a few retransmissions sent after 500ms. With TCP, the > wall isn't as dense. > > 2) UDP sockets have a shared receive buffer, most commonly around > 64k I believe (even though the maximum seems to be 256k on > FreeBSD at least). With SIP messages of perhaps 700 bytes on > average, you have to be able to move messages out of that buffer > pretty fast to keep it from filling up. A full buffer means > dropped packets. I've also heard that on for example Linux, > every packet actually occupies an even 2k (or was it 4k) in the > buffer, so 64k buffer is actually at most 32 packets at a time. > > And then there are of course other aspects than scalability where UDP > is an inferior solution, most notably security related things like for > example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). > > /Fredrik > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 05 16:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GriB5-0004Os-5C; Tue, 05 Dec 2006 16:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GriB4-0004On-7Q for sip@ietf.org; Tue, 05 Dec 2006 16:50:14 -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 1GriAz-0002Yl-M5 for sip@ietf.org; Tue, 05 Dec 2006 16:50:14 -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 kB5LnmTc009431; Tue, 5 Dec 2006 23:49:48 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 23:50:00 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 23:50:01 +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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 23:50:00 +0200 Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D00088025CD605@esebe104.NOE.Nokia.com> In-Reply-To: <8B658935-C258-4547-B748-84EB6A7E3EE9@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYhzklYB2ckY74RsOHPnEqyKhovgAGNgWg From: To: , X-OriginalArrivalTime: 05 Dec 2006 21:50:01.0654 (UTC) FILETIME=[50C55560:01C718B7] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061205234951-24ABFBB0-3E39A3AE/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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, On 05 Dec 2006, Dean Willis wrote:=20 >The simplest answer, which we've discussed here previously, is=20 >that a naive implementation of a proxy using TCP is limited by=20 >the number of sockets provided by the OS, which is usually=20 >something less than the number of file handles and tends to be=20 >less than 64k. This caps the "fan out" of a proxy" at a number=20 >smaller than some operators would like. Of course, it's=20 but it's also good to notice that many/most modern operating systems do not have these limitations. For instance, on most systems the=20 64k limit you mention, only applies to outbound connections (due to the available port range), and does not limit for instance how many incoming TCP=20 flows a SIP proxy can handle. I believe the unofficial record for a single=20 x86 box is still the 1.6M TCP connections (on FreeBSD, from 2003) [1], but=20 this of course is not the case in general. But tens of thousands of TCP=20 connections is surely not a problem on any modern system. And of course, it's true a naive implementation will have problems, but=20 I can assure the limit on TCP connections is not the only place where a naive implementation will hit the limits. ;) There are numerous interesting papers and resources on the topic [2-4] (and note that most of these are quite old papers), and many indicate=20 that TCP scalability is not _that_ big of an issue. Especially, in the case of SIP, if we consider that UDP flows will require more frequent=20 keepalives, it is not obvious that a system using persistent TCP flows=20 from the clients, will scale worse than a similar system utilizing UDP. [1] http://kerneltrap.org/node/277 (search for "1.6 Million") [2] http://www.kegel.com/c10k.html [3] http://bcr2.uwaterloo.ca/~brecht/papers/getpaper.php?file=3Dols-2004.pdf [4] http://haproxy.1wt.eu/ >possible to write a more sophisticated proxy using select/poll=20 >that doesn't have this limitation, but only on OS that support it. Actually you shouldn't be using select/poll if you want to=20 write a modern proxy -- see [2,3] above. ;)=20 >One other thing that UDP makes easier is fault tolerance=20 >across a proxy farm with replicated state. Of course, we've=20 >also learned how to do this with TCP (and even with TLS) at=20 >reasonable levels of efficiency. Yes, agreed. This is a real concern, but also a problem that has been solved in many existing TCP/TLS based services. >In other words, to the best of my knowledge, the only good=20 >reason to keep using UDP is because you have it deployed=20 >already and don't want to change, because change is expensive=20 >and disruptive. Of course, if one is going to phase in=20 Yes, agreed.=20 But it's also good to note that a big reason why UDP is so widely used as the default transport, is the not-so-great state of standards support=20 for using TCP/TLS in SIP clients (how TCP/TLS flows are managed/reused in clients, how server elements can reuse these flows -> leading to need=20 for ugly, but currently necessary, real-world hacks as described=20 for instance in [5]). The sip-outbound draft may be useful for UDP, but=20 it is absolutely critical for getting TCP/TLS more widely used.=20 [5] sect 3.4.1 of http://tools.ietf.org/wg/sipping/draft-ietf-sipping-sbc-funcs/ --=20 first.surname@nokia.com (Kai Vehmanen) Networking Technologies Laboratory, 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 Dec 05 17:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grj1B-0003Pe-R1; Tue, 05 Dec 2006 17:44:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grj1B-0003PZ-5e for sip@ietf.org; Tue, 05 Dec 2006 17:44:05 -0500 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grj18-0001VM-LS for sip@ietf.org; Tue, 05 Dec 2006 17:44:05 -0500 Received: (qmail 948 invoked by uid 0); 5 Dec 2006 22:45:07 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Dec 2006 22:45:07 -0000 Message-ID: <00c901c718be$d6e0ad50$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , , References: <719D5CCC2F6E3644B0A9F5C9B1D00088025CD605@esebe104.NOE.Nokia.com> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 23:43:52 +0100 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: 34d35111647d654d033d58d318c0d21a 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 Not to mention the differences in transaction timers. For UDP transaction state (in particular non-INVITE server transactions) is retained much longer than for TCP. For the proxy-2-proxy case (i.e. small fan-in, few rx buffers ) TCP is often a better choice than UDP, especially when memory is your bottleneck. Drawbacks for TCP are message boundary detection overhead and some byte copying overhead, which add some delay and some CPU load (though probably insignificant). Implementation complexity is slightly higher for TCP too. Though interesting, IMHO all of this is not so relevant for the outbound discussion. Proxies must already implement TCP, the UA is better of using TCP if it can. Regards, Jeroen Kai.Vehmanen@nokia.com wrote: > Hi, > > On 05 Dec 2006, Dean Willis wrote: >> The simplest answer, which we've discussed here previously, is >> that a naive implementation of a proxy using TCP is limited by >> the number of sockets provided by the OS, which is usually >> something less than the number of file handles and tends to be >> less than 64k. This caps the "fan out" of a proxy" at a number >> smaller than some operators would like. Of course, it's > > but it's also good to notice that many/most modern operating systems > do not have these limitations. For instance, on most systems the > 64k limit you mention, only applies to outbound connections (due to > the available port range), and does not limit for instance how many > incoming TCP > flows a SIP proxy can handle. I believe the unofficial record for a > single > x86 box is still the 1.6M TCP connections (on FreeBSD, from 2003) [1], > but > this of course is not the case in general. But tens of thousands of > TCP connections is surely not a problem on any modern system. > > And of course, it's true a naive implementation will have problems, > but I can assure the limit on TCP connections is not the only place > where > a naive implementation will hit the limits. ;) > > There are numerous interesting papers and resources on the topic [2-4] > (and > note that most of these are quite old papers), and many indicate > that TCP scalability is not _that_ big of an issue. Especially, in > the case of SIP, if we consider that UDP flows will require more > frequent > keepalives, it is not obvious that a system using persistent TCP flows > from the clients, will scale worse than a similar system utilizing > UDP. > > [1] http://kerneltrap.org/node/277 (search for "1.6 Million") > [2] http://www.kegel.com/c10k.html > [3] > http://bcr2.uwaterloo.ca/~brecht/papers/getpaper.php?file=ols-2004.pdf > [4] http://haproxy.1wt.eu/ > >> possible to write a more sophisticated proxy using select/poll >> that doesn't have this limitation, but only on OS that support it. > > Actually you shouldn't be using select/poll if you want to > write a modern proxy -- see [2,3] above. ;) > >> One other thing that UDP makes easier is fault tolerance >> across a proxy farm with replicated state. Of course, we've >> also learned how to do this with TCP (and even with TLS) at >> reasonable levels of efficiency. > > Yes, agreed. This is a real concern, but also a problem that > has been solved in many existing TCP/TLS based services. > >> In other words, to the best of my knowledge, the only good >> reason to keep using UDP is because you have it deployed >> already and don't want to change, because change is expensive >> and disruptive. Of course, if one is going to phase in > > Yes, agreed. > > But it's also good to note that a big reason why UDP is so widely > used as the default transport, is the not-so-great state of standards > support > for using TCP/TLS in SIP clients (how TCP/TLS flows are managed/reused > in clients, > how server elements can reuse these flows -> leading to need > for ugly, but currently necessary, real-world hacks as described > for instance in [5]). The sip-outbound draft may be useful for UDP, > but it is absolutely critical for getting TCP/TLS more widely used. > > [5] sect 3.4.1 of > http://tools.ietf.org/wg/sipping/draft-ietf-sipping-sbc-funcs/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 05 18:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrjQ6-0006Su-Fo; Tue, 05 Dec 2006 18:09:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrjQ5-0006Sp-2Q for sip@ietf.org; Tue, 05 Dec 2006 18:09:49 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrjQ3-00063x-Lq for sip@ietf.org; Tue, 05 Dec 2006 18:09:49 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB5N9j424592 for ; Tue, 5 Dec 2006 18:09:45 -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] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 17:09:43 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E4AFD9C@zrc2hxm0.corp.nortel.com> In-Reply-To: <00b801c718b6$84185490$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccYtw6Wig8vrdIoRBCG+cul0H3WRgACfnsw From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Thanks for bringning back the original topic. It seems to me that we do not have any evidence that when Outbound keep-alive is used because of the presence of a NAT, that there are any advantage to using UDP instead of TCP. It seems that all the perceived advantages of UDP versus TCP vanish in the presence of a NAT (in fact some have argued that TCP will actually scale better). Worst, all the evidence is that UDP will have=20 problems with fragmentation and that it will therefore not be suitable. Futhermore, if the most important use case for outbound keep-alive is TCP=20 and not UDP, "optimizing" the solution for UDP is not a good idea. I'd rather we have a solution optimized for TCP (and TLS). If we have a solution for UDP or not is of little interest to me: I just don't think it will be very popular and it will be just one more useless feature to implement. Nit-pick: the other major use case for outbound is TLS support, but that does not require the keepalive. So what you really meant in the second paragraph is "The major use case for outbound keep-alive is ...". > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Tuesday, December 05, 2006 13:44 > To: Fredrik Thulin; Hisham Khartabil > Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org;=20 > Markus.Isomaki@nokia.com; peter.leis@siemens.com; aki.niemi@nokia.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > Let's go back to the original topic - what should the draft=20 > say about the transport protocol in relationship with outbound >=20 > The major use case for outbound is UAs behind NAT /=20 > firewalls. Many of such devices have known issues with UDP=20 > fragmentation, so for many environments TCP will need to be=20 > used for messages larger than the path MTU (often ~1460 bytes=20 > in ethernet environments, RFC3261 puts the limit at 1300). >=20 > If you start from the requirement "MUST only use UDP", then=20 > there is little room for constructive discussions. For=20 > UDP-only to work you will need to ensure that messages either=20 > stay below path MTUs, or disallow NAT. This implies=20 > significant limitations for your deployment environment. In=20 > any case, this is not a setup that outbound should focus on. >=20 > In the general case, there are environments that have to deal=20 > with NAT and messages larger than path MTU. This is what=20 > outbound was written for. This also implies a UA that=20 > supports TCP. Given that the UA supports TCP and the fact=20 > that presence of devices like stateful firewalls cannot=20 > reliably be detected, the UA SHOULD use TCP (or another=20 > connection oriented transport).=20 > If in addition the UA supports TLS, it SHOULD use TLS. >=20 > I think this is sufficient >=20 > Regards, > Jeroen >=20 > Fredrik Thulin wrote: > > Hisham Khartabil wrote: > >> > >> On Dec 5, 2006, at 3:33 PM, wrote: > > ... > >>> I personally believe going TCP-only would actually help=20 > deployment=20 > >>> rather than hinder it, but I'd be really interested to be=20 > convinced=20 > >>> otherwise. > >> > >> I could ask you the converse. I'd really be interested to be=20 > >> convinced how TCP deployment improves scalability. > > > > To name two things where TCP would provide better=20 > scalability than UDP=20 > > for a SIP service provider : > > > > 1) Say that your services maximum capacity for non-INVITEs is 1000 > > requests per second. If you get 2000 in a single second, you > > won't only have to deal with all those 2000 requests, but also > > with quite a few retransmissions sent after 500ms.=20 > With TCP, the > > wall isn't as dense. > > > > 2) UDP sockets have a shared receive buffer, most commonly around > > 64k I believe (even though the maximum seems to be 256k on > > FreeBSD at least). With SIP messages of perhaps 700 bytes on > > average, you have to be able to move messages out of=20 > that buffer > > pretty fast to keep it from filling up. A full buffer means > > dropped packets. I've also heard that on for example Linux, > > every packet actually occupies an even 2k (or was it 4k) in the > > buffer, so 64k buffer is actually at most 32 packets at a time. > > > > And then there are of course other aspects than scalability=20 > where UDP=20 > > is an inferior solution, most notably security related=20 > things like for=20 > > example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). > > > > /Fredrik > > > > > > _______________________________________________ > > 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=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 Dec 05 19:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrknN-0005ft-Bh; Tue, 05 Dec 2006 19:37:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrknL-0005fn-PP for sip@ietf.org; Tue, 05 Dec 2006 19:37:55 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrknH-0006gv-HG for sip@ietf.org; Tue, 05 Dec 2006 19:37:55 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id B67DF3A02157; Tue, 5 Dec 2006 16:37:44 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 6E78B3A0214B for ; Tue, 5 Dec 2006 16:37:43 -0800 (PST) Message-ID: <457610D7.4010508@acm.org> Date: Tue, 05 Dec 2006 16:37:43 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] I-D Preventing Fragmentation in 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: , Errors-To: sip-bounces@ietf.org I just submitted a new version of this I-D. Until it appears in the archives, a copy can be found here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-fragmentation-responses-01.txt The new version was rewritten to be more readable and an example was added. This version also solves a problem when multiple hops would trigger response fragmentation. I am interested in any comments or questions on this I-D, and especially to hear if people are interested in this work. 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 Tue Dec 05 22:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grnmj-00037i-85; Tue, 05 Dec 2006 22:49:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grnmh-00037M-CI for sip@ietf.org; Tue, 05 Dec 2006 22:49:27 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grnmf-0001E4-6E for sip@ietf.org; Tue, 05 Dec 2006 22:49:27 -0500 Received: from [206.176.144.212] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kB62r1WX026988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Dec 2006 20:53:07 -0600 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: Dean Willis Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Tue, 5 Dec 2006 21:48:51 -0600 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: fluffy@cisco.com, rohan@ekabal.com, ft@it.su.se, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 On Dec 5, 2006, at 1:22 PM, Hisham Khartabil wrote: > > I could ask you the converse. I'd really be interested to be > convinced how TCP deployment improves scalability. > That's easy. Imagine that the Internet is a set of sewer pipes, down which someone periodically flushes whole cantaloupe. The cantaloupe have the side effect of blocking up other drains, causing "back up" problems in other people's plumbing fictures. UDP fragmentation of large responses (or large messages, if one is so tacky as to send them that way) will cause bursts of non-flow- controlled traffic to be inserted into the network. This clogs up buffers, reduces efficient network flow, and generally makes SIP a bad network neighbor -- much like the moron upstairs who flushes the cantaloupe. TCP reduces the congestion impact of large messages substantially. The net effect is like running the whole cantaloupe through a blender, flushing it a cup at a time, and not flushing the next cup until you've asked everyone in the building to make sure their plumbing is working. Sure, we could re-invent all of the TCP flow-control using UDP, but why bother? We'd eventually just have TCP again. Factor in the detail that we're well on the way towards having the average message large enough to throw at least one fragment (and possibly 3 or 4, especially on smaller MTU networks), and I think TCP- only SIP starts to become very attractive. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 06 07:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwK4-0002Pi-AU; Wed, 06 Dec 2006 07:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwK2-0002PC-Lr for sip@ietf.org; Wed, 06 Dec 2006 07:56:26 -0500 Received: from datnt07.tieto.com ([194.110.47.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrwJm-0006Jb-4v for sip@ietf.org; Wed, 06 Dec 2006 07:56:15 -0500 Received: from viper.eu.tieto.com ([194.110.47.167]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Dec 2006 14:55:57 +0200 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 14:55:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Dec 2006 14:55:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue related to sigcomp Thread-Index: AccZNd5PRSHTZlFJQOGcICBh4dBo8Q== From: To: X-OriginalArrivalTime: 06 Dec 2006 12:55:56.0692 (UTC) FILETIME=[DEE5ED40:01C71935] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] Issue related to sigcomp 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, I have encountered one unclarity in usage of SigComp as specified by RFC = 3486. In section "4. Sending a Request to a Server" there is said that = if client wants to receive subsequent requests with compression then = "this client SHOULD add the parameter comp=3Dsigcomp to the URI in the = Contact header field". Later in the specification there are examples = that are in conflict with this statement. (1) INVITE UAS Via: UAC;comp=3Dsigcomp Route: P1;comp=3Dsigcomp Contact: UAC;comp=3Dsigcomp The contact header adds the comp parameter, but not as the URI parameter = but as the header parameter. I have found another example in 3GPP TS 24.141 v7.2.0 where on page 24 = there is the Contact header in the form Contact: This header has no header parameter and its value is sip uri with = parameter. Later in that document, there is SIP NOTIFY message where the = SIP URI from the Contact header is used in Request-URI in exactly the = same format. I have got few questions: 1. Where shall be the comp parameter used - as uri parameter or as = header parameter? 2. If it is uri parameter, are the examples in RFC 3486 invalid? 3. If it is header parameter, then if client issues comp parameter as = uri parameter does it mean that it is willing to receive compressed = content? br, Martin Hynar _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 06 08:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwnE-00076Y-Cr; Wed, 06 Dec 2006 08:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwnC-00076S-VI for sip@ietf.org; Wed, 06 Dec 2006 08:26:34 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrwnB-0003Ga-Hw for sip@ietf.org; Wed, 06 Dec 2006 08:26:34 -0500 Received: (qmail 30707 invoked by uid 0); 6 Dec 2006 13:26:15 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Dec 2006 13:26:15 -0000 Message-ID: <000a01c7193a$25079540$0202fea9@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: Subject: Re: [Sip] Issue related to sigcomp Date: Wed, 6 Dec 2006 14:26:31 +0100 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: 7aafa0432175920a4b3e118e16c5cb64 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 Martin, The text above the example in RFC3486 explicitly says "We have not used a correct format for these header fields." comp=sigcomp is a URI parameter, not a header parameter Regards, Jeroen Martin.Hynar@tietoenator.com wrote: > Hello, > > I have encountered one unclarity in usage of SigComp as specified by > RFC 3486. In section "4. Sending a Request to a Server" there is said > that if client wants to receive subsequent requests with compression > then "this client SHOULD add the parameter comp=sigcomp to the URI in > the Contact header field". Later in the specification there are > examples that are in conflict with this statement. > > (1) INVITE UAS > Via: UAC;comp=sigcomp > Route: P1;comp=sigcomp > Contact: UAC;comp=sigcomp > > The contact header adds the comp parameter, but not as the URI > parameter but as the header parameter. > > I have found another example in 3GPP TS 24.141 v7.2.0 where on page > 24 there is the Contact header in the form > > Contact: > > This header has no header parameter and its value is sip uri with > parameter. Later in that document, there is SIP NOTIFY message where > the SIP URI from the Contact header is used in Request-URI in exactly > the same format. > > I have got few questions: > 1. Where shall be the comp parameter used - as uri parameter or as > header parameter? > 2. If it is uri parameter, are the examples in RFC 3486 invalid? > 3. If it is header parameter, then if client issues comp parameter as > uri parameter does it mean that it is willing to receive compressed > content? > > br, Martin Hynar > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 06 14:17:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs2Eq-0007R0-Fb; Wed, 06 Dec 2006 14:15:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrgxG-0003NX-RX for sip@ietf.org; Tue, 05 Dec 2006 15:31:54 -0500 Received: from mail.exchange.microsoft.com ([131.107.1.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrgxD-0001ec-Gt for sip@ietf.org; Tue, 05 Dec 2006 15:31:54 -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.23; Tue, 5 Dec 2006 12:31:50 -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, 5 Dec 2006 12:31:50 -0800 From: Sean Olson To: Fredrik Thulin , Hisham Khartabil Date: Tue, 5 Dec 2006 12:31:45 -0800 Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYq/9zelngzT1fTGGLuHpNXFHfAwAADlKw Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01755CEE852@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <4575D55B.8040200@it.su.se> In-Reply-To: <4575D55B.8040200@it.su.se> 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: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Wed, 06 Dec 2006 14:15:27 -0500 Cc: "fluffy@cisco.com" , "rohan@ekabal.com" , "sip@ietf.org" , "Markus.Isomaki@nokia.com" , "peter.leis@siemens.com" , "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 My two cents: it's all about re-transmissions and security. Would be curi= ous to hear deployment experience around DTLS and whether or not that has a= ctually helped the security of UDP deployments. -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se] Sent: Tuesday, December 05, 2006 12:24 PM To: Hisham Khartabil Cc: fluffy@cisco.com; rohan@ekabal.com; sip@ietf.org; Markus.Isomaki@nokia.= com; peter.leis@siemens.com; aki.niemi@nokia.com Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Hisham Khartabil wrote: > > On Dec 5, 2006, at 3:33 PM, wrote: ... >> I personally believe going TCP-only would actually help deployment >> rather than hinder it, but I'd be really interested to be convinced >> otherwise. > > I could ask you the converse. I'd really be interested to be convinced > how TCP deployment improves scalability. To name two things where TCP would provide better scalability than UDP for a SIP service provider : 1) Say that your services maximum capacity for non-INVITEs is 1000 requests per second. If you get 2000 in a single second, you won't only have to deal with all those 2000 requests, but also with quite a few retransmissions sent after 500ms. With TCP, the wall isn't as dense. 2) UDP sockets have a shared receive buffer, most commonly around 64k I believe (even though the maximum seems to be 256k on FreeBSD at least). With SIP messages of perhaps 700 bytes on average, you have to be able to move messages out of that buffer pretty fast to keep it from filling up. A full buffer means dropped packets. I've also heard that on for example Linux, every packet actually occupies an even 2k (or was it 4k) in the buffer, so 64k buffer is actually at most 32 packets at a time. And then there are of course other aspects than scalability where UDP is an inferior solution, most notably security related things like for example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 06 18:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6MO-0007je-KN; Wed, 06 Dec 2006 18:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6MN-0007jV-70 for sip@ietf.org; Wed, 06 Dec 2006 18:39:31 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6ML-0008Uj-M8 for sip@ietf.org; Wed, 06 Dec 2006 18:39:31 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061206233859b1100epe2ke>; Wed, 6 Dec 2006 23:39:20 +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 kB6Na9nU018264 for ; Wed, 6 Dec 2006 18:36:09 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kB6Na5QM018253; Wed, 6 Dec 2006 18:36:05 -0500 Date: Wed, 6 Dec 2006 18:36:05 -0500 Message-Id: <200612062336.kB6Na5QM018253@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <3f9af3b5cb86e8cce5fbe7adc1f62d27@telio.no> (hisham.khartabil@telio.no) Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <8f785eca4408c5a6ef5d7a097bc5e7f0@telio.no> <200612051528.kB5FSWif027762@dragon.ariadne.com> <3f9af3b5cb86e8cce5fbe7adc1f62d27@telio.no> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: Hisham Khartabil Besides scalability issues, there are no technical issues. Naively, the scaling of UDP-with-outbound doesn't seem to be any better than TCP-with-outbound. Can you elucidate the scalability issues that are causing you problems? The issues are with having to throw all the infrastructure we currently have out of the window and start all over again. Having 110k+ customers live does not make is an easy and justifiable task. Naively, to implement outbound will require changing the software in the proxies and UAs, regardless of whether it uses UDP or TCP. I suppose this can be called "throwing infrastructure out of the window", but it seems to be a routine matter. Can you elucidate why UDP-with-outbound reduces this burden compared to implementing TCP-with-outbound? Why do we prefer to run away from the problem and ignore it pretending it does not "really" exist instead of trying to fix it? Can you elucidate what "the problem" is that you are referring to? 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 Dec 06 19:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lk-000229-Cx; Wed, 06 Dec 2006 19:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6le-0001wQ-2q for sip@ietf.org; Wed, 06 Dec 2006 19:05:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6lN-0005vC-NI for sip@ietf.org; Wed, 06 Dec 2006 19:05:38 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2006 16:05:21 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kB705Jew017398; Wed, 6 Dec 2006 16:05:19 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7058io017840; Wed, 6 Dec 2006 16:05:09 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 16:05:08 -0800 Received: from caryfitz-mac.local ([10.21.89.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 16:05:08 -0800 Received: by caryfitz-mac.local (Postfix, from userid 501) id 7153A24BBC8; Wed, 6 Dec 2006 16:05:19 -0800 (PST) Date: Wed, 6 Dec 2006 16:05:18 -0800 (PST) From: Cary FitzGerald X-X-Sender: caryfitz@caryfitz-mac.local To: Dean Willis Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Dec 2006 00:05:08.0331 (UTC) FILETIME=[5B23D3B0:01C71993] Authentication-Results: sj-dkim-3; header.From=caryfitz@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: fluffy@cisco.com, rohan@ekabal.com, ft@it.su.se, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 > Sure, we could re-invent all of the TCP flow-control using UDP, but why > bother? We'd eventually just have TCP again. More likely, SCTP. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 06 19:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs74f-00073u-1Q; Wed, 06 Dec 2006 19:25:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6lr-00029C-Ij for sip@ietf.org; Wed, 06 Dec 2006 19:05:51 -0500 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gs6lg-00065Q-N9 for sip@ietf.org; Wed, 06 Dec 2006 19:05:51 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 9D09E3A0215B; Wed, 6 Dec 2006 16:05:37 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id A92C53A0215F for ; Wed, 6 Dec 2006 16:05:31 -0800 (PST) Message-ID: <45775ACB.2090904@acm.org> Date: Wed, 06 Dec 2006 16:05:31 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (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 followed a little bit the discussion about the usage of UDP and TCP with Outbound, and my opinion is that both UDP and TCP need to be supported. Obviously UDP alone cannot be used with Outbound because if there is a potential fragmentation in a request sent to the UA or in a response sent from the UA, there is no way to switch to a congestion controlled transport. So we (Packet8) did some tests by comparing UDP and TCP, and we found that, even by using advanced coding techniques, UDP uses less resources than TCP. So we tried a combination of temporary TCP and UDP. The idea is that TCP is really needed only for few types of transactions on a real life endpoint. One of this transactions is an INVITE, because the size added by the SDP, especially when carrying ICE attributes and audio+video+text sessions, nearly always results in a packet size that is over the MTU. Another case is the full state NOTIFY for the reg-event that is to be received after sending a SUBSCRIBE (partial state NOTIFY are OK). REGISTER, even fully loaded with extensions are generally OK. We retried our tests and found that using temporary TCP for the INVITE and full state NOTIFY transaction with UDP for all the other transactions was using more ressources than UDP alone, but still less than using only TCP. So I wrote this I-D that describe a solution to implement this mixed UDP/TCP as an extension to Outbound. This is really a first draft, as there is a lot missing (e.g. how an edge proxy knows that the UA supports this, etc...), but I wanted to know if there is interest in working on this direction. Until the draft appears in the archives, a copy can be found here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound-fragmentation-00.txt Questions and comments 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 Wed Dec 06 19:33:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7CQ-0003Hy-N5; Wed, 06 Dec 2006 19:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7CP-0003Hj-SE for sip@ietf.org; Wed, 06 Dec 2006 19:33:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7CO-0002Jh-8g for sip@ietf.org; Wed, 06 Dec 2006 19:33:17 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2006 16:33:15 -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 kB70XFpx021906; Wed, 6 Dec 2006 16:33:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB70Wvj8002352; Wed, 6 Dec 2006 16:33:07 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 16:33:02 -0800 Received: from [128.107.139.23] ([128.107.139.23]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 16:33:01 -0800 In-Reply-To: <00b801c718b6$84185490$0601a8c0@BEMBUSTER> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Wed, 6 Dec 2006 16:33:15 -0800 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Dec 2006 00:33:01.0933 (UTC) FILETIME=[40AF39D0:01C71997] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4588; t=1165451595; x=1166315595; 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=20[Sip]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=q+Gmzlc4PcV/uX0waVrQTJKMYBBn6EW0+6w6ft4FtzU=; b=JM+kJ97lEmEMFRHYIAmousutbAErKleOqxYXZ1jyA1yxWQkUnmiYFG5kEtjo3nrscDeuYGyJ BcrNohsjiXN7JCOwPB3cfz+ZTOTJUuJSS6jeP80ZeCOMglIGyv9Luc/x; 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: rohan@ekabal.com, Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 I find this whole conversation way off base. If people would like to deprecate UDP, go work on a document to explain that and feel free to bring it to the WG. In the mean time, SIP is specified over both UDP and TCP. Most deployments only use UDP, some only use TCP, and I suspect there are some that do both but I am not aware of them. Outbound as it is seems very consistent with 3261 in that it allows a system to use TCP or UDP. Keeping this in mind few comments inline .... On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > Let's go back to the original topic - what should the draft say > about the transport protocol in relationship with outbound > > The major use case for outbound is UAs behind NAT / firewalls. Many > of such devices have known issues with UDP fragmentation, so for > many environments TCP will need to be used for messages larger than > the path MTU (often ~1460 bytes in ethernet environments, RFC3261 > puts the limit at 1300). These known issues with fragmentation might be less common than you think however, outbound does not have anything to do with MTU issues. It does not try and solve them and it does not make them worse. > > If you start from the requirement "MUST only use UDP", then there > is little room for constructive discussions. For UDP-only to work > you will need to ensure that messages either stay below path MTUs, > or disallow NAT. This implies significant limitations for your > deployment environment. In any case, this is not a setup that > outbound should focus on. MTU is a problem regardless of NATs or Firewalls. Fragmented packets do manager to traverse most NATs and Firewalls. > > In the general case, there are environments that have to deal with > NAT and messages larger than path MTU. This is what outbound was > written for. This also implies a UA that supports TCP. Given that > the UA supports TCP and the fact that presence of devices like > stateful firewalls cannot reliably be detected, the UA SHOULD use > TCP (or another connection oriented transport). If in addition the > UA supports TLS, it SHOULD use TLS. Again, this topic is not really about outbound. If you think a 3261 UA that supports both UDP and TCP SHOULD use TCP, that is a fine argument to go make in the discussion about use of TCP and UDP but it seems to be an independent choice from anything to do with outbound. Cullen > > I think this is sufficient > > Regards, > Jeroen > > Fredrik Thulin wrote: >> Hisham Khartabil wrote: >>> >>> On Dec 5, 2006, at 3:33 PM, wrote: >> ... >>>> I personally believe going TCP-only would actually help deployment >>>> rather than hinder it, but I'd be really interested to be convinced >>>> otherwise. >>> >>> I could ask you the converse. I'd really be interested to be >>> convinced how TCP deployment improves scalability. >> >> To name two things where TCP would provide better scalability than >> UDP >> for a SIP service provider : >> >> 1) Say that your services maximum capacity for non-INVITEs is 1000 >> requests per second. If you get 2000 in a single second, you >> won't only have to deal with all those 2000 requests, but also >> with quite a few retransmissions sent after 500ms. With TCP, the >> wall isn't as dense. >> >> 2) UDP sockets have a shared receive buffer, most commonly around >> 64k I believe (even though the maximum seems to be 256k on >> FreeBSD at least). With SIP messages of perhaps 700 bytes on >> average, you have to be able to move messages out of that buffer >> pretty fast to keep it from filling up. A full buffer means >> dropped packets. I've also heard that on for example Linux, >> every packet actually occupies an even 2k (or was it 4k) in the >> buffer, so 64k buffer is actually at most 32 packets at a time. >> >> And then there are of course other aspects than scalability where UDP >> is an inferior solution, most notably security related things like >> for >> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >> >> /Fredrik >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Dec 06 20:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7oD-0001xS-Fq; Wed, 06 Dec 2006 20:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7oB-0001wV-OV for sip@ietf.org; Wed, 06 Dec 2006 20:12:19 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7oA-00005v-EU for sip@ietf.org; Wed, 06 Dec 2006 20:12:19 -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 kB71CFr22967; Wed, 6 Dec 2006 20:12:15 -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] Re: issue with oubound and the used transport protocol Date: Wed, 6 Dec 2006 19:12:14 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E501174@zrc2hxm0.corp.nortel.com> In-Reply-To: <200612062336.kB6Na5QM018253@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccZkG+5zLtm+5lhQQWG3rfMfpwyrQADBZEQ From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 I don't think this is naive at all. I think you hit the nail on the=20 head very sqarely. =20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Wednesday, December 06, 2006 15:36 > To: sip@ietf.org > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > From: Hisham Khartabil >=20 > Besides scalability issues, there are no technical issues. >=20 > Naively, the scaling of UDP-with-outbound doesn't seem to be=20 > any better than TCP-with-outbound. Can you elucidate the=20 > scalability issues that are causing you problems? >=20 > The issues are with having to throw all the infrastructure we > currently have out of the window and start all over again. Having > 110k+ customers live does not make is an easy and justifiable task. >=20 > Naively, to implement outbound will require changing the=20 > software in the proxies and UAs, regardless of whether it=20 > uses UDP or TCP. I suppose this can be called "throwing=20 > infrastructure out of the window", but it seems to be a=20 > routine matter. Can you elucidate why UDP-with-outbound=20 > reduces this burden compared to implementing TCP-with-outbound? >=20 > Why do we prefer to run away from the problem and ignore it > pretending it does not "really" exist instead of trying to fix it? >=20 > Can you elucidate what "the problem" is that you are referring to? >=20 > Dale >=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 Dec 06 20:38:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8DB-0005iC-Vj; Wed, 06 Dec 2006 20:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8DB-0005i7-45 for sip@ietf.org; Wed, 06 Dec 2006 20:38:09 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8D9-00032d-U3 for sip@ietf.org; Wed, 06 Dec 2006 20:38:09 -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 kB71c5r24124 for ; Wed, 6 Dec 2006 20:38:05 -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] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) Date: Wed, 6 Dec 2006 19:38:04 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E5011B3@zrc2hxm0.corp.nortel.com> In-Reply-To: <45775ACB.2090904@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) thread-index: AccZlnKi1CTxtSCTSGOGFpk0rpk9KQABkrfQ From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Maybe I'm missing something in this keep-alive and UDP/TCP debate. I find the obsession with performance out of place. All the evidence that I've seen is that in a commercial product, that the server is=20 really not spending much of it's cycles doing keep-alives. The evidence is also that if you are doing keep-alives, the transport will matter even less. We keep going back to the same issues, with the same conclusions regarding performance: the keep-alive mechanism doesn't really matter, and the transport=20 doesn't matter either. Yet somehow, we keep agonising over this. In the real world, people keep on using PING/OPTIONS/short-lived-REGISTER/CRLF/STUN and whatever. Let's pick something and move on. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 06 20:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8JR-0001j0-Tc; Wed, 06 Dec 2006 20:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs8JQ-0001iY-TV for sip@ietf.org; Wed, 06 Dec 2006 20:44:36 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs8JP-00041T-O9 for sip@ietf.org; Wed, 06 Dec 2006 20:44:36 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <2006120701443001500b0a7je>; Thu, 7 Dec 2006 01:44: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 kB71h9nU020400 for ; Wed, 6 Dec 2006 20:43:09 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kB71h9VI020396; Wed, 6 Dec 2006 20:43:09 -0500 Date: Wed, 6 Dec 2006 20:43:09 -0500 Message-Id: <200612070143.kB71h9VI020396@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1ECE0EB50388174790F9694F77522CCF0E501174@zrc2hxm0.corp.nortel.com> (audet@nortel.com) Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <1ECE0EB50388174790F9694F77522CCF0E501174@zrc2hxm0.corp.nortel.com> 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: "Francois Audet" I don't think this is naive at all. I think you hit the nail on the head very sqarely. Well, I know I'm not up-to-date on all these issues. I suspect that Hisham knows of certain problems that I don't, but we need more information about them to be able to discuss the situation usefully. 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 Dec 06 23:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsBDe-0000XQ-D6; Wed, 06 Dec 2006 23:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsBDd-0000XL-RN for sip@ietf.org; Wed, 06 Dec 2006 23:50:49 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsBDc-0002ly-Ii for sip@ietf.org; Wed, 06 Dec 2006 23:50:49 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id E7A413A02157; Wed, 6 Dec 2006 20:50:45 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id B93CA3A0214B; Wed, 6 Dec 2006 20:50:44 -0800 (PST) Message-ID: <45779DA4.4060802@acm.org> Date: Wed, 06 Dec 2006 20:50:44 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] I-D: Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) References: <1ECE0EB50388174790F9694F77522CCF0E5011B3@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E5011B3@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Francois Audet wrote: > Maybe I'm missing something in this keep-alive and UDP/TCP debate. > > I find the obsession with performance out of place. Performance is important at least for service providers, because they have to buy the hardware to run the servers, pay the licenses per CPU, pay the datacenters cost, pay the sysadmins to run the servers and pay the managers to manage the sysadmins. So yes, performance is important, but perhaps not for the hardware vendors, the software vendors and the sysadmins. > > All the evidence that I've seen is that in a commercial product, that > the server is > really not spending much of it's cycles doing keep-alives. The evidence > is also that > if you are doing keep-alives, the transport will matter even less. > > We keep going back to the same issues, with the same conclusions > regarding > performance: the keep-alive mechanism doesn't really matter, and the > transport > doesn't matter either. > > Yet somehow, we keep agonising over this. In the real world, people > keep on using PING/OPTIONS/short-lived-REGISTER/CRLF/STUN and whatever. > > Let's pick something and move on. > -- 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 Dec 07 00:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsBhE-0007M8-Ci; Thu, 07 Dec 2006 00:21:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsBhC-0007JH-JE for sip@ietf.org; Thu, 07 Dec 2006 00:21:22 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsBhA-0004To-VJ for sip@ietf.org; Thu, 07 Dec 2006 00:21:22 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB75Fg228141; Wed, 6 Dec 2006 21:15:42 -0800 In-Reply-To: <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Wed, 6 Dec 2006 21:15:50 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 On Dec 6, 2006, at 16:33, Cullen Jennings wrote: > I find this whole conversation way off base. If people would like to > deprecate UDP, go work on a document to explain that and feel free to > bring it to the WG. In the mean time, SIP is specified over both UDP > and TCP. To be more specific, SIP is currently specified so it can use UDP for requests smaller than 1300 bytes. It is specified so it can use TCP for requests of any size. Some people have suggested that user agents SHOULD be able to send and receive requests larger than 1300 bytes when using the outbound mechanism. This seems like a logical requirement. Are you objecting to this requirement Cullen? For the sake of this discussion, lets assume that we have consensus on this requirement. What are the implications? Well, most UAs implementing outbound are doing so because they are behind a NAT or a firewall and will not be able to receive inbound TCP flows. These UAs will need to establish a TCP flow if they want to meet this requirement of receiving requests larger than 1300 bytes. The logical normative statement is to say a UA which cannot (or suspects that it cannot) receive an inbound TCP flow from its outbound proxies SHOULD open at least one TCP or TLS flow to a server in its outbound-proxy-set. A few people on this mailing list have suggested that for any user agent that actually bothers to open a TCP flow, there is no reason whatsoever to open a corresponding UDP flow. I wholeheartedly agree with them. The problem is that this thread strikes right at the heart of our community's dilemma. We have a large body of people who have deployed UDP almost exclusively and effectively ignore the MUST use (and several even ignore the MUST implement) TCP statements in our core spec. Ironically, one of the problems which prevents realistic interoperable deployment of TCP-based SIP implementations is the lack of a standardized mechanism for doing outbound. [Dean also identified some other problems often faced when deploying TCP with programs that use "obvious" (Dean actually said "naive") textbook implementation techniques.] I think that a large number of the core spec contributors and seasoned implementors now recognize that there are many non-academic problems with SIP over UDP and that some day we will want to either deprecate or at least seriously curtail the use of UDP. Like a very heavy drinker we know it will be good for us to kick the habit. We are not quitting today. The question before us is are we going to do something in outbound that makes it harder for us to quit in the future. My concrete proposal is the following: - make CRLF the only keepalive mechanism for TCP and TLS over TCP flow (retain STUN for UDP flows) - make outbound registrations over UDP flows optional for UAs - include 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 (the 3GPP exception). explain that for historical purposes a lot of deployments still only use UDP, but that we expect/hope those deployments to eventually migrate to TCP when doing outbound. What's in it for the TCP crowd? They get to implement outbound with no UDP if they so desire. They don't have to implement STUN over TCP. The draft clearly explains why TCP is the technically preferred solution. What's in it for the UDP crowd? They get outbound behavior (at least for requests <1300 bytes) specified in the core draft for UDP. They can keep doing what they are doing, but with STUN keepalives if the UA and edge proxy both support it. What's not to like? thanks, -rohan > Most deployments only use UDP, some only use TCP, and I suspect there > are some that do both but I am not aware of them. Outbound as it is > seems very consistent with 3261 in that it allows a system to use TCP > or UDP. Keeping this in mind few comments inline .... > > On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > >> Let's go back to the original topic - what should the draft say about >> the transport protocol in relationship with outbound >> >> The major use case for outbound is UAs behind NAT / firewalls. Many >> of such devices have known issues with UDP fragmentation, so for many >> environments TCP will need to be used for messages larger than the >> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts >> the limit at 1300). > > These known issues with fragmentation might be less common than you > think however, outbound does not have anything to do with MTU issues. > It does not try and solve them and it does not make them worse. > >> >> If you start from the requirement "MUST only use UDP", then there is >> little room for constructive discussions. For UDP-only to work you >> will need to ensure that messages either stay below path MTUs, or >> disallow NAT. This implies significant limitations for your >> deployment environment. In any case, this is not a setup that >> outbound should focus on. > > MTU is a problem regardless of NATs or Firewalls. Fragmented packets > do manager to traverse most NATs and Firewalls. > >> >> In the general case, there are environments that have to deal with >> NAT and messages larger than path MTU. This is what outbound was >> written for. This also implies a UA that supports TCP. Given that the >> UA supports TCP and the fact that presence of devices like stateful >> firewalls cannot reliably be detected, the UA SHOULD use TCP (or >> another connection oriented transport). If in addition the UA >> supports TLS, it SHOULD use TLS. > > Again, this topic is not really about outbound. If you think a 3261 UA > that supports both UDP and TCP SHOULD use TCP, that is a fine argument > to go make in the discussion about use of TCP and UDP but it seems to > be an independent choice from anything to do with outbound. > > > Cullen > >> >> I think this is sufficient >> >> Regards, >> Jeroen >> >> Fredrik Thulin wrote: >>> Hisham Khartabil wrote: >>>> >>>> On Dec 5, 2006, at 3:33 PM, wrote: >>> ... >>>>> I personally believe going TCP-only would actually help deployment >>>>> rather than hinder it, but I'd be really interested to be convinced >>>>> otherwise. >>>> >>>> I could ask you the converse. I'd really be interested to be >>>> convinced how TCP deployment improves scalability. >>> >>> To name two things where TCP would provide better scalability than >>> UDP >>> for a SIP service provider : >>> >>> 1) Say that your services maximum capacity for non-INVITEs is 1000 >>> requests per second. If you get 2000 in a single second, you >>> won't only have to deal with all those 2000 requests, but also >>> with quite a few retransmissions sent after 500ms. With TCP, the >>> wall isn't as dense. >>> >>> 2) UDP sockets have a shared receive buffer, most commonly around >>> 64k I believe (even though the maximum seems to be 256k on >>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>> average, you have to be able to move messages out of that buffer >>> pretty fast to keep it from filling up. A full buffer means >>> dropped packets. I've also heard that on for example Linux, >>> every packet actually occupies an even 2k (or was it 4k) in the >>> buffer, so 64k buffer is actually at most 32 packets at a time. >>> >>> And then there are of course other aspects than scalability where UDP >>> is an inferior solution, most notably security related things like >>> for >>> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >>> >>> /Fredrik >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 Dec 07 02:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDeL-0007qg-4Y; Thu, 07 Dec 2006 02:26:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDeI-0007qV-NW for sip@ietf.org; Thu, 07 Dec 2006 02:26:30 -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 1GsDeF-00049W-4G for sip@ietf.org; Thu, 07 Dec 2006 02:26:30 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J9W00F9C7BYJR@siemenscomms.co.uk> for sip@ietf.org; Thu, 07 Dec 2006 07:26:22 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 07 Dec 2006 07:26:14 +0000 Content-return: allowed Date: Thu, 07 Dec 2006 07:26:13 +0000 From: "Elwell, John" Subject: RE: [Sip] Re: issue with oubound and the used transport protocol To: Rohan Mahy , Cullen Jennings Message-id: <50B1CBA96870A34799A506B2313F26670A8205C5@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: 2b2ad76aced9b1d558e34a970a85c027 Cc: sip@ietf.org, Fredrik Thulin , peter.leis@siemens.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 I like this proposal. It makes it very attractive to implement outbound for TCP, whilst still having the possibility of doing UDP if you really want to. Don't forget that one of the use cases for outbound is TLS, where there is no certificate deployed at the UA. For this case, outbound is needed regardless of the presence of NAT/firewall. Having to do STUN keep-alive for this case just because it is needed for the UDP NAT/firewall case is rather burdensome. John > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: 07 December 2006 05:16 > To: Cullen Jennings > Cc: Rohan Mahy; Fredrik Thulin; sip@ietf.org; > Markus.Isomaki@nokia.com; peter.leis@siemens.com; aki.niemi@nokia.com > Subject: Re: [Sip] Re: issue with oubound and the used > transport protocol > > > On Dec 6, 2006, at 16:33, Cullen Jennings wrote: > > I find this whole conversation way off base. If people > would like to > > deprecate UDP, go work on a document to explain that and > feel free to > > bring it to the WG. In the mean time, SIP is specified over > both UDP > > and TCP. > > To be more specific, SIP is currently specified so it can use UDP for > requests smaller than 1300 bytes. It is specified so it can use TCP > for requests of any size. > > Some people have suggested that user agents SHOULD be able to > send and > receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you objecting > to this requirement Cullen? > > For the sake of this discussion, lets assume that we have > consensus on > this requirement. What are the implications? Well, most UAs > implementing outbound are doing so because they are behind a NAT or a > firewall and will not be able to receive inbound TCP flows. > These UAs > will need to establish a TCP flow if they want to meet this > requirement > of receiving requests larger than 1300 bytes. The logical normative > statement is to say a UA which cannot (or suspects that it cannot) > receive an inbound TCP flow from its outbound proxies SHOULD open at > least one TCP or TLS flow to a server in its outbound-proxy-set. > > A few people on this mailing list have suggested that for any user > agent that actually bothers to open a TCP flow, there is no reason > whatsoever to open a corresponding UDP flow. I wholeheartedly agree > with them. > > The problem is that this thread strikes right at the heart of our > community's dilemma. We have a large body of people who have deployed > UDP almost exclusively and effectively ignore the MUST use > (and several > even ignore the MUST implement) TCP statements in our core spec. > Ironically, one of the problems which prevents realistic > interoperable > deployment of TCP-based SIP implementations is the lack of a > standardized mechanism for doing outbound. [Dean also > identified some > other problems often faced when deploying TCP with programs that use > "obvious" (Dean actually said "naive") textbook implementation > techniques.] > > I think that a large number of the core spec contributors and > seasoned > implementors now recognize that there are many non-academic problems > with SIP over UDP and that some day we will want to either > deprecate or > at least seriously curtail the use of UDP. Like a very heavy drinker > we know it will be good for us to kick the habit. We are not > quitting > today. The question before us is are we going to do something in > outbound that makes it harder for us to quit in the future. > > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over > TCP flow > (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include 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 (the 3GPP > exception). explain that for historical purposes a lot of > deployments > still only use UDP, but that we expect/hope those deployments to > eventually migrate to TCP when doing outbound. > > What's in it for the TCP crowd? They get to implement > outbound with no > UDP if they so desire. They don't have to implement STUN > over TCP. The > draft clearly explains why TCP is the technically preferred solution. > > What's in it for the UDP crowd? They get outbound behavior (at least > for requests <1300 bytes) specified in the core draft for UDP. They > can keep doing what they are doing, but with STUN keepalives > if the UA > and edge proxy both support it. > > What's not to like? > thanks, > -rohan > > > > Most deployments only use UDP, some only use TCP, and I > suspect there > > are some that do both but I am not aware of them. Outbound as it is > > seems very consistent with 3261 in that it allows a system > to use TCP > > or UDP. Keeping this in mind few comments inline .... > > > > On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > > > >> Let's go back to the original topic - what should the > draft say about > >> the transport protocol in relationship with outbound > >> > >> The major use case for outbound is UAs behind NAT / > firewalls. Many > >> of such devices have known issues with UDP fragmentation, > so for many > >> environments TCP will need to be used for messages larger than the > >> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts > >> the limit at 1300). > > > > These known issues with fragmentation might be less common than you > > think however, outbound does not have anything to do with > MTU issues. > > It does not try and solve them and it does not make them worse. > > > >> > >> If you start from the requirement "MUST only use UDP", > then there is > >> little room for constructive discussions. For UDP-only to work you > >> will need to ensure that messages either stay below path MTUs, or > >> disallow NAT. This implies significant limitations for your > >> deployment environment. In any case, this is not a setup that > >> outbound should focus on. > > > > MTU is a problem regardless of NATs or Firewalls. > Fragmented packets > > do manager to traverse most NATs and Firewalls. > > > >> > >> In the general case, there are environments that have to deal with > >> NAT and messages larger than path MTU. This is what outbound was > >> written for. This also implies a UA that supports TCP. > Given that the > >> UA supports TCP and the fact that presence of devices like > stateful > >> firewalls cannot reliably be detected, the UA SHOULD use TCP (or > >> another connection oriented transport). If in addition the UA > >> supports TLS, it SHOULD use TLS. > > > > Again, this topic is not really about outbound. If you > think a 3261 UA > > that supports both UDP and TCP SHOULD use TCP, that is a > fine argument > > to go make in the discussion about use of TCP and UDP but > it seems to > > be an independent choice from anything to do with outbound. > > > > > > Cullen > > > >> > >> I think this is sufficient > >> > >> Regards, > >> Jeroen > >> > >> Fredrik Thulin wrote: > >>> Hisham Khartabil wrote: > >>>> > >>>> On Dec 5, 2006, at 3:33 PM, wrote: > >>> ... > >>>>> I personally believe going TCP-only would actually help > deployment > >>>>> rather than hinder it, but I'd be really interested to > be convinced > >>>>> otherwise. > >>>> > >>>> I could ask you the converse. I'd really be interested to be > >>>> convinced how TCP deployment improves scalability. > >>> > >>> To name two things where TCP would provide better > scalability than > >>> UDP > >>> for a SIP service provider : > >>> > >>> 1) Say that your services maximum capacity for > non-INVITEs is 1000 > >>> requests per second. If you get 2000 in a single second, you > >>> won't only have to deal with all those 2000 > requests, but also > >>> with quite a few retransmissions sent after 500ms. > With TCP, the > >>> wall isn't as dense. > >>> > >>> 2) UDP sockets have a shared receive buffer, most > commonly around > >>> 64k I believe (even though the maximum seems to be 256k on > >>> FreeBSD at least). With SIP messages of perhaps 700 bytes on > >>> average, you have to be able to move messages out of > that buffer > >>> pretty fast to keep it from filling up. A full buffer means > >>> dropped packets. I've also heard that on for example Linux, > >>> every packet actually occupies an even 2k (or was it > 4k) in the > >>> buffer, so 64k buffer is actually at most 32 packets > at a time. > >>> > >>> And then there are of course other aspects than > scalability where UDP > >>> is an inferior solution, most notably security related > things like > >>> for > >>> example spoofed CANCELs (which can't be challenged, > RFC3261 #22.1). > >>> > >>> /Fredrik > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP 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 Thu Dec 07 03:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEkv-0008V9-Ms; Thu, 07 Dec 2006 03:37:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEku-0008Ux-Bv for sip@ietf.org; Thu, 07 Dec 2006 03:37:24 -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 1GsEks-0000PD-U5 for sip@ietf.org; Thu, 07 Dec 2006 03:37:24 -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 kB78aj8M004759; Thu, 7 Dec 2006 10:36:54 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:07 +0200 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:37:07 +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] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 10:37:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccYosEG5/idYBaVTiGJCXOUkhoc+ABN0IMw From: To: X-OriginalArrivalTime: 07 Dec 2006 08:37:07.0320 (UTC) FILETIME=[E1158F80:01C719DA] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061207103657-12395BB0-44FB3488/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: fluffy@cisco.com, rohan@ekabal.com, ft@it.su.se, sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.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 personally believe going TCP-only would actually help deployment=20 >> rather than hinder it, but I'd be really interested to be convinced=20 >> otherwise. > >I could ask you the converse. I'd really be interested to be=20 >convinced how TCP deployment improves scalability. That's not what I said. I said using TCP helps *deployment*, namely gives more robust NAT/FW traversal, enables security and just generally reduces complexity (e.g., makes transport-switching unnecessary). My thesis here is that going TCP-only makes deployment easier without incurring any noticeable performance penalty regarding server-side scalability. And we've done some experiments that show this to be accurate. 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 Dec 07 07:48:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIei-00021W-JI; Thu, 07 Dec 2006 07:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIeg-00021N-PZ for sip@ietf.org; Thu, 07 Dec 2006 07:47:14 -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 1GsIef-0003WX-Bh for sip@ietf.org; Thu, 07 Dec 2006 07:47:14 -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 kB7CkTsO020852; Thu, 7 Dec 2006 14:46:46 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 14:46:51 +0200 Received: from 4FIL15472 ([172.21.39.123]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Dec 2006 14:46:48 +0200 From: "Aki Niemi" To: "'ext Dean Willis'" , Subject: RE: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 14:46:50 +0200 Message-ID: <001301c719fd$c3c22790$ed9cb70a@NOE.Nokia.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: <8B658935-C258-4547-B748-84EB6A7E3EE9@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccYh3cH6/h1fNdhRz+j8IrTl2BS9gACWhRA X-OriginalArrivalTime: 07 Dec 2006 12:46:48.0903 (UTC) FILETIME=[C2CDB570:01C719FD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 >> Not knowing much about the subject, my guess would be that TCP has >> overheads, in that one must keep significant state about each >> connection and perhaps send keepalive packets periodically. But >> outbound seems to incorporate those already; I don't see how >TCP could >> be more burdensome than UDP-with-outbound. >> > >The simplest answer, which we've discussed here previously, is >that a naive implementation of a proxy using TCP is limited by >the number of sockets provided by the OS, which is usually >something less than the number of file handles and tends to be >less than 64k. This caps the "fan out" of a proxy" at a number >smaller than some operators would like. Of course, it's >possible to write a more sophisticated proxy using select/poll >that doesn't have this limitation, but only on OS that support it. Let me also chime in here a bit. We've done experiments on Linux using a proxy server built on top of our sofia-sip stack, and have noticed no significant slowdown on an ordinary desktop PC handling 100s of thousands of registrations simultaneously using TCP. The stack's Linux implementation uses epoll, which is even more efficient than select() or poll(). Now, this is not very portable, although other OSs have similar schemes, like kqueue in BSD. Also, if one wanted to write their proxy in Python, the numbers would probably look a lot different; then again high performance probably isn't what one is looking for with Python in the first place. Similarly, the performance of a proxy can suck due to numerous other reasons as well, e.g., a frequent dip in a hugely expensive database or RPC backend. We didn't really touch up on those issues in our experiments, but I suspect many of these other issues have fairly easy (and expensive) solutions to them. :) So once and for all, I'd really like to bust the myth, break the urban legend, and stop the folklore that using TCP wrecks proxy performance. On modern OSs it really *does not*. 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 svideocom@aphextwin.ru Thu Dec 07 08:32:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsJLi-0001vp-4p for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 08:31:42 -0500 Received: from host247-12.oskbraniewo.pl ([81.15.247.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsJJb-00028z-8m for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 08:29:38 -0500 Received: from QXEQ (unknown [194.112.187.104]) by aphextwin.ru with ESMTP id 79399ED21405 for ; Thu, 7 Dec 2006 14:27:12 +0100 (GMT) Message-ID: <000901c71a03$546afbf0$00000000@szczepan6d2ab3> From: "Original" To: sip-archive@lists.ietf.org Subject: clients Date: Thu, 7 Dec 2006 14:26:23 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71A0B.AC1BBD50" 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.8 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 ------=_NextPart_000_0005_01C71A0B.AC1BBD50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71A0B.AC1BBD50" ------=_NextPart_001_0006_01C71A0B.AC1BBD50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Svideo to the products section of offer you. Flash, linksall categories, = search for! Order through our secure! Locking right angle rcasvideo yc vga mini, or. Composite cablepin = svideopro, ftvga video. Just write question on subject line this. Email, = us first if any questions just, write question. Excluive, cables adapters amplifiers baluns. Write question on subject = line this website is. Section of offer you pin and, excluive cables = adapters. Copyright copy svideocom page was. Plate stereo wall, flash. Listing that, we offerto. Pin and excluive cables adapters amplifiers baluns selectors splitters. = Just write, question on subject line this. Question on subject line this = website is updated. Shipped hundreds thousands order through our secure. = Hundreds thousands order through our secure serverfree, shipping = economical. Please scroll down, see listing. Down see listing, that we. = Of offer, you pin and excluive cables, adapters amplifiers. Splitters, = etc please, scroll. Day moneyback, original here, accept visa. Secure serverfree shipping = economical. We offerto major caterogies other? ------=_NextPart_001_0006_01C71A0B.AC1BBD50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Svideo to the products section of offer = you. Flash,=20 linksall categories, search for! Order through our secure!
Locking right angle rcasvideo yc vga = mini, or.=20 Composite cablepin svideopro, ftvga video. Just write question on = subject line=20 this. Email, us first if any questions just, write = question.
Excluive, cables adapters amplifiers = baluns. Write=20 question on subject line this website is. Section of offer you pin and, = excluive=20 cables adapters.
Copyright copy svideocom page = was.
Plate stereo wall, flash. Listing that, = we offerto.
Pin and excluive cables adapters = amplifiers baluns=20 selectors splitters. Just write, question on subject line this. Question = on=20 subject line this website is updated. Shipped hundreds thousands order = through=20 our secure. Hundreds thousands order through our secure serverfree, = shipping=20 economical. Please scroll down, see listing. Down see listing, that we. = Of=20 offer, you pin and excluive cables, adapters amplifiers. Splitters, etc = please, scroll.
Day moneyback, original here, accept = visa. Secure=20 serverfree shipping economical. We offerto major caterogies=20 other?
------=_NextPart_001_0006_01C71A0B.AC1BBD50-- ------=_NextPart_000_0005_01C71A0B.AC1BBD50 Content-Type: image/gif; name="SVideo.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71a03$4a575550$00000000@szczepan6d2ab3> R0lGODlhAAJsAofqAAAAAH0ADgCFAHp3AQoLcnoAhwCOd8LNycLet5u+5ToRAGcZAIQZAKUoALIq CNQlAAtBDhVLCT89B18zDncyAKdAALs8ANEyAA5cACNjBURfAlRbAHxdBJFbAMteAOhcBACLAiCG C0p+AFWDAH6JAJx2C8CCDeCFAA2tACaWCUmsBVGXBoOSAJ2kALWVAOiiBQC5ACW8CkTLAFXCAIbG BKK7A8TLDdq5AADgABfeDUDVBF3iAI7nAJjkAMffANXjBgEAPiMAMTwIS1gDOokIR6IAO7IEQNQA QwAuOhsoSkQZRlkZN4QTP5QpQ7gjQuYYRgBJPyE7PjhFRVlBSXFEN5lNQM5ENdJDSgFRQx5sPjxW TGFfOnhnBqFrPbpTONxUQgB/PyJ8MUB0SVaEPY2CS6V6TsmGROWCRwCRMyKsMUGSS1utPoWjMZ6k Nc6YTOyrRgK+Phi8Pka6PlOyS3/EMp/FNMG7TdXERwDZSSztOU3rRlPeNInqOaXsSs7qOtvlRAQA hhMBfTEBglkOgngBjqQCis4AitcBiAAueh4te0cZiVgudX0pfqYTdc4jc+YafgdAfRdMgUBOjFsz jYlLcZFKhrFHjts4ggxYcSJki0NmgWdXe41beJNVeLJnfttkfwB3gil0gkSMf1mIeHh2caZzjrKE fOWDfQeagB+bdjeZdmykjnujhZGed8akdOmtigDAhSq1eTvEiFy/jnHKgq3IhbrAgte6ggTejSzh czvZiF3ufIjbda3ficPZcu3UiwgAyR4AxD4HuGIAvokAv5kNw7IAuOgBsQATtiIttz8jx18fwYQp yJQmxMEpudUtzgBMsSExzU5Lu1YyvHo5yp9Mv8s2ztRNyAVtuSpYzEpgy2tZwnZqyZRcuclZx9Nl ygCFxCF7xEB4tVaLwHN7w6x5zbiDt9J3xgquxBWqvkqttFOhvXuuyp+auMWutNKStwW7wiS3xjyz vFa9sXe8w5TCxP/34Zqar4WAgf8HCwD8APXwAAcB9/QI8gH1/////iH5BAD/sE0ALAAAAAAAAmwC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePEP+JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fMEEKHUq0qNGjSJMqXcq0qUSgUKNKnUq1qtWrWLNq3SrTqdevYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3L1GugAMLHky4sOHDiGP6Xcy4sePHHRNLnky5 suXLmLdC3sy5s2fHmUOLHk26tGnCn1OrXs067enXsGPLnk27tu3buHPrntq6t+/fwIMLH068uPHj yJMrX868uXPVu6NLn069uvXr2LNrl/y8u/fvZreL/x9Pvrz58+jTq7cKvr379/Djy5/Pdr39+/iv 09/Pv7/BlwIEWFKAAvxD4IEEGijggAgWiFKDCI7UIEsTMuighAuKlCCECZrEYYUYFvjhhSdV2GGI Gh6oIIkpgtiiiiSNuCKJJ56Y342KOURgQTvueJCPBPkIZEJDCiRkgAodKQCPSAbZpJFIFtnQkEX2 +OSUTVq5pJNb2qOkQUAeOJCSXUoJZZhPmunfd1VGeSWXYKb5Zpxdngnnj1fmKeadX0ZE5ZtaPvSn l4DKuaWUbR5q6JhznrmonWvClyihdd5pqZqM1oloo5hSWqiioEr0Z6WBYllppkyWmeWcmy6Jpqqn Ov+6KqyRIgdghi2u+CCuufaako02+hojrwwqaGGvwbYELK8bErsriygOe2GHyVYrYI0ZJpvrgthC i+O3OY0o4oe6Hitsibha6+2M0DbLIrfTkqvSsuTK6KGz7IJILbHqlksvhLq6Gy24BKsk6KeUItQq pEnqeWqnCMKZ6KuiOpxqwqYqjDCkC18M4cV4KorxyLWCN6mare650Kh0ZizrpxT7abHEjYasMamP dkyzqxu37OmjJZuMMMqs1kzkzJY2HCrDjiatI9J2duo0qpfO6rOTHENddcxBszl0zTo/jbOmYJO9 NMmeTs0QyzsfTDbaMYeNMZlUXx1x18nd+u61+Pb/C5Pf2iKb7d4W0ojvvOkyy/e66MI77t7xOuj3 jAPDGPi/AxeseUlue/zhz6V2TqfUDdbNNKGpfqy001qqfnOfVEfMIeg9pz0iySpLjffuvPfu++/A By/88MQXD9fmyCevfFbGN+98XMtHL/30Oj1v/fVoUa/99twbjP334Icv/viQdW/++dqTr/76kaHv /vvwxy///NKxb//9FNGv//7i4e///wvhnwAHOB0AGvCACEwgAAnIwAY68IEQjKAEJ0jBwijwguyr oAY3yMEOevCDIAyhCEdIwhKa8IQMxKAKx4fCFrpQJCuMoQxnSMP5vPCGOMyhDnfIwx768IdADKIQ /4dIxCIa8YhI/CA/lqgVJpbEidtZIj9aIsWTVDGJ1HuIFBGyxYF08SJLNEgYe/PFgnSxjF4cI1HQ WMPisFEgZXxjRNSYxt/I8Yx0TCM/jCLHNpbPJVc0SSD/MUiaQHEkh9ROIVGySEImEiiNxGJ2pEjJ KTqykpjMpCUR+chOWvKKoGRiKD8pSieOkpGVJAkmRXJKVlLyia+8ZCpdScpNZpKWkdSkKmMpy0hK EjZaxOMe7RFHNVKSmHREYx6RqUc4jnGLwnTmHqOJzGGa8ZnYbKYmpVnNZjLzmN0MJzWhiU1rEgSc 0fxiH/1oR2OW85zutOY6mXlNeHKTnvTEYx3Faf9OePbzIMKkZjfZqM53DjSe4VRIQaeJ0ISyszMv CWQraclJWz4SloLcZC9XictbdpSjGeXlR2s50SouUqKmTOkUUbrSWVoRiiaFqUp/SR6WUrSiOL0p KjMKy5iytJQ/bakvPdpKjmpSqCHN6SltulGN5vSSTZ0pTcXD1EEyFaop8WRPgSpTn3aVq059KVCf ystGnrSrN/XpU3EpVpzm8qJTjU0w5WnQeyZ0ncvMKznzeExw6pGhy+RiGBf6V29e85+E5SdgDctY w+5VsP98KHASW0y6DrOy+7SnGBvqWL5ylpvpLKdlzVnQew62oeM8rWrt+ljTutOukhVOYqsp2m3/ +jOzuO1sP2fLWs9etpJ/9Ss+g0tadKK2rpmUJmZni0l/Bja235mnZqcL3eq2JaJHza52t8vd7nr3 u+ANr3jHS97ygjSucj2KdJ25Weu697rojW/B3kvf+tr3vvjNr373y9/++ve/AA6wgAdM4AIbWCPy TbCCF8zgBjv4wRCO8EgOTOEKW/jCGM6whjfM4Q4/T8IgDrGIeejhEpv4xChO8QFHzOIWu/jFMI6x jGdcQBXb+MY4zrGOg0bjHotmx0AOspDt4uMiX2bISG6fkZecmLoEQCBPLkiUoUyRKZtFCkPBckO0 7BEuL8XLFwHzljUiZoSUWT4vCQBJ1DwSNmOF/81ubrNI1BznlsD5JHWGiRRIsueR9Pklf8ZJoEUy 6JT0udA0ObRLEJ1oQp+E0SuBtKFjwmhEF1rSU8E0deLMaa3cuSSdhsmndxLoUlOa1CbRtKN5ouiW qHrRq87Jq/msE0unGjCz3o2b6SznfwTg13n2NbDnLOw5D9skwN41sUFNbGUL+9fITvaze31sWDv6 z4eWgrYfre1t/6Pbl/62t8XtbXDTutt+Rveqs11uPxNa3Xw2N7zNTe5B03vP6sZ2vfE9bnyTO93w vna/503vc2fb3fv+9r/rbXBs53vh/HZ4uwP+7m0XHOHrHjd3HDLlJ3fcHla2skE8/vGBiFzKVP8G +cipHOWWE+TkLS+5x03+EC5j2eb28DKYdZ5zguwc5zzveUG0PZCb+1wgWjZ60YXe86AfPec4HzrS F3JzoC9d6ESfetOtfvWiR/3oTvc60pM+dZ5nHesGObuYq750tTN9612/etjfrvS328XlLlc5zRMy 872nHCF5hznL9U74wqc85IOfCNnJTnept/3pca872h1f9qcv3vKT1zrm4671Mz9e7kxnfOcbP/e5 Nx3yXY+65Fev+cinnfRgjz3nM293s7tF1L6WM5yTnWfe577Nvge1tH/f+2ZzOvhrXvaydx9slfj7 2hWnuKlNTWt3Uz/c1gd3qyP+cHZTXOHgz/j/w1Mt7+o/H/zXD7/CqY9x9Je//bHW9/rPbf5bI1z7 6j//+vHP/vtXv/3sNhu81mzKh2fJF2ooEWqjRm2552wpsYAL+Huwpm+thhLT93+xNn/+VxIXaH/6 Z30Z+GgZqH8VCID5B33rVn8dGIIrqIEhGH7yR4InqH4jeIIt+IEzWH/w1380eBgQ0Xcql3d/93e/ VniI93ImF3grF4SHh4QoZ4SJp3clZ3h1p3SlJ3ZX+HmjR3mnB3pdqHlfZ3e0V4Wil3qs13pleHla eHZoGHpk+HpgWHlj13hiaHtzaIdymId12IaQR3SqhxciF3LAdhCDCIRQNogjV4RK+IRAGHNF/0iI j9iEIBeJU3hyO+dz3XYQmZh0mciFnMiGoAhuXud2WNeJaGiKQweKY/eGmGh0TvdzQXeGm5iKpjiL UCd5cbiFs/iKYfeJW9eJ2jeKaaiJVceGo1iKYTgWTJYYueZqg9GMzsiBN5JkSeF5FWGNSIGNigeH ebOMhgGNFvh9V3FxqCaN3niO6JiO6riO7Igj4EgVJWgV4iiCFjiO9IgV7xiNITR+uPYT8Thp8JiC +Ah/9WiO0JiPtpYV+cgSC8k9EJGMTKGN2yiGZqYUZXgUEol6W/iQ16iJESkUGfk8nwiLwliSZceJ x0iLxbh2lmeMt+iHageMqPh1I8mNf0h7v/9okqoHjFCnkqdXi6LYijBpc6i4ijBplG1YjHJXlHD3 kkl5i8K4djz5eC4ZjE6JlE3ZH3pGkBRIf/d3cC6IfTy4gmIpfzr4f125gxi3fSyYlijogvtXkHH5 lj0IlnBZliY4fTGYg++WlwYHgmoJmAJ3j3dpgw2pPWYZmHRZgW5Jj2PplQXJg+gngv5WguFWmRto b5A5mZbZg2tpgxgokIvpgRgog+n3mH4pmIVZmqBJmKa5mQyUmAAXfRaHfzD4lQmJmuLnmOZ3b5Sp gdp3mWEpmjUYnChonJDWmDJokA33fZ2pmsvJfRrHl68JneY4mpW2mdXpQLIpjdh3nbIplqH/qZsb OJqeiZn/6J3DOZmsaWv/mJzWKZmdiWnPiZ0q6HztqZ182Zp0mZ/x+T4c2XpxiIeZx3V7SIdmGHpw iIdZd2Y0qZG5qIueiKBhiIt9CHtz6HgEypII+oV+iHlZ+JR3KHs9iXpv6KBYSKJfKKDxAWgDx4ED F6NmGYPTmW4MR37PN48BF4AOZ3/5p6MmyJ5BenGlxo8+Gp0Wx23Xp6PTWXDoJp24+Z3RN5tIioNO mqTJmaQ3eqOauT3U+KVgGqZiOqZkWqZmeqZ70Y5qakKStpCH6ZmZFmn4eZ2NtjxvKhsPGZQ11xmM Z40h6ZEYcZFEgY1lJqgcSnUsKhF/yo1g/7GoEOoQhUpk1kaQ6JGelAposqYV9DmnoYmpcLqVNXGn mVqnMpGQu1FpBNdv+ydxNUqOtyl+FGiXvumcn7mqtXmZMjqYDQdwipaq7cal3TdxuUqbOFqZqup+ tBpxxaqsU4qjxFpuvtqsRxqltxaszSpvwcqqmhmtW8pwrgobprqa/GadAFmr4gqWuKqYe+l+O6ic 4sZtXPmu5omDf6mrhUme8sqey1mvddmX5lmrsqqfn/qqq2mj9pp+hkmuBiuuvHmpp2GbN2ifDtuv mDmDM1qtnYqemTme+pmd8RqxcImx/6mwLKiD+0qyxHmy/UqdFiunFUueJ8uWI1uy5Jqbnf9aG9KZ sxL7grZJfzl6ljT6pBk7f+sKs/tGrxb7fvNal0p7r/zHsazJmUMrn8XZs7OZsvwHsS4LnFbLn0cL q1r6r8V5lmQrqlLRkYeqomfoelLninz4oBv6em4roZxHoImKoXooi7WntnjLtnW7eWurhQdqtwnR pxAaqQrhtoJqoh3qhYwboiu6uMMIX/q4s1IrmE26sGg5pJ/Zo5JJsPoKtZbrn+9Klr0Kntt5r5pL gwh7fq26n0JasPGXsgLbnbNbg6Tbsl7rul26tKQ5saXRs1eqqktqpWG7ubxqrjwKu6ArcaKLrJZa vOf6s8BqrPk2vM57aUK7sf8mnJS6o9L/Gm9Fam/c2pce+6Ot6pviW6Rc2psfWLzsC6Pd+i1maz5S aqflqD9k4ai9k7buwb+F+zuC8a0SdL/cyT9omsAKvMAMrMCTUb+gWhiWVqNyyWoU/IID3I/yKGin Vh5dNntjRpEgYbgjPJGPmrh3a8IBXBYAHGYpDKkBWpEMsagtHMK31xMNaalRocNbYcByisMMiRgQ HI05HMGEWa6T6o+3wazVm6PXm75POqxz+bq3C6Xi+K3jmq+uK61di61SfLq+qr3Q2qTCyqrZ56/z e60Ll3Awypi6WsbJm3D8uKmxqq2GFsWvW77ZZ8arGscQN4+mQbxAy7pDq8VJ66+9W7Ro/9ym5IfI KTifhQyyvequUfudWbyy0Cq21UrJnfuVjnysJuuWdLywKsuc7YqygnzGO8vDgVy7qgm7kFye3amx Avm58VrFxymwZau7qdu7sUuzPHu7siuymuy9BFvKMvvIPxy7pbzLuevLvey1GAyurtyfxmnKAqe+ oAt9W8zMyzqtoqmtyEybOnu5xUy2Vwu/bpzNztm0yJzKx5y043eayxzL00y77dnFHducYwy8PgjD git6uEioIkp5EKm4Xgi5h3qTVsioHOq/oxe3jCvCeUuHcIvCAd24IJp6GR2Lb0vRRjmMprd5Akq4 j8u3fvrC4ZHE0fnKVLu7wmyqrSu6VP/8qqfLn1QsyasMzcG80zG9n54LmZkrzPFsuvgMy+qJuelZ n2OrmKo7s+tMGXu6lKGIjDVJjLFYixxtk32oirR4oArqoVgJlQsNlKQoix/qk4k6lZ2X1g96lV+N 1hY6kxd6kmbthq94uG3bkg1NjHAdlSY50UGZ1TGpcxa60nE1xKHxaneq2Pfcymtaqtsxa2/q2AMb vJHtohdMHZQ9qpn92fLVwKI92tRIGqoGnxw8jpsN2uQxFxL50ACtoYDakbM9wxxRwydM2n7x2gsa 2yRtFCGJ2yWs2xHhqTZ9xdaaxmzsfbxKvngcx0TqxbhJmQH7x7c6yWzMzVLsvpvMx+T/qM1EG4Cs HaqdPLGXbLQUG8mzjMHV3c3x5sjrOZ8Ie7BIHZ6ULKWmebHjTRIcObcjndF/67gA/tuw3dugl9K5 ONcFvZGRq9GHveCGitK5DaZb+bJdK8frO9S17M6/C7bsjbviDZ6Zeawt6M166aohnprE2dTWvNr7 vbXUW8HNzLkgu8vz7cy+/NOEbOLY/NRIvOO++8xwatnpqN/AfLy6OXE22qM9zrsf3rLrjcuK7NLx F81JDeQMS6dOzn6szI4RUaFMSda1F+a26ItmjtV87YZp59W+yNW6SIpXKZViTtiIy5R0jolqPedf rdI7ttgvHl9wIdzEjWF6Ougy9OeI/57oim4Tht7ojs5hix7pnPPoSCbpln7plk7plY7pnN7p463p oB7qAebppF7qpn7qMibqqr7qrN7qrv7qy4Hqnw7rtF7rKiTruJ7rMWbrvN7rvv7rtqLrwj7sxF7s OQTskG7s64jsG6bsnN58MQHtEthrVCHtMmHt1V4TACAT254VAPDtK9HtMyHu20HuWGHuLYHuhcF7 0IbteHZswRaB084Tw0d8D5hmzJZ8NSHv+j4S6l4S3f7vKiHwOaHuBE8SBz/wJpHw/t7w/0Dw4s7w QIHuAe/tIiHxD28ZCIjvuqcSxecTCkjv+U7tNiHt7g7wF8/tUWHwLoHxC28TFK/wif/h8j1B8xlf GZ1WbfVO8roHbctnbMNGZ8x3Zzrv8/2e77ym80A/9DxfZ0wP9ManbNJW73UW8OAO8N8O7lnv71v/ 8g/f9dt+9Vkv9l3/9VZ/9Re/9WPP9WAP9l+f9mgf82Ef92Sv9WaP9hm/9mdf8WXf8G5f9xWf8jc/ 9nxv9myP9ylP9od/+IG/9nfv8JRxfB3f9O/OgA14gA7YgFJP+Qao+Qxo8gU47wNIgMZn+fEe+mEP +Q4f9zcv+Aj/8qzv968f8a7/+q2f97M/+/8e+Lov+4JP+4Nv+7RP7nOv+m+f+MCf+Kt/+3w//LaP 8Fav/L7/+7fv9TafFRs/+qLf+T//f/mTX4Dar/0jj/TTTvQeH/rsHv7bb/qdX/XVj/LMH//wn/uq n/rTb/zUf//2L/0nwfv6DxD/APwjWHAgwYMJCwpEaJChw4MNF0ZkSNFiw4gDL1ac+FBix48aO24U udCkQpMpVa5kmdLeS5gxZcIMELMmTXsBdO6UebOnzZc3a/rMWZTmTp1GgwZN+nOm0aFAixJlylPp UqBEhTbVitUnUqEyAbwEUPbpWHtoyaYt23Ym2rZm1aaNOTauWbZq58KEe5cu37xu9/r9W7fwX7dr FcM1XNiu4bmDITde7Pgw48iX3wJee/cx58914yp+Wtr0adSpr3al6tQ11KWspc6+/1q7tdfVsV+H pT21d1ScsHPXliyWNN29mzNnBpy8sXPGxptv5lzZOHPQ2TVbXk75eOjtocFjnly9ut7D3ztLt67a /Xv4XXHKpw0ct2+mw3XPD14ft3z7sMqJt/72MzBA3gjk6jrz2kPOu/XIGo+vCdFLz0HxKqQMr+Q0 bC86vaJ7cLoGuzPPwgjZSnFEFdlDz8QWwXNMRPhqnKmllQJYSMeCeEQqx50I4lFIIv/xUScjk9wx SCWLZDKlH51sUskjkTQSSR9NGtLJJ5kEq8cedQwyS5DaWslMhwRC8ySEyuJoIjcTWnNNNdls0807 H4rrozxRGqlMPNv0KM44DSppT/+PElUTTYoW3UgiMxUiqVA7B70zI0rlxDNSPnH09FNQQxV1VFJL NfVUVMFMdVVWz2z1VVhjDbVRWUGltVZcc9V1V157ZWlLX4O9NVhihS3W1WOTXchGZpt19lloo41P WmqpHa1abLPVFjXntj0rMW/DjVZZcss191x001V3XXZfFfddeOOVd15667X3Xnzz1Xdffvv191+A AxZ44HxlHdZUPztFONmDFQbp4XYjVrZhWhve1WJDMZa4V2g7pI5ZGi8E+Th4u23QQZI79s5kCFVj Od6XpYUuZY9hdplgnGX+2MaQY77Z3pdZrtnalX+Gz2dxkX5W6J3r9VnpnN8VFVH/Pam+1FGVqE64 okAR1ahrr6/GmmtJwTY70IxFmhPSPb8W+2uKIUrT6kvdzuikSOlMe++xw2ZUb783TRPOQteuWm+O EIeb77EdrfhvtPv+M/KNj5UUYkgxt3PrrlNyG6MyFWWzc9L/HLzTzvVM9PPV63Q4JEsfnftuhROO u1HcR6LdYtZLUhT33UE/HSPaDZX7eOFRD73SN4mv/NzLh1dd+uVzl9735lW/3fTks7f+dJSwF597 0UMPX3POy7e9Jex/J39rz1vPXvm5u69YfvBbv0h2+e9Hfv7nCctv6OPT4xhFP7Zx6n/RIxyl7Oe4 8WGOJA+0yF3wl7XY1c1/ubvV//rwpsDheaZ/WWub+eIHsfPxz3vMg1veShjC5aFQfwG0nAmvV0AW Zk6G+3tf92a4QNHx73vTG58KVci9Q+EofR3E4Q6ZF8QY5m+C/suf9ggoRPLVToJRxCEPaciq94Qo RXh5DoTEiBj2sEgu5YlResQIIxapsTgnqswbi8acmb1IPdIZGh/NSCE3pnFCF7Ljec4iyDoCkkEl YmMcM4RIQrJxjVGr1tQy1ScSNo5wRMzholboyfBBjmyb0tqcHLi3CR5ufmGrHwZRiLg8PRFOmszY 4TR1y7rNcpMRLB/WUqkpKGJxdmerpQGL18Bi9vKLy2SmFptJLo1dzGDPpCY1Kf8JsD5eM19QCxc3 U+NNbYYzZ9Wc2AnJaSzoxSqa52RnucT5TnjGU57zpGc97XlPfOZTn/vkZz/9+U+ABlSgAxUYuK4J ToImVKFAKw1C3ePQaKFIZdSBaERNk82FZlSjMilnO10Jq7hBkyXr9GhJTfrMUmJqd6QklOBMyVIm 2s11KSWeSm3qS0vR8m2A8yXlFve2mR4Qcj8Npid3Sjo5Me6kS2WqOjOYueDFr3QyHB2mpAiRu3nx Yb7jZROZOL3fHdN5XYyqWHX3v/4l9ZNNZWtbmyUjj2HUkYE82SDVM8e5Do0826GjyEB00ZbZda5o /KZm8CoiPZ5so4v9lyVFGUv/VYbkhT4U4ehe6TXBYXWyg4teZav4VZWa05bis2AqjeoqrXqVsxBs a2tdq8QtcvF8QBwiBmW3PbRCEaqvU+0JqdjFHnbyt5ZFq2mz+lrkMjWMgEwsGi2EWA/1tZHYUaNh G0kaFFE3PIckLF3HKNhBIhawcNwudsvLWPTyy7GRPS0wjcepScHUthJ8aS7F1jgHVpBy+P1oSz1H 0/axUrKnne8wcQm7BJo1uQtm8ElJ+rwHN1jCE6awxCK8sQtXWMMb5rCvMhyxD3dYxCMWVXpNfGIU p1jFK2Zxi138YhjHWMYqJnGNbXxjHBNkxjvmcY99/GMgBxnIOSZykY18ZCQn/1nJS2Zyk538ZChH WcpTpnKVrXxlLJdKyFvmcpe9/GUwhxlgWSZzmcksZjSnWc0vMXOb3RzlNcdZznOmc53tvNg351nP e+Zzn/38Z0AHWtCkunOhDX3iQSda0Us9dKMdvdBFR1rS1Xx0pS3tz0lnWtOb5nSnj3xpUIe6np4m dalNfWpUp1rVq2Z1q139aljHusmipnWtCUrGbVZ0X/zgx7x4LZNf/zPYpRl2TIpt64HNyoKCMtd+ l8lrX0F7IdJuK7WnzY9/WLsg2pZ1usDG7HI5+1TiLpW4uU0Qa587VNpWt0nbnW1sp+Tdq5r3qsMY GbvoOqL6Fg22cA3sXj+l2P/HrtGxCb7Pg8Pk4AmnFsOR7W98tygwYrlWYPD977cQZuIS0rjFOZ6Y ijf0Wp6ZCa9NHuyTp1zlJgd4y40dcJTDvNcxf8mvaW6PhKf85SzHecBr7vOTAzzmOu950X8e9J7z vOQq3znQif7wbeFaLn2RkCJVREYOUV3kisw6x7l+Rqlr/VtfN43Sb/5zhZ/d6Gl3+c1tLnO0u93n L2f72t9Od6MPm+Zmn3nf0R53pwtc73C3+9yhDh9lG69OaNsvof6rS7zNkvGsc13kKz/5T5GSJemO N+e3HW90g14l7O48tk8Ob9SfHtqrNznq5S36lUhb9qW/tutr//nUm170rPf/lOc9b/tu37viUyf5 x7N+8Y5b/eoRDzuFRh6i4n/r+WWfu9oHj3fBu/zoT1+505lObIJ/X+5MD3/1/X73uis9+2zv/t8P X6PEP97Z365l5dlXQfs7XvH0p7+n+H+w3/s94Gs30rs2lfu8Awy9BNw8amtA0Du90Bs92BtA3cu9 21PA2Nu9CpTAbiuIexs7jJM4Eay6EMy4fms+FIw4iStBiuu3EcS+vDO/unO/pdO+pDu6tJM578PB 1EA/90O6tYNBGrw7HwxCGpzBoss5w3s/1Yg/y/s2s7k8tbI/XfobZsO8KMw/q3q8WDI3DYxA3AND CgxDMgzDAgQ+1ztDB7S9/9YrQzakPQvEPd5Lwzl8QzGkQzOcwA5Uog6yKT+EKf0iN88qpSocxKE6 GM+4KZMQQAjsvjNEQ26bvUWEwzycRAR0wJS7wEvUQEmUww2Et0aEQDBkRFEERT3cw1KrtztEQ1T8 MyakPtUwuCV8xcNzNVVsRVzMRV3cRV7sRV/8RWCkIWahj225DW+xitcYxnhBxve4DWakRUsjFTIB llihRpUgk1KxRmw0FWv0lG38lVOhxm4MRiirka8QkGKclmZxRnRURmcxxmRUx96ARnqECqQYkK94 RqU4R3wMC2T8x34MyJm4R4GsiqT4R30MyKFoCoFcyNggSNuASN9AyGe8R/+CdMh6rDUAOUdi3Ef+ mA+ODI4E+Q2pYMcB+ch2pAqGbA2MvA9+LMmsCMkCuY+HzEhkA5CsmMeoAA7ZQEmRREeVhMmBBEr9 SEmdtA0BCZCf9EkEGcrcgEebrDScBEmJ1A2eBIvhAEh7rMqpdArWwEqSFEmL9EqfXEoDwY92FI6z jMpQ60q0LI2dVMsCCUrhgEq3NMu3dMq5fEqyXEuafMum7Eu/ZEs1E5Ut2UYx2ZFrVJUpSUwwGZJp LBLJnMxvlJLHVEzMZMwkgUzHVJXDzBHJxBLF5EwoocwpIUcyO0wr4ZLV1BLNjJIvEZLVJM0o0ZIu AZLPvJLWDBPR9EzRBBb/0jxNxhyTxpTNzhxOL0FNJjPHR4NKwnzOd2w054RO6rSR6Uyz66xO7dxO 7uxO7/zOO1NO8XyzZpSW7MyW8zSN9HTH9cxOAknH07BLvWRO8KSkUBlHw5xMXsFPUOHP/gRH4cQR /7RMXOFPbdTPAP3P8TSX8oyW9aSWB51P+GxP93hPbXFO+YxHeazPZPvPLknOD01O3aySLAHR2QzR 3RxRIkFRcTxRF53G29xMzTTOxERRz6TRFX1REuXNFP0RMZlN1vzNHd3M1hzQBT0XIHVNIM3N4yzN JYXM4sxN0FzSzAzNKC1N16SSJgFO25xRLZXRx4TSzxzTKj3NJC3R0YTS/zB9zSNVlgZNy6bESfns ybMMTLjky5mkS79kSZesDaScybrE0zoV1D/dS9igU0LtSA5tLAUN0uN81BWFEh8dzTSdVC/9EjK9 VCvJVMyMzcgUxyx1VCkBC0gdU0wtUy69UTCNVB7tTdNs02N5U8BM1LVE1DidTz2dVUVlSj8NzJHk U/+YSqWkVWA1Sv841JwEVGKM0EWFl/ukVNm80mhd1dAsVWhl1SsJVVdd1d0U02u9zGnFxgOt0s7c VGyl1nK11mmdUSbF1m3l1OJMUFgtFyb9zU7tzSElTk+tTX7dVuNE139tUc58Udb8UjWV1HcNWMuE zXt1zH5tUhVtVyqx1/8lMdfh9NJ5xZWoKdaAYtZjhCePbdbF4th/Cln4DCeTFVlveR5QfS0j3ZXa /KKXzVhYUVmbbTSazVmd3VmeXZWb/dnw7FmhHVqiHVqgPdo5K1qlXVqmbVqnfVqojVpJQ1qqLUyp vVqszVqt3Vqu7VqvtaaqDVsw+1qyFUaxPVsuK1u13Ri0bVu3fVu4jVu5tbO1rVt2mVu8zVu9jVu7 7Vu//VvADVzBHdzg21vDZSzCTdxcOVzG1SjFfdxYaVzJPdt8uJd8uNynqNx8uVzNtZfORY3PnSd+ M7RQyYeFMN2CQF1zUV1ZYd1XcV2TgN3TTQnZrZXaDZbbjV1lgx+G4S3/Waqmr2qm9/hc4u2X0MWW 45WW5IWJ5X2J423ebIHeeJFe5j0axWIokeEue5oZeCrd1P0H1UVdzpXd8SUI071c8+VclShf8P3e 8T1f8VVf8wXf+E1d+W3f8KXd8oXf9EVf+kVf9n3f2W3f01Vf9h1gAg5gBO5f+PVf/kXg+HXg2X1g 9/Xf/83fBmaf+xorYgKq+vog/zqqRzkwIxKqA9MdRcwqOmkbxQGUEOMVDHbfBaZd+v1eG77hBCbg BM5fG3Zg8dXhHOZhHKZg3c3hHp7fIy5i1nXdGJZhHEbiJa5hGp7fKK5i8m1iKJZiIK6UPrzCCxqr 5tkgs4Kf4wKikbo8//oyY65yJWFKnhfelR/+YSDO3fNdYCYe4DrO4iFGYh3OYz324z2+XTmOYiPW YzyeYfzl40R+4kJe5PVtZEAGZDueYypG5NUypzLWotTyLQJSH7BaqwJroquqHwXzoFEOID/O4/eF XQFeYgEu4AMmZFdWYD5uYPmN4ymuZFiW4AvmZVmeYkKeYEWOZGAW5pVQZWPW5VzG31cmZmTxZNip rNJyYTZ24cwirtQyJtKim/1Zti/WIQRiL2KBj8rt3HJ23tMo3uI1jeQ9Z3S2h3WWCXOu3nZG5+eN CXd+53fW3HqGZ3zW5+r154D+Z34m6H+WZ4DO55lwZ3U26Mx1aISO5/+P4V7u2BnBiiTr0o5FgqPD 4ivtjSMS8as9kq6UAZh8ZuiDHmjMlejQXeeTTuiDnmd7jumBTumVtumCFuh91mfM1emAlmiVhuie pml6TueaPmmFTml/dmmfzukN0d7mkqOMxmgY4ZCGoqMzOg/wQiQ8sgyK+iMSvN5/aWl85tzMvemW NuuFVmuZhuehdl611mmZHt+gPutzTmukduuhNueb9mnmLee4Rui/3uu+xumehl7ijWuzTuqjhuu9 1uvHFo2sNq/FABfBCI8SNKi+eCRBsuxJkmyQDrk9GjmtNkHR9rrNvpcly11FjhjWxpXXtt0Ne+O1 je3YJpfbjpXc1m3/DaPtJ+Ox5qXrnKHebSHu4mas0Z1c5V5u5m7uqIFc6IawXvFtPcsw6j4TcnMy 2r5ujukmojkkpAnvL0vE7C0s7z6oqyYYfZMrRsUV3w4p/7MVLDuizNMV7q4hC2OV4bpb4cMMrDvt 57NqkBsNAc+LuxIMg/q4jaM4q54OjAvwFxG7fKs6BUeOEIRw53O+p4GM/xbwBveuzaaRwUBwD3eR CteuBffs5zq+fPNw6Atx5YBxC39xGZ/wFBdtAk/wE58MFpQXGx8sRmqO56Lwzojqv6qrkb4rDv9o zKZwrStwIQ/yqzZy8ybyuEosvZpqql7yidZypmmuveouLg9tM5Ko/x+PLgvH6sBKci9/wXtBc7xq czHPqzLyaAzh6uuS8u4acvPi6DRSDkg6DeqKKx6fciVHci3f6OkSdO8KacVCczsf9Db3c0evGe3y 8+Rms909pa5yHzVWnmxOMJ8SZeDKrXD2k6h6qgdCH8y6pey+IFfXH0T85E6ndWVKIjNuIPdqL8jy wx9Km8gJRE6X9c0SISMi9V8HIJ99qEW/dDzXDsmg9JD5aj2H9Gqn7D2v9EgP9BUxmkkvdPA+dJoR d0CXc5Kmq+IQ8URnGkRfERmxc3hX9zvK83GRb0HRqmDPoV8iLjeeLWdq4zBuHxhqpZwqniKKLc5a Y9MSLXw/+F46Jv+u2qAs4mIk+p78KniMHxSHryKOXyGrCnXkGfUvbnhlOpWjWSM8+mwN33Gtjvbh +2zi65aYlz7oA2nJlnGvzvbK/nBCGvDPUHGJ4vbUji6KvvF3f/GSPhEV7/mf73DQSMHHSHkWbxrS fvqm53mj96sWh46lf/d6j+6FwW+wx9r7rm+dde59yXRmf9uxb/tRQXu4HzW3n/tzKnv3liZ7/129 LzVYujBY+iiQenV2qq1R4V3qmRqHwZh1UnxUWXzAf+Z0guZ2om7QIpUHM/xyY6flapmRASyd6Xxv j7rN/3Mm7xe19yfu9SZuUvvTp5dZ2ZwPJqoW4i8Qrr+qyncCy6X/YQ9jqTKqlZqqBKspA5OqDu6b AxompdIs6+l7E+7Da1YblzrhD7Yl4f8v+QL29lIcF1JEK3opnxqq1+IgJELjTyb4UJb43v93iHdj 4g95Tj721Ol04Fd22sp183f/M06dz6oarDrlNQaIfwAE/itIEMDAggkNLiTo0KBChQsHNmwY8eFB iAk3CpyI0WLFixBHkixp8iTKlCftsWzp8iXCmAjtAXBZs6bNnDRZ4oTJ86XPnkB3Eg06tCVOoUp/ 7hSKtCjRm0OTQnXaVKfUpzp/LrWas6tPrVinQj3KdStTplnBir2K9uzTpWipAqULN61WtmrvusVb 1a/ZwIIHEy48/9hpVrUz/0ZFKhOwzKSLw3qVXBmvXKqXMxeNzNfyTM6REX/1bNU01sWj6wKOOtnm Y7mOH6fVS9Pz7Z4x4359y5n139WUTePW3LstY6+GlzNfrpLhSIoao3+8yBE6xurTqWcX6d36dvAZ SUrHXj7k+Igh0Zc3uZ48d/Xh5aO8Hv/7e+z6p9tP332+Q+35B9J2FolH30n9fQdefvgV+ByEEUr4 nGGk6ZVYYxne5pduiZ3WmofAyaYacryJpZtjd4WWomi+HcdXZx6GKFteZKG41YrItRjcXJ352BeQ pNUo4otlaRjkXhcKuVdzTTpJWIQEdoQQQ1ROaeVDVMYUIHlaSv9kYJZSblnSmFWetx9/4VXkZYBs bkmRTOaVaSaWcX65kZt5TjSnflha56eZA3ZppUeR4VcmonXe6Z2Bdv43ZYF8iuQopQi2KeCiC064 KacpPVnhp6GK6qRyo5p6Kqqpqmrkqq26+mmpr8o6K1m02nrYrbnquithsfL666m+Ajtsk8ISm6qx xyq7LKjMOrscbc+u2im11Vp7LbbZarstt916+y244Yo7Lrnlmnsuuumquy677br7LrzxyjsvvfXa ey+++eqrEphkmitlp/2mJDCa6xKs78ED78tpwgpHWW3D5UrbWq1hIWsxtBQLJmyyzEW7sa4d4/qk yIHZNWzJwBX/lvKREx+bLMukYtwsyxyrSqNZMSurM6uw7hyqyDVrvKuEdlZKKEdI12l0okkrCieY RkN6J4FjwpmpoU07jWCjWMsJ6H0aad2o1VZPTR3S0F19JZ3a4UlopIWi+R6ibDu639tkmj02fGl7 /SfYUKv3NuGCe600t822JRlPmimHIeQ+TuZ4iaWZyCGKk4+14Wecq8jahYxV3CPOsd50I2yNJ/l4 WTt2fmOIpMPOJIcvmu555DAxbuRamOkeF+oZat4V6jyTjLFdmefM4+W+I7m8bUs+z2T0rcPYuVs4 v+V76SaLfmKNpWKYHPPXG4c8+UdKPz70RX5YG+g/1t78b9Vr/2/qw/PZJ7fYb/Jn6NTYo53+sclS ABOUeRh1pQIyyF8CLJzA9iSgCYZtgQPsUwJBEqcDJi1NX8sgfNT2oEvxiT1gs2CDuuMRwGlpTXer DnrEs56sReeE5OLgpESINxjWx20X5KEOHRREHwIRQB3s24MUlCC0eVCIO4whBhv4xPsc0YDcqeIU E8ilJc6NikVUIQbpVjD9XfA6KdTUozqlOOcVT3Q52lDoXGc91SkJfTSii/0sxroRLQ5E7ovRzDr0 PfglCUfjEySSBDk7P9Jxcydb0hshGTlE4uhyOXqkHXukvvLJb1RFK5uicqjB8+hJggo8yAu/hED/ EVBBd5sT4f+c2K9Y4q1uegOlKcmGOArGZ4WYYiXTzsQ2VeYth7dcZZWGWUNSRs1LJsRUlj7YHlq2 8lB+guXfArWwd0VsmyH0Jjiz1c1wkpNdLhuV8c7ZM3Wy82btfCc84xkseXqMnvYUVTrvqc998rOf /vwnQAMq0IEStKAGPShCE6rQhTK0oQ51VT7RmSueiW+eztJZRGeV0YdytFcjU5nP1rkqikJGZjN7 WXNOZiuhdbSl9gjXOCvIMDR+K6YypanDAMTNTSlxXDZNYzmDii5o7aYpk/tY42Cnmt3Q5nRJrUts jirV2bxPcrmh6lSamtTXGLVDS32N8oqam+SVKFpmZepVofr/1dBIlXKVHOtstgpXo24VNIR06UAD 1pEhAqyKZvxfFCPF12hCMZqDGywZEZhMK4KxTYNdYXYK65+9OnGLTwPsNynoSwWGckHTFCpo6aVZ IyLxik0Ean9Gm9g0CZOxO1QsZ0fYxBR2EJqS/SVptUjbNLZ2slt0bWOhGdrhXouoaKWfWvOiubG+ 8alEQm5ahdOb3kG3j9Pj3uZS18cWsU84qNGkdTG5moqC5qvKjY0miyNSvCo0j5WjHfVAuj3xushX UqEu9sI7yOrxrpO5u29/MwleNmL3pCa6Xcu+99/1shehirQdJD+3ST5S5o/Kq1wbq1ub83muwPCN b3WDt10W/6EvvR4GkspCN2FDAtJ5De7nJ6XzTBWGEpZQc6UNsalMrbknsCQ8phkZ6DYbq2nI1xzj jkv5Q2We7ceoJaA2JTLMUV7KsDglLpazrOUtD/en3PIyl7X84jG3dKMmJTOa06xmdZq5WGv2Z5jj LOc507nO1noznvOs5z3zuc9+/jOgAy3oQRO60IY+NKITrehFM7rRjn40pHll50lTutKWvjSmM63p TXO6057+NKhDfa9Ik7rUpj41qlPtUlGzutWufjWsYy3rWYdZ1ba+9Zhpretd85qcuP41sIMt7GET O1S9Pjayk63sZTO72XUuNrSjLe1pU9vRzr42trOt7W1zu//b3v42uMNNkmqTu9zLEje60x1rc7O7 3e5+N7zjLe9507ve9u6zuvOt70/fu9/+fsm+Ay7wgRO84AY/OMITrvCFM1zh/354vxsu8YnHC+IW pzfFM67xjXO84x7/OMg7ffGRk7zkJr91yFOucgidvOUufznMYy7zmdO85ja/Oc6BvfKd87znPv85 0IMO8pwTvehGP7qyhK70jSO96YJeOtSjLvWpU73qVn+207Ou9a1zHUpX/zrYwy72sZO97GY/u8C7 rnZyb6LtzGn7JhAKd7cLBu6hsrs68d5OvReG7w/3u98/FXh7zF3vg2/S4VuS+FQl3vB0f9LiT4X3 yCv+8YH/KTzlBzN3l0ze7ZnnvOWPMvjNVz7umrf85zsaIbiPhPXZcn3r214Q18PeWrUvye3BlXuD wH73EvI9t2gv++cAHyK9L75KCs/74bMe+SRx/u6VP/vhp6T2zte0YQAfesFvn/CPt3vq7dn473d/ OeE31eczr33TI5703md/6d9e/r67P/10P/9DV0/96W9i+bfHvPEB4PNRX/NhXv/9g/AdoAAiIAHO nf/5XwJKn0lI4AJCoAE6oAWexAUGoPVJnwFyIAN6IAXunwaSYAiG4PUJYAKeIAai4AHynwW+YPSJ 4AtWH/PtXwV+IP9FYAu64AOeoDnRH/y9H0uAH/nFHxEm/+FLOF7ckV7nOeH9RaHpdV4RRmH8QeEQ XiH5ZSESvt8USqESLuETVmETgiERbh4TkiHoIaH6bZ8Rzh9QGKEanqHnbaESUuEcjl4dzuHpfSH7 2WES4iEdmuEbkmHhDYv+XWD/HV8NPiAj4l4DLmIk7uANNiIMzqAlsuAkDqAMVmIJdiIoAqEoguAl TmLuPSIQAt8KJp8JFmAmfqImKqDsLSAqYiIMcmIs6t/0wSIqxp4khmItSuC6ZF/oFSIfGuAddt8Y JqMfPiHfGaMY/iHmMeNQpGEYRmMXQqMeSmMZcqMXAmIgmmHpYSFhBB40lqMVjuEhZqM4IuM15mE3 EqP7Gf+iNm4hGtqhNU7jO63fN5LjIHYh6K0jNRpiQJLjNsJjPPJhQLLh/FnjIOojNqphPk7jRPrh QoYjF8ahG9ZhRoqeFKrjPFYkQiokQ85j3QkkRg4kSHpjReJfqiSiL47iD+biLcYkLtZkD0JgKWai KzriJtpkKprgTD5iCpriT+6gKK5iL66iDVqiJ8IkJe7kUnpiMPJkJArlJ9YgURolMHLlUF6fuMgj Nh6kRILjRUYkM2bkSlYjR2qhN2rkW47fW/5jH7olQJZlXLYjILbhEC6jEI6jRbqjSIokXAKm+T0j PiYmSyomO8Lhs/BjMmJkYJIlWjpkSl4mGDrjQBamZVb/5l4eYWGO5DIaI2FK5jGaoz3e5TuGoUFy 5GQuZjOSpELWHxyG5EfiZULeY14mJEESC1R+ZQtuICUKpS3iJAnS4lWGogv2ZE1yIg5i5XD+ZAWS YlL2oArmYHIu51PKZHQ24ikS53NSZSXKYgeSJw1Colb24gQ6pQ5qZ3dWJyi24isOlUK5pKLZ52F2 ZLDhpzzVGVh22392SoCC23aq3IBq24FOSIICqDDS2do96IuhnYROKIVWaLhAKIZmqIa6nIV26Kxt KIgulIeO6KuFqIkeFImmqKidKIvmlYq+qMi1qIzOKI3WqI3eKI7maK7AKI/2qI/+KJAGqZAOKZEW qZEebymSJqmSLimTSp2OPunENKmUTimVVqmVMh2UZqmWbimXdqmXfimYhqmYjimZlqmZosqVpqma rumknambvimcxqmczimdthOb3im51Kme7imf9qmftgSeBqqgDuo2/amhHiqiJmqWEiqjNqqjtktA AAA7 ------=_NextPart_000_0005_01C71A0B.AC1BBD50-- From sip-bounces@ietf.org Thu Dec 07 09:40:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKOS-00059E-Cw; Thu, 07 Dec 2006 09:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKOR-000599-Cs for sip@ietf.org; Thu, 07 Dec 2006 09:38:35 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKOL-0006cW-4O for sip@ietf.org; Thu, 07 Dec 2006 09:38:35 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kB7EcON3026801 for ; Thu, 7 Dec 2006 08:38:24 -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, 7 Dec 2006 08:38:24 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 15:38:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 7 Dec 2006 15:38:22 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180959A57@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New email address Thread-Index: AccaDViErmXmTvJRQL+pMd8I1ma56g== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 07 Dec 2006 14:38:23.0140 (UTC) FILETIME=[58E13640:01C71A0D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] New email address 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 any of you have your SIP WG chair in your address books, as opposed to using the alias provided by IETF, please note that my email address has changed to that shown below. While the old address will continue to work until end February, now would be a good time to update your address books. The IETF web pages and email lists are now all showing/using the new address. 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 Dec 07 09:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKii-0005m8-UH; Thu, 07 Dec 2006 09:59:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKih-0005m2-Vb for sip@ietf.org; Thu, 07 Dec 2006 09:59:32 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsKid-0004dI-Uv for sip@ietf.org; Thu, 07 Dec 2006 09:59:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5CBAAAE; Thu, 7 Dec 2006 15:59:18 +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, 7 Dec 2006 15:59:18 +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] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 15:59:17 +0100 Message-ID: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: AccZwBMTtBIwEBfKTWiY7S6W1zJbWgATcV2A From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "Cullen Jennings" X-OriginalArrivalTime: 07 Dec 2006 14:59:18.0453 (UTC) FILETIME=[451AC650:01C71A10] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: sip@ietf.org, Fredrik Thulin , peter.leis@siemens.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 Hi,=20 >>I find this whole conversation way off base. If people would like to=20 >>deprecate UDP, go work on a document to explain that and=20 >>feel free to bring it to the WG. In the mean time, SIP is specified over=20 >>both UDP and TCP. >=20 >To be more specific, SIP is currently specified so it can use=20 >UDP for requests smaller than 1300 bytes. It is specified so=20 >it can use TCP for requests of any size. >=20 >Some people have suggested that user agents SHOULD be able to=20 >send and receive requests larger than 1300 bytes when using=20 >the outbound mechanism. This seems like a logical=20 >requirement. Are you objecting to this requirement Cullen? Isn't that an implementation issue? What if a client "knows" that it will never send or receive requests larger than 1300 bytes? >For the sake of this discussion, lets assume that we have=20 >consensus on this requirement. What are the implications? =20 >Well, most UAs implementing outbound are doing so because=20 >they are behind a NAT or a firewall and will not be able to=20 >receive inbound TCP flows. These UAs will need to establish=20 >a TCP flow if they want to meet this requirement of receiving=20 >requests larger than 1300 bytes. The logical normative=20 >statement is to say a UA which cannot (or suspects that it=20 >cannot) receive an inbound TCP flow from its outbound proxies=20 >SHOULD open at least one TCP or TLS flow to a server in its=20 >outbound-proxy-set. I think it's quite clear that a client located behdind a NAT/Firewall, wanting to be able to receive inbound TCP flows, should take actions to allow that. But, do we need to say more than that? =20 >A few people on this mailing list have suggested that for any=20 >user agent that actually bothers to open a TCP flow, there is=20 >no reason whatsoever to open a corresponding UDP flow. I=20 >wholeheartedly agree with them. That's probably true. But, again, is that something we need to specify, or is it an implementation issue? =20 >The problem is that this thread strikes right at the heart of=20 >our community's dilemma. We have a large body of people who=20 >have deployed UDP almost exclusively and effectively ignore=20 >the MUST use (and several even ignore the MUST implement) TCP=20 >statements in our core spec. =20 >Ironically, one of the problems which prevents realistic=20 >interoperable deployment of TCP-based SIP implementations is=20 >the lack of a standardized mechanism for doing outbound. =20 >[Dean also identified some other problems often faced when=20 >deploying TCP with programs that use "obvious" (Dean actually=20 >said "naive") textbook implementation techniques.] >=20 >I think that a large number of the core spec contributors and=20 >seasoned implementors now recognize that there are many=20 >non-academic problems with SIP over UDP and that some day we=20 >will want to either deprecate or at least seriously curtail=20 >the use of UDP. Like a very heavy drinker we know it will be=20 >good for us to kick the habit. We are not quitting today.=20 >The question before us is are we going to do something in=20 >outbound that makes it harder for us to quit in the future. First people wanted to use outbound to "promote" STUN, now to get rid of UDP. Is that really what we are supposed to be doing? I still fail to see what the technical problems with outbound and STUN is. It may be more complex than TCP, but are there really any open issues to be solved? =20 >My concrete proposal is the following: >- make CRLF the only keepalive mechanism for TCP and TLS over=20 >TCP flow (retain STUN for UDP flows) >- make outbound registrations over UDP flows optional for UAs >- include the statement that its is RECOMMENDED that the=20 >outbound-proxy-set is configured to result in registrations=20 >over TCP or TLS whenever the UA can't accept incoming TCP=20 >flows (the 3GPP exception). explain that for historical=20 >purposes a lot of deployments still only use UDP, but that we=20 >expect/hope those deployments to eventually migrate to TCP=20 >when doing outbound. I don't understand why a standards spec shall talk about what we hope and expect... As Cullen said, UDP is a valid transport protocol for SIP, so I don't understand why we need to "justify" anything... =20 >What's in it for the TCP crowd? They get to implement=20 >outbound with no UDP if they so desire. They don't have to=20 >implement STUN over TCP. The draft clearly explains why TCP=20 >is the technically preferred solution. >=20 >What's in it for the UDP crowd? They get outbound behavior=20 >(at least for requests <1300 bytes) specified in the core=20 >draft for UDP. They can keep doing what they are doing, but=20 >with STUN keepalives if the UA and edge proxy both support it. Just to clarify: the edge proxy is still required to implement STUN, in case someone establishes UDP flows with it, right? Regards, Christer >=20 > > Most deployments only use UDP, some only use TCP, and I=20 > suspect there=20 > > are some that do both but I am not aware of them. Outbound as it is=20 > > seems very consistent with 3261 in that it allows a system=20 > to use TCP=20 > > or UDP. Keeping this in mind few comments inline .... > > > > On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > > > >> Let's go back to the original topic - what should the=20 > draft say about=20 > >> the transport protocol in relationship with outbound > >> > >> The major use case for outbound is UAs behind NAT /=20 > firewalls. Many=20 > >> of such devices have known issues with UDP fragmentation,=20 > so for many=20 > >> environments TCP will need to be used for messages larger than the=20 > >> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts=20 > >> the limit at 1300). > > > > These known issues with fragmentation might be less common than you=20 > > think however, outbound does not have anything to do with=20 > MTU issues. > > It does not try and solve them and it does not make them worse. > > > >> > >> If you start from the requirement "MUST only use UDP",=20 > then there is=20 > >> little room for constructive discussions. For UDP-only to work you=20 > >> will need to ensure that messages either stay below path MTUs, or=20 > >> disallow NAT. This implies significant limitations for your=20 > >> deployment environment. In any case, this is not a setup that=20 > >> outbound should focus on. > > > > MTU is a problem regardless of NATs or Firewalls.=20 > Fragmented packets=20 > > do manager to traverse most NATs and Firewalls. > > > >> > >> In the general case, there are environments that have to deal with=20 > >> NAT and messages larger than path MTU. This is what outbound was=20 > >> written for. This also implies a UA that supports TCP.=20 > Given that the=20 > >> UA supports TCP and the fact that presence of devices like=20 > stateful=20 > >> firewalls cannot reliably be detected, the UA SHOULD use TCP (or=20 > >> another connection oriented transport). If in addition the UA=20 > >> supports TLS, it SHOULD use TLS. > > > > Again, this topic is not really about outbound. If you=20 > think a 3261 UA=20 > > that supports both UDP and TCP SHOULD use TCP, that is a=20 > fine argument=20 > > to go make in the discussion about use of TCP and UDP but=20 > it seems to=20 > > be an independent choice from anything to do with outbound. > > > > > > Cullen > > > >> > >> I think this is sufficient > >> > >> Regards, > >> Jeroen > >> > >> Fredrik Thulin wrote: > >>> Hisham Khartabil wrote: > >>>> > >>>> On Dec 5, 2006, at 3:33 PM, wrote: > >>> ... > >>>>> I personally believe going TCP-only would actually help=20 > deployment=20 > >>>>> rather than hinder it, but I'd be really interested to be=20 > >>>>> convinced otherwise. > >>>> > >>>> I could ask you the converse. I'd really be interested to be=20 > >>>> convinced how TCP deployment improves scalability. > >>> > >>> To name two things where TCP would provide better=20 > scalability than=20 > >>> UDP for a SIP service provider : > >>> > >>> 1) Say that your services maximum capacity for=20 > non-INVITEs is 1000 > >>> requests per second. If you get 2000 in a single second, you > >>> won't only have to deal with all those 2000=20 > requests, but also > >>> with quite a few retransmissions sent after 500ms.=20 > With TCP, the > >>> wall isn't as dense. > >>> > >>> 2) UDP sockets have a shared receive buffer, most=20 > commonly around > >>> 64k I believe (even though the maximum seems to be 256k on > >>> FreeBSD at least). With SIP messages of perhaps 700 bytes on > >>> average, you have to be able to move messages out of=20 > that buffer > >>> pretty fast to keep it from filling up. A full buffer means > >>> dropped packets. I've also heard that on for example Linux, > >>> every packet actually occupies an even 2k (or was it=20 > 4k) in the > >>> buffer, so 64k buffer is actually at most 32 packets=20 > at a time. > >>> > >>> And then there are of course other aspects than scalability where=20 > >>> UDP is an inferior solution, most notably security related things=20 > >>> like for example spoofed CANCELs (which can't be=20 > challenged, RFC3261=20 > >>> #22.1). > >>> > >>> /Fredrik > >>> > >>> > >>> _______________________________________________ > >>> 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=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 Thu Dec 07 10:19:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL12-0000vK-B5; Thu, 07 Dec 2006 10:18:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL10-0000tv-K1 for sip@ietf.org; Thu, 07 Dec 2006 10:18:26 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsL0S-0007R7-1B for sip@ietf.org; Thu, 07 Dec 2006 10:18:26 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kB7FHpRq028783; Thu, 7 Dec 2006 09:17:51 -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 kB7FHo827086; Thu, 7 Dec 2006 09:17:51 -0600 (CST) Message-ID: <4578309E.703@alcatel-lucent.com> Date: Thu, 07 Dec 2006 09:17:50 -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: Aki Niemi Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <001301c719fd$c3c22790$ed9cb70a@NOE.Nokia.com> In-Reply-To: <001301c719fd$c3c22790$ed9cb70a@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.35 X-Spam-Score: 0.0 (/) 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 Aki Niemi wrote: > We've done experiments on Linux using a proxy server built on top of our > sofia-sip stack, and have noticed no significant slowdown on an ordinary > desktop PC handling 100s of thousands of registrations simultaneously using > TCP. The stack's Linux implementation uses epoll, which is even more > efficient than select() or poll(). Now, this is not very portable, although > other OSs have similar schemes, like kqueue in BSD. You can actually hide all of this behind canonical APIs by using libevent (http://monkey.org/~provos/libevent/). Your code is extremely portable then, unless of course, your target is a RTOS system of some sort where libevent is not compilable (and I know a couple of the RTOS where this is the case). Maybe this thread should now migrate to sip-implementors ;-) - 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} URL: 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 next@be.la Thu Dec 07 11:48:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMQ1-00065O-Jq for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 11:48:21 -0500 Received: from [81.185.255.240] (helo=[81.185.255.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMPg-0007eJ-Ea for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 11:48:21 -0500 Received: from QFW (unknown [150.166.193.173]) by be.la with ESMTP id E7930C8F1871 for ; Thu, 7 Dec 2006 17:48:25 +0100 (GMT) Message-ID: <000d01c71a1f$7532f290$00000000@Ordinateur> From: "Stop its" To: sip-archive@lists.ietf.org Subject: week more Date: Thu, 7 Dec 2006 17:48:01 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C71A27.D6F75A90" 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.6 (+++) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad ------=_NextPart_000_0009_01C71A27.D6F75A90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C71A27.D6F75A90" ------=_NextPart_001_000A_01C71A27.D6F75A90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Back power army general sonthi. Within step back power army? Gay marriage, among ballot, issuesnew = judge. Ballot issuesnew judge expels! Will iran, stop its! September wed sep baghdad expelled hussein his and. Power army general sonthi. Us, congress, americans vote next. Newsmiami zoo hosts poop says, = nkorea. Said about three after pyongyang staged! Wednesday september, wed, sep baghdad, expelled hussein his and. Polls will iran stop its, uranium enrichment? Off, protest government sacked, chief throwing monthold? Test abortion = issues san francisco apart deciding whether. Gay marriage among ballot = issuesnew judge. No main feeds latest newsmiami, zoo. No main feeds latest, newsmiami? = Has agreed stalled sixparty on ending programmes. Tuesday october, tue oct. Thai bangkok thailands, military leaders = choose. ------=_NextPart_001_000A_01C71A27.D6F75A90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Back power army general = sonthi.
Within step back power army? Gay = marriage, among=20 ballot, issuesnew judge. Ballot issuesnew judge expels! Will iran, stop = its!
September wed sep baghdad expelled = hussein his and.
Power army general sonthi.
Us, congress, americans vote next. = Newsmiami zoo=20 hosts poop says, nkorea.
Said about three after pyongyang = staged!
Wednesday september, wed, sep baghdad, = expelled=20 hussein his and.
Polls will iran stop its, uranium = enrichment?
Off, protest government sacked, chief = throwing=20 monthold? Test abortion issues san francisco apart deciding whether. Gay = marriage among ballot issuesnew judge.
No main feeds latest newsmiami, zoo. No = main feeds=20 latest, newsmiami? Has agreed stalled sixparty on ending = programmes.
Tuesday october, tue oct. Thai bangkok = thailands,=20 military leaders choose.
------=_NextPart_001_000A_01C71A27.D6F75A90-- ------=_NextPart_000_0009_01C71A27.D6F75A90 Content-Type: image/gif; name="North Korea.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c71a1f$7532f290$00000000@Ordinateur> R0lGODlhGAJEAocJAAAMAHMACgx6AHiICgAMfnQIiAqNeL/Ou8DisbK77DEfAFQZAI4bAJolCrgf B+EuDAg5ACVFBEdICWE6CX83AJxJCso/ANw9CgRkAipqBjxUB11XAIBnBp9VAM1pANZuAAByACt5 AEWBDV+EAIKBAJmIAMx/AOqIAAyYACOiCjybAGquAIyZDKycDcmsAN6YAAPGABW1AD3FBmq5AIy0 C6PAAb7GAOfJAAjdDSffAELZA1LrCn7YDprYAbjcCN7sAAMDPh8ASkoDNmkAPoEGQKkHOMEAMt4B PAAfNSUoRjYaN2ouNYInNpIoS7wfNNskRwQ9ThkzQE0yMV88PHs2Ra5BNbJCOeNKOwpSMSxqQEtZ RGhtOXdaDZhcMcxVTOVlNQCDQyaDPkJySl57PXtxOauDSraGPOOBRwabNxOnPESaPWOoQXGbS6Sb ScuWMtKZPQC6QByxNzm2PVu3MY6xPJbCRMC1OtixPQDnQRHbOEDSPVHnNonpS63RRL/YRebrSgYA jScGczMAcV8LeX8GjZgAdMQAjtIAewAkjSYpcUAmd1ITgYkoiqQSiswtgtImiwBJcxEygTs/i1k2 i3UxiaA2frJMg9VLiQBidSBkeDpSfGVrd45riZdterdpf9ZkegB0jRaAjUF/eG6EdYSHfZiAfM2K cuF/egCXghacfjSgiGCsiniRjZOVcs2ffOCTeQ7JdBWycjS8i1O7d3y3garHfbLAce7NigPidSjg jT/ai1TafnHpdqndiLXlitzieggJwSgAwDcLvG4JzYQJtqcMwb0Av9YOyQQqshETtjYbtWkgu3gX tJIZvbQaut0tvQBEuy48wEI+uWBFtHg9vqNFyrczzuRJswBnxC5pv0petlRUuYxTxqRTyLVivtpp tQ59yCd5uzqAxF+AvX53tphxy8KHydWOswCYtB+ivzKat1mevHqmuKehzL2rvNmhwwCyyBa0y0a6 uFnIwYGzsam2v/7/8ZiTsn1xgPADBgf/AP//AAAA8P8M/wjx8v/w/yH5BAAruXkALAAAAAAYAkQC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBH+G0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qVOjIaNKnUq1qtWrWLNq3cq149OvYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27eGF23cu3r9+/gAMLHvwxr+HDiBMrXlySsOPHkCNLnkw5 MuPLmDNr3qy0sufPoEOLHg2as+nTqFOrXs26tevXsGPLnk279krSuHPr3s27t0TbwIMLH068uPHj xX0rX868ufPAyKNLn475ufXr2LNr3869u/fv3qmL/x9Pvrz58+jTq1/Pvv1N8PDjy5//1739+/hf 0t/Pv7///wAGKOCABBZo4IEIPiTAggUtKIA9DkboIIQMNijhgwhdKOFAFzLUoYUYclihQBNqOKFB Jn4o4oMphnjQhyeuSGKEFLo4o4o30khQizW6GGOMCQbpUUsOmlRkkSghWRKSSqrU5EhMLrhSlAIY KeWSV0Ip5ZMuNfnkkVl2eSWYVWJZ5j9UnqRkhCRReSaXWq6ZJZz51RmnlVXSyaWcZ6b0ZZh6Atqn hHjeiWaYL3mJKJkwKXpon4+2OSaikZppaKWY4jnnppDamZ6HI95YY4ahimpqQkACeeqOpYJY6omw tv8Kqo+vMqgqqrKOymqIsdqo666//pgrjCPeKuSxUqla4rCtCusriMBCi2KuM1Ioba8SpVori9RK O62Nzq4q7qjhjitqheUiq26yPLbbbLHd/iqvuT36uiy4GMJr4kLapljvht+S6q+ptxZsK7qhusvt wjKu6zBFRC66JaWXSlomnZZarCbFFguap8RsVpyox4ViXGiSIGucqciRanjyxhd//CbHnuL3p8x+ UupyxIPqTHPGj4bcMaczKQopo2J2KjKfLO85Mc5An3yhyjWrNyu0xs6rNb8Jv/tswMFuS+vXCvWL dbwNg502tt6KSHDXXzur78N0d6TswXF7HdHdY5P/Gm26OUYLkdnAZv1i1/OWazC++SI89+G86lj3 5BHxXDLHTis9pc8xa16pnFZqGvXIPR/9dKNp3qxy5h1THXKgpc/sedXiXV24v/saLjDkuv+btrhi 4wi54OcOLDDbDW+Yu4Zt06jwrpGTTfn0tFdv/fXYZ6/99tx3731O04cv/vi/fW/++dWRr/767NuD /vvwG9b+/PTXHf/9+Oev//7m1e///0HinwAHSMACGnAzAEygAgN0wAY60CcLjKAE5fPAClrwghjM IFAmyMEOevCDIAzhQzRIwhKORIQoTKEKV8hCypnwhTCMoQxnSMMaVq+FOMyhX2zIw/zp8IdADKIQ /4dIxCIa8YhITKISl8jEJjrxiVCMohQp2MMqvm+KWPyhFbfIxS568YtgDCNa+EFGppTRJGdsDRn5 4ZI1osSNYrweQ9aIEDoOxI4XIaNB9AgePBbEjn68Ix+lEsgsPqyQAvEjIiMySEHGZ5GAbKQg+UGV RRqSgSyB40k0+Q9O1iSNJAElazyZElJ2UpRBMWUch7PGVrLxlK6MpSxfGUpU2vKVcMxlGXWJy12e kZeldGVJYjkSYBazlWhEJiyFecxe0lKWzVTlLIepzGWqcpW1UaYxm1lLX9ISlsnc5DN/SU42GtON 50QlONeZRnRCE5ya1OUyucnOcnJzm9S0Jzzbqf9ObAYnnvqk5zoHGkxxUpOe/EToOBUazG82NJoB dadDB5pOc/LTohMV5zgx2k2B+vM1cxxkJCk5yZImUpJ7JClBGjlLPLZUpC+toyv/GMuTttKmJS2k S/k4UnvslJI1lalK6fhTnF6ybkX1KUthOlSUrlSljnwqUW9qUz3OtKpApepBZGnUkXp1pjplalet KlalXpWmTc0qV816VKSWVZFlZWtCUCpJsGrVrj8lqyUnqVaTmjWtW6XrW3mqV79WNbCAhaRT2yqk pMIVsEaVaUpTqleo/vWyUlWrZeda2Mje1alhhWxPkypVxOZ0sXtl7IEcu1TRtjaqTzVtZD1b17j/ 4nS0hGUqVHc6VrnKtadsvSlwgzvYps5WtQBqCUA3Ws6WJnOh4dRoR/M53ep6kpfLZeYxNcpJZi5X oczFLiglal3tWvOj97mmQaOL3vbW5aXwja9850vf+tr3vvjNr373W1/3rmYqqYWtgJFL4OX498AI TrCCZVLgBidwwRCOsIQnTOEKW/jCMHSwhjfM4Q7jBsMgDrGIL+jhEodvxChOsYpXzOIWu/jFMI6x jGdcQxPb+MY4zjFVaMzjHvv4x0BGn46HTOQiG5khQU4yU47M5P8o+clIabKU9wPlKhNlyliOj5W3 vMEse7k7XA6zmMcsli+bWYQBEEiaC7JmNVOk/82CkUJU5NwQOnvEzlnB80X0XGeN8Bkhf+5gSwJQ EkKTxNBKMTSiDz0SQi/aJYpGyaNjIoWSVJokl4ZJpnOy6ZF0WiWX/nRNQv0SUY/a0ygxNUtUDWqZ mFrUn2Z1UWR9nEXbmimRNsmtY5Jrnmz616729UlojeqekNolxC51sXWSbEvvBNbDfkqzh4NoRzP6 HwHI9qSxre1Gc7vR3T6JtqvtbV17m9zczra4x53ua4db2ajOdKilQO9U07ve/7h3rPONb37jW9/O vjemBV7sef8b054muKUBrnCA+7vTDq80weX9cIn3W+L+HrjC433xhjs84PNGeMXznfGHg1zeE/8v ucVRfvCNJ7zeHxd5wfvtGnLbvNArcTS6y52SXE860j7Hubm/XW5r87wlFE+6s5ceb6YnHOHAJrlJ Li71gjcd6liXucipPvVlp8TiWZd6yK1O9agPXOtX9/rT+U12kG992BTvetmVDvW4L93sXse42hnT kDWn2e9uHgicDfJ3gsB58GwOPOIBX/jAO17wj2c8RegsZ8oLBM96xrw9NE8QzXOez57v/OVH//nN j34goD+96lG/+oNUXvSmt7PlWR970XOe9q2vPe5xL3vS2x72qd+971kfeuLDHvjHX/3rswNpbDNa 0eP+ObttHf11h7vX7iY6uNk99F1Df9sr0Tv/yQ3ucmDjverjv3u06x5xjref/DS3+tbbD3eBR138 x2572NGPfvj3f/1VR2rmp35dN3/2F3And4BoJ3ZO938lBxtG53zYJ244t2s9J3QT6HwSqIEceIEd OIHg93UByICttn8Qh4BvV4Bpp37Qln8i+H/3B4Dp93ZxF4MDiHY3uIL7tmwCiILy53TiN4M6yH8O SIBqd37ThhkRaHQWyHPq1oSPVm1B130aiH0/d3RAl31OKHdZh4Rn54UmuHc5SIJBaHfnR4Jpd3Aq CHNMF4M06IPxl4NsuHZt+IZP54ZAGIBlCIM+SIQueIJ3mIJ813eJJ3jadhCH2HiGmG2IyIiA/2cP i+dmbeZ3h9iIh6d4jOh4k2gQmdd59+Z69GZ6m/eJBfF5pHh5mKdvqHeKs6eKu+eKnBiKtPeJspd5 obh8qmeLpWeKuIiKrHiLviiKx9d7okiLwiiMsqh8wVh5rqhvtSiLt+eJo5iMnrh8rHhm9BNoFaGN V8GNk8eJ2HhU3jgR40gV5RgRwReOWXSODAGLWuGOG5GO6jiPREZm9kgT9JiPSsSOWDF7/UiNCqGN /IgRfzaQfhYSBklEpJiQHcGQC+GPD1kVrZhnwgdo4HiMDuGQBfmOCHlJxNgVDhmQuWeR3TiSUjGQ wWeQGul6HAkSIRlCyPZyENdxNJl0Y/eAGv+3cjs4c7HGcDUpk3XIkztZgz/ofjnJg0A5fjPJhiuX k0sJcz85dT6ZlAPYcEnpdibHhx7ncllZlT05cVspgEmIPnYnc3t4f2OHf+sHhmm4lmVZlEg5hEFJ hkdId21pfq9Wd2FYgGXXgGJXlmdJlEgImDBol/w3hmAng2eJlQ70lofZh/lnmGvZgGM4mQvoglin d2eIcWqJhnnngJrZh2vIh5f5mZv5mWFog5SZh4hZhKYpmlq3mPsXP302kgvpjNO4kLwXjBcZjcdI eQB5erwIjSz5esAJj7WHixOZfMzYjMWImwJpfNKZexDZnKc4i8z5m9oZe7iZndOpe8PXesX/F56l +Hvf2YsoFJN7B5vQFpel6ZrwuYOtSYTpF5rhV58pCIgr2IUyOJrzaYRC+IJ4J5v694KvmZqriaCp Bpmk+UCOaZh7OIJtyZcJynYPeqBsR58SCp/uSZesOZeVWYdyKJ8MSqGxqYegGZ8fGohhF4dwGIRt SKABqqHb047JCJC/eKPXmIu8GYu5CYrWGJw9+pzKmY6pKKTIiHwYOZzMqZskCZ5EipFDepyBdp0/ uoy5SYzIqYvPCKXHKaWwaIwCCYxXeqWdqI9omqZquqZs2qZu+qZHdI9yqhdwWqeA4R6sNpZ+SRN6 ymmrdp8qeGrl0afk4YzBxhnHlqc3QagA/zprf2qZfklsmMmnizoWhNqn7Tkc+gkck7qnmsZsTCFr ihqolLaehyqoYXGpqOqptPFqYZmZNfmVQ2mANkmH7xd/GyqW9oerTUmVGcp+R6mULKeGEZdyxhqV IyeVTMl1/seFXGmor1p/MpmYH1esuOqe5Bdtx0qVu9pysSp3URlzPnmtrpGpASqWe2mg2Aqaaamt b2mG8sd1ZzeE1yqveimXMAqu93quKrpw+cmhiemHttqvZEiYeLigSDmY++qGeJmuA3uwgkijrGGo DcqA/4mwCGifP3ihp8mZ/4qDDJqXpTmf+RqyJguyeWixkQqwGPqYJtqynZqxnrmpERqvJ/97hCXa nmeYGRJhnbfYnb0YtLFopclZjEqapFm6nb+nnMKZfNrpjOj5ir5IpuRpeaCniuPJnVjrtGfatF4K jr5ptMTXndWInauItUAbkcY5tThqnmzbitDptksqtxBptibJHDORry1YoifqrDO7rhfbdJ35h4Gq t+oqoxEKo60ZomyJmj04sitbsYBKuKRqqpnpmYrJoZhbsTSbopAqsapxgiTboC5KhyBqhHY5h+tJ mH+7ovt5oihHuo9rlogru6TKsCjKhe8ZuETpmom7gOuKsnJpswr6qzC7uqhpGnUWpjnae7wIplQ7 jNX4kVoKjGGLtLlIjV1LpHUrtdP4td//C7fQaL3NyLw6GrVba7ZfmnrXe51UCqRlO71nm4pSyqPz O7TEKb+raKbAF73b6Y7B+bNIOj4vuT7yqC4FXJFDlsDkc8DHwsB3u0JOEXPvs5Pew6g1aqcavMEc HB5z+sFwgcGVShawRq79+WwmLMI/ocI2wcLwNsKfajUHGcEJ0b0dKbYfkZAOHJH1+408DBgQDBE2 LMREXMO1+RBBfJFB8pJDPGc0TJHlWcQcMY5JnBFVXJtMLMUs2Y7o6MTbgXQPaK2aCZa8Oq7BqpSm G7w62avK2oI3Obhh+ZRZOcc9GMf1l60Lp6tnTK3Dam/eOqxfGZd8bJTc2q0duqA2Ccig/9at+xat JxesbFyt/8aV5QqhCVu4brmXk4yzgjxzwHuZ7aqynPu5v4vGw+u4ABiw8tmuO7uwBAvHa6fKltmX lpuGllyCCnvKvxqYxRuz5Zqzs3mao5yr2iqEicqqAtvJMxi4f4u7vNuoLiuGgIvMtbuy8KrLHlqg Bkq4rVyUndu4tcu4qsHF58mjXBrAygi19gumReu1YUu2u+m1yBi3FUmlAuykQuubpTe0ypi02Ouz V2uM5VyKN/rPA522/9vD8Zy13FidUUx68Py0dJulX/rEygHGmhzMjxqixOy3vQvOqfyvkyrMFmyH ugyxuouvZimxi8uqswuvo5uiokp/2P8MoN8MqPQKm9AMGzE9oyQNzIfcoccsvLy60qI8oqTsuQRa unA5gkhNzGypusasn6zr1C/qzX27mk+tsxXKr67Lr3IY1BN7dxs3h2L8dTSHxx09mrS7mVKtxhIq yYZ7ldWKr29Nx37suGZt1BT8cl6tgHmcsk4t13podsKsyXttb3PslGfctzT9lzTpry7MFgV2xZVx jgxs2RbtGZrdwQqMHeyYwJ3d2VtB2huMnNoR2lbcYSDc2ijh2bAd27KtGyGsnhgLw0dBya4NHJd9 xHb7w0frtD37pOQ8wwQ52wjs2/IM3L89FaodZ8g9GBgd15R8q1eZx8Rqx9gdyWT8a2b/zJOI/MZ+ bXLWTbGCi6xk3cjhWn4pB6vjvdu38cPOK9y295Fz29zg27/1bJuoiJ323d+j2LRams77DNED7ba2 eNBK/LUFvdnRrRAx6bGa67CdK7A/vbsIq5olGNfJXJnczLez+dUjfbOgC9+lKuFQe8dlaN6oPHIX LpSdSrkGh7Efzayi+eHs96zvDbvQ3NKBbeIq0Wdrq9AS/dn9nM/C7dAFHtx1a6TNvZzkicMMztzb K7TsXM5V+uDmGM/iub/R2LXEWYvz3JsIbsMODZ5OLuDqK7c4HL1WjuAPDb7yWKRK28RaDuG27d31 ypRtnNeJatZ3jZMzHrvKSoDVzdfv/93HftiUiXvoOKnXaS3Hfq249grk/yAZpn3ndZrpmr6mqN3p OWbpoj7qpF7qPgbqqJ7qqq4Rpt7qrv7qsB7rsj7rtK4/q37ruJ7reF7rT6brvv7rwB7swj7sHczr xn7sCEbsqI7sSabszv7scMrsQQbtdy7t1n7t2J7t2r7tnEHt3v7t4B7u4j7uOcTtMkbuvo54E6Hu kFeIVMHub8YX8M4QACAR9Z4VAJDvC3HvE8Hv3+HvWAHwDSHwlDFo0ReBvHZ9knZ0DM8T3FeFKhGC FCh011YTGUjxIwEALaHx/8DxMeHxQAHyJCHyKkHyMEHyJp8SHs/xKZ/xI+8UKO/ySv/B8idfFw9x iRFxifMeiR6B8/MuEYMX9Bmx8/YuEAS/71FB8EdvEEtP7xYh8E3f9F0h9Ulf9M6h85kIiZVoeIio 9ZsIiWo2bmCfiWI/9lm/9e1OeJLo9e1e9mUP9lwf929fiX939l5f93ZPEPee71DP9/XO9wPh9wex 94BvD39P+IUv+Eav74Zf+Iuv74rf+Imf+I3/+PwO9YYv+YHP+IJ/+I6f+Z1v+Uav+QXh+aPP+ZQ/ +pkv+ZwP+ozP+piP+pv/+n6/96LP+oEvGjBBfc+H8R14aOiWhc+3cxJ4cwwPfkAX/L9Phb6P8Euo fVPI/C+/8ifB8tQP8jFvEhqf7y//P/0lsf3db/I07/3k7/LcjxLj//0df/3h3/4dr/7vb/7qf/7x P/LXT/3lT/PYb/7s3/3fDxAA/v0DIJDgwYEHDQ40KHBhQogNIU6kWNHiRYwZL9rj2NHjxwAeQ3YM OZKjyZMfU5JcWVKkPZQxYb5ECVJly5ksZ9a0mZNkAKBBfe7siXOozpoA7Cm9yZEpU6dLPULtSDUq VaxSq2qdevNp16xhm2q1KlXsR6hfuZLdejZq17Zw3ypNu/ar27VvudIFC5fvWLVjBQ8mXNhwYZks gwp9qTLxSJeKRS6O3BKo46aQh2rmSXmlTslIL282CnPx57kFveo1W9C1yqeu/7Km/ys7dl3YTm3b Xbrb6u68Zv2q1qs2617ex7fGXT4X+fHZwps3r2s7+l3Yslkf5t69u8aEASCKD/+PvMXz49WbHyg+ vfv18dnLn0+RPPzy7NPXn7/fP///3mtvQAAJTOghhCJiSEEEKXKIQQUPTLAiiRxccKKHHsQwwgsb 1PBCCROsMEMQP1SIQxBPDLFDESeUiEQSNyxxwhRflJFF8HLUcUeMDksspR9BIwopIH8iLbQiUUNN syFxqsmk0Z60SSYoj2QSSiaZCy4w6bbrUjXlwOzLudySq+o63nTzEk3c2iwuMDbloi3N4sbs7So7 iZOrujyx25NL7wIVtCkdBcxvMf/0gjKwPwIVxS88RQs0D6hEKW1U0vsidXRR/vqLdNJMPz2P0k07 baggi1yLUDYKGULVRIJedRXVWSNCcCFWaz2V1ltlpVHFDml1VUSHfI0VoVxjPDBZDFVdEVlfTdz1 V1xDzDVWDXedtkIeu/UWvEHDFXdccssNlCdz0xW0LHXbdVdddt8VLF5567X3pm/z1Xdffvvtdz9/ A963QYELNvjgXxHOiGCFG3b4YYgjlrhbgCc++FqLM56YYYgx1vjjgO8VeWSSSzb5ZJRTVnlllkcG +WWYY5Z5ZpprtvlmnHPWeWeee/b5Z6BfNpfeQAEl+rCj3z2a6LKSbvlplpkuE2X/p3urGmqsv/PW Qwu/5TbFfL9+mGOwcUSRX2UT7npHsjseu1Vq13a47bKDtjtgrr0Gm27w+Da4bbLz9jdtvv0+O2PD w8ZIcMT7vvtxHa/VttdXnW1WWLGLxdVZzZflfFZtF/zccsk9xvZB0oNVtVjQRRcWbmBDv7zyFm2t /HXPN+eV89F3x53Zz8tmtXMcbbOQeAYxJ315y3Nv3favUU8c8o9tfNZstYtv9nqFqo0R1g0xP1Z0 CK/v1VryJRRf/WpTVf997k9dMe+0j7+xxvGRXTj/D2/dXvv6dc983itf+va2KrlJK3/Us1h3/LSm OQGGTNNpmpmWE53c4CVO08kL/3TwpCULeskvbKHTBdESHBKKEIQdtFMKm4KmLnHQgzGsoHLmpMES pqmCIMRg1nzokb4B73DRcxCzaPS94RVQfx5KIvxc18QDomhELnKR8QJYwGwZT0b+IxgRZwcryq0O gUUUI/oYR8UlDhGNz9Lc6qx4tu8lkIrTY6DE4hhAL7IRe3NUogKBhT8YKRF/cByjAvF4OCzqb3EH 7OIg9eg/NaLvfn4EHyQBqMb6BfJ+jhwk4wxZR5xtzoC4U2QUx5c5LH5yWH8kFh+dGDtLdnKUfjRg KROZR0ki0paWNJYp/yi2ViqrkVJkkSjDR8hXqnKBaPRkMEEZymjpikJtnGa2fP+5LWZG83TS1KIW tynN2TFTdaw04h7NB71UkZJjt+titHjnu8nZ6nK/5F7r4gitSq6xk8zTHbVSR8Z+gu+ZA2XgGQl6 sZjRUSMKPWhDcfZDiO4Qoj68Wr0qWpiLTlSjG+VoR9slUY+uLKPuGum8QnpSlKZUpStlaUtd+lKY xlSmM6VpTW16U5zmVKc75WlPffpTiurJoyUFalGNai6EMYyhOVoq2uq5Nbg11anu26RDrXpVrPZL qjrbqty8arF1ZlWsY7UbRl+jm7To6TZorQ1x2nomt571hLVpDVvhehW1ylU7e0WO1dilHb/O9TVy bUte3XqnwLbmNm+FIGMTC9j/uiI2sUelbE951L/aYTZhrKulPl23rEeyL5lxG6Vn77nFGclTePxL niTb1yrxxVJ+p/QsWW17W4o4kIVznVoLMWjDD0YwuDdsYZ2kA9wZntCFym2snGAIqBeGMIK4oWFl rXtd4OhVrWilDl9XaJ0MOje7hy2sd/f0QfA6V4RwEup0zetXMZmQuxLEiw6pA1+iXle/LUWucn8z wer+16Q2lFp9t2RC6KoXhdAV8HBhqGCQ8va7I6xTfvd7Yf6e6TkIlm9apZvD6lJwwzw8sHFzmFwK U5e4aiKwffu6mvoml0/yxXCNUxrELPZznKAVIxLhCVs4Mg90uiMyj9nYPOfV/02USD5dQI8YvBIh D8jWeudr2yc53GY5yza2cNa6bGMwhzldWt7fQLtKZjSnWc1BO7PM2rxmOMdZznOmc53tfGc851nP e+Zzn/38Z0AfVMyDJnShDX1oRCda0TUOdKMd/WiHLlrSk6a0TSF9aUxn+meV5nSnPR1STYda1KMW 2qdNfWpUq4zUq2Z1q139aljHWtazpnWtbX1rXOda17vm9axT/WtgB7tdvSZ2sY19bGQnW2PCZnaz nW0YZUdb2tOmdrWtfW1sZ1vb2+Z2t7397V4/W9zjFje4zX1udKdb3etmd7upR254x1ve86Z3ve19 b3znW9/75je/3f1vgE+k3/8DJ/hOw/ZmryHcYvzgh8QYPpGHYzXiFpk4RCoe8IcOJr2SVVl7U8rw kYHcIyLPKclHzg97mLwjKi84ZfOqpqh9eSoyh/lNWM4Rk9/8MCrX+Ux7nnKUq+Tn4xp6y58mVDDR fFAeFxfTl04vnec86ILi+dRx+vObFz1cWjd6vRaaIc5+M3dEBjspv1jkIb+um2s3O/Qm1yCGxz3i cqd73eMO8YZbPO8JmXve+/6PvwO+4YG/ON/lrve7C17vhr/44QVP94E8fOJ1j7zjKWJ3xO+d8hj/ G9hPOVv+hX13q5wmaD9fq1Uqj/SnT6fp2/54w1d+8ZX3+94VP/vY3/7vhB//fO1lf3nN+172Fed9 7iU/+d7rPvi3Zz7ijS/85nOeR4R5+Z2Q/le6ogUr2J85x5Pe/ezU/PpmrbnQrS5yqa/8/FY3/0fQ j3K5A13+8Qd5/eMu//YP5v04D3r6We5/+AvAk8M/wQDAASTArkOZryudJuMn33E7Jlsg2uExz0s7 0rOO17OO1cO72SO+5cu9img827O74Nu8x4M8iiu8zeM9ylPBEUy+4+vAwsM9xSPB35O+ziu9tlM9 z9nA1qNAeVI70Bs9H/xB1gvBF7xB5vPAixDBzLM8G6Q9FGxC5ANBKLQ9EMzCGIxBLZzB5uNC4MNB b6E+7mO68dM+jgOM7fO+/+xjsTWULKdDQw1LwwPkPztUPzzMQ5tjP6nrP5K7P6CbOkAERP0TQD2M vzt0P/ZDQPubv/XLP0UcwKhbxATEGjOMDQ0zLDjExPIDv7OKq/L7vvk6QzrcRE7cwwNMv0RURQRs RfyrukS8Q1gkwEbkv0esw/1zREk0xPczRFr0w1QURGCsxIjiPrZKq/EiLOB4oWWErDPEQLhaLHqB RruKxEMcRBLkQ2G0xmC0xlmcxUD8w7qrQ/UjxHCMxUYUR0Sku268RnNERGKMx5PhOnCUR3sclG7z Qg6kQTHsR1zTR39st3scSIIsSIM8yJsKSIXUNu4IknZBl3dhjKIQFIhUF/+J9JGbuEiEvMdCuRSF qRj74JQdqZj72BeQzIiS1IiTVMmQXEhkM4wqOQqLbMhBQZcsochwqcjGOBfM2MiDzJFQIRVLARWA GZVD0RRQgRSjRBREsQ9N+RSidI+hbMqJYMqkbA+ktBSpFJWqpEr9uMqo7Eqh1MpJcclaQ4zGGI0m OYqYXMuSqJKYvJKdXBIlsQwkYUuQaEvFeIzP6Ay6VMvKkMmbfEuf3Ei+vEu/dInBJA2/zAmHPMye oJK5xEshSRIiscy0pAnNrEzH3MzCPEjI3AnPmJIhoYzAhAzAtIzTmMubvEwgGc3KfIzTkBKfCEzX dMsjycy7/EyCDE3bxAz/xazLxzQKnQzN2/zNyZTM3cwS5FxM5RTOv+RNowMPQxEQQ6nK/CgQ6zwU j+SU6qyIlByQ6/RO9RiVR+nOTuFOrNROSGnJ7TRLZXuPofSU+YwP+dRKquTK9fRKpTRK8JzPoPxP UlmPTfmP9UxPAylQAh1Q7MRKsoTPs0TLetNJ6axQ7ujIXFtJCDVLDXW1Dt1QdbNQER1RjgBREyU2 Ek1RFZ3ImkQZCpVQeWlNwnjR0nAXCi3OnvQOGl3RndrRwZDRevHRsRDSIS1SmfxRmKzLdLnRjIRO nOTRyiLSzHDRcZHS7gBSwdhRLC0XJjXSybxSKKWst8SSKDENMi1TM0XN/zJljDH9CcBczclY0zfV SDN10zNVzbisTccQijY9CYm8EjatUz9l0z+FUzsVzTxNU8VUU85QyyMNU55KzSmBy8zE0dS8VM98 1NdEzKI4TcHsSc6IzbzkTLmkEkrl1OGcjMv0VEndVLqEVKBySNzkS0vNVFb9UlvNTSV5TlIlzk9l TVDFzFtF1eScyFLNVU7lTFjVKdnkU2T9Tc/g1TF1VlKdTWSN0+iMzNU8VhZtVjSd1suQVkX11GJd VcaMU2p91WWNKZYsj/cUTwLtlHf9SndtSfKsV3wVyXyl1/KMV0YpygaFV/U8z0U5T4KVlOws2EuZ V4BN2A890bt5VwYV2P+y5NcENVj2zNf6NM+MrdjsxFiA5VhG0VcDpdgHBdl+3c+U9dh79chHmdiO xRSIJajqHNCaxY8ATcqtxE9R6dmDVdCj/Nmp9NmULJXwBEmrDNqRzdmbpU/zFFqYLVoHtViiVNgE ndlNg6jGjNSssVKW8dp1TbStZVYfAtuUMduwPbSxzSm05VI65ai2TVuswVq6rVu7vduslVu91Te8 7VtS21vADVzBHdyf8lvDPVzETVzFXdxbI1zHHTfGjdw9e1zKrVzLvdyskVzNvTPM7VzP/VzQRarN HV05C13TPV3UTV3VXd0wI13XXTPWjV3ZnV3arV3b/aHXzV3d3V3e7V3/31WY2w1e4R1e4i1e4/2I 301e5V3eZDte531e6I1e6Z3ekMoHlMkH7L0J61UZ7N3ek/HewQDfDKNc8C3fpxHfdEFfclHfjmBf jkBf91WX+BWZ+W1fpCGvqFGh3nKpv7IujcgHiADghBBgmCFggzHggEHgiVDgAKYIBj6YB5aYCF5g tnkqsKob2KmjYcIzAgbgDh6I7mXgEAbhf8BeEO7eihjhEh7gEh5hE27hF17hF45hFZZhFl5gF27h E55hFFbhEDZgAUZgF0ZhCiZhGA7iBg7gHiZiDxbiG/bhBm5iCibiI2bhJp5g2RGt0FMeXsGWHvwi L34ejLkyKPOnLv6x//DhYm6hJucxHR/Lqg+O4yS2CCk2Yju+YyT+YB3G4xPuYxt+4hW+40Am4Rgu YiQG5EEOZAU+ZEGWYyueY0QmZBF+ZEqW5BR2ZCOu40S+kXZKvdoSvdpZldfKpflxJQz+LE5irTuq J1wyZYWTmMLYXuuV5ff1iPidZVvOZV2uZXvAZV42X/vt5WAWZmCmZfjNZfelZWEOZmX+ZZVo5mVG Zl6uZWDWZfNN5mW+ZmnW3m125mqemv6tMDlxMBSisRLrXy55MBhTMBHzIBUz5waLoZYCDw+m5B9e 5Bwe4B/G4RoGYjze50GOY4DOYweOYn6e4R1mYj7eZEWGZELmY382ZP+DpuOGruQ/LmgrHuhEjuBR LuUnqjJKMjsv6qYp0yThgaIGnKSUTmXskS3Ug5xYjmZfvuVujmZufmaZnmabHmbv9eWPMGactt9v Vmb1hWZoduZhFmqd9umdzuaa/mmnVmqpDmpq5uZvZq5wHjH16i//8q31ciF1li6pWaHgCmeu3g6l +yGfnuldnubsHWqoZuactuli5mm6duub7mWm7mmitma3Puqo1mm7nursjWttHoue7ua3borD9ma/ xurVEGctia+yLhO3wF/InuwGo+wT8+ovieyzpuy0LpkccWJ9LuTTvuiEvmSEtmMqXm3XfmIq1mMH NuF6VuLb1uF+Tm3/RlbiKk5h3O5g28bo355gIJ7t4X7giN5tgN7k5eFkKuNiegpjMhLl/vEkIWMi 1Aknlf4mK2MisbMdfMK4CRbkmylvhEFvCF6zV7a1Q6vfps4a+G6X+aZv6xpt6mVsxO5ejqrv9E0Z /7Yp/M5vAg9b5j3wdytwBb+pAWeuSiypBp8vVPuyCN8ohNIq9/EbDRc1DMyeMkuqn1EqrsLwqvKz MwscpkpxUrsix1GY9rajEZ8qXWooszos7SKsagQsxvIN7PhEsBgsHA8syJo5zOYLj9NxvUKs7QLF HLcar/jEG49GjPpxZLwL/N3sJpchILdxLH+scZ6sKE+NxfLyGx9z/8Fq8jI38+xzxiEX8iD38riI Q1Wr4NhCpke6stUD5Xs6JNPqo2W6ptQbkdkypI5GcQKy4COLH1VerVqiJVIOOw5RJg/HLDzH8+M5 dD1SrTnCdHpan0bvmkzy89djM1M+IpXe82MarV0CdTvvdKrKdCtLLVc/p4sAoxnP9NUKJBEnIj43 afspdUOvqnz69c4K9dAaLV9Pdlan9U9/8Y5BaUc3dVVHJWXHJyZrZWUXcWIK5TVG9lYfMtTTwA/P pjJC5ZL2c9R6pVSvdrd76X/6pyYr9ZU+MmjfdGh/I0Xvc2/PGerz6rNeMTL5LxxaLsseZxyKl3iG ExqbMXI2eIe/qP8WO/hy/ouBp7DhkrCKFy603niw/rCxhiASAymRL3gZ8vfxtb4+cXCxBrAAm8N0 JnmOL+seivkUchPJbviSZzESK+cSmg3OpvjoAvgjB/jIDqH28jCGfyDjyMTi+neJ1/mdl3mY3y2p r/BwwbHpLvckKydi4aLSue7wDsII/HpWQiexi3VuF+Mheqfxfp7sIRxuSqQEyu614fq5l27tbnvq nhYK3O7ozuIB6uLotva9ofsiCnu37zEEty1nr/XFf/zL0pjGh9AF9w6rL/rKz3zNFxTI73zP//xz m3y8mZvIyeBX57ax35pRv/WDE/2CKvHSn/SBUbKFiv1FUhwVh33/1t8Y2n+mNhsmOpoeYMJ9Posl 4jf946/g3Afx5Uf0UwYZ1wcl4O8W4f+b0tU4/wpzx2or7ucgMDfDyRLz7ABy+3pn4fBxMWd4svDx JA9/vKpyKYdz8a9GwTp6CSdyK8e+K1csvKL/MAcIewDsCQRgkOBAgwMJMix40OFChAoTPoTYUOLB iQw1IuxIMeLEiBsVYhR58STKlCpXsmzp8qVKkwkbzvQIsqNAlAtNXqyZsydOoDeBFtxI06NRoTeH Hs0pkifFpD5/jjT6lKpOrD6nQg16lGnWijKb1hRb1OtWqju1nsXK1i1Os1eJXp27Vm7TpHFh8u3r 96/Lf4IHExYc/9LgPwCEFSte7Dix4cKRIUsezLiy5cmFL2Om3Fiz58ifHY9uzHmz6MekH5+mnDlz adeVW7eWPXry7dSdV7/uHdo0b9C1c9O2jfp17tCwVSMPrrx4bObAd1Ovbv069uzaZUOOrlA4bssT QRsenxix5OnHv6cH37z7bOPwy7Mvfv679/vsfTMOyV2/ffX5t1589802XnTimedabKUNuB+ExiXo XnLqdTcga/4dFl6DzMmX3HYhijiidS2NNZdVZO0lFVFewbXWSWPRlddPd4WlIox71fUVjivt2CJa b6Xoo4suyoiUXkU6FSSKWfU4pJEqxsgkSzkmyeKPUbIIGJddev/JUnW3Qbfce+qhJ6Z4DLb333z/ WfjZmb45B2dvccJ5GmL5TSihcwziiad8rMVHp2p5eqgneBMCSuiYcua3ZodyKqdbeG22iR5/5JG4 KaecmkgXSRiVxFRGGRVJ0k4V5aVqjayOJJOpaqXEVZKoxhWrrSFJFSpNHFlUkqipliUWr6vKWOyr S17561IcwUosSGYxSyOwSjpEFrJB+botkrdOVS1cX4o7Lrle8lQuuuOemy677br7rpPwyjvvS+vS ey+5nWIGor799suvvwELPDDB2QFcMMIJh6kwww0jfLDDDUMcMcUVRzyxxRmLuKDGHYeIL8ghizwy ySWbfDLKKYP/7DHLLbv8MswxyzwzzTXbfDPOOeu8M88954wxxp2iOWLQHhbocdExJ32cz9QtzbR1 T0vatM1AH+3v0NpZiB3EUju9n9MUe73mxvpunfHYbHb29NlU12y1xFBzrWnUCwe8575uj5022R2n XTTbdLstmEvO8hrVWYhvazi0Ni11bYyhfvQqq5M7JSzmlk/7UFqgcr6rq9RSTjlUkksOuVISpcj5 4bZu6Sy2j2uJ1OEW+VqrqJF/3nq2ikf7ubddnc468aX+fpewKvd1ZKuqXz4rW1kiXmNb9j7frVty gQUjXlZJP+X3TQKJu/jWT1+688hDz7yNUCpLPVjRD8U9td/H/1S9kFUlDv6KRjaLe/Owd75locxu mVITpdoTqQR+KFCDmhPU7FOpBVrqNw9szpvWdjUJCi6BxKkTA/uEKDKFEDgfJOFz3JMpq1HwhAhc DaHI00JB8QmFfENaBDVDJzEhiDQPihMGjaYhCErHgdNp0BAFVaEGmgZDZMMPESWVRE3F0ISb6WER LRUgTFkxh49qIsc+hKnFYNGDT0QOghwUxhmWyYdlpA/VsjapHRaRggpU4qEguCc2TrBP3OkiakYI Nxs68I9RBCGH6phDLRbyiG4ioiM16CgvHlKHhASUJM3YRhQK7oYVk6OZCFkeP9WQkaasU6POQ8kD ZtCOMQxkof9YucFSjtGQo8RbFTWpyqzZKTiGqhSb7tTASdlyl5O8pS9dSEdkEhOURgQmIxPkyU8K iIsg5CFnoKgfBVEIQAe6jHd+qSAgjpOM4SSnJQvEMTW+0pxngpA4y2kgDqbTgub0TDWfA89sWrOT hnrULsHGTTB+05TajCVu/onGWnrzj2B7KH22JtCXKU9dFUWX9S6qUXlldKMe/ShINdrRkN6PpCZl 10hPqtKVstSiLS3cS2Pql5TKtKY2vSlOc6rTnfK0pz79KVCDKtShErWoRj0qUpN6U5rCi6lfcur4 RMclqDZ1qialqlKzeq+OrgurM9pql6xkrU9F1WRQFeu8qOr/Va2y1V1eXeuW6LVWe2G1K8o761jd +he4trWvMRketFxVO8hpBHbE053xRpe7X61qdYHVCewgcqLHMlZWmousrHrCu+Nd7lyMS2y1pqct cJnOeOqTbGgJ6Fetak2VukwnJluZy/Usk1L0zKU194hHR9WWmBPsLSaL+UgeHvO3l1yiGRmVqFd+ sJ2De+7gUincEibKaDRM7iJh2MxG7laGkLxjdYNYm0JWULebxG7eWgmpQ55wvNB9r86meEpuJpRR 8jXQekVZzYmCc7vmTWRxDZoeRTGxggACYzy5e94LvRGWB4ZjfQ8qxvqoDb4WntkM8faeBXcyv681 MCyzWckR/3pXv+AtpQXH68Ly5nHBKtZg2zj8TBJfuMY0E+YCa6lc5aLYueolIT3ryUcdAlLH3yVQ jxG5SmNmUZZJBhhzEfhjIpNShTa+csugeE439fOh/UEnfgd8zjuRGUSzjXBBj5jgMZMxlmxW8hW5 +Ms3EsfLb4ayO+l7Swrfk6BRxjKgEbbaQROVr08l9KADrehFJ2yaRGM0pCMt6Um/zNFlozSmRYTo TXO6057+NKhDLepRk7rUpj71UTOt6lWzutWufjWsYy3rWdO61ra+Na5zretd87rXvv41sIONZVQT u9jGPjayk61sVAu72c5+ts6WLe1pU/td0L42trPdsWpzu//b3v42uMMt7nGTu9zmPom2063udbO7 3e5+d8bOLe9507ve9r53TeGt733rG9/+/jfAAy7wgRO84AY/OMITXnB+M7zhDn84xCMu8YlTvOI1 UzjGM15Ri3O84x7/OMhDLvKRk1zVGj85ylOu8pX3tOQufznMYy5zYLO85jYf18xzrvOd87znV745 0IPeF58Tvej6EjrSk670pTO96U5/OtSjfnKjU73qVr861jsl9a1zvete/zrYwy72sZO97GaHetbT nvazs53can873OMud5m3ve52vzvePTr3ves8735XNt8DH/O/E97Ygj98yQuv+MUzvvGOfzyxES/5 yVO+8iX/3wTmtYP5TQR685mnzuY3FXqbjR5npb/O6S2f+tSTiPX/8HzpXR8i2Q+G9gGjfew/PyLb 92v0vK+97ncD+99Xx/OE8X3miX/84GPG9cYHPueLH3zlt3v1zG/99V//eeRHn1O8p77osy+Y3Hdf RODf/fbFLxnik7/824E99MeffPU3n/7yd//9dc/+6dsf2i3Z/EUA4LgIYABiHkMAIAHyVAIW4CYc oAF2yQLOSwSmxASexAJWoEvAngM2IAP2BQZmoOdt4EsI4AeK2wU+oD1oYEMM3wqyoAWiIAIOHweS 4AO6YArCYAgSBAG6oAxyIAXm4A0C4Qb2oBCqIEr0YAsm/yAP2mAQBmEO2mAJ6iAKiiATqsQSzqAB xiAOKuEW7uAUDmENfqEVhqEPOuEUyiAYYiETGiENluFPnaAaNqEUiqAcTqAXNuATkmEbSmEc1mEf bqET8uEP4iEgDuIQCmITVmAexuEeJqIW0iEXQqIYHqEYaqEbrkQMIuIj3qEc+qEkXqIjIuL/kaED fqIm+qAlniIhqqERypT0EaH2dZ/zzZ8sZh/5xWL8xSL3VUbozSL+4eItrp/+pd8v3l8uAuMw/uIt LuP1BeMu1l/07R/+9WL/LR/nUWM00mIw4iI3FsYzeiMtdqP0yV9nYOMxWmM3mqMx6mI15swouuEj iiIacv/iC/5hIV4hF64iJaIiC9JjB6riGPKjQHaiHQIiJ0LhPZJiEi4iCF5iPI5gGPrhKp5hQgok Q9bjHEZhGjJgCPrjPBpkRWokSb0iOF5jD66jOooj9D1fOiZj+cmgMfoiSobjOpZkLuJeMsYfLApj LZpkT+ZfSj7j6QllNbJeSloH9+0i/B0jUWajU/IiMVLf8KEjMv4kNwYlTV7lUkLXO3ZgQQ6kPybh PtJhINYjI07iQ6YlWlZkQJLlQ2IiSA7kQhKkQnqkQrJEBN5lQ4KhICKkXKplH/6jGfJFEcYlFRpm XxZiWQ4VHHaiWCamXArmY9LlJEqkYx4mWCrmZDbiWMr/YxZWpmACJkbSI2eSJmhOJkDCxB2SIhpS JmSaIkby4Wma5WZ+ZmbeJma6pUiOJOgx3zfS5PNhozLaYk7WpFY+pVbGZFS2ZDFiZTEy500OI1Ra pToqJTFGJ3X+plG65Dka5zkGZziCp0/q5HKqpHGypO2x5HE+pfElJXRWpTU+p890ZW0CIRLK5ld2 pmsupGKyoR52pGZyZBl+4H1SpiL2Z2EuYoLy5X2GZRp+YV6u5YDuYRuy4oRaKGeipn3OZiW2phn+ p2ji5wsi3G5SW4kCxoma4GwSGqCdX7q5qOa1o75dZ6+94Yp6W4p64I2qqBCKmuX9KJAGqZAOKZEW aXVAIR6SJqmSmp2RNqm6LSmURqmUTimVVqmVXqnhOamWXltAAAA7 ------=_NextPart_000_0009_01C71A27.D6F75A90-- From sip-bounces@ietf.org Thu Dec 07 12:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMnm-0002cS-1d; Thu, 07 Dec 2006 12:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMnk-0002VR-R3 for sip@ietf.org; Thu, 07 Dec 2006 12:12:52 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMie-0002QB-Ci for sip@ietf.org; Thu, 07 Dec 2006 12:08:00 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB7H1J204927; Thu, 7 Dec 2006 09:01:19 -0800 In-Reply-To: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41b77144d7964f0dde0a8500db001688@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 09:01:26 -0800 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: Cullen Jennings , Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 On Dec 7, 2006, at 6:59, Christer Holmberg ((JO/LMF)) wrote: > Hi, > >>> I find this whole conversation way off base. If people would like to >>> deprecate UDP, go work on a document to explain that and >>> feel free to bring it to the WG. In the mean time, SIP is specified > over >>> both UDP and TCP. >> >> To be more specific, SIP is currently specified so it can use >> UDP for requests smaller than 1300 bytes. It is specified so >> it can use TCP for requests of any size. >> >> Some people have suggested that user agents SHOULD be able to >> send and receive requests larger than 1300 bytes when using >> the outbound mechanism. This seems like a logical >> requirement. Are you objecting to this requirement Cullen? > > Isn't that an implementation issue? No, it is an interoperability issue which is consistent with our core spec. > What if a client "knows" that it will never send or receive requests > larger than 1300 bytes? For most UAs the client will never be able to "know" that. In fact most UAs will be reasonably sure that they WILL be getting requests larger than this size. The only reason this is not a MUST is that we have some environments (like 3GPP) that are trying hard to keep requests under MTU size and where requests larger than this size are rare. >> For the sake of this discussion, lets assume that we have >> consensus on this requirement. What are the implications? >> Well, most UAs implementing outbound are doing so because >> they are behind a NAT or a firewall and will not be able to >> receive inbound TCP flows. These UAs will need to establish >> a TCP flow if they want to meet this requirement of receiving >> requests larger than 1300 bytes. The logical normative >> statement is to say a UA which cannot (or suspects that it >> cannot) receive an inbound TCP flow from its outbound proxies >> SHOULD open at least one TCP or TLS flow to a server in its >> outbound-proxy-set. > > I think it's quite clear that a client located behdind a NAT/Firewall, > wanting to be able to receive inbound TCP flows, should take actions to > allow that. But, do we need to say more than that? For most UAs we do. Therefore a SHOULD is appropriate. >> A few people on this mailing list have suggested that for any >> user agent that actually bothers to open a TCP flow, there is >> no reason whatsoever to open a corresponding UDP flow. I >> wholeheartedly agree with them. > > That's probably true. But, again, is that something we need to specify, > or is it an implementation issue? We have normative language in our specifications that recommend all sorts of things that are far less important and significant than this. >> The problem is that this thread strikes right at the heart of >> our community's dilemma. We have a large body of people who >> have deployed UDP almost exclusively and effectively ignore >> the MUST use (and several even ignore the MUST implement) TCP >> statements in our core spec. >> Ironically, one of the problems which prevents realistic >> interoperable deployment of TCP-based SIP implementations is >> the lack of a standardized mechanism for doing outbound. >> [Dean also identified some other problems often faced when >> deploying TCP with programs that use "obvious" (Dean actually >> said "naive") textbook implementation techniques.] >> >> I think that a large number of the core spec contributors and >> seasoned implementors now recognize that there are many >> non-academic problems with SIP over UDP and that some day we >> will want to either deprecate or at least seriously curtail >> the use of UDP. Like a very heavy drinker we know it will be >> good for us to kick the habit. We are not quitting today. >> The question before us is are we going to do something in >> outbound that makes it harder for us to quit in the future. > > First people wanted to use outbound to "promote" STUN, now to get rid > of > UDP. Is that really what we are supposed to be doing? No, we already have several good reasons to get rid of UDP in the future. What I am proposing is that we don't make it harder for us to do so when the time comes. > I still fail to see what the technical problems with outbound and STUN > is. It may be more complex than TCP, but are there really any open > issues to be solved? >> My concrete proposal is the following: >> - make CRLF the only keepalive mechanism for TCP and TLS over >> TCP flow (retain STUN for UDP flows) >> - make outbound registrations over UDP flows optional for UAs >> - include 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 (the 3GPP exception). explain that for historical >> purposes a lot of deployments still only use UDP, but that we >> expect/hope those deployments to eventually migrate to TCP >> when doing outbound. > > I don't understand why a standards spec shall talk about what we hope > and expect... As Cullen said, UDP is a valid transport protocol for > SIP, > so I don't understand why we need to "justify" anything... If we have a SHOULD, we need to justify why someone might not do the SHOULD. In some ways the bar is even higher here since we are justifying why this wasn't a MUST. >> What's in it for the TCP crowd? They get to implement >> outbound with no UDP if they so desire. They don't have to >> implement STUN over TCP. The draft clearly explains why TCP >> is the technically preferred solution. >> >> What's in it for the UDP crowd? They get outbound behavior >> (at least for requests <1300 bytes) specified in the core >> draft for UDP. They can keep doing what they are doing, but >> with STUN keepalives if the UA and edge proxy both support it. > > Just to clarify: the edge proxy is still required to implement STUN, in > case someone establishes UDP flows with it, right? That would be part of my plan. thanks, -rohan > Regards, > > Christer > > > > > > >> >>> Most deployments only use UDP, some only use TCP, and I >> suspect there >>> are some that do both but I am not aware of them. Outbound as it is >>> seems very consistent with 3261 in that it allows a system >> to use TCP >>> or UDP. Keeping this in mind few comments inline .... >>> >>> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >>> >>>> Let's go back to the original topic - what should the >> draft say about >>>> the transport protocol in relationship with outbound >>>> >>>> The major use case for outbound is UAs behind NAT / >> firewalls. Many >>>> of such devices have known issues with UDP fragmentation, >> so for many >>>> environments TCP will need to be used for messages larger than the >>>> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts >>>> the limit at 1300). >>> >>> These known issues with fragmentation might be less common than you >>> think however, outbound does not have anything to do with >> MTU issues. >>> It does not try and solve them and it does not make them worse. >>> >>>> >>>> If you start from the requirement "MUST only use UDP", >> then there is >>>> little room for constructive discussions. For UDP-only to work you >>>> will need to ensure that messages either stay below path MTUs, or >>>> disallow NAT. This implies significant limitations for your >>>> deployment environment. In any case, this is not a setup that >>>> outbound should focus on. >>> >>> MTU is a problem regardless of NATs or Firewalls. >> Fragmented packets >>> do manager to traverse most NATs and Firewalls. >>> >>>> >>>> In the general case, there are environments that have to deal with >>>> NAT and messages larger than path MTU. This is what outbound was >>>> written for. This also implies a UA that supports TCP. >> Given that the >>>> UA supports TCP and the fact that presence of devices like >> stateful >>>> firewalls cannot reliably be detected, the UA SHOULD use TCP (or >>>> another connection oriented transport). If in addition the UA >>>> supports TLS, it SHOULD use TLS. >>> >>> Again, this topic is not really about outbound. If you >> think a 3261 UA >>> that supports both UDP and TCP SHOULD use TCP, that is a >> fine argument >>> to go make in the discussion about use of TCP and UDP but >> it seems to >>> be an independent choice from anything to do with outbound. >>> >>> >>> Cullen >>> >>>> >>>> I think this is sufficient >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Fredrik Thulin wrote: >>>>> Hisham Khartabil wrote: >>>>>> >>>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>>> ... >>>>>>> I personally believe going TCP-only would actually help >> deployment >>>>>>> rather than hinder it, but I'd be really interested to be >>>>>>> convinced otherwise. >>>>>> >>>>>> I could ask you the converse. I'd really be interested to be >>>>>> convinced how TCP deployment improves scalability. >>>>> >>>>> To name two things where TCP would provide better >> scalability than >>>>> UDP for a SIP service provider : >>>>> >>>>> 1) Say that your services maximum capacity for >> non-INVITEs is 1000 >>>>> requests per second. If you get 2000 in a single second, you >>>>> won't only have to deal with all those 2000 >> requests, but also >>>>> with quite a few retransmissions sent after 500ms. >> With TCP, the >>>>> wall isn't as dense. >>>>> >>>>> 2) UDP sockets have a shared receive buffer, most >> commonly around >>>>> 64k I believe (even though the maximum seems to be 256k on >>>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>>> average, you have to be able to move messages out of >> that buffer >>>>> pretty fast to keep it from filling up. A full buffer means >>>>> dropped packets. I've also heard that on for example Linux, >>>>> every packet actually occupies an even 2k (or was it >> 4k) in the >>>>> buffer, so 64k buffer is actually at most 32 packets >> at a time. >>>>> >>>>> And then there are of course other aspects than scalability where >>>>> UDP is an inferior solution, most notably security related things >>>>> like for example spoofed CANCELs (which can't be >> challenged, RFC3261 >>>>> #22.1). >>>>> >>>>> /Fredrik >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP 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 Thu Dec 07 12:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMzK-00084r-3P; Thu, 07 Dec 2006 12:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMzI-00083A-Ue for sip@ietf.org; Thu, 07 Dec 2006 12:24:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMzG-0005CA-Ln for sip@ietf.org; Thu, 07 Dec 2006 12:24:48 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 09:24:46 -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 kB7HOifO023503; Thu, 7 Dec 2006 09:24:44 -0800 Received: from [216.102.208.13] (sjc-vpn5-144.cisco.com [10.21.88.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7HOdOV015692; Thu, 7 Dec 2006 09:24:43 -0800 (PST) Message-ID: <45784E6C.3030006@cisco.com> Date: Thu, 07 Dec 2006 09:25:00 -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: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> <41b77144d7964f0dde0a8500db001688@ekabal.com> In-Reply-To: <41b77144d7964f0dde0a8500db001688@ekabal.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=974; t=1165512284; x=1166376284; c=relaxed/relaxed; s=sjdkim8002; 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=20[Sip]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=Y9+7W9lQVHtymD4/sFJTpzO1kZEUIs158kOFprGVXK8=; b=w4IzyCM+wR7mG1/+AK0bPsoNGATMKwlskhRd3XUAUaGoeVz/5mBTLXBDSabCJyhUPGZ30xTD 8QftqbIYsUTKAuXnOVYKR6ZK+tzqvK8SXCjhbjTi2knl7opXxyCbcUpt; Authentication-Results: sj-dkim-8; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Cullen Jennings , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, aki.niemi@nokia.com, "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 Rohan Mahy wrote: >> What if a client "knows" that it will never send or receive requests >> larger than 1300 bytes? > > For most UAs the client will never be able to "know" that. In fact > most UAs will be reasonably sure that they WILL be getting requests > larger than this size. The only reason this is not a MUST is that we > have some environments (like 3GPP) that are trying hard to keep > requests under MTU size and where requests larger than this size are > rare. And the minute that they interconnect to something that hasn't been trying, the assumption gets blown clean out of the water, right? That is the nature of an internet, right? I guess I don't see the point of special casing something for the range of the moment. It seems like the SHOULD isn't really a SHOULD at all because we know that those assumptions will eventually bite because the SIP wg sure isn't putting any energy in making that true for the Internet at large. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 07 12:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNHR-0001Kh-Cd; Thu, 07 Dec 2006 12:43:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNHQ-0001KY-Nh for sip@ietf.org; Thu, 07 Dec 2006 12:43:32 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNHP-0007RG-Al for sip@ietf.org; Thu, 07 Dec 2006 12:43:32 -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 kB7HhOV27077; Thu, 7 Dec 2006 12:43:24 -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] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 11:43:23 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E50182C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: AccZwBVSHGn1IUq+Q2GHarQlpbEBpgAZuiOg From: "Francois Audet" To: "Rohan Mahy" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org, Fredrik Thulin , peter.leis@siemens.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 I really like this proposal and support it. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Wednesday, December 06, 2006 21:16 > To: Cullen Jennings > Cc: Rohan Mahy; Fredrik Thulin; sip@ietf.org;=20 > Markus.Isomaki@nokia.com; peter.leis@siemens.com; aki.niemi@nokia.com > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol > > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over=20 > TCP flow (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include the statement that its is RECOMMENDED that the=20 > outbound-proxy-set is configured to result in registrations=20 > over TCP or TLS whenever the UA can't accept incoming TCP=20 > flows (the 3GPP exception). explain that for historical=20 > purposes a lot of deployments still only use UDP, but that we=20 > expect/hope those deployments to eventually migrate to TCP=20 > when doing outbound. >=20 > What's in it for the TCP crowd? They get to implement=20 > outbound with no UDP if they so desire. They don't have to=20 > implement STUN over TCP. The draft clearly explains why TCP=20 > is the technically preferred solution. >=20 > What's in it for the UDP crowd? They get outbound behavior=20 > (at least for requests <1300 bytes) specified in the core=20 > draft for UDP. They can keep doing what they are doing, but=20 > with STUN keepalives if the UA and edge proxy both support it. >=20 > What's not to like? > thanks, > -rohan >=20 >=20 > > Most deployments only use UDP, some only use TCP, and I=20 > suspect there=20 > > are some that do both but I am not aware of them. Outbound as it is=20 > > seems very consistent with 3261 in that it allows a system=20 > to use TCP=20 > > or UDP. Keeping this in mind few comments inline .... > > > > On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > > > >> Let's go back to the original topic - what should the=20 > draft say about=20 > >> the transport protocol in relationship with outbound > >> > >> The major use case for outbound is UAs behind NAT /=20 > firewalls. Many=20 > >> of such devices have known issues with UDP fragmentation,=20 > so for many=20 > >> environments TCP will need to be used for messages larger than the=20 > >> path MTU (often ~1460 bytes in ethernet environments, RFC3261 puts=20 > >> the limit at 1300). > > > > These known issues with fragmentation might be less common than you=20 > > think however, outbound does not have anything to do with=20 > MTU issues. > > It does not try and solve them and it does not make them worse. > > > >> > >> If you start from the requirement "MUST only use UDP",=20 > then there is=20 > >> little room for constructive discussions. For UDP-only to work you=20 > >> will need to ensure that messages either stay below path MTUs, or=20 > >> disallow NAT. This implies significant limitations for your=20 > >> deployment environment. In any case, this is not a setup that=20 > >> outbound should focus on. > > > > MTU is a problem regardless of NATs or Firewalls.=20 > Fragmented packets=20 > > do manager to traverse most NATs and Firewalls. > > > >> > >> In the general case, there are environments that have to deal with=20 > >> NAT and messages larger than path MTU. This is what outbound was=20 > >> written for. This also implies a UA that supports TCP.=20 > Given that the=20 > >> UA supports TCP and the fact that presence of devices like=20 > stateful=20 > >> firewalls cannot reliably be detected, the UA SHOULD use TCP (or=20 > >> another connection oriented transport). If in addition the UA=20 > >> supports TLS, it SHOULD use TLS. > > > > Again, this topic is not really about outbound. If you=20 > think a 3261 UA=20 > > that supports both UDP and TCP SHOULD use TCP, that is a=20 > fine argument=20 > > to go make in the discussion about use of TCP and UDP but=20 > it seems to=20 > > be an independent choice from anything to do with outbound. > > > > > > Cullen > > > >> > >> I think this is sufficient > >> > >> Regards, > >> Jeroen > >> > >> Fredrik Thulin wrote: > >>> Hisham Khartabil wrote: > >>>> > >>>> On Dec 5, 2006, at 3:33 PM, wrote: > >>> ... > >>>>> I personally believe going TCP-only would actually help=20 > deployment=20 > >>>>> rather than hinder it, but I'd be really interested to be=20 > >>>>> convinced otherwise. > >>>> > >>>> I could ask you the converse. I'd really be interested to be=20 > >>>> convinced how TCP deployment improves scalability. > >>> > >>> To name two things where TCP would provide better=20 > scalability than=20 > >>> UDP for a SIP service provider : > >>> > >>> 1) Say that your services maximum capacity for=20 > non-INVITEs is 1000 > >>> requests per second. If you get 2000 in a single second, you > >>> won't only have to deal with all those 2000=20 > requests, but also > >>> with quite a few retransmissions sent after 500ms.=20 > With TCP, the > >>> wall isn't as dense. > >>> > >>> 2) UDP sockets have a shared receive buffer, most=20 > commonly around > >>> 64k I believe (even though the maximum seems to be 256k on > >>> FreeBSD at least). With SIP messages of perhaps 700 bytes on > >>> average, you have to be able to move messages out of=20 > that buffer > >>> pretty fast to keep it from filling up. A full buffer means > >>> dropped packets. I've also heard that on for example Linux, > >>> every packet actually occupies an even 2k (or was it=20 > 4k) in the > >>> buffer, so 64k buffer is actually at most 32 packets=20 > at a time. > >>> > >>> And then there are of course other aspects than scalability where=20 > >>> UDP is an inferior solution, most notably security related things=20 > >>> like for example spoofed CANCELs (which can't be=20 > challenged, RFC3261=20 > >>> #22.1). > >>> > >>> /Fredrik > >>> > >>> > >>> _______________________________________________ > >>> 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=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 Thu Dec 07 13:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNtP-0003Hd-2R; Thu, 07 Dec 2006 13:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNtO-0003G3-88 for sip@ietf.org; Thu, 07 Dec 2006 13:22:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNtL-0005Mc-Gc for sip@ietf.org; Thu, 07 Dec 2006 13:22:46 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 10:22:43 -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 kB7IMgLZ022176; Thu, 7 Dec 2006 10:22:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IMAP5027449; Thu, 7 Dec 2006 10:22:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:25 -0800 Received: from [192.168.1.3] ([10.21.123.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:23 -0800 In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 10:22:38 -0800 To: Dean Willis , Keith Drage X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Dec 2006 18:22:23.0964 (UTC) FILETIME=[A43C31C0:01C71A2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9594; t=1165515763; x=1166379763; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=plcyzxcicvFhpGjFnYI6Wy2A3GR2DHvxp3VHIz4cv+Y=; b=bAx+IqXBUMEDv5UPEwyGhrTjCGJqCr6hKErgkP6J2AGWyXcudrGMybwsaGtHAOAOlyZwZ/dH vpNMyhiiG812C6v6BF0SXq9PVW58dYZCbFt8lLY9mXGjm+Ihb/YRMyUw; 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: a492040269d440726bfd84680622cee7 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , 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 Dear chairs, Rohan has always disagreed with our TCP keep alive mechanism. He has brought this up over many meetings. IT has been discussed many times and we have taken WG hums on it. This whole argument that he is creating is centered around trying to kill the way TCP keep alive are done. He is not alone, others agree with him. The basic argument against it is it is a pain to implement - I've implemented and did not find it a big deal but agree it is more complicated that implementing the Double CRLF approach. We did have reasonable good consensus for it in the last WG hum we took on it. I would like the chairs to make a statement about if they want reopen the issue of how to do TCP Keep alives. If yes, I'm glad to present on it at next IETF, if not, I want to know that I can just ignore it. Cullen (with my outbound editor hat on) On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > > On Dec 6, 2006, at 16:33, Cullen Jennings wrote: >> I find this whole conversation way off base. If people would like >> to deprecate UDP, go work on a document to explain that and feel >> free to bring it to the WG. In the mean time, SIP is specified >> over both UDP and TCP. > > To be more specific, SIP is currently specified so it can use UDP > for requests smaller than 1300 bytes. It is specified so it can > use TCP for requests of any size. > > Some people have suggested that user agents SHOULD be able to send > and receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you > objecting to this requirement Cullen? yes. > > For the sake of this discussion, lets assume that we have consensus > on this requirement. What are the implications? Well, most UAs > implementing outbound are doing so because they are behind a NAT or > a firewall and will not be able to receive inbound TCP flows. > These UAs will need to establish a TCP flow if they want to meet > this requirement of receiving requests larger than 1300 bytes. The > logical normative statement is to say a UA which cannot (or > suspects that it cannot) receive an inbound TCP flow from its > outbound proxies SHOULD open at least one TCP or TLS flow to a > server in its outbound-proxy-set. > > A few people on this mailing list have suggested that for any user > agent that actually bothers to open a TCP flow, there is no reason > whatsoever to open a corresponding UDP flow. I wholeheartedly agree > with them. > > The problem is that this thread strikes right at the heart of our > community's dilemma. We have a large body of people who have > deployed UDP almost exclusively and effectively ignore the MUST use > (and several even ignore the MUST implement) TCP statements in our > core spec. Ironically, one of the problems which prevents > realistic interoperable deployment of TCP-based SIP implementations > is the lack of a standardized mechanism for doing outbound. [Dean > also identified some other problems often faced when deploying TCP > with programs that use "obvious" (Dean actually said "naive") > textbook implementation techniques.] > > I think that a large number of the core spec contributors and > seasoned implementors now recognize that there are many non- > academic problems with SIP over UDP and that some day we will want > to either deprecate or at least seriously curtail the use of UDP. > Like a very heavy drinker we know it will be good for us to kick > the habit. We are not quitting today. The question before us is > are we going to do something in outbound that makes it harder for > us to quit in the future. > > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over TCP > flow (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include 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 (the 3GPP > exception). explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > What's in it for the TCP crowd? They get to implement outbound > with no UDP if they so desire. They don't have to implement STUN > over TCP. The draft clearly explains why TCP is the technically > preferred solution. > > What's in it for the UDP crowd? They get outbound behavior (at > least for requests <1300 bytes) specified in the core draft for > UDP. They can keep doing what they are doing, but with STUN > keepalives if the UA and edge proxy both support it. > > What's not to like? > thanks, > -rohan > > >> Most deployments only use UDP, some only use TCP, and I suspect >> there are some that do both but I am not aware of them. Outbound >> as it is seems very consistent with 3261 in that it allows a >> system to use TCP or UDP. Keeping this in mind few comments >> inline .... >> >> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >> >>> Let's go back to the original topic - what should the draft say >>> about the transport protocol in relationship with outbound >>> >>> The major use case for outbound is UAs behind NAT / firewalls. >>> Many of such devices have known issues with UDP fragmentation, so >>> for many environments TCP will need to be used for messages >>> larger than the path MTU (often ~1460 bytes in ethernet >>> environments, RFC3261 puts the limit at 1300). >> >> These known issues with fragmentation might be less common than >> you think however, outbound does not have anything to do with MTU >> issues. It does not try and solve them and it does not make them >> worse. >> >>> >>> If you start from the requirement "MUST only use UDP", then there >>> is little room for constructive discussions. For UDP-only to work >>> you will need to ensure that messages either stay below path >>> MTUs, or disallow NAT. This implies significant limitations for >>> your deployment environment. In any case, this is not a setup >>> that outbound should focus on. >> >> MTU is a problem regardless of NATs or Firewalls. Fragmented >> packets do manager to traverse most NATs and Firewalls. >> >>> >>> In the general case, there are environments that have to deal >>> with NAT and messages larger than path MTU. This is what outbound >>> was written for. This also implies a UA that supports TCP. Given >>> that the UA supports TCP and the fact that presence of devices >>> like stateful firewalls cannot reliably be detected, the UA >>> SHOULD use TCP (or another connection oriented transport). If in >>> addition the UA supports TLS, it SHOULD use TLS. >> >> Again, this topic is not really about outbound. If you think a >> 3261 UA that supports both UDP and TCP SHOULD use TCP, that is a >> fine argument to go make in the discussion about use of TCP and >> UDP but it seems to be an independent choice from anything to do >> with outbound. >> >> >> Cullen >> >>> >>> I think this is sufficient >>> >>> Regards, >>> Jeroen >>> >>> Fredrik Thulin wrote: >>>> Hisham Khartabil wrote: >>>>> >>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>> ... >>>>>> I personally believe going TCP-only would actually help >>>>>> deployment >>>>>> rather than hinder it, but I'd be really interested to be >>>>>> convinced >>>>>> otherwise. >>>>> >>>>> I could ask you the converse. I'd really be interested to be >>>>> convinced how TCP deployment improves scalability. >>>> >>>> To name two things where TCP would provide better scalability >>>> than UDP >>>> for a SIP service provider : >>>> >>>> 1) Say that your services maximum capacity for non-INVITEs is >>>> 1000 >>>> requests per second. If you get 2000 in a single second, you >>>> won't only have to deal with all those 2000 requests, but also >>>> with quite a few retransmissions sent after 500ms. With >>>> TCP, the >>>> wall isn't as dense. >>>> >>>> 2) UDP sockets have a shared receive buffer, most commonly around >>>> 64k I believe (even though the maximum seems to be 256k on >>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>> average, you have to be able to move messages out of that >>>> buffer >>>> pretty fast to keep it from filling up. A full buffer means >>>> dropped packets. I've also heard that on for example Linux, >>>> every packet actually occupies an even 2k (or was it 4k) in >>>> the >>>> buffer, so 64k buffer is actually at most 32 packets at a >>>> time. >>>> >>>> And then there are of course other aspects than scalability >>>> where UDP >>>> is an inferior solution, most notably security related things >>>> like for >>>> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >>>> >>>> /Fredrik >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Dec 07 13:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNt2-00039v-Hj; Thu, 07 Dec 2006 13:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNt0-00039a-Pg for sip@ietf.org; Thu, 07 Dec 2006 13:22:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNsy-0005JS-Fs for sip@ietf.org; Thu, 07 Dec 2006 13:22:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 10:22:20 -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 kB7IMJfV021919; Thu, 7 Dec 2006 10:22:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IMAOX027449; Thu, 7 Dec 2006 10:22:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:10 -0800 Received: from [192.168.1.3] ([10.21.123.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:09 -0800 In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <496F2C9D-3B39-445A-8A67-2D4CB9FB6E72@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 10:22:23 -0800 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Dec 2006 18:22:09.0729 (UTC) FILETIME=[9BC01B10:01C71A2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=918; t=1165515739; x=1166379739; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=aNeNDX9bt++f7cokSSipu4YtN4cNBU9XabLnZaoq/TQ=; b=lWF+tI8+ubh3u47ekU9szH1Ni2r932IcuGVNpV7L1b9P/UKm/HLEgH7XvpmtVtk1taManTYB AEedm2gIfXditmk6CPwgb7Jbw6qPQ+1Vht66bm5ahkbZJJ9GHeMnNav9; 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: 93238566e09e6e262849b4f805833007 Cc: Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > To be more specific, SIP is currently specified so it can use UDP > for requests smaller than 1300 bytes. It is specified so it can > use TCP for requests of any size. Agree with above. Note that you said SIP specified a way to do this not that deployments must use this. > > Some people have suggested that user agents SHOULD be able to send > and receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you > objecting to this requirement Cullen? yes - I object to this. I think the specification should specify how things work for large requests but that an UA should be allowed to choose to use only UDP if it wants to accept the limitations that this implies. Again, I don't see why you are trying to tie up deprecating UDP with the outbound 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 Thu Dec 07 13:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNtP-0003Hd-2R; Thu, 07 Dec 2006 13:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNtO-0003G3-88 for sip@ietf.org; Thu, 07 Dec 2006 13:22:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNtL-0005Mc-Gc for sip@ietf.org; Thu, 07 Dec 2006 13:22:46 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 10:22:43 -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 kB7IMgLZ022176; Thu, 7 Dec 2006 10:22:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IMAP5027449; Thu, 7 Dec 2006 10:22:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:25 -0800 Received: from [192.168.1.3] ([10.21.123.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:23 -0800 In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 10:22:38 -0800 To: Dean Willis , Keith Drage X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Dec 2006 18:22:23.0964 (UTC) FILETIME=[A43C31C0:01C71A2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9594; t=1165515763; x=1166379763; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=plcyzxcicvFhpGjFnYI6Wy2A3GR2DHvxp3VHIz4cv+Y=; b=bAx+IqXBUMEDv5UPEwyGhrTjCGJqCr6hKErgkP6J2AGWyXcudrGMybwsaGtHAOAOlyZwZ/dH vpNMyhiiG812C6v6BF0SXq9PVW58dYZCbFt8lLY9mXGjm+Ihb/YRMyUw; 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: a492040269d440726bfd84680622cee7 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , 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 Dear chairs, Rohan has always disagreed with our TCP keep alive mechanism. He has brought this up over many meetings. IT has been discussed many times and we have taken WG hums on it. This whole argument that he is creating is centered around trying to kill the way TCP keep alive are done. He is not alone, others agree with him. The basic argument against it is it is a pain to implement - I've implemented and did not find it a big deal but agree it is more complicated that implementing the Double CRLF approach. We did have reasonable good consensus for it in the last WG hum we took on it. I would like the chairs to make a statement about if they want reopen the issue of how to do TCP Keep alives. If yes, I'm glad to present on it at next IETF, if not, I want to know that I can just ignore it. Cullen (with my outbound editor hat on) On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > > On Dec 6, 2006, at 16:33, Cullen Jennings wrote: >> I find this whole conversation way off base. If people would like >> to deprecate UDP, go work on a document to explain that and feel >> free to bring it to the WG. In the mean time, SIP is specified >> over both UDP and TCP. > > To be more specific, SIP is currently specified so it can use UDP > for requests smaller than 1300 bytes. It is specified so it can > use TCP for requests of any size. > > Some people have suggested that user agents SHOULD be able to send > and receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you > objecting to this requirement Cullen? yes. > > For the sake of this discussion, lets assume that we have consensus > on this requirement. What are the implications? Well, most UAs > implementing outbound are doing so because they are behind a NAT or > a firewall and will not be able to receive inbound TCP flows. > These UAs will need to establish a TCP flow if they want to meet > this requirement of receiving requests larger than 1300 bytes. The > logical normative statement is to say a UA which cannot (or > suspects that it cannot) receive an inbound TCP flow from its > outbound proxies SHOULD open at least one TCP or TLS flow to a > server in its outbound-proxy-set. > > A few people on this mailing list have suggested that for any user > agent that actually bothers to open a TCP flow, there is no reason > whatsoever to open a corresponding UDP flow. I wholeheartedly agree > with them. > > The problem is that this thread strikes right at the heart of our > community's dilemma. We have a large body of people who have > deployed UDP almost exclusively and effectively ignore the MUST use > (and several even ignore the MUST implement) TCP statements in our > core spec. Ironically, one of the problems which prevents > realistic interoperable deployment of TCP-based SIP implementations > is the lack of a standardized mechanism for doing outbound. [Dean > also identified some other problems often faced when deploying TCP > with programs that use "obvious" (Dean actually said "naive") > textbook implementation techniques.] > > I think that a large number of the core spec contributors and > seasoned implementors now recognize that there are many non- > academic problems with SIP over UDP and that some day we will want > to either deprecate or at least seriously curtail the use of UDP. > Like a very heavy drinker we know it will be good for us to kick > the habit. We are not quitting today. The question before us is > are we going to do something in outbound that makes it harder for > us to quit in the future. > > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over TCP > flow (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include 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 (the 3GPP > exception). explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > What's in it for the TCP crowd? They get to implement outbound > with no UDP if they so desire. They don't have to implement STUN > over TCP. The draft clearly explains why TCP is the technically > preferred solution. > > What's in it for the UDP crowd? They get outbound behavior (at > least for requests <1300 bytes) specified in the core draft for > UDP. They can keep doing what they are doing, but with STUN > keepalives if the UA and edge proxy both support it. > > What's not to like? > thanks, > -rohan > > >> Most deployments only use UDP, some only use TCP, and I suspect >> there are some that do both but I am not aware of them. Outbound >> as it is seems very consistent with 3261 in that it allows a >> system to use TCP or UDP. Keeping this in mind few comments >> inline .... >> >> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >> >>> Let's go back to the original topic - what should the draft say >>> about the transport protocol in relationship with outbound >>> >>> The major use case for outbound is UAs behind NAT / firewalls. >>> Many of such devices have known issues with UDP fragmentation, so >>> for many environments TCP will need to be used for messages >>> larger than the path MTU (often ~1460 bytes in ethernet >>> environments, RFC3261 puts the limit at 1300). >> >> These known issues with fragmentation might be less common than >> you think however, outbound does not have anything to do with MTU >> issues. It does not try and solve them and it does not make them >> worse. >> >>> >>> If you start from the requirement "MUST only use UDP", then there >>> is little room for constructive discussions. For UDP-only to work >>> you will need to ensure that messages either stay below path >>> MTUs, or disallow NAT. This implies significant limitations for >>> your deployment environment. In any case, this is not a setup >>> that outbound should focus on. >> >> MTU is a problem regardless of NATs or Firewalls. Fragmented >> packets do manager to traverse most NATs and Firewalls. >> >>> >>> In the general case, there are environments that have to deal >>> with NAT and messages larger than path MTU. This is what outbound >>> was written for. This also implies a UA that supports TCP. Given >>> that the UA supports TCP and the fact that presence of devices >>> like stateful firewalls cannot reliably be detected, the UA >>> SHOULD use TCP (or another connection oriented transport). If in >>> addition the UA supports TLS, it SHOULD use TLS. >> >> Again, this topic is not really about outbound. If you think a >> 3261 UA that supports both UDP and TCP SHOULD use TCP, that is a >> fine argument to go make in the discussion about use of TCP and >> UDP but it seems to be an independent choice from anything to do >> with outbound. >> >> >> Cullen >> >>> >>> I think this is sufficient >>> >>> Regards, >>> Jeroen >>> >>> Fredrik Thulin wrote: >>>> Hisham Khartabil wrote: >>>>> >>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>> ... >>>>>> I personally believe going TCP-only would actually help >>>>>> deployment >>>>>> rather than hinder it, but I'd be really interested to be >>>>>> convinced >>>>>> otherwise. >>>>> >>>>> I could ask you the converse. I'd really be interested to be >>>>> convinced how TCP deployment improves scalability. >>>> >>>> To name two things where TCP would provide better scalability >>>> than UDP >>>> for a SIP service provider : >>>> >>>> 1) Say that your services maximum capacity for non-INVITEs is >>>> 1000 >>>> requests per second. If you get 2000 in a single second, you >>>> won't only have to deal with all those 2000 requests, but also >>>> with quite a few retransmissions sent after 500ms. With >>>> TCP, the >>>> wall isn't as dense. >>>> >>>> 2) UDP sockets have a shared receive buffer, most commonly around >>>> 64k I believe (even though the maximum seems to be 256k on >>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>> average, you have to be able to move messages out of that >>>> buffer >>>> pretty fast to keep it from filling up. A full buffer means >>>> dropped packets. I've also heard that on for example Linux, >>>> every packet actually occupies an even 2k (or was it 4k) in >>>> the >>>> buffer, so 64k buffer is actually at most 32 packets at a >>>> time. >>>> >>>> And then there are of course other aspects than scalability >>>> where UDP >>>> is an inferior solution, most notably security related things >>>> like for >>>> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >>>> >>>> /Fredrik >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Dec 07 13:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNt2-00039v-Hj; Thu, 07 Dec 2006 13:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNt0-00039a-Pg for sip@ietf.org; Thu, 07 Dec 2006 13:22:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNsy-0005JS-Fs for sip@ietf.org; Thu, 07 Dec 2006 13:22:22 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 10:22:20 -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 kB7IMJfV021919; Thu, 7 Dec 2006 10:22:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB7IMAOX027449; Thu, 7 Dec 2006 10:22:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:10 -0800 Received: from [192.168.1.3] ([10.21.123.118]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 10:22:09 -0800 In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <496F2C9D-3B39-445A-8A67-2D4CB9FB6E72@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 10:22:23 -0800 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Dec 2006 18:22:09.0729 (UTC) FILETIME=[9BC01B10:01C71A2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=918; t=1165515739; x=1166379739; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=aNeNDX9bt++f7cokSSipu4YtN4cNBU9XabLnZaoq/TQ=; b=lWF+tI8+ubh3u47ekU9szH1Ni2r932IcuGVNpV7L1b9P/UKm/HLEgH7XvpmtVtk1taManTYB AEedm2gIfXditmk6CPwgb7Jbw6qPQ+1Vht66bm5ahkbZJJ9GHeMnNav9; 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: 93238566e09e6e262849b4f805833007 Cc: Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > To be more specific, SIP is currently specified so it can use UDP > for requests smaller than 1300 bytes. It is specified so it can > use TCP for requests of any size. Agree with above. Note that you said SIP specified a way to do this not that deployments must use this. > > Some people have suggested that user agents SHOULD be able to send > and receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you > objecting to this requirement Cullen? yes - I object to this. I think the specification should specify how things work for large requests but that an UA should be allowed to choose to use only UDP if it wants to accept the limitations that this implies. Again, I don't see why you are trying to tie up deprecating UDP with the outbound 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 Muzik@bakecafe.com Thu Dec 07 14:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOop-0006Tx-FG for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 14:22:07 -0500 Received: from abql58.neoplus.adsl.tpnet.pl ([83.8.79.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOoj-00065T-H6 for sip-archive@lists.ietf.org; Thu, 07 Dec 2006 14:22:07 -0500 Received: from BBAG (unknown [115.106.143.9]) by bakecafe.com with ESMTP id 3AA94F3CC3DB for ; Thu, 7 Dec 2006 20:22:17 +0100 (GMT) Message-ID: <000901c71a34$f3e19fa0$00000000@systemgjzuf4yr> From: "OUR NEWSLETTER" To: sip-archive@lists.ietf.org Subject: Rap MusicIntro SkitsPop MusicRap Date: Thu, 7 Dec 2006 20:21:53 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71A3D.55A607A0" 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: bdfdd9dd835c9bb499f7c92933fef080 ------=_NextPart_000_0005_01C71A3D.55A607A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71A3D.55A607A0" ------=_NextPart_001_0006_01C71A3D.55A607A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Forgot profile search cnetthe trickscnet tvcompare prices. Dead oregonbush bad iraq killed upland. Ticket sites download hottest psds clicks. Suite targeted at high data plane telecom. Innocent manman depot racial lane, garrison took. Look hand, game = console put paces. Helpclicks albums now herethese require winrar = rights! Extra my loses, its crown rival possibly due. Tape desktop, enterprise = computing mobility identity management proxy. Rock salsa techno reggaeton bachata. Musicsalsa musicmore copykazaa = varity view alladd as alljoin rate. Great oregon, logs onwatch what. = Filings quotes djia sp nasdaq tech symbol. Playing markets charts sec filings? Account majority, usually between. Racial lane garrison took vodka shots. Browse recent december announces the latest in open. Charts sec filings, quotes, djia sp. Phone flop sources hp settle civil = complaint. Neutral not, sunnews inc kazaa muzik. Under submission request two south = carolina fraternity. Garden quake, national, wirepolice murder charges = man suspected. Pp users traveling edonkey cnet newscom memoriam james kimcnet. Jobs, = contact advertise partners. Charges man suspected killing spreestate = official who. Rock salsa techno reggaeton bachata country much, more add. ------=_NextPart_001_0006_01C71A3D.55A607A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
Forgot profile search cnetthe = trickscnet tvcompare prices.
Dead oregonbush bad iraq killed = upland.
Ticket sites download hottest psds = clicks.
Suite targeted at high data plane = telecom.
Innocent manman depot racial lane, = garrison took.=20 Look hand, game console put paces. Helpclicks albums now herethese = require=20 winrar rights!
Extra my loses, its crown rival = possibly due. Tape=20 desktop, enterprise computing mobility identity management = proxy.
Rock salsa techno reggaeton bachata. = Musicsalsa=20 musicmore copykazaa varity view alladd as alljoin rate. Great oregon, = logs=20 onwatch what. Filings quotes djia sp nasdaq tech symbol.
Playing markets charts sec filings? = Account=20 majority, usually between.
Racial lane garrison took vodka = shots.
Browse recent december announces the = latest in open.
Charts sec filings, quotes, djia sp. = Phone flop=20 sources hp settle civil complaint.
Neutral not, sunnews inc kazaa muzik. = Under=20 submission request two south carolina fraternity. Garden quake, = national,=20 wirepolice murder charges man suspected.
Pp users traveling edonkey cnet newscom = memoriam=20 james kimcnet. Jobs, contact advertise partners. Charges man suspected = killing=20 spreestate official who.
Rock salsa techno reggaeton bachata = country much,=20 more add.
------=_NextPart_001_0006_01C71A3D.55A607A0-- ------=_NextPart_000_0005_01C71A3D.55A607A0 Content-Type: image/gif; name="MusicIntro SkitsPop.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71a34$f3e19fa0$00000000@systemgjzuf4yr> R0lGODlhNAJ0AofqAAkLDo4AAgB6AXZyAAAAjYsFjAB7ebe7uMnhvKW780EhBGASAHEgAKEtCbkU AOYuAABLABM4AD84AGw+AIJIAJhKDcY/BNI3AABjAydiDkdTBlxcBY5hBpJZAr9jAO1hAQB/AB94 ADyJAGRyAIZ7AJ1zAMGGC+F7AACkARinADmSB2CsB4ugAKSaALOdA9WqBADBCy62DTzEAGa5C4q+ AJHEAMe1AuS8AAvTDSjlDUPjC13cCnXbCZbjCcnoAN/RAAAASCsAR0AISVMAQYoEMqcCOrILMdYA TAAhThUWTU4iOlQqQY4pRqYfQr8jPt0lNwBMNBdLQEAzSm4yNYNKNq1ASco2QOVENwxVOydaQj1m S2tmOIxZC5FdR7FlNN9sOAuOSBSFSUx/Smx9RYWKPqWOSrWJNNZ5NwCtOiOtPUitRFGnNnqiS6qn P8SsOdaaNgDCShbAQjW7NlizSIe+R5W3PMzBNe7IRgjSRizYRkrqPmfWTXPnOJXVSMzoRuTTRAAC fycKjEQGh1gJc3cNea4AdMcAh+MAgQ0YcxYcezwnflMph3MtfKEZecUjeeITgwA9cxQ7jEhDhmg8 fYo3gqFOfLlMft5DdQNphSNshDVZiF1thYdWc6FZdbdogtNthQBxey5/gU2AhlOHdnV8g5iNirFx huN9hAChgSCgczKgcWChcoWUhqiYibyVe9qRfQDCdybNeUm+imXNhnTEiazBfcLEgeu0eQPXhRze dzTZhFvchnbuc6DTib/cd9/fgQAAsyUAtjQAylMAwIgAtZEAscEAsdkNxQQnzB0VvkQjzGgqvYca wqknxb8WtOAhvQA+yR4yv0pHzGc/w4NJtq4yvMhDydU2tQlosylmyTZstV1ZsolltqpuwbJizNFa twCHyBqKvj16tmV9yHiMtKSBy7eGyudztAKhsyykyUOcu2GrzXSmxJqpuMCcy+2ruQvFzBzBuUHM uGHBs463zZuyvPX5+JatnXiIjf8AAAD2C///AAAG+/8A/wD7/v3//yH5BAAzop0ALAAAAAA0AnQC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEMOtEeypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHVpSpNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cr1KNGvYMOK HUu2rNmzaNOqRdu1rdu3cOPKnUu3rt27ePPq3cvX4Nq/gAMLHky4sOHDgPsqXsy4sePHkCNLnky5 suXLmDNr3sy5s+fPoEM/Rky6tOnTqFOrXh1TtOvXsGPLnk27tu3buHPr3l2Zte/fwIMLH05cJe/j yJODLs68ufPn0KPvVE69uvXr2LNr3869u/fvdaWL/x9Pvrz58+jTq1/PXj349/Djy59Pv779+/jz 69/Pvz/GlwIEeFKAAthD4IEEGijggAgWqFKDCJbUoEsTMuighAuSlCCECaLEYYUYFvjhhSlV2GGI Gh6oIIkpgtiiiiaNuCKJJ57Y3o041mTjijyWmCGKPbK0Y49Dxrjgjkj+uOGPMNmYpIhMttThkizW eGSUVmY4ZZYPwhhkkTmGKaaHTFLZJYtfRmnhmkCSSeObT7Yo50xOlikgmD6+GeScRGJpp4Nc8mmh loSiOeah5jVEYEGLLnqQowRBCilCk04qkKWXBqgQgoxq+o+jmDJUqacDNUrqQqF+eqqqApTqKaaw av8qKampNphpq7f6p+ujq5qKq0Gx/pqqq7+yCuyquSYka7HGNjussqda6qtDtfZK66vIBtvsttW2 iq2wyO4aH4AyluvnhXgKOiSYEa6ZZIohQiilkuZymOeZ9s657rl9wimvmYEiKvCYcbLL755nGolm uu3K+WTAMdVZ5Z1q3mtxm1suzK+8CiesYJqGDiyyegVXvG/DQtKrcchszvhwoTRJ7G7FbnqM8ZUr 12xmxxaDmO7IQAenqLXehrstsRGNyuzR0OI6K7MHRmr0ptESzXTTlFqdrLadbl310smyei3Y4vIn 7bJkc/3Q2cVWK7XTY3f6tURKy3011q4y/XTYSL//7XXcvIL7bNn+sX331YMfuzSoUzMObtdvtz01 3nwbmzixcBcNNeBqRx22591G3jfh8pE7MZT2pk6zzQr/7POfDA7q4sUIU8kxvjizGaHqs0uM+r8q o7t60MSzRvrxyIdW/PLMN+/8SslHLz1mz1dv/fUCT6/99qNh7/334JfH/fjkl2/++eOGr/767AOH /vvwxy///PTXb3/67eev//789+///+65nwAHqBEAGvCACMQJARfIwAY68IEbSaAEJ0hBlEDwghis oAY3aEAMevCDIAyhCEdIwrJx8IQoTKEKV8hC9pTwhTCMoQzf08Ia2nBkM8yh9G7Iwx768IdADKIC /3VIRNIJ8YhITKISl0jBIjrxiVCMomWYSMUqIkaKWMyiFrcYl5fw44tnAeNJxHijL/LDi2Q0iRmt yMaeNMSMCIHjQOR4kS8axI6doWNB5KjHOeLRKH3kom3QeMaUrLEkh8RJGkmySPYkcoxifCQiGxkU SbaxhW/84x41GUiJaFIgn9RMJ+8Yyn+MsiOnFGRsCGnGSLbylbB8JSQLqUZaTpKRrizkGg/JSzD2 UpeUtAcsa9lKXAKTlrIkZi6TKcxcTjKZwzRkLJWJzGheEonFbOYxifnMMz5Sko0k4y+NqU1ylnOc 5UQJOsXpy2mek53A1OY207nOds5zlvPcJTyvyf/ERKLTnOkMqErCaUtnNvOW9KymOYNpSXUu06Dv tCVA6+nNfTZ0ls8M6D/5ycJM8sOPHzUlJ/9Ix1SKlJQEiWUrQapSlsYyjq/cZExFulKagtSmMr0p TuFYUjvCMiE9/WhQQVlKVSZnqDglakiTmspQfjKmM6WpT2sqVaFSlZQz5SMef1rVlQYSqVq16lLD elWd2lSlITWpUXUD1pGOlaRFJSpKU+pVqkLVrnVVa17Nitel0tWvStVpWJn61E4OdZRqXStu2upX pCb1IE4FrFQn+1exAjavkoWpWPnq2L9iVbBbnepbJWtYuG4WsnFVLFtNG1jOptWtfpxrTlvr2tn/ PvasoT1tXxsL19aKFrSvDe5kBxtYxsb2tqqFDSEzasyHupO5B4WkNKspUX8u0rrVdW43s4lLh3JX nvek6Ha1m1HsjpeaHF0hUhIr100m971XYSVa50vf+tr3vvjNr373y9/++ve/F01vE4/C3sjC98BU EbCCF6wTBDt4kAyOsIQnTOEKW/jCGM6whjd8kgd7+MMgLiKHR3zNEJv4xChOsYpXvBQSu/jFMI5x AllM48jI+MZBrLGOd8xjI+L4xzzssZCHTOQiG/nISE6ykpfM5CbXBshQjrKUp0zlKlu5wU7Ospa3 PJkrexmBXA6zmMdM5jIr78to9p+Z15wR3wSA/yRvPkmc4WyTORdGCkTB80v0DBQ+m8XPOQH0nnki aJUUmqMNCQBBFD0QRjOF0Y5utEAUHelET/oglYaIFAiy6YF0+iGfxkioBTLqhHS61BQ5tUNQnWpS H4TVC4G1qSPCalSXWtZHwXV9Is1rp0DaIL2GyK85Eupi03ojt151R1TdEF2D2tUacXZBpM0QWxuE 2h/BdnVeMuc3dxvOAQh3SsItbnt4O87ktnNJ0r1uOsuZzt82N7lRku5zx3veMeEznvVNEin4u9D/ 9ne//42SfQt84AcPuEkMrm+C9/vh9lB4xEuiZ4kvXOEOj7jDLY7wimvc4w8POMMpPvGMi/wkI//v OMU5HvKK8/vjAk85x1MO85Z73OQb/3jBCc7yiZNc5+z7ttBNou53l9vcRGcJut2ddKQvHentfre8 o+7tqA865CT3M6C17nOIrzzrC/f617H+85uHnd9cR/nAfx72rhta42CHuMvLDneyi73ubrd73uue cL0bnO4of/nZ0Y72wbMd8HfnuuCL55BfDzvYCKH0oiefkMcD+9KSv7SkCzJszWdeIqpmtrE5TfrR e7r0pP9Hsk8/+tCnftPMhvbrUz97hcB+9p+OvepdbWzTy3730wb+72Wfe96j/vTCR/7wd9/74xtf +cj3ffJv353PZ77ema73P3itfc6n2/OX3/7/9rn/fc5rHvzjz3SshU99kY+6+dCfvvyT/3vYixza 9g/4891/7fqTWv/093//Nn/UB3ytJ3/S13r6J33sF30IWHu0Z4AL6HzMd38MqHvv93r+phswUXXw xnTjlnR2VnRN525P13RVF28rcYJQp24kuBL7FneHJnYxeHhuV4NyV3BnlxJmp4MgB4M0eIN3J4Rp h4M/6HM4WHJtd3hJ2IQ66HU96HdDqHg7GHd6F4RqJ4RLmHczODCNJ36Yd35guHnjN4ZmWGmOFm7o R3nXJ4bZ54ZhuIZpGHzFh4HB93/zB30FaID9x3q1t4fF5393CH+qp3vEB4h6KIiImHsZ6Id4/8iI fdiAzOdpiBiAhLiBhDiJjrh8dkh7mOiA14GGi0ZumKaGnzdppAhspriGm2d9qKiGpRhskAaLYziH d6iHA3htn1iIG3iLEtiLeEiJuciLgXhqwzh9x8hpwPiL7Pd+n2h6zniACriHxMiI7beLngiKA1iJ hRiBxnh791eNwtiJ05Z/traLw6htbAYb6rh+U9GO7hiB63g+8Gh7VFGPs+aL82g++KiMy9gUALhs kbiPBFmQBvlAaZaQ+/Ma/RgShpgUyZiPr7YU1gaQDplDe9Z3a9GFN3GELMGRPQFyINlnNvh2WTiS WVgTAHcWKKmSOKZsy2eRHvGQCNGQxxaAuf92kxD4bK02kEphkzWJkVfHcjh3cDXXcmuHcDsXcxnH hEoZeDxnlBI3c2znckZZlYDnkTQ3lWWXc1dZczFYlF95cmK5lEypckQIdEjYlEh5lFQoloLGlWD3 lTBnlQ3Xd3SpYYsHhWnZlUlphE+Ydk65l2tZkh7ZdYVng4InkomXmHbnhHmJmHjnhCfpmHs3d0Go eC9HmWPXl22phIpZhZ+5hZBpeDBGmFsnmkiIlV14hKlphTyIhW23kmEpm3MpmatJmlpYg1RokqAp hSepmnFpm6VJd4JJnJ75m1wonHuXmczZkhRGmEDnfnX5g5uZl66Zkmu5krspl2pXm9Xpg7//yZi6 SZ2gSZ0zaJmciXgld3LBOZjM2Z5EWZ7PuYXJmYT0CZv4SWLSCZtDiJvL+Z6JZ5/DeZ//WZuH+Z3j mYP5qaCXCYRSeJwMeoWB2aDKGYWxCZ/6qYUaSqHOuaHQOWGoCaKzyZqGaZuICZgCOp4JCqASypdZ qZ2cuXj7aaJWSJfZ+aLZeaOUuZ4cyqKeOZaiGXO+SaQkap/81GzA+I/p2KRLqnzfWJPm+Gro+I/C qIEFaKWBKIC1loh86I1c6o25CGt1iKU4eYzfWGtM6qQVmI5hqo8BuY0EiI3jeKXU6I+/aI2GCJQH 2afbo5CAGqiCOqiEWqiGeqiIehN+uqjv/yFr+GiTfKpp8TiR+gh61RGp2QET7plv50GevumSOtGi QsGR3FmgSJqhIZqhNpGqQ8Gq/3l12vk9zVaprkGT8aeTFoGpMCmRlCqPPNmQj2oV9QiPFRkfarqk bpp/43hrEbmlacp6xlinbRqJxSiOzcqL0mp/dIisvaisXCp6Yzqm2DqtbyqO5fiMT5qnyeat/oiJ 3HqOaaqtxJitEUl80Xet4tqt4equ3Tqu5gqtelqu8xqQ21Gsmoh/3fh8MRl/zjqnwbiuW2qvCCuB DFum0EqltyqvB8uHjpqwFbiJG9uIlKiNeXixnBiMIXuL4JqIByiRFjt8T5quE9t7L0t/Mf+7k6C4 sE+WkTm3oRf6o0+4g7xZojAan0KLmzvaocqpmw4KnDV6pBFKoDKagzoKtLkJnCf6oz3aEgiKor2J hTlqtB86oUT7qsQzEebIr/lKgcyKr5rYspJogb4KjnEriCwrt72qrg/ogG1Lp4uItzDri6JXsgpr if7Hf+eas9WYtrbqh9dIsHv7reA6gSArsil7pnYLHndqbZlouev6thBYs9zouHVLuJm4sJ0buRwr uKq7ufLouQh7gYT7pYVrj7RruD7Zf3SLkyzrq7d7uK/LtjFJjtqRgambspDoicUasbH3sn7bqy2b gMLbpZv4vMlLjZCYupdouQSosFo6u3b/KL0zC6ZwS72SGLiV+4fTO7Lki7MTq7OXGqdOKroCaIl0 CqXtir/494y+y7xXyrBYaqvTeLlymqf1m7bfKq3Y2rfdy4yfe6v+asC6WGxr+q7KyLvM26wAGI0U PK9zir0BfMHl6MG8ERiuikCmCj4nHLQaVhW6WrC5ixyR+sJRBLmEs3q7QsOMusN/mqg+/MNAHMQh mRYrHBQAF5ksHJJIXMRGrBZMLBNMHKJPrD/EBsHVBr8C+btVbKm0art8qms6XBFhnI/9iG0de8WS epHI4RNFLKqtarZokcKwOsRce2csCcdz7BKtmcd6nGfYM6vzG6bPSsLL6q9xmrDfK7EI/1yvNvyx Hpul5RqOdSq/6QqO78rAhDyu7HrI+qrA+Uuu//q/1drJoLzBC9ivWAzJ80um24ivFrytAVvKbJrJ uJGRPmuZVouZP8t3WomVuSmVH7lzf0m1Y/ugBrqawCyhRRi0fzeFf4mhe5zMUvuYz/yZBarLKgqE DeezJqnM6hl4IPrNm/nHaFy4zWuzcwu8ORuxxgfJt3vG2Ti+4ZvOrRu7wgumuOuloZu+s3a8GXu+ 9DuIisi7+uvPlCq+5sy62kuBWEwdx1uzi9uHNLvB+ot67ky8Cayy67yso7u/p0zRyBu8iivKAXzO vCfJhWzQ9eu9+DuNqCyN8TjPVvy+6P8MsMm40Datr+xcvPcM0bgm0xp9srv7pQidz9UKuqwr0LTq evzspR370C1tuwnNgHxb0YuovlVteyCd0GQs0rWr0Ovb1d4B1bUru/UM0NCL1ejrsVZtz5GbyGR9 1Sg70Bq9vRJ7uVAq12yN1m1t1++szwDs1xVZ1B2N01O90Tx9r8tYpTp9rCF818urvBd4v3x90WyK w5Q8ymaKyWeKyh5Nu8XIyPyr2Pbrew0ryQUcwf4Lpx+sxY+owYGc1Fstwap9pzs7YlMMHCg5xbmt qszR24lCQmPcFtQGqSIx3DLJgXrJlurRkk8M3DHGw9I93fMoxNYNRCOZnjsB3VyLxNf//UNz4Wyr J22DnbdoG5S7mhFAidzUrRjiLdHpPdJGUdxawd7tnRCwep3Y6ZV2yYNyaXGb2nFbuXFNSZbArJam eeAEzpR4yXBXGZZSydzb6YMRnnBs6Z1KaOHc/d2CsZhWa5pAu8xNa8wHXrazOc6oiZlR6KntaeLN vMtDCs5Oy8KQ6eEcHh1d++HcHKBki7Xsec2oWqJ7DKP7GbYufsyqObUibqE+euPQkePmeXE8J+UX TrRkiaQ76p6lauXY6ctW+eMB+rXyydxfruQmXsz4KeFOXhrKtrvwjNd5y9RcvZOVWN4jjdl3TtMg XM8/zdr8jMMhbd73vRCcWrQ8bqRe/zt2RrjoFcqjBwq2AOrLyByj/mmdxenMeynmh/m1iI60a34a PImMVrrANiva7XfAqD7Bm82+eKqNo96wzHiInj2ycurSB53IHt3Bn0zq0TjTgx7ev76O9h3sDtbI xD5Dn57s0HHsa6bszv7s0B7t0n5lzG5m037t2J7t4VPtZabt3m4Y3E5m3z7ughHu5n7uH0bu6r4W 6N7u7q5a6x7vZ/Hu9F7vWSTv+J7v+l4c9t7v/v7vAN8f+z7wQRHwBn/wGUTwCr/wDN/wDv8bCB/x Ej/xFE8bD3/xrUER6icRGy+GHi8SHT8RIZ8UI68QACARJ98UALDyC5HyE+HynAHzTP8h8w1B89Tj EtjngTPBblAndUX3gjrB8y24gjHhglJXZyBIbycBAC7B9Pbg9DIB9UEh9SVB9Sth9TFh9VivElDv 9FtPEl2fFloP9mbh9VmfI8JGeWkvaSH/hh4hixwhimpvEW2P8gJh8y0vEjaP9wbB9wzh93/f9ya/ FYCv93bfGTIxgvLWbfhWgiJ4dE9Xb06Hbvhmb+t2dFbn85N/b5Xf+EaPgp5fbpYPb/Mm9Orm9SuP Eiu/+k+f+mDP+qr/+q7P9LO/+qjv+q1/+1Jv+7nf9bzf+2Rf+7g/9rQ//MJP+72/+8Cv+8GP+1Wf +80v+2ZP9k8v/WZf/L4P+yZR/K//X/Xab/vT//u/X/3MM4JDl/k9T3T39oHtBvmP3/7o/4JL5/5O p3RJb/SKL3Trn/5Ut/TkDxD2ANgjWHCgwIMCFRosyLChQgAJE0JsOFAiwYkOJ1qsuBAjwocaQ1q8 eNHjQZQdT3qEaNJgSZcUP8qcSZLhxpEoU+LESTPkwow/hQ4lWtToUaRJhQZoyLQgU6cEo0r9OdXp VXtWszblqnXqw69PqWrdGpbr1qYB1K5FOxbsWawh494kmpKuQ5Ude37kOfKnXb56BQsFfDfwQ5OF AXM0zJIl45k1V/aE7DOoy8qZDxOOrNTzZ9ChC/4jXdr06X8BTKsurXrt2tOsY68m/83aNW3ZqV/f bl1bLerctFMP7z08uG7YxIv3zm37t3Litlu/rn0aAOmI11Fr1479X/bs27GD/266e3nwEcd3P1+a e/ry7r/Dbw8/vvn78cN7588d//3rzgvwP/nkE/C/Ab07ED38FiSQvfnIWzBB88jLDzUMM9RwQw47 9PBDEJeDjrcMjxuxOuNwE25F6Fo0MboTU2RROhZlRJE54Whs7kb+CkSwQQ4pZNDHITP0T7wL8xOy RyWZVJDA/go8MsonDYSySQf1A7DJIrtsb8sqofSvvh9DNPNMNNNUc0ccReSRRBht/I3N6naU7Tg2 pcvTxel45NPONlHUsc8WKfxySv8vxWNPyEWxlBJDRA1llMv5nEwUQjCnVG/LA7N0lEhMw9x00kat 85FU98Y0dTxL1XT1VViVIouqrNiqylay4mILKrBwhUutpWxFi1exhsUV2LloLfa1p4CtVdiokEVW 2ZoiIsxajbL7CyNrK0OIMfBe2igjibTlFlxzye22s82Awpbbk0iCbN1vFUMsXMfw7UwncB8717GV qn1XW7vwJZhd0RJWeGGGG3b4YYgdNitiio8KqmKMMw7tYo237fhjkEMWeWSSKZ645Ig5Rnnlh1UW 2WWWYx4ZVpprtvlmnP3Meecg9+P5Z6Bp/jLoCjcl+mikeZZ5aaabdvppqKOWemr/qqu2+mqss9Z6 a65XTvprsMMWe2yyyzb7bLTTVhvSmxFNEs2hiY6bSCSvXPvusudOUu+g+U7Vb7wDF5zuvdV0G/AO 3e47SLYLtzlLwBG3G2zJDW/80LoXT3xwzjsPEfM0DxdabL71Br1myD2svNWvV4d7w9PDjtxz2gO3 UL/b1wvQ56IxJdNnC3dfdL/3RiU+QgWNvt2+3tFTvj8JK41wTKMbL7L4QyU01Lrwcv97eOx1Tz78 5p3XdLvukaeSeSt5H/97+HXP3vjqp2dywPpr1z/Dz3bKSyS8eKwwIEGYTdrlv6EYsCWN0cz/CAiU Az6QJzFBjGEaqJKBBVAyGqwg/7kqeJPEFEWB8/rgSwB4QRBqMIN9YWAJIehCzbyrazPcWAQ/uBcB sguHEaQMwAbDwx/mC4aSYeG+/JXAw9jrhh3MIQeDKMQW+jCICHRgDy3jlx0W8YpZxKBfWggzGl7t Q/aZ1Ko8Nb0jkUlK0bPSo+annk41iD5XUuP6PiW/MhqJU3hE0u8uZ7c50jGQVOJe+tyYOS6pinB5 vB8ahWdIJ00oc6jaXyU5ZLEu7vCFOuwiFIEYRW9pMYZe5OT/CuYvTWryh/2qCycvpsQAhtKFRgSY KNtVyg2i0IaxrCUpPblJXmoxjMNEIrxoIsMN4hJbAywivTazTE86c4ur9KApif9oQhw28JWToWUn HQhAZcrSmlbMizQpiMsXzusyRwzmFOM1xF5a0FvEpOe9WHmwnNTrL/RiJgbXRRl+notfLUmXvgwq TYEesWD/tKcSOVbNhO5zndfSZ07QtcyCYtRcxhTXFRGWUCsOdJ1czNbANorPipxUouXiCBjr+VKY ImWiMa2YSzVmU6XglKY75SlBLDm22P00aa7bGVFhJ1SkJlWpSwVRUJnKM6PiLKp6fGpVrXpVrGZV q1vlale9+lWwhlWsY8VqT816VrSmVa1ZI2sl3de5qbZVrnO1atziyjigEi50fyTb3JxKV8AG9qt3 FRxhV0XVvCJWsItlLOeWp7z/56lPe6NSn/0sa6rdOU9863nfZu0XPd+91bLee2RlDQRZytKPeuED nqIqG7zWGi9+jaVtbY8KId9lim3Pq2PhIAsqTuEWSIfdnqck2cce1SdUpwVuZM+nR94eFnesSpRt rSvW/v3ylj4cpTWZyMvGoPKJAWMlOgeYy2IWkJ0ePe+2hEnOknxzrfOlb8PGCNvhrTFUg+ySI10L KjJS9rRsfFCV0tNbxWmJs9LFHqP4q6n8DTdMjQST+UR7XQy31bhm5PAd+1s6Sr2tjRO2VG4TDNy3 KQ7BHo6dijVESRTvV8QZprGGU7XHKOUWQDCmsIRDXFwfL6nCy11xigm54kal/+64y8WsjxN5qifX WMpMlSk/TZoYGXaLoSXl1zazeFKNXpml5QpYRBvqRDJvVFxX9klF96Jll2kzo5jhshPre2c85zlh Oq0an/X8Z0AHer5+nhqhBX1oRCc6jIaOGqMV/WhIR23Kk6Z0pS19aUxnWtOb5nSnPf1ps0Va1KMm dalNfWpUp1rVGAN1q139as6tWtazpnWtbX1rXOda17vmda99/WtgB1vYrIZ1sY19bGQnW9nL/umw nf1saNuX2dOmdrWtfW1sZ7s00eZ2t739bXCHW9zjJne5zX1udKdb3etmd7vd/W54d1vb86Z3ve19 b3znW9/75ne//f1vZcdb4P8DJ3jBDR5vgCdc4V49eMMd/nCIRzzXC6d4xasqcYxnXGYW53jHLalx kIc8ZB4necmzGmHKGXZs/OBH0lh+mpdvNeYZmrlpam5y2x74xmZDee1u/rOb//yqQn850VuOc7la jMwPXBkyF+b0PauM5UKZekGqHpqrEyTrO936Q7puj687LOwiL/S4mI4yqEe9ZVLnB9XbbvW3Yz3u Wp871+vu9buDPe9i3zvZS6Y6AWXWs/L7XuB7zkfPHtjwqlVtz4jHPtKwXPIxn3zlLS95mB+9NEE/ OuU733LPRx70nxc9zSdv89P/o+YzT/3mMa96y5ee9ZUX/etRc3nUz771SE//m9JTSkCMmhBeJjVm 2iWok+IT//gcBb7KlG98ycOd7g25evT1Tv26b73q23/71Lk//e9fPyTV737cvT/38JMf/Oo///TX L/3xq1/88vf7xhNXKjgGHlKCr1D/0df/6sk//+Me6pKeAoSd99CQ1SM912tABzS9zJM9zCu60aNA 2IM9C7w9zVNABgy9Bvy5BbzADJTADgnBELxA3vspnWMVxQMf+ukd7zlAAbyxAHTBBMSjnlvBnjvB E0TB0oNA1Ms92qu9IcTAItTADSRCD/S82APBDbTAEURB28MQE8Q9H0xBtfG9fEo75fuXs6MobDK7 LEO+5BM+o3g+tsM+91vD/6wbO+1Dv8uDO8uTw8orCusTPzycPPjDu/hTw/ZrQzjcO0DEQz6sv6uB Oi3bp9+7ly9UxDD8vTFkuuBjvgQyu0Zcw/mDwz0kxELcROu7w08kv/LrOz/URLqjPzXsxOv7Q1NM RVVsv58YO0McufvbvwKcQeT5LQNEuReUHtmiwfwywF0cGtQ6wAh0wB6cvSD8wQdExiT0QGc8RmXU vWV8wCUcvSDMQCb0QWW8QmiERizUnwhDLXJ8PN6BvEICHnX0P8WLH3QsPHLUwGpMvcubQm58xiSU Qnxkxh/kPNezPSvkRyUUQn6EQs2LPSN8QgZkxiPcvXB8SJ4ROircR4isSP+IlMhjbEaL3Ej+MThZ nEWQDEmRHEmK4UiTPMkOIUmVXEnPmBWTCRlhOQvROJmHiUmkMAubZMmQ1JWMocllmcmqoBbQ8Mml EMqiDI2wIEqdJLtoMcqalBWglAunhMqoLAqlPEqZXMqRvApmgZacbEpaYZaycJZnEYuuzMln4Uqy TEuoIEux7JVp8UpnacuxeMuv2I2uKEupeMu9lJa5rBWt1LhcaUqXbAvC7IrDDEvFLBbGHJagBEy3 aMy22EvJHEu4UJakpBa6jEyjTJbNDMyMy5W8rExeIRavGM3LnMy7TM23UE3XzMrXRM3FLIvHPE2z hE3HvE3QFEzWHEu+dAv/08TLwQRLtbRJ0ZRK19yN1czK4iSWn+TM3nRO2iRNzZzM3XS3D9mTQCmR FKGRGZmNOHmRN9GZOKmTDQkOQNnO8oST4khP83ST8rQRlLRI7XxP8rwTEYETEhmUGMnP+xxPOvET 95wT8AzQHOmTAcUTAJ1PkksKq1jL4sTKB51Lu3TLZknLW7HQDP2VtWyWaVmWuGxNyJyYaAlREJVO zPSV64Q3EBHPZHNRBo1RM6HKbrvKFdVKM4FRWNNRGe1RH/1RIA1SIR1SIi3SajsKGyWKJJWYhVnS z0gWJL3JqWwYn6TJzBzKGyU1J61NkdlSEU2Yk4FSo7hKMX1KJeXSL23J/ywVNS9NU5Bp08qEmDI9 0yi1Tjm1SjrFTRpd0/nyENd4DuTQE0DdDUFJDuowjuf40ztJjkDFE0NFjulg1EiN1EVNVN8YVPt0 VAJl1EMNz0fl1EPtVEKNDdhQ1Pa81E11DkuVVB41UrnC1NnA1D1x0T9lDvx0zxaJ1VutkV1Vz1wd FPzk1WA9UPmsVfss1v4U0GDVE9wYVkT1T1etLQNF1lk9zxPBVf20VmwFT/9U0AIVlF/l1nCFkW0t V14VV2BVkW79zmjFrjHl0A+FTqxIyq6UzbasV9LEV3mVi7/UTXjlyemEzeHs13vdFXtlS+lczsbk SdvsS4NdWD6lLz9V1/9jzVb5vFaKvdhkxdjtFM9sVVDtZFZx5Vhw1VhzRdeRDVmSHdfxbNewqlPO jNeA/UuFldmETc4LlUmbNcyaxdm3KNHZxMkvdU6C9dmYvVmgFdjUJNqb9dfXhNOIZasOyZNNzREC jQ5DTdWsBdVBvdrVqNr29NpJRVVKLVTe8M4XoQ6qPVuz9U6sPVuu/dVSJVZVvdhQXRFndVmtmpor RSuovdOt+duovbW+NSvBNdOsOdzBxZrB8dauatWg6dTagVy9rVzLvVzMzdyFW1zO7VzP/VzQDV3R VQrNLV3TPV3U1Z/RXV3WbV3Xtb/UjV3ZnV3arV3b9bfXzd1du13exTT/3f3dW+td4aU04C3eWRte 5K0x411e5m1e531e6I1e6Z1e6q1e673ecEte7d1e7u1e7/1e8A1fgMNe8i1f82048U3flz1f9oUp 9X3frmpf+Z1f+q3ffCiZfMjfn7jflclf/iWZ/y2KAKYhR/vcAD7gpRngh1FghmHggnBgglBgCIaY Cf6YCn7gpEiXpWkvjyGmbbI1D8kH0xDh0iBhszHhnEFhm1Hh02DhEUYNF96ZGE6aGW7hz9Er2WEd REIqYuS0o/jf+wXiCPbf/SViewhi/vVfBlbiCMZgJUbiIdbfJpZiKT5iIz5iLG7ih3hiLKZiI2Zi JrbiK87iAQbjMdZi/zL+4oYoYyIOYyheYwwW4ySG4zd24ioO4y4W41aqqBQ6PjHjCzZrKHlZMzMj Lw3mIINpPqcb5IiCiTGEs5lylwKupxAu4X8wYRFG4RrOZEx+YU8mDRLOZEu+5E4e5fwF5VC+ZE8W ZVC2YUs+ZQxJZVU25VamZVfWZFdWZVzG5Vt+YVjOZVZu5V124V8O5lnm5FG2HmK8QUZKnhEDncgq kwKLIxx25h67xSdjMkK6EGqeMdpKZVnm5QwxZnGu5VoOZlk252NOZnI+51n+ZF3WkHBeZXVOZ1tW Z2Gu53feZ3d+ZXleZ38OaBj2ZXouZ+JS5hHzLSfrsBJrlQTpZm9mJP8k+xFtVrBIWmgaQ+djfmIY VuJ9fmIVBulkBmhU9uh37mSRXmcW3uUWNulQ5miSjul+xud4/mib7mWBHmh7bucYHmaXvmmErhvc CjBIwp0eTqTg2a1GOqMHg7xOYZ4zsmhuRpDD++aTlulcrmmahmeB3ulYZmd+dueVJuiRnueBvumx BuqAZumRnmmt1ml9Zuuzzme4busCE+qEXmo6Qq6ETrCHDjIGC7FJMrKKjpTAnhzb0miv/uRTLueQ Luh7Rmuw5uVSBuZ2RmW3NmtSpunFBmay3mycputxLuuTNmZ4vmzUxmvVvhQalDBodu0TI7IdIy6J DmxJKuxrnu2Ktq7/xy5h/43lxuZnk25pWK7s3x7h477qc07uyibutyZldObkYvZtViZm6e5p5C7m 4Lbs4t4QTWbu4MZuU2Zu6J7uotk5KIOeYiyjCztHzioVMVFHIUsf5cqfCTme5Mqeyzrv4hGsU7vg C46ZAI+YAafgP5vk+q2YAC9w/G1wB8czBE9wioFgPJYaBneYC8dwPYvwiINfD/9wEN83CR9xMSqq o1G5ZDMqFN+/FRcswmpxTjMsu/JmxN5hTGtHFQcaGDdx68GbF7dxZpPxo1KdMWq1qCbyn9nxoRqc H5cuGqsyaAIzNWtkDZ4zA2opaAIhSLYoeXmlQw6MRZ6zPl4hMnSz/29ZKTOTcpeaoDED5MUooS7r JpCqcoiK8/VK80CW5DmP8j/m4zGn8zGz8ytXc3XZci43IgWiqTPhv2ZGMh0LwF2MMqbObYjmv71e I+piZkWy5ql+MRzTYQBbpEh3sQlrZqm2dCir9Nt6ZlFx6FE/bPR+6r7GEtmedMFW9aomKx7rLRbb ZtZ+FME+ddvG6E4/MmD/9Oqq5g+rcRRr6DiaccO2dYhusl73dF7vL8J2sg1rLsBW9Vln6GL/da6C cnO6c4hiL1dyJ0mecmA69+7yJYXCizf/JHQSqIGqF+MDL4Epd+MrL4/ypjYbDFsSZC88c4GR93B5 r/SAoYW3pQN7jP+G/yZYQvTxUvTNmfVt53Zg96NvP7FjD3ceu3RjH3lxD/dbp/HBxngggXa9FnUP o3Zvb/aL7vRo1/Yhb2iVh3WZ3+aJzuuswqTho6ZZGvh+aqZTQmQ5F6+g72BaorMye3ftSjNQSi+l BwkWeqh2osR2l6LIMHo4J6EQCqF3eq8qGiehH/hnmiiSSnuuf6n7wh+qnm9zNOwFG7D1BkZeLC30 uXu/mvv0tujQErASM0ejni2/EpP3vqOjTjw4Emr8VqzHkvuHLkb1BsDGv+/Gc/Kk1i+jPhz5TjG9 T8e/wfYQd3HSKX0MIXERKhkOV/3rbf0Mdn3Zn33ar31BQ33c9zT/Jc+Z3Ud5vfKb3jc20SKqCwPy Vyl+4j3DWfIMDv6onPooMMKp6N+z2Id3po+Z9oL9pnOYD/YzPmv+7NI1JFf2prr549+rItfx8jd+ 8j/9Gjtq11mdFg/+sQL6OvNCRiaoLkdkKXevKQcIAPbsASg48CDBggYXIhRI8OFAhw0fKox40KFC iQIlQsxosaLFhAYRUhwpUiNIjxBDgjxJ8mNLliYbphT50uXKjTZLRmzp0yTGmjEvpoyZcSPQoS5V 4uxYEqVSlUxvUq1q9SrWrFq3ciX57yvYsGABiCVLduy/s2nTqj3rVuzXt3DRtoUrt+zauHbj1kW7 tm9Ys3UB+zUb/3hvwcJ59QYefFjtXMN0J/s9vPhx5chsM19+63YwYcl/FUMWzLk0Y7yb9aJWjbq1 Z8enLUOea/s27ty6d/Pu7fs336OdLw/PW5vxccy37yq3zRw2a83Qk3u23Nx48cyiRy8fXrs1bem8 t38P/zw7d87p15dXvNe7dffR3ZNHXzw58Pz69/Pv7xwvbIndl5pwxLGlUHCaGWicgK7FJ9d2lCG3 WIH1HZjYdAVqdyGGdmV0n4BHHcdcYQ02hiB4wSFI4HUiJvgie/ZB995rGpb4oYvYvRbfgP75+COQ QSooIXEWQhjeg6ohqWRq8vUY4XwTnhfjjqThViWPWBa54JJZMv9poXrcaYlfkzq2+GWZExKp4Ihs wjebk0LKOeecWXFE0UQareQUnwmFdBFROb2E0U06/Qnonij9eSegHOm5KKGKSjoRnohaWulHJE3a k6CODnpoo5fmZCionlbqqamZquoUqpReSuinicqq6aGk8mkrqTPNymhXvfr6K7DBbnVnUEkVC1Sg FcFKk6FKjUrrToPqquyiVOH6KkMdZUvtUYhO1dNPxharbbPiFhoopc5y6ypRI+nZ7Z5NhettTaLK a+1Mx54LLlSPXmsTo0zxKizBBRt88MEDI7wwwQoz/DDEEUsM7cQVW6yVwxdrvDHHFHf8ccYfizwy xCGTfLKvJqP/vDLLdrZsscovyzwzqDTbzGzMN+tsFZ09+/wz0EELPTTRRRt9NNJJK7000007/TTU UUs9NdVB7nw11llrvTXXXXvdsso5C0tssGLXHOvJZoNd9tdXqc0uVm+f3fbCUpPJZJj+tfcbiePp dvd+H+4GuJyE92Z4dz72fTTiifsN3OJVFz1z2BqT3euyXIUsd1WpWsV52mwjDLrBoOesduZ0jyyV T366jhS/7bo771OhqiuUuGTjHvtJSPUL06oB8+6vs/by3ru0s7sbbZ5B2a5v7KZCLz2yj75aO0wL RZWursNHC2/znHovU/e+A49Tt+FGOq7qDXvs/Ouuf9pqqOez/2r9udXDXT3+sOrfKP3ihSlM/Wtf 75uV8QBor9mxRH60ulwDA0jA4B0QWbfaX54SaL8Comt5D2ygqPh3PW3Vb4MabB/GDiioVc0vgyWs FQsddi3Pycpz/nMhC1mVv3T1SYDGkyAEd7hAS0Wqc/GSXg1x6C0BAhGENJTg55I4xGp9sH8VZNcN X8hBFIpuhNazFfJQBa96RRBuYVRiEDmYxexRi4e8+le5vuWqNsbQY/za4gp1iDMwIrGJ38uhFJ14 xzSCq1Ae8eMc6aUsR4EPhjYEIRuz1S4uVmVwaKIQkcbEpSiZCU6cBFOTQHmkNW1pPZmcD+LKo0kv nVJJfRFlKf+ldCYkQWmVo/yPJ0P5pjQBpj6iudsq1aSlNBFTcoW7ZC+z0yG+7NJIMhqLL6GJphTd kkqu/A94QkNMTbZlbwQCJYtkWZlljrM6EiLnXagjzRlNqZyYtA4502OicMpTMu3UJTXV9EllGjNo ghPcO02JogR9pkErytCKytKhAEWoQgo1UUIZFKJrsimipUkofiqE0XiqiKD2Cag5oWnPgy6zoN0c aTIjs9AlYSiiIpWoSg3DUAOldKCvdCmHygTQA9HmoA/tZ38oaUahkk6oNCuqUZOqVK4h9ahLpWRT nypVmwEVclXNT+OuqlVLbrWrXl3aVMMq1rGStawt+ypa06r/1rWyta1eNStc4yrXudI1dCuLaty6 iDb3vUxueI3YX+sq2F7RiXAZVVwxC8ufvmWVR5tEWmOxU7TIPtatlr3sP0oGrKKmbmKcU9jbhNdX zM1NYqgbLGp1JpXvybF1Oznk7ph3R9YaS3Zoexdt37ha5DXvd03pVG6pyET12dZ8yTuWcdHnwBUK THm+W99slVva1FK3YrCrYyIn2MPr5pFeWgRuCIkovy32cX+4XSK04DfAXIV3iMTC367Et97lViuA a+QJDD843ery92EzxKB+efhdIwZygAi03XYPHN8norFm7B2wTsCoYAMzGL1NBG2CRYtIJgKyvx4e 3SEbrCkL/7pWREfsXoa5h1zhRdiRAC5je7EbsEeWV8ImPiMWVZi550qyhb1jH7nouKvVBvbDceXq PlPkIFq+p8lOAieUACSmWW4oRkmaUXNsOZo2TfOSVT4Pl8Xz2GrqspVRxiyaLdvNZu4tpNUEE5e5 2UqK7jKWE13zlbskTCoTZkNr9iag9WlNx2Hpzcr8pTbTrGigYowh1LMxifP13FKhmHnQC64Brfjb Sfqvx0OWdCIfnaqBNTeOeJyKUcZnLZxNMllkLOS4NG3kWdO61kYtsuZsreubLLrXvgYaZYUU7F8T W2i7PvbVcD0sZDO72c5+NrTpWuxpU7va1r42kKKt7W1zu//b3v42uMMt7nGTu9wzwza6063udbO7 3e5+N7zjLe9507ve9r43vvOt733zu9/+/jfAL2vugRO84AYLOMITrvBFG7zhDn84zxYu8YlTfKsQ vzjGG17xjXO84x7/OMhD7uuMk7zk4hY5ylOu8pWzvOUufznMYy5zuJi85ja/Oc5zrvOd87znPv/V zIMu9KETvehGPzrSk650/fy86U5/OtSjLvWpU73qVr861rOu9a1rfele/zrYwy72sWeW62Y/O9rT rva1s73tbn873OMu97nTve52Ry3Z8673vfO97wu/O+ADL/jBE77whj884hNvVr8zvvGOfzzki634 yfs88pb/v7ycKK/5zXO+857/POgJhvnRk770pj896lOveqCFvvUGXz3sT+/62dO+9rb/WOxzP/rb 8773vv898IMv/OETv/jGR7buk6/85TPf6C3bBPS7Av1NSHX60b/K9IWVfZ1t/2rd18r3P7+b6YuF /D8yf/mtD32woL8/7Z/L+3sWf/av/yvz9839hWT+/Kd/E+NXf/3xh/WFxf6tH//BXwDexvwNIP35 n2603wEGXVaEX/gFSwXaw/Zl4PURzAUiRAcyzAd23weC3wZKjAZS3wSWYFWI4AhihfodxAlioAq6 4Ay+xAW+4EC0YA6WoA6a3P85YAMCyQIGIPlFIFrlH/oZ/yFuKGGQKKERvh8TwoX6BWH//UYUSiED /oMT1t8VvlwKoiAMbiAOhqH1eSAA3gQLUh8AXl8MymAZ7iAYjmEanuAYouEbumEFrqEemmEIriEf 8iAO+iEZ4iEdimEN2uAMZt8Z0uAbxqAiziEYuiEZpqEdNuIhIiIKft8iwuEdLuIeTmIcsuElHtkD JqAWcqEBEiEQFqADDuEqpiIqtuIUnqIs1qL9oeItymIQMuD9FaEqAiEWvmIs5iIt2gYvDiMrEuMA JuEw0h8VPqEpFmMWlqL/NaMvVuMvFiMxnuIzRqM02uIPbiM3bmMyjuM3WiMs5uIsstsX7iElYqIk wmElDv/iO3piDT5iJA4iPL4jSdTjJfIjPupjPxqiGhJkPPKhPrbhPB6kVeRh9PUgPT6kKBZkJxok QybkPUokRW6FKK6gRgokQlKiP96hrlHgR8ojJwYkSg5kJk4kRloiSaokS4LiSV7kSiokPN5kTd6g QYqkHFokThKiSzLiPo5iTp4kPgJiKLbkUsLkQtYkI5rkCwLkGfrkUqZkPgpWOBIgLAIgOaajOHLl OjKjMALjGiqjN5bjNVJhFX4lMLalNp6jVwbjLmYjLS6jXZajW4alAkbjWvYGKybjOsalWqLjW7ol E87lXpLlYmYjY96lN9YbFIIlXP5lXIolAgpjAx7mXaL/JWdaJmimZV5GJmE6JmlipmeypTqWJjg+ pjZC42E2I2+QJTKO5Whio2ZeJlsOJjWapWlqJmMGp1125rt94Uzy5FXyI0Lm5EGS5HLKZEj2pEXO JEr24VXKYw9aJUhiJ1AOZXN6Z0OqYFBiH0G6pCCO5Hcy5UISIlfEpHQm53tG5HXiIbNJpU7Go1M6 50ouZ3o+51BqIHcy5UbuZ3TOJ3Oi5w6upyP+J1J253U6JSceqHIS6H7mp0aqp3bSp00yZEVm5R/6 p3mqZBmipyZCZHXZJ1bSZHkip4JOZ4rq5EhOpYuypFKG5yZCoof2Z0r+4US6Z1NSZCDOKFaKZyJm ZCRa/6iA7uhLBqmHlqiQDiQm/iSTyuh81mGC8levdaHEaakVnqbLcWnAVZ9RlpuJ/kqZkql68t6Z ftuaSt+YFtwmalzzzSmd1qmdVtzx5Wlq3SmfKp2e/imgBmrc9SmhOp+gHiqiJqqiLiqjNqqjPiqk Rqqkil+hVqoETiqmXo2lbiqndqqnslWmhqqojiqplqqpniqqpqqqriqrtqqrviqsxqqs4t2n1qqt 3iqugtWs7iph5aqvShyvBquwDuvB/aqxIhyxJquyLmvEHauz9huzMuuzTiu1Vqu1Xiu2qlu0Lmu2 dqu3fiu4hqu4jiu5fty2niu67mq5riu7tqu7viu2pifrsMIrvdarvYacvOarvu4rvyrqvf4rwAas wA4swRaswR4swoZFQAAAOw== ------=_NextPart_000_0005_01C71A3D.55A607A0-- From sip-bounces@ietf.org Thu Dec 07 16:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRFh-0006RJ-Kf; Thu, 07 Dec 2006 16:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRFe-0006RE-SA for sip@ietf.org; Thu, 07 Dec 2006 16:58:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRFd-0004UP-Id for sip@ietf.org; Thu, 07 Dec 2006 16:57:58 -0500 Received: by ug-out-1314.google.com with SMTP id 72so538098ugd for ; Thu, 07 Dec 2006 13:57:56 -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=kV22SK/Tnr9RwG4RV/qPfDUVNysitPqsp4pV4hf7dYhdcaYQIWwhWZUeIRe3TItXt9B1B57kmNiKXiMxUmmc66bM/vud8WubK6JABUEwOeVErTtDm5T/37LRB8x8tFTVBw83k6BtUvUpuHE3mBXl9G11UXKbgM6zsq3Z7q4vv1o= Received: by 10.78.204.7 with SMTP id b7mr1688036hug.1165528675815; Thu, 07 Dec 2006 13:57:55 -0800 (PST) Received: by 10.78.120.15 with HTTP; Thu, 7 Dec 2006 13:57:55 -0800 (PST) Message-ID: <953beacc0612071357v243b4fb2m8bda0f149eddd6a6@mail.gmail.com> Date: Thu, 7 Dec 2006 13:57:55 -0800 From: "Rohan Mahy" To: "Cullen Jennings" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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, - The argument for using STUN over TCP was "for consistency with UDP". However the code necessary to demux STUN and SIP over TCP is pretty much orthogonal to the code to demux STUN and SIP over UDP. - In addition to being simpler, CRLF over TCP is backwards compatible with RFC 3261 implementations. I believe the WG made the decision it did based on the erroneous assumption that STUN over TCP would be easier since implementations would have to implement STUN for UDP anyway. I would like to reopen this decision because I believe it was based on faulty data. In addition, if we allow UAs to only implement outbound over TCP, this woudl be yet another assumption that would no longer hold true. thanks, -rohan On 12/7/06, Cullen Jennings wrote: > Dear chairs, > > Rohan has always disagreed with our TCP keep alive mechanism. He has > brought this up over many meetings. IT has been discussed many times > and we have taken WG hums on it. This whole argument that he is > creating is centered around trying to kill the way TCP keep alive are > done. He is not alone, others agree with him. The basic argument > against it is it is a pain to implement - I've implemented and did > not find it a big deal but agree it is more complicated that > implementing the Double CRLF approach. We did have reasonable good > consensus for it in the last WG hum we took on it. > > I would like the chairs to make a statement about if they want reopen > the issue of how to do TCP Keep alives. If yes, I'm glad to present > on it at next IETF, if not, I want to know that I can just ignore it. > > Cullen (with my outbound editor hat on) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 07 17:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRLm-00015e-PG; Thu, 07 Dec 2006 17:04:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRLk-00013o-SX for sip@ietf.org; Thu, 07 Dec 2006 17:04:16 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRLj-0005V4-I3 for sip@ietf.org; Thu, 07 Dec 2006 17:04:16 -0500 Received: by ug-out-1314.google.com with SMTP id 72so539411ugd for ; Thu, 07 Dec 2006 14:04:14 -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=gwoKG1EP/cIal3HLRIIdx+neKa32fmkcCgnB4YgoJ8m9kjJPpCguROhh3mViCyaqZr8yZibtjZ/6YJKuriWcrHEAVDmaO8cs8ml1zbTlFSJijJ1SWdcnD45VlLT+1DHA6h5RS4RNnySHJCvLbYclNRrI0Sr23Wz+VpPC5JBNuwU= Received: by 10.78.201.2 with SMTP id y2mr218604huf.1165529054267; Thu, 07 Dec 2006 14:04:14 -0800 (PST) Received: by 10.78.120.15 with HTTP; Thu, 7 Dec 2006 14:04:14 -0800 (PST) Message-ID: <953beacc0612071404s4326012aw4f57dcaa959ed560@mail.gmail.com> Date: Thu, 7 Dec 2006 14:04:14 -0800 From: "Rohan Mahy" To: "Cullen Jennings" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <496F2C9D-3B39-445A-8A67-2D4CB9FB6E72@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <496F2C9D-3B39-445A-8A67-2D4CB9FB6E72@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, 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 Cullen, Please read the following definition carefully and then tell me why you think my proposed statement ("user agents SHOULD be able to send and receive requests larger than 1300 bytes when using the outbound mechanism") is inappropriate. >From RFC 2119: >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. thanks, -rohan On 12/7/06, Cullen Jennings wrote: > On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > > > To be more specific, SIP is currently specified so it can use UDP > > for requests smaller than 1300 bytes. It is specified so it can > > use TCP for requests of any size. > > Agree with above. Note that you said SIP specified a way to do this > not that deployments must use this. > > > > > Some people have suggested that user agents SHOULD be able to send > > and receive requests larger than 1300 bytes when using the outbound > > mechanism. This seems like a logical requirement. Are you > > objecting to this requirement Cullen? > > yes - I object to this. I think the specification should specify how > things work for large requests but that an UA should be allowed to > choose to use only UDP if it wants to accept the limitations that > this implies. > > Again, I don't see why you are trying to tie up deprecating UDP with > the outbound 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 07 17:27:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRgz-00024A-3S; Thu, 07 Dec 2006 17:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsRgx-000243-DH for sip@ietf.org; Thu, 07 Dec 2006 17:26:11 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsRgv-0000o1-Uu for sip@ietf.org; Thu, 07 Dec 2006 17:26:11 -0500 Received: (qmail 1187 invoked by uid 0); 7 Dec 2006 22:25:39 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Dec 2006 22:25:39 -0000 Message-ID: <004f01c71a4e$ab1a5770$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Cullen Jennings" References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER><3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com><602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> <953beacc0612071357v243b4fb2m8bda0f149eddd6a6@mail.gmail.com> Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Thu, 7 Dec 2006 23:25:57 +0100 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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 hum. This is not about deprecating UDP, it's about avoiding unnecessary complexity for TCP (and TLS) Regards, Jeroen Rohan Mahy wrote: > Hi, > > - The argument for using STUN over TCP was "for consistency with UDP". > However the code necessary to demux STUN and SIP over TCP is pretty > much orthogonal to the code to demux STUN and SIP over UDP. > - In addition to being simpler, CRLF over TCP is backwards compatible > with RFC 3261 implementations. > > I believe the WG made the decision it did based on the erroneous > assumption that STUN over TCP would be easier since implementations > would have to implement STUN for UDP anyway. I would like to reopen > this decision because I believe it was based on faulty data. In > addition, if we allow UAs to only implement outbound over TCP, this > woudl be yet another assumption that would no longer hold true. > > thanks, > -rohan > > On 12/7/06, Cullen Jennings wrote: >> Dear chairs, >> >> Rohan has always disagreed with our TCP keep alive mechanism. He has >> brought this up over many meetings. IT has been discussed many times >> and we have taken WG hums on it. This whole argument that he is >> creating is centered around trying to kill the way TCP keep alive are >> done. He is not alone, others agree with him. The basic argument >> against it is it is a pain to implement - I've implemented and did >> not find it a big deal but agree it is more complicated that >> implementing the Double CRLF approach. We did have reasonable good >> consensus for it in the last WG hum we took on it. >> >> I would like the chairs to make a statement about if they want reopen >> the issue of how to do TCP Keep alives. If yes, I'm glad to present >> on it at next IETF, if not, I want to know that I can just ignore it. >> >> Cullen (with my outbound editor hat on) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 08 00:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsYMY-0006ud-Jv; Fri, 08 Dec 2006 00:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsYMW-0006uY-Q2 for sip@ietf.org; Fri, 08 Dec 2006 00:33:32 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsYMV-0000ky-GO for sip@ietf.org; Fri, 08 Dec 2006 00:33:32 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 1ABFAAC2B5; Fri, 8 Dec 2006 07:33:23 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17784.63779.1170.884485@harjus.tutpro.com> Date: Fri, 8 Dec 2006 07:33:23 +0200 To: "Rohan Mahy" Subject: Re: [Sip] Re: issue with oubound and the used transport protocol In-Reply-To: <953beacc0612071357v243b4fb2m8bda0f149eddd6a6@mail.gmail.com> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> <953beacc0612071357v243b4fb2m8bda0f149eddd6a6@mail.gmail.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: 01485d64dfa90b45a74269b3ca9d5574 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 support rohan's proposal to use CRLF over TCP. -- 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 Dec 08 00:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsYVF-0001cr-Ri; Fri, 08 Dec 2006 00:42:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsYVC-0001cL-Lu; Fri, 08 Dec 2006 00:42:30 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsYVB-0002Zt-02; Fri, 08 Dec 2006 00:42:30 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J9X001HDX6MUR@mailout2.samsung.com>; Fri, 08 Dec 2006 14:42:22 +0900 (KST) Received: from mycomputer ([10.89.26.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPSA id <0J9X00DYXX6MJX@mmp2.samsung.com>; Fri, 08 Dec 2006 14:42:22 +0900 (KST) Date: Fri, 08 Dec 2006 14:42:23 +0900 From: Eanny Bae To: 'mmusic' , 'sipping' , 'SIP' Message-id: <0J9X00DYZX6MJX@mmp2.samsung.com> Organization: Samsung Co. Ltd MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-index: Accai6Kiu//xFrVaQ9GydDWZblmaOA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: Subject: [Sip] The support of multiple connection line 'c=' in SIP 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: , Content-Type: multipart/mixed; boundary="===============2145044307==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2145044307== Content-type: multipart/alternative; boundary="Boundary_(ID_KU5Cae/N+UmV7c7775k+hQ)" This is a multi-part message in MIME format. --Boundary_(ID_KU5Cae/N+UmV7c7775k+hQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all SIP experts, Related with the usage of this multiple connections in SDP, I'd like to get a clarification from all your SIP experts. The IETF RFC 4317 provides some examples for multiple connection lines (i.e. 'c=') in SDP offer and SDP answer. Even though IETF RFC 4566 (SDP), there is no clear definition of the usage of multiple connection lines in SDP. Can it be expected that all SIP UA support media transmission to/from multiple IP addresses in a single session. i.e. Can supporting multiple connection('c=') lines be regarded as a basic capability of the SIP UA? Best Regards, Eanny Bae ----------------------------------------------------- Eanny Bae (Ms.) Engineer Samsung Electronics Co., Ltd. Tel) +82-31-279-5886 Mobile) +82-16-9530-5886 E-Mail) eanny.bae@samsung.com ----------------------------------------------------- --Boundary_(ID_KU5Cae/N+UmV7c7775k+hQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all SIP experts,

 

Related with the usage of this multiple connections in SDP, I’d like to get a clarification from all your SIP experts.

The IETF RFC 4317 provides some examples for multiple connection lines (i.e. ‘c=’) in SDP offer and SDP answer.

Even though IETF RFC 4566 (SDP), there is no clear definition of the usage of multiple connection lines in SDP. Can it be expected that all SIP UA support media transmission to/from multiple IP addresses in a single session. i.e. Can supporting multiple connection(‘c=’) lines be regarded as a basic capability of the SIP UA?

 

Best Regards,

Eanny Bae

 

 

-----------------------------------------------------
Eanny Bae (Ms.)
 
Engineer
Samsung Electronics Co., Ltd.
Tel) +82-31-279-5886
Mobile) +82-16-9530-5886
E-Mail) eanny.bae@samsung.com
-----------------------------------------------------

 

--Boundary_(ID_KU5Cae/N+UmV7c7775k+hQ)-- --===============2145044307== 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 --===============2145044307==-- From sip-bounces@ietf.org Fri Dec 08 02:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsZtq-0004ME-97; Fri, 08 Dec 2006 02:12:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsZtn-0004Hw-81; Fri, 08 Dec 2006 02:11:59 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsZen-0008KO-8V; Fri, 08 Dec 2006 01:56:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] The support of multiple connection line 'c=' in SIP UA. Date: Fri, 8 Dec 2006 06:56:28 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3682@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The support of multiple connection line 'c=' in SIP UA. thread-index: Accai6Kiu//xFrVaQ9GydDWZblmaOAACJ/Et From: "Attila Sipos" To: "Eanny Bae" , "mmusic" , "sipping" , "SIP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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="===============1361814038==" Errors-To: sip-bounces@ietf.org --===============1361814038== Content-Class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkZDIDQ1NjYgc2F5cy4uLg0KIA0KNS43LiAgQ29ubmVjdGlvbiBEYXRhICgiYz0iKQ0KDQogICAg ICBjPTxuZXR0eXBlPiA8YWRkcnR5cGU+IDxjb25uZWN0aW9uLWFkZHJlc3M+DQoNCiAgIFRoZSAi Yz0iIGZpZWxkIGNvbnRhaW5zIGNvbm5lY3Rpb24gZGF0YS4NCg0KICAgQSBzZXNzaW9uIGRlc2Ny aXB0aW9uIE1VU1QgY29udGFpbiBlaXRoZXIgYXQgbGVhc3Qgb25lICJjPSIgZmllbGQgaW4NCiAg IGVhY2ggbWVkaWEgZGVzY3JpcHRpb24gb3IgYSBzaW5nbGUgImM9IiBmaWVsZCBhdCB0aGUgc2Vz c2lvbiBsZXZlbC4NCiAgIEl0IE1BWSBjb250YWluIGEgc2luZ2xlIHNlc3Npb24tbGV2ZWwgImM9 IiBmaWVsZCBhbmQgYWRkaXRpb25hbCAiYz0iDQogICBmaWVsZChzKSBwZXIgbWVkaWEgZGVzY3Jp cHRpb24sIGluIHdoaWNoIGNhc2UgdGhlIHBlci1tZWRpYSB2YWx1ZXMNCiAgIG92ZXJyaWRlIHRo ZSBzZXNzaW9uLWxldmVsIHNldHRpbmdzIGZvciB0aGUgcmVzcGVjdGl2ZSBtZWRpYS4NCg0KVGhl ICJzZXNzaW9uIGRlc2NyaXB0aW9uIiBhYm92ZSAgaXMgdGhlIGJpdCBiZWZvcmUgYW55IG09IGxp bmVzLg0KVGhlICJtZWRpYSBkZXNjcmlwdGlvbnMiIHN0YXJ0IHdpdGggYW4gbT0gbGluZS4NClNv IGFuIFNEUCBoYXMgMSBzZXNzaW9uIGRlc2NyaXB0aW9uIHNlY3Rpb24gYW5kIGNhbiBoYXZlDQpt dWx0aXBsZSBtZWRpYSBkZXNjcmlwdGlvbnMuDQogDQpzbyBhcyBleGFtcGxlcyBvciBwb3NpdGlv bmluZyBvZiBjPSBsaW5lcywgeW91IGNhbiBoYXZlOg0KIA0KMS4gVGhlcmUgaXMgb25lIGM9IGxp bmUgYXQgdGhlIHNlc3Npb24gZGVzY3JpcHRpb24NCiAgICBFYWNoIG1lZGlhIGRlc2NyaXB0aW9u IHVzZXMgdGhlIGNvbm5lY3Rpb24gaW5mb3JtYXRpb24gZnJvbQ0KICAgIHRoYXQgdG9wIGM9IGxp bmUuDQpjPS4uLi4gICAgICAgICAgICAgICAgICAgICAvLyBzZXNzaW9uIGRlc2NyaXB0aW9uDQpt PS4uLi4gICAgICAgICAgICAgICAgICAgIC8vIDFzdCBtZWRpYSBkZXNjcmlwdGlvbg0KYT0uLi4u LiANCm09Li4uLiAgICAgICAgICAgICAgICAgICAgLy8gMm5kIG1lZGlhIGRlc2NyaXB0aW9uDQph PS4uLi4uDQogDQpvcg0KIA0KIA0KMi4gRWFjaCBtZWRpYSBkZXNjcmlwdGlvbiBoYXMgaXRzIG93 biBjPSBsaW5lDQogICAgKFRoZXJlIGlzIG5vIHNlc3Npb24gZGVzY3JpcHRpb24gYz0gbGluZSk6 DQogDQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNlc3Npb24gZGVzY3Jp cHRpb24gKG5vIGM9IGxpbmUpDQptPS4uLi4gICAgICAgICAgICAgICAgICAgIC8vIDFzdCBtZWRp YSBkZXNjcmlwdGlvbg0KYz0uLi4uDQphPS4uLi4uIA0KbT0uLi4uICAgICAgICAgICAgICAgICAg ICAvLyAybmQgbWVkaWEgZGVzY3JpcHRpb24NCmM9Li4uLg0KYT0uLi4uLg0KIA0KIA0Kb3INCiAN CjMuIFRoZXJlIGlzIGEgc2Vzc2lvbiBkZXNjcmlwdGlvbiBjPSBsaW5lIGJ1dCB0aGUgZmlyc3QN CiAgICBtZWRpYSBkZXNjcmlwdGlvbiBoYXMgaXRzIG93biBjPSBsaW5lICwgc28gdGhlIGZpcnN0 DQogICAgbWVkaWEgZGVzY3JpcHRpb24ncyBjPSBsaW5lIG92ZXJyaWRlcyB0aGUgc2Vzc2lvbiBk ZXNjcmlwdGlvbiBjPSBsaW5lLg0KICAgVGhlIDJuZCBtZWRpYSBkZXNjcmlwdGlvbiB1c2VzIHRo ZSBjPSBsaW5lIGluIHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uLg0KYz0uLi4uICAgICAgICAgICAg ICAgICAgICAvLyBzZXNzaW9uIGRlc2NyaXB0aW9uDQptPS4uLi4gICAgICAgICAgICAgICAgICAg IC8vIDFzdCBtZWRpYSBkZXNjcmlwdGlvbg0KYz0uLi4uDQphPS4uLi4uIA0KbT0uLi4uICAgICAg ICAgICAgICAgICAgICAvLyAybmQgbWVkaWEgZGVzY3JpcHRpb24NCmE9Li4uLi4NCiANCiANClJl Z2FyZHMsDQpBdHRpbGENCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEVh bm55IEJhZSBbbWFpbHRvOmVhbm55LmJhZUBzYW1zdW5nLmNvbV0gDQoJU2VudDogRnJpIDA4LzEy LzIwMDYgMDU6NDIgDQoJVG86ICdtbXVzaWMnOyAnc2lwcGluZyc7ICdTSVAnIA0KCUNjOiANCglT dWJqZWN0OiBbU2lwXSBUaGUgc3VwcG9ydCBvZiBtdWx0aXBsZSBjb25uZWN0aW9uIGxpbmUgJ2M9 JyBpbiBTSVAgVUEuIA0KCQ0KCQ0KDQoJRGVhciBhbGwgU0lQIGV4cGVydHMsDQoNCgkgDQoNCglS ZWxhdGVkIHdpdGggdGhlIHVzYWdlIG9mIHRoaXMgbXVsdGlwbGUgY29ubmVjdGlvbnMgaW4gU0RQ LCBJ4oCZZCBsaWtlIHRvIGdldCBhIGNsYXJpZmljYXRpb24gZnJvbSBhbGwgeW91ciBTSVAgZXhw ZXJ0cy4gDQoNCglUaGUgSUVURiBSRkMgNDMxNyBwcm92aWRlcyBzb21lIGV4YW1wbGVzIGZvciBt dWx0aXBsZSBjb25uZWN0aW9uIGxpbmVzIChpLmUuIOKAmGM94oCZKSBpbiBTRFAgb2ZmZXIgYW5k IFNEUCBhbnN3ZXIuIA0KDQoJRXZlbiB0aG91Z2ggSUVURiBSRkMgNDU2NiAoU0RQKSwgdGhlcmUg aXMgbm8gY2xlYXIgZGVmaW5pdGlvbiBvZiB0aGUgdXNhZ2Ugb2YgbXVsdGlwbGUgY29ubmVjdGlv biBsaW5lcyBpbiBTRFAuIENhbiBpdCBiZSBleHBlY3RlZCB0aGF0IGFsbCBTSVAgVUEgc3VwcG9y dCBtZWRpYSB0cmFuc21pc3Npb24gdG8vZnJvbSBtdWx0aXBsZSBJUCBhZGRyZXNzZXMgaW4gYSBz aW5nbGUgc2Vzc2lvbi4gaS5lLiBDYW4gc3VwcG9ydGluZyBtdWx0aXBsZSBjb25uZWN0aW9uKOKA mGM94oCZKSBsaW5lcyBiZSByZWdhcmRlZCBhcyBhIGJhc2ljIGNhcGFiaWxpdHkgb2YgdGhlIFNJ UCBVQT8NCg0KCSANCg0KCUJlc3QgUmVnYXJkcywNCg0KCUVhbm55IEJhZSANCg0KCSANCg0KCSAN Cg0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoJRWFubnkgQmFlIChNcy4pDQoJIA0KCUVuZ2luZWVyDQoJU2Ftc3VuZyBFbGVjdHJvbmljcyBD by4sIEx0ZC4NCglUZWwpICs4Mi0zMS0yNzktNTg4Ng0KCU1vYmlsZSkgKzgyLTE2LTk1MzAtNTg4 Ng0KCUUtTWFpbCkgZWFubnkuYmFlQHNhbXN1bmcuY29tIDxtYWlsdG86ZWFubnkuYmFlQHNhbXN1 bmcuY29tPiANCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQoJIA0KDQo= --===============1361814038== 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 --===============1361814038==-- From sip-bounces@ietf.org Fri Dec 08 02:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsa8S-0000mx-5T; Fri, 08 Dec 2006 02:27:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsa8Q-0000mh-7a; Fri, 08 Dec 2006 02:27:06 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsa8N-00005S-On; Fri, 08 Dec 2006 02:27:06 -0500 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J9Y00GH41ZN89@mailout1.samsung.com>; Fri, 08 Dec 2006 16:26:12 +0900 (KST) Received: from mycomputer ([10.89.26.180]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0J9Y001N71ZNA2@mmp1.samsung.com>; Fri, 08 Dec 2006 16:26:11 +0900 (KST) Date: Fri, 08 Dec 2006 16:26:12 +0900 From: Eanny Bae Subject: RE: [Sip] The support of multiple connection line 'c=' in SIP UA. In-reply-to: <8F1F2062CA7D754A838F0E66097D23A0012A3682@veg-brk-svr-pri.vegastream> To: 'Attila Sipos' , 'mmusic' , 'sipping' , 'SIP' Message-id: <0J9Y001N81ZNA2@mmp1.samsung.com> Organization: Samsung Co. Ltd MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Accai6Kiu//xFrVaQ9GydDWZblmaOAACJ/EtAAEUOGA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 Dear Attila Sipos, Thanks for quick answer. >From your kindly explanation, I got to clarify that all SIP UA can support SDP including multiple media description having a different connection ('c=') value per media type. Furthermore, I believe this capability is a basic capability of SIP UA. Best Regards, Eanny Bae ----------------------------------------------------- Eanny Bae (Ms.) Engineer Samsung Electronics Co., Ltd. Tel) +82-31-279-5886 Mobile) +82-16-9530-5886 E-Mail) eanny.bae@samsung.com ----------------------------------------------------- -----Original Message----- From: Attila Sipos [mailto:Attila.Sipos@vegastream.com] Sent: Friday, December 08, 2006 3:56 PM To: Eanny Bae; mmusic; sipping; SIP Subject: RE: [Sip] The support of multiple connection line 'c=' in SIP UA. RFC 4566 says... 5.7. Connection Data ("c=") c= The "c=" field contains connection data. A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. The "session description" above is the bit before any m= lines. The "media descriptions" start with an m= line. So an SDP has 1 session description section and can have multiple media descriptions. so as examples or positioning of c= lines, you can have: 1. There is one c= line at the session description Each media description uses the connection information from that top c= line. c=.... // session description m=.... // 1st media description a=..... m=.... // 2nd media description a=..... or 2. Each media description has its own c= line (There is no session description c= line): // session description (no c= line) m=.... // 1st media description c=.... a=..... m=.... // 2nd media description c=.... a=..... or 3. There is a session description c= line but the first media description has its own c= line , so the first media description's c= line overrides the session description c= line. The 2nd media description uses the c= line in the session description. c=.... // session description m=.... // 1st media description c=.... a=..... m=.... // 2nd media description a=..... Regards, Attila -----Original Message----- From: Eanny Bae [mailto:eanny.bae@samsung.com] Sent: Fri 08/12/2006 05:42 To: 'mmusic'; 'sipping'; 'SIP' Cc: Subject: [Sip] The support of multiple connection line 'c=' in SIP UA. Dear all SIP experts, Related with the usage of this multiple connections in SDP, I'd like to get a clarification from all your SIP experts. The IETF RFC 4317 provides some examples for multiple connection lines (i.e. 'c=') in SDP offer and SDP answer. Even though IETF RFC 4566 (SDP), there is no clear definition of the usage of multiple connection lines in SDP. Can it be expected that all SIP UA support media transmission to/from multiple IP addresses in a single session. i.e. Can supporting multiple connection('c=') lines be regarded as a basic capability of the SIP UA? Best Regards, Eanny Bae ----------------------------------------------------- Eanny Bae (Ms.) Engineer Samsung Electronics Co., Ltd. Tel) +82-31-279-5886 Mobile) +82-16-9530-5886 E-Mail) eanny.bae@samsung.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 Dec 08 03:25:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsb1Z-0007Kq-4c; Fri, 08 Dec 2006 03:24:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsb1V-0007I8-Ky; Fri, 08 Dec 2006 03:24:01 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsaxY-0008MF-BD; Fri, 08 Dec 2006 03:19:59 -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] The support of multiple connection line 'c=' in SIP UA. Date: Fri, 8 Dec 2006 08:17:49 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C24021@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] The support of multiple connection line 'c=' in SIP UA. thread-index: Accai6Kiu//xFrVaQ9GydDWZblmaOAACJ/EtAAEUOGAAAh3oQA== From: "Attila Sipos" To: "Eanny Bae" , "mmusic" , "sipping" , "SIP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 By the way, for interop, most UA's like the style in example 1. I have found some UA's that don't like example 2 where there is no c=3D line in the session description. (I have not actually tried example 3 with any UA) Regards, Attila -----Original Message----- From: Eanny Bae [mailto:eanny.bae@samsung.com] Sent: 08 December 2006 07:26 To: Attila Sipos; 'mmusic'; 'sipping'; 'SIP' Subject: RE: [Sip] The support of multiple connection line 'c=3D' in SIP UA. Dear Attila Sipos,=20 Thanks for quick answer.=20 >From your kindly explanation, I got to clarify that all SIP UA can = support SDP including multiple media description having a different connection ('c=3D') value per media type. Furthermore, I believe this capability is = a basic capability of SIP UA.=20 Best Regards, Eanny Bae=20 ----------------------------------------------------- Eanny Bae (Ms.) =20 Engineer Samsung Electronics Co., Ltd. Tel) +82-31-279-5886 Mobile) +82-16-9530-5886 E-Mail) eanny.bae@samsung.com ----------------------------------------------------- -----Original Message----- From: Attila Sipos [mailto:Attila.Sipos@vegastream.com]=20 Sent: Friday, December 08, 2006 3:56 PM To: Eanny Bae; mmusic; sipping; SIP Subject: RE: [Sip] The support of multiple connection line 'c=3D' in SIP = UA. RFC 4566 says... =20 5.7. Connection Data ("c=3D") c=3D The "c=3D" field contains connection data. A session description MUST contain either at least one "c=3D" field = in each media description or a single "c=3D" field at the session level. It MAY contain a single session-level "c=3D" field and additional = "c=3D" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. The "session description" above is the bit before any m=3D lines. The "media descriptions" start with an m=3D line. So an SDP has 1 session description section and can have multiple media descriptions. =20 so as examples or positioning of c=3D lines, you can have: =20 1. There is one c=3D line at the session description Each media description uses the connection information from that top c=3D line. c=3D.... // session description m=3D.... // 1st media description a=3D.....=20 m=3D.... // 2nd media description a=3D..... =20 or =20 =20 2. Each media description has its own c=3D line (There is no session description c=3D line): =20 =20 // session description (no c=3D line) m=3D.... // 1st media description c=3D.... a=3D.....=20 m=3D.... // 2nd media description c=3D.... a=3D..... =20 =20 or =20 3. There is a session description c=3D line but the first media description has its own c=3D line , so the first media description's c=3D line overrides the session description c=3D = line. The 2nd media description uses the c=3D line in the session = description. c=3D.... // session description m=3D.... // 1st media description c=3D.... a=3D.....=20 m=3D.... // 2nd media description a=3D..... =20 =20 Regards, Attila -----Original Message-----=20 From: Eanny Bae [mailto:eanny.bae@samsung.com]=20 Sent: Fri 08/12/2006 05:42=20 To: 'mmusic'; 'sipping'; 'SIP'=20 Cc:=20 Subject: [Sip] The support of multiple connection line 'c=3D' in SIP UA.=20 =09 =09 Dear all SIP experts, =20 Related with the usage of this multiple connections in SDP, I'd like to get a clarification from all your SIP experts.=20 The IETF RFC 4317 provides some examples for multiple connection lines (i.e. 'c=3D') in SDP offer and SDP answer.=20 Even though IETF RFC 4566 (SDP), there is no clear definition of the usage of multiple connection lines in SDP. Can it be expected that all = SIP UA support media transmission to/from multiple IP addresses in a single session. i.e. Can supporting multiple connection('c=3D') lines be = regarded as a basic capability of the SIP UA? =20 Best Regards, Eanny Bae=20 =20 =20 ----------------------------------------------------- Eanny Bae (Ms.) =20 Engineer Samsung Electronics Co., Ltd. Tel) +82-31-279-5886 Mobile) +82-16-9530-5886 E-Mail) eanny.bae@samsung.com =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 uvmywiupihx@canariastelecom.com Fri Dec 08 04:14:29 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsboL-0001Ug-NH for sip-archive@lists.ietf.org; Fri, 08 Dec 2006 04:14:29 -0500 Received: from [88.232.58.77] (helo=[88.232.58.77]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsboH-0001Go-Vs for sip-archive@lists.ietf.org; Fri, 08 Dec 2006 04:14:29 -0500 From: "draw" To: sip-archive@lists.ietf.org Subject: Attention Small Stock Players Date: Fri, 8 Dec 2006 11:14:26 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C71ABA.05A9C5C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccaugWpuJlxW3uERVSM5F7fpJ1jCg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <503ABD50AFF4174.BCAC7643A1@canariastelecom.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0005_01C71ABA.05A9C5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Another Heavy Trading Day For VSUS.PK!

VSUS's new application MYOneScreen and integrated Blog marketing solutions has continued to stir investors for another day of heavy trading. In the last couple days over 6.5 Million shares have traded and the price continues to spike. This kind of trading shoots the price up.We expect to see this climb over 7cents next week. Read the news, check out this new technology and see the potential to grab the market.

Grab VSUS Friday morning and ride the wave into a prosperous Christmas.
------=_NextPart_000_0005_01C71ABA.05A9C5C0-- From sip-bounces@ietf.org Fri Dec 08 04:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2Z-0006uc-MZ; Fri, 08 Dec 2006 04:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsc2X-0006t3-5q for sip@ietf.org; Fri, 08 Dec 2006 04:29:09 -0500 Received: from web52905.mail.yahoo.com ([206.190.49.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gsc2T-00053a-Qb for sip@ietf.org; Fri, 08 Dec 2006 04:29:09 -0500 Received: (qmail 38826 invoked by uid 60001); 8 Dec 2006 09:29:03 -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=CdoNPvKr3VzSHDY2AyfjXLVgQ+rEOApxHTak+OiAO1i4crHgLKhmGA5v5YcBtQniDJkON1FAOC9B7oC2qCOFfzgJqIpUeUibc088GrkkRcbgPWlcrBlYkpluZfFgnUlMdYyrMtGHX3mcv4EfUVi+zumXbl2jo+qVB0BvgJ/rWAs=; X-YMail-OSG: tQ.MKOIVM1niZE9TwNH3NYvRTIKn_g_1TXhb_RVkGbY7Ws5oIlKybvcN8NIYBv3ZXxfRFbdMi34kpXFmRhFZVqr3Hjjyl2KdhsaNbfVGELt3R2spoVRE5fvJEmjWu2omFVKoQ_Y1HDxFO3CxD_P6QTvPPKXMp6.WtjPTtztilmJ_z3UwjvX0UkFPsqg- Received: from [217.33.106.234] by web52905.mail.yahoo.com via HTTP; Fri, 08 Dec 2006 01:29:03 PST Date: Fri, 8 Dec 2006 01:29:03 -0800 (PST) From: Raj To: SIP forum , SIP forum , SIP Proposal Investigation , SIP Resiprocate MIME-Version: 1.0 Message-ID: <246746.38709.qm@web52905.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sip] Information carried by SIP Message - regarding 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="===============1231400886==" Errors-To: sip-bounces@ietf.org --===============1231400886== Content-Type: multipart/alternative; boundary="0-1690771946-1165570143=:38709" Content-Transfer-Encoding: 8bit --0-1690771946-1165570143=:38709 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I know that SIP can carry signalling information and media information. Is it possible to make SIP to carry information related to configuration of the end devices or any other information that user wants to exchange. Thanks in advance with regards Raj. --------------------------------- Access over 1 million songs - Yahoo! Music Unlimited. --0-1690771946-1165570143=:38709 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello,

I know that SIP can carry signalling information and media information. Is it possible to make SIP to carry information related to configuration of the end devices or any other information that user wants to exchange.

Thanks in advance

with regards
Raj.

Access over 1 million songs - Yahoo! Music Unlimited. --0-1690771946-1165570143=:38709-- --===============1231400886== 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 --===============1231400886==-- From sip-bounces@ietf.org Fri Dec 08 08:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg6K-000593-2Q; Fri, 08 Dec 2006 08:49:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg6I-00058v-Hj for sip@ietf.org; Fri, 08 Dec 2006 08:49:18 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gsg6E-0005PF-IM for sip@ietf.org; Fri, 08 Dec 2006 08:49:18 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id D51CF194506 for ; Fri, 8 Dec 2006 14:49:10 +0100 (CET) Received: from [192.168.1.64] ([192.168.1.64]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 14:48:57 +0100 In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 14:48:46 +0100 To: Rohan Mahy X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 08 Dec 2006 13:48:57.0043 (UTC) FILETIME=[9B5C7A30:01C71ACF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: SIP WG 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 like this proposal and support it. Hisham On Dec 7, 2006, at 6:15 AM, Rohan Mahy wrote: > > On Dec 6, 2006, at 16:33, Cullen Jennings wrote: >> I find this whole conversation way off base. If people would like to >> deprecate UDP, go work on a document to explain that and feel free to >> bring it to the WG. In the mean time, SIP is specified over both UDP >> and TCP. > > To be more specific, SIP is currently specified so it can use UDP for > requests smaller than 1300 bytes. It is specified so it can use TCP > for requests of any size. > > Some people have suggested that user agents SHOULD be able to send and > receive requests larger than 1300 bytes when using the outbound > mechanism. This seems like a logical requirement. Are you objecting > to this requirement Cullen? > > For the sake of this discussion, lets assume that we have consensus on > this requirement. What are the implications? Well, most UAs > implementing outbound are doing so because they are behind a NAT or a > firewall and will not be able to receive inbound TCP flows. These UAs > will need to establish a TCP flow if they want to meet this > requirement of receiving requests larger than 1300 bytes. The logical > normative statement is to say a UA which cannot (or suspects that it > cannot) receive an inbound TCP flow from its outbound proxies SHOULD > open at least one TCP or TLS flow to a server in its > outbound-proxy-set. > > A few people on this mailing list have suggested that for any user > agent that actually bothers to open a TCP flow, there is no reason > whatsoever to open a corresponding UDP flow. I wholeheartedly agree > with them. > > The problem is that this thread strikes right at the heart of our > community's dilemma. We have a large body of people who have deployed > UDP almost exclusively and effectively ignore the MUST use (and > several even ignore the MUST implement) TCP statements in our core > spec. Ironically, one of the problems which prevents realistic > interoperable deployment of TCP-based SIP implementations is the lack > of a standardized mechanism for doing outbound. [Dean also identified > some other problems often faced when deploying TCP with programs that > use "obvious" (Dean actually said "naive") textbook implementation > techniques.] > > I think that a large number of the core spec contributors and seasoned > implementors now recognize that there are many non-academic problems > with SIP over UDP and that some day we will want to either deprecate > or at least seriously curtail the use of UDP. Like a very heavy > drinker we know it will be good for us to kick the habit. We are not > quitting today. The question before us is are we going to do something > in outbound that makes it harder for us to quit in the future. > > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over TCP flow > (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include 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 (the 3GPP > exception). explain that for historical purposes a lot of deployments > still only use UDP, but that we expect/hope those deployments to > eventually migrate to TCP when doing outbound. > > What's in it for the TCP crowd? They get to implement outbound with > no UDP if they so desire. They don't have to implement STUN over TCP. > The draft clearly explains why TCP is the technically preferred > solution. > > What's in it for the UDP crowd? They get outbound behavior (at least > for requests <1300 bytes) specified in the core draft for UDP. They > can keep doing what they are doing, but with STUN keepalives if the UA > and edge proxy both support it. > > What's not to like? > thanks, > -rohan > > >> Most deployments only use UDP, some only use TCP, and I suspect there >> are some that do both but I am not aware of them. Outbound as it is >> seems very consistent with 3261 in that it allows a system to use TCP >> or UDP. Keeping this in mind few comments inline .... >> >> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >> >>> Let's go back to the original topic - what should the draft say >>> about the transport protocol in relationship with outbound >>> >>> The major use case for outbound is UAs behind NAT / firewalls. Many >>> of such devices have known issues with UDP fragmentation, so for >>> many environments TCP will need to be used for messages larger than >>> the path MTU (often ~1460 bytes in ethernet environments, RFC3261 >>> puts the limit at 1300). >> >> These known issues with fragmentation might be less common than you >> think however, outbound does not have anything to do with MTU issues. >> It does not try and solve them and it does not make them worse. >> >>> >>> If you start from the requirement "MUST only use UDP", then there is >>> little room for constructive discussions. For UDP-only to work you >>> will need to ensure that messages either stay below path MTUs, or >>> disallow NAT. This implies significant limitations for your >>> deployment environment. In any case, this is not a setup that >>> outbound should focus on. >> >> MTU is a problem regardless of NATs or Firewalls. Fragmented packets >> do manager to traverse most NATs and Firewalls. >> >>> >>> In the general case, there are environments that have to deal with >>> NAT and messages larger than path MTU. This is what outbound was >>> written for. This also implies a UA that supports TCP. Given that >>> the UA supports TCP and the fact that presence of devices like >>> stateful firewalls cannot reliably be detected, the UA SHOULD use >>> TCP (or another connection oriented transport). If in addition the >>> UA supports TLS, it SHOULD use TLS. >> >> Again, this topic is not really about outbound. If you think a 3261 >> UA that supports both UDP and TCP SHOULD use TCP, that is a fine >> argument to go make in the discussion about use of TCP and UDP but it >> seems to be an independent choice from anything to do with outbound. >> >> >> Cullen >> >>> >>> I think this is sufficient >>> >>> Regards, >>> Jeroen >>> >>> Fredrik Thulin wrote: >>>> Hisham Khartabil wrote: >>>>> >>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>> ... >>>>>> I personally believe going TCP-only would actually help deployment >>>>>> rather than hinder it, but I'd be really interested to be >>>>>> convinced >>>>>> otherwise. >>>>> >>>>> I could ask you the converse. I'd really be interested to be >>>>> convinced how TCP deployment improves scalability. >>>> >>>> To name two things where TCP would provide better scalability than >>>> UDP >>>> for a SIP service provider : >>>> >>>> 1) Say that your services maximum capacity for non-INVITEs is 1000 >>>> requests per second. If you get 2000 in a single second, you >>>> won't only have to deal with all those 2000 requests, but also >>>> with quite a few retransmissions sent after 500ms. With TCP, >>>> the >>>> wall isn't as dense. >>>> >>>> 2) UDP sockets have a shared receive buffer, most commonly around >>>> 64k I believe (even though the maximum seems to be 256k on >>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>> average, you have to be able to move messages out of that >>>> buffer >>>> pretty fast to keep it from filling up. A full buffer means >>>> dropped packets. I've also heard that on for example Linux, >>>> every packet actually occupies an even 2k (or was it 4k) in the >>>> buffer, so 64k buffer is actually at most 32 packets at a time. >>>> >>>> And then there are of course other aspects than scalability where >>>> UDP >>>> is an inferior solution, most notably security related things like >>>> for >>>> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >>>> >>>> /Fredrik >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Dec 08 08:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg7M-0005vv-Eh; Fri, 08 Dec 2006 08:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg7K-0005vo-St for sip@ietf.org; Fri, 08 Dec 2006 08:50:22 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsg77-0002zh-4W for sip@ietf.org; Fri, 08 Dec 2006 08:50:22 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 2501519451A for ; Fri, 8 Dec 2006 14:50:08 +0100 (CET) Received: from [192.168.1.64] ([192.168.1.64]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 14:49:52 +0100 In-Reply-To: <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34f07dacefcdbf71845564a5170b88cc@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 14:49:42 +0100 To: Cullen Jennings X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 08 Dec 2006 13:49:52.0594 (UTC) FILETIME=[BC78E320:01C71ACF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: Rohan Mahy , Fredrik Thulin , SIP , Dean Willis , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Keith Drage 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 Dec 7, 2006, at 7:22 PM, Cullen Jennings wrote: > > Dear chairs, > > Rohan has always disagreed with our TCP keep alive mechanism. He has > brought this up over many meetings. IT has been discussed many times > and we have taken WG hums on it. This whole argument that he is > creating is centered around trying to kill the way TCP keep alive are > done. He is not alone, others agree with him. The basic argument > against it is it is a pain to implement - I've implemented and did not > find it a big deal but agree it is more complicated that implementing > the Double CRLF approach. We did have reasonable good consensus for it > in the last WG hum we took on it. > > I would like the chairs to make a statement about if they want reopen > the issue of how to do TCP Keep alives. If yes, I'm glad to present on > it at next IETF Please, lets not wait until March to discuss this. We can take a hum here on the mailing list. My vote for TCP keepalive is CRLF. Hisham > , if not, I want to know that I can just ignore it. > > Cullen (with my outbound editor hat on) > > > On Dec 6, 2006, at 9:15 PM, Rohan Mahy wrote: > >> >> On Dec 6, 2006, at 16:33, Cullen Jennings wrote: >>> I find this whole conversation way off base. If people would like to >>> deprecate UDP, go work on a document to explain that and feel free >>> to bring it to the WG. In the mean time, SIP is specified over both >>> UDP and TCP. >> >> To be more specific, SIP is currently specified so it can use UDP for >> requests smaller than 1300 bytes. It is specified so it can use TCP >> for requests of any size. >> >> Some people have suggested that user agents SHOULD be able to send >> and receive requests larger than 1300 bytes when using the outbound >> mechanism. This seems like a logical requirement. Are you objecting >> to this requirement Cullen? > yes. > >> >> For the sake of this discussion, lets assume that we have consensus >> on this requirement. What are the implications? Well, most UAs >> implementing outbound are doing so because they are behind a NAT or a >> firewall and will not be able to receive inbound TCP flows. These >> UAs will need to establish a TCP flow if they want to meet this >> requirement of receiving requests larger than 1300 bytes. The logical >> normative statement is to say a UA which cannot (or suspects that it >> cannot) receive an inbound TCP flow from its outbound proxies SHOULD >> open at least one TCP or TLS flow to a server in its >> outbound-proxy-set. >> >> A few people on this mailing list have suggested that for any user >> agent that actually bothers to open a TCP flow, there is no reason >> whatsoever to open a corresponding UDP flow. I wholeheartedly agree >> with them. >> >> The problem is that this thread strikes right at the heart of our >> community's dilemma. We have a large body of people who have deployed >> UDP almost exclusively and effectively ignore the MUST use (and >> several even ignore the MUST implement) TCP statements in our core >> spec. Ironically, one of the problems which prevents realistic >> interoperable deployment of TCP-based SIP implementations is the lack >> of a standardized mechanism for doing outbound. [Dean also >> identified some other problems often faced when deploying TCP with >> programs that use "obvious" (Dean actually said "naive") textbook >> implementation techniques.] >> >> I think that a large number of the core spec contributors and >> seasoned implementors now recognize that there are many non-academic >> problems with SIP over UDP and that some day we will want to either >> deprecate or at least seriously curtail the use of UDP. Like a very >> heavy drinker we know it will be good for us to kick the habit. We >> are not quitting today. The question before us is are we going to do >> something in outbound that makes it harder for us to quit in the >> future. >> >> My concrete proposal is the following: >> - make CRLF the only keepalive mechanism for TCP and TLS over TCP >> flow (retain STUN for UDP flows) >> - make outbound registrations over UDP flows optional for UAs >> - include 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 (the 3GPP >> exception). explain that for historical purposes a lot of >> deployments still only use UDP, but that we expect/hope those >> deployments to eventually migrate to TCP when doing outbound. >> >> What's in it for the TCP crowd? They get to implement outbound with >> no UDP if they so desire. They don't have to implement STUN over >> TCP. The draft clearly explains why TCP is the technically preferred >> solution. >> >> What's in it for the UDP crowd? They get outbound behavior (at least >> for requests <1300 bytes) specified in the core draft for UDP. They >> can keep doing what they are doing, but with STUN keepalives if the >> UA and edge proxy both support it. >> >> What's not to like? >> thanks, >> -rohan >> >> >>> Most deployments only use UDP, some only use TCP, and I suspect >>> there are some that do both but I am not aware of them. Outbound as >>> it is seems very consistent with 3261 in that it allows a system to >>> use TCP or UDP. Keeping this in mind few comments inline .... >>> >>> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >>> >>>> Let's go back to the original topic - what should the draft say >>>> about the transport protocol in relationship with outbound >>>> >>>> The major use case for outbound is UAs behind NAT / firewalls. Many >>>> of such devices have known issues with UDP fragmentation, so for >>>> many environments TCP will need to be used for messages larger than >>>> the path MTU (often ~1460 bytes in ethernet environments, RFC3261 >>>> puts the limit at 1300). >>> >>> These known issues with fragmentation might be less common than you >>> think however, outbound does not have anything to do with MTU >>> issues. It does not try and solve them and it does not make them >>> worse. >>> >>>> >>>> If you start from the requirement "MUST only use UDP", then there >>>> is little room for constructive discussions. For UDP-only to work >>>> you will need to ensure that messages either stay below path MTUs, >>>> or disallow NAT. This implies significant limitations for your >>>> deployment environment. In any case, this is not a setup that >>>> outbound should focus on. >>> >>> MTU is a problem regardless of NATs or Firewalls. Fragmented packets >>> do manager to traverse most NATs and Firewalls. >>> >>>> >>>> In the general case, there are environments that have to deal with >>>> NAT and messages larger than path MTU. This is what outbound was >>>> written for. This also implies a UA that supports TCP. Given that >>>> the UA supports TCP and the fact that presence of devices like >>>> stateful firewalls cannot reliably be detected, the UA SHOULD use >>>> TCP (or another connection oriented transport). If in addition the >>>> UA supports TLS, it SHOULD use TLS. >>> >>> Again, this topic is not really about outbound. If you think a 3261 >>> UA that supports both UDP and TCP SHOULD use TCP, that is a fine >>> argument to go make in the discussion about use of TCP and UDP but >>> it seems to be an independent choice from anything to do with >>> outbound. >>> >>> >>> Cullen >>> >>>> >>>> I think this is sufficient >>>> >>>> Regards, >>>> Jeroen >>>> >>>> Fredrik Thulin wrote: >>>>> Hisham Khartabil wrote: >>>>>> >>>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>>> ... >>>>>>> I personally believe going TCP-only would actually help >>>>>>> deployment >>>>>>> rather than hinder it, but I'd be really interested to be >>>>>>> convinced >>>>>>> otherwise. >>>>>> >>>>>> I could ask you the converse. I'd really be interested to be >>>>>> convinced how TCP deployment improves scalability. >>>>> >>>>> To name two things where TCP would provide better scalability than >>>>> UDP >>>>> for a SIP service provider : >>>>> >>>>> 1) Say that your services maximum capacity for non-INVITEs is >>>>> 1000 >>>>> requests per second. If you get 2000 in a single second, you >>>>> won't only have to deal with all those 2000 requests, but also >>>>> with quite a few retransmissions sent after 500ms. With TCP, >>>>> the >>>>> wall isn't as dense. >>>>> >>>>> 2) UDP sockets have a shared receive buffer, most commonly around >>>>> 64k I believe (even though the maximum seems to be 256k on >>>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>>> average, you have to be able to move messages out of that >>>>> buffer >>>>> pretty fast to keep it from filling up. A full buffer means >>>>> dropped packets. I've also heard that on for example Linux, >>>>> every packet actually occupies an even 2k (or was it 4k) in >>>>> the >>>>> buffer, so 64k buffer is actually at most 32 packets at a >>>>> time. >>>>> >>>>> And then there are of course other aspects than scalability where >>>>> UDP >>>>> is an inferior solution, most notably security related things like >>>>> for >>>>> example spoofed CANCELs (which can't be challenged, RFC3261 #22.1). >>>>> >>>>> /Fredrik >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP 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 Dec 08 08:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgEn-0007zv-Q1; Fri, 08 Dec 2006 08:58:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgEl-0007uR-M4 for sip@ietf.org; Fri, 08 Dec 2006 08:58:03 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsgEg-00069j-Jr for sip@ietf.org; Fri, 08 Dec 2006 08:58:03 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89AA860F; Fri, 8 Dec 2006 14:57: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); Fri, 8 Dec 2006 14:57: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] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 14:57:50 +0100 Message-ID: <7374777208BDC7449D5620EF94232567D9EDBC@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: Accaz/+VWIsoYeWXQP+/r+pavmgYgwAAHTxA From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" , "Rohan Mahy" X-OriginalArrivalTime: 08 Dec 2006 13:57:51.0457 (UTC) FILETIME=[D9E59510:01C71AD0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: SIP WG 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, A couple of questions: 1. What was the reason(s) the CRLF solution is not suitable for UDP? 2. Even for UDP it can be possible to use lower layer keep-alive mechanisms, e.g. when UDP encapsulated IPSec, is used, so I think one should be allowed to use that instead of STUN.=20 Regards, Christer > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 > Sent: 8. joulukuuta 2006 15:49 > To: Rohan Mahy > Cc: SIP WG > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 > I like this proposal and support it. >=20 > Hisham >=20 > On Dec 7, 2006, at 6:15 AM, Rohan Mahy wrote: >=20 > > > > On Dec 6, 2006, at 16:33, Cullen Jennings wrote: > >> I find this whole conversation way off base. If people=20 > would like to=20 > >> deprecate UDP, go work on a document to explain that and=20 > feel free to=20 > >> bring it to the WG. In the mean time, SIP is specified=20 > over both UDP=20 > >> and TCP. > > > > To be more specific, SIP is currently specified so it can=20 > use UDP for=20 > > requests smaller than 1300 bytes. It is specified so it=20 > can use TCP=20 > > for requests of any size. > > > > Some people have suggested that user agents SHOULD be able=20 > to send and=20 > > receive requests larger than 1300 bytes when using the outbound=20 > > mechanism. This seems like a logical requirement. Are you=20 > objecting=20 > > to this requirement Cullen? > > > > For the sake of this discussion, lets assume that we have=20 > consensus on=20 > > this requirement. What are the implications? Well, most UAs=20 > > implementing outbound are doing so because they are behind=20 > a NAT or a=20 > > firewall and will not be able to receive inbound TCP flows.=20 > These UAs=20 > > will need to establish a TCP flow if they want to meet this=20 > > requirement of receiving requests larger than 1300 bytes.=20 > The logical=20 > > normative statement is to say a UA which cannot (or suspects that it > > cannot) receive an inbound TCP flow from its outbound=20 > proxies SHOULD=20 > > open at least one TCP or TLS flow to a server in its=20 > > outbound-proxy-set. > > > > A few people on this mailing list have suggested that for any user=20 > > agent that actually bothers to open a TCP flow, there is no reason=20 > > whatsoever to open a corresponding UDP flow. I wholeheartedly agree=20 > > with them. > > > > The problem is that this thread strikes right at the heart of our=20 > > community's dilemma. We have a large body of people who=20 > have deployed=20 > > UDP almost exclusively and effectively ignore the MUST use (and=20 > > several even ignore the MUST implement) TCP statements in our core=20 > > spec. Ironically, one of the problems which prevents realistic=20 > > interoperable deployment of TCP-based SIP implementations=20 > is the lack=20 > > of a standardized mechanism for doing outbound. [Dean also=20 > identified=20 > > some other problems often faced when deploying TCP with=20 > programs that=20 > > use "obvious" (Dean actually said "naive") textbook implementation=20 > > techniques.] > > > > I think that a large number of the core spec contributors=20 > and seasoned=20 > > implementors now recognize that there are many non-academic=20 > problems=20 > > with SIP over UDP and that some day we will want to either=20 > deprecate=20 > > or at least seriously curtail the use of UDP. Like a very heavy=20 > > drinker we know it will be good for us to kick the habit. =20 > We are not=20 > > quitting today. The question before us is are we going to=20 > do something=20 > > in outbound that makes it harder for us to quit in the future. > > > > My concrete proposal is the following: > > - make CRLF the only keepalive mechanism for TCP and TLS=20 > over TCP flow=20 > > (retain STUN for UDP flows) > > - make outbound registrations over UDP flows optional for UAs > > - include the statement that its is RECOMMENDED that the=20 > > outbound-proxy-set is configured to result in registrations=20 > over TCP=20 > > or TLS whenever the UA can't accept incoming TCP flows (the 3GPP=20 > > exception). explain that for historical purposes a lot of=20 > deployments=20 > > still only use UDP, but that we expect/hope those deployments to=20 > > eventually migrate to TCP when doing outbound. > > > > What's in it for the TCP crowd? They get to implement=20 > outbound with=20 > > no UDP if they so desire. They don't have to implement=20 > STUN over TCP. > > The draft clearly explains why TCP is the technically preferred=20 > > solution. > > > > What's in it for the UDP crowd? They get outbound behavior=20 > (at least=20 > > for requests <1300 bytes) specified in the core draft for=20 > UDP. They=20 > > can keep doing what they are doing, but with STUN=20 > keepalives if the UA=20 > > and edge proxy both support it. > > > > What's not to like? > > thanks, > > -rohan > > > > > >> Most deployments only use UDP, some only use TCP, and I=20 > suspect there=20 > >> are some that do both but I am not aware of them. Outbound=20 > as it is=20 > >> seems very consistent with 3261 in that it allows a system=20 > to use TCP=20 > >> or UDP. Keeping this in mind few comments inline .... > >> > >> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: > >> > >>> Let's go back to the original topic - what should the draft say=20 > >>> about the transport protocol in relationship with outbound > >>> > >>> The major use case for outbound is UAs behind NAT /=20 > firewalls. Many=20 > >>> of such devices have known issues with UDP fragmentation, so for=20 > >>> many environments TCP will need to be used for messages=20 > larger than=20 > >>> the path MTU (often ~1460 bytes in ethernet environments, RFC3261=20 > >>> puts the limit at 1300). > >> > >> These known issues with fragmentation might be less common=20 > than you=20 > >> think however, outbound does not have anything to do with=20 > MTU issues. > >> It does not try and solve them and it does not make them worse. > >> > >>> > >>> If you start from the requirement "MUST only use UDP",=20 > then there is=20 > >>> little room for constructive discussions. For UDP-only to=20 > work you=20 > >>> will need to ensure that messages either stay below path MTUs, or=20 > >>> disallow NAT. This implies significant limitations for your=20 > >>> deployment environment. In any case, this is not a setup that=20 > >>> outbound should focus on. > >> > >> MTU is a problem regardless of NATs or Firewalls.=20 > Fragmented packets=20 > >> do manager to traverse most NATs and Firewalls. > >> > >>> > >>> In the general case, there are environments that have to=20 > deal with=20 > >>> NAT and messages larger than path MTU. This is what outbound was=20 > >>> written for. This also implies a UA that supports TCP. Given that=20 > >>> the UA supports TCP and the fact that presence of devices like=20 > >>> stateful firewalls cannot reliably be detected, the UA SHOULD use=20 > >>> TCP (or another connection oriented transport). If in=20 > addition the=20 > >>> UA supports TLS, it SHOULD use TLS. > >> > >> Again, this topic is not really about outbound. If you=20 > think a 3261=20 > >> UA that supports both UDP and TCP SHOULD use TCP, that is a fine=20 > >> argument to go make in the discussion about use of TCP and=20 > UDP but it=20 > >> seems to be an independent choice from anything to do with=20 > outbound. > >> > >> > >> Cullen > >> > >>> > >>> I think this is sufficient > >>> > >>> Regards, > >>> Jeroen > >>> > >>> Fredrik Thulin wrote: > >>>> Hisham Khartabil wrote: > >>>>> > >>>>> On Dec 5, 2006, at 3:33 PM, wrote: > >>>> ... > >>>>>> I personally believe going TCP-only would actually help=20 > >>>>>> deployment rather than hinder it, but I'd be really=20 > interested to=20 > >>>>>> be convinced otherwise. > >>>>> > >>>>> I could ask you the converse. I'd really be interested to be=20 > >>>>> convinced how TCP deployment improves scalability. > >>>> > >>>> To name two things where TCP would provide better=20 > scalability than=20 > >>>> UDP for a SIP service provider : > >>>> > >>>> 1) Say that your services maximum capacity for=20 > non-INVITEs is 1000 > >>>> requests per second. If you get 2000 in a single second, you > >>>> won't only have to deal with all those 2000=20 > requests, but also > >>>> with quite a few retransmissions sent after 500ms.=20 > With TCP,=20 > >>>> the > >>>> wall isn't as dense. > >>>> > >>>> 2) UDP sockets have a shared receive buffer, most=20 > commonly around > >>>> 64k I believe (even though the maximum seems to be 256k on > >>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on > >>>> average, you have to be able to move messages out of that=20 > >>>> buffer > >>>> pretty fast to keep it from filling up. A full buffer means > >>>> dropped packets. I've also heard that on for example Linux, > >>>> every packet actually occupies an even 2k (or was=20 > it 4k) in the > >>>> buffer, so 64k buffer is actually at most 32=20 > packets at a time. > >>>> > >>>> And then there are of course other aspects than=20 > scalability where=20 > >>>> UDP is an inferior solution, most notably security=20 > related things=20 > >>>> like for example spoofed CANCELs (which can't be challenged,=20 > >>>> RFC3261 #22.1). > >>>> > >>>> /Fredrik > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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=20 > 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=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 Dec 08 10:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshmc-0006G9-7A; Fri, 08 Dec 2006 10:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshma-0006FF-TA for sip@ietf.org; Fri, 08 Dec 2006 10:37:04 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GshmZ-0006tJ-HT for sip@ietf.org; Fri, 08 Dec 2006 10:37:04 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB8FXU229790; Fri, 8 Dec 2006 07:33:31 -0800 In-Reply-To: <45784E6C.3030006@cisco.com> References: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> <41b77144d7964f0dde0a8500db001688@ekabal.com> <45784E6C.3030006@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0fbed33f4d7fe56232bac3e27b6cab21@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 07:33:39 -0800 To: Michael Thomas X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Cullen Jennings , Rohan Mahy , Fredrik Thulin , sip@ietf.org, Markus.Isomaki@nokia.com, peter.leis@siemens.com, aki.niemi@nokia.com, "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 Hi, Well in this case, the compression they are using still makes it rare to receive > 1300 byte requests over the last hop even when they get requests from something in the public Internet that is substantially larger. Even over TCP it is still acceptable for a proxy or UA to reject a request that is too big. thanks, -rohan On Dec 7, 2006, at 9:25, Michael Thomas wrote: > Rohan Mahy wrote: >>> What if a client "knows" that it will never send or receive requests >>> larger than 1300 bytes? >> >> For most UAs the client will never be able to "know" that. In fact >> most UAs will be reasonably sure that they WILL be getting requests >> larger than this size. The only reason this is not a MUST is that we >> have some environments (like 3GPP) that are trying hard to keep >> requests under MTU size and where requests larger than this size are >> rare. > > And the minute that they interconnect to something that hasn't been > trying, the assumption gets blown clean out of the water, right? That > is the nature of an internet, right? I guess I don't see the point of > special casing something for the range of the moment. It seems like > the SHOULD isn't really a SHOULD at all because we know that > those assumptions will eventually bite because the SIP wg sure isn't > putting any energy in making that true for the Internet at large. > > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 08 10:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshpo-0007T1-FL; Fri, 08 Dec 2006 10:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gshpm-0007St-Er for sip@ietf.org; Fri, 08 Dec 2006 10:40:22 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gshpl-00079k-Kg for sip@ietf.org; Fri, 08 Dec 2006 10:40:22 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB8Fdv229956; Fri, 8 Dec 2006 07:39:58 -0800 In-Reply-To: <7374777208BDC7449D5620EF94232567D9EDBC@esealmw113.eemea.ericsson.se> References: <7374777208BDC7449D5620EF94232567D9EDBC@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8e6202ded939f3e119ea0d07b99e993e@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 07:40:06 -0800 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: SIP WG , 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 Dec 8, 2006, at 5:57, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > > A couple of questions: > > 1. What was the reason(s) the CRLF solution is not suitable for UDP? You can't detect that a NAT has rebooted and your binding has changed over UDP unless your message contains the reflected address. > 2. Even for UDP it can be possible to use lower layer keep-alive > mechanisms, e.g. when UDP encapsulated IPSec, is used, so I think one > should be allowed to use that instead of STUN. There is not MUST USE for keepalive=stun, so I think this is tacitly permitted anyway. thanks, -rohan > Regards, > > Christer > > > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: 8. joulukuuta 2006 15:49 >> To: Rohan Mahy >> Cc: SIP WG >> Subject: Re: [Sip] Re: issue with oubound and the used >> transport protocol >> >> I like this proposal and support it. >> >> Hisham >> >> On Dec 7, 2006, at 6:15 AM, Rohan Mahy wrote: >> >>> >>> On Dec 6, 2006, at 16:33, Cullen Jennings wrote: >>>> I find this whole conversation way off base. If people >> would like to >>>> deprecate UDP, go work on a document to explain that and >> feel free to >>>> bring it to the WG. In the mean time, SIP is specified >> over both UDP >>>> and TCP. >>> >>> To be more specific, SIP is currently specified so it can >> use UDP for >>> requests smaller than 1300 bytes. It is specified so it >> can use TCP >>> for requests of any size. >>> >>> Some people have suggested that user agents SHOULD be able >> to send and >>> receive requests larger than 1300 bytes when using the outbound >>> mechanism. This seems like a logical requirement. Are you >> objecting >>> to this requirement Cullen? >>> >>> For the sake of this discussion, lets assume that we have >> consensus on >>> this requirement. What are the implications? Well, most UAs >>> implementing outbound are doing so because they are behind >> a NAT or a >>> firewall and will not be able to receive inbound TCP flows. >> These UAs >>> will need to establish a TCP flow if they want to meet this >>> requirement of receiving requests larger than 1300 bytes. >> The logical >>> normative statement is to say a UA which cannot (or suspects that it >>> cannot) receive an inbound TCP flow from its outbound >> proxies SHOULD >>> open at least one TCP or TLS flow to a server in its >>> outbound-proxy-set. >>> >>> A few people on this mailing list have suggested that for any user >>> agent that actually bothers to open a TCP flow, there is no reason >>> whatsoever to open a corresponding UDP flow. I wholeheartedly agree >>> with them. >>> >>> The problem is that this thread strikes right at the heart of our >>> community's dilemma. We have a large body of people who >> have deployed >>> UDP almost exclusively and effectively ignore the MUST use (and >>> several even ignore the MUST implement) TCP statements in our core >>> spec. Ironically, one of the problems which prevents realistic >>> interoperable deployment of TCP-based SIP implementations >> is the lack >>> of a standardized mechanism for doing outbound. [Dean also >> identified >>> some other problems often faced when deploying TCP with >> programs that >>> use "obvious" (Dean actually said "naive") textbook implementation >>> techniques.] >>> >>> I think that a large number of the core spec contributors >> and seasoned >>> implementors now recognize that there are many non-academic >> problems >>> with SIP over UDP and that some day we will want to either >> deprecate >>> or at least seriously curtail the use of UDP. Like a very heavy >>> drinker we know it will be good for us to kick the habit. >> We are not >>> quitting today. The question before us is are we going to >> do something >>> in outbound that makes it harder for us to quit in the future. >>> >>> My concrete proposal is the following: >>> - make CRLF the only keepalive mechanism for TCP and TLS >> over TCP flow >>> (retain STUN for UDP flows) >>> - make outbound registrations over UDP flows optional for UAs >>> - include 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 (the 3GPP >>> exception). explain that for historical purposes a lot of >> deployments >>> still only use UDP, but that we expect/hope those deployments to >>> eventually migrate to TCP when doing outbound. >>> >>> What's in it for the TCP crowd? They get to implement >> outbound with >>> no UDP if they so desire. They don't have to implement >> STUN over TCP. >>> The draft clearly explains why TCP is the technically preferred >>> solution. >>> >>> What's in it for the UDP crowd? They get outbound behavior >> (at least >>> for requests <1300 bytes) specified in the core draft for >> UDP. They >>> can keep doing what they are doing, but with STUN >> keepalives if the UA >>> and edge proxy both support it. >>> >>> What's not to like? >>> thanks, >>> -rohan >>> >>> >>>> Most deployments only use UDP, some only use TCP, and I >> suspect there >>>> are some that do both but I am not aware of them. Outbound >> as it is >>>> seems very consistent with 3261 in that it allows a system >> to use TCP >>>> or UDP. Keeping this in mind few comments inline .... >>>> >>>> On Dec 5, 2006, at 1:44 PM, Jeroen van Bemmel wrote: >>>> >>>>> Let's go back to the original topic - what should the draft say >>>>> about the transport protocol in relationship with outbound >>>>> >>>>> The major use case for outbound is UAs behind NAT / >> firewalls. Many >>>>> of such devices have known issues with UDP fragmentation, so for >>>>> many environments TCP will need to be used for messages >> larger than >>>>> the path MTU (often ~1460 bytes in ethernet environments, RFC3261 >>>>> puts the limit at 1300). >>>> >>>> These known issues with fragmentation might be less common >> than you >>>> think however, outbound does not have anything to do with >> MTU issues. >>>> It does not try and solve them and it does not make them worse. >>>> >>>>> >>>>> If you start from the requirement "MUST only use UDP", >> then there is >>>>> little room for constructive discussions. For UDP-only to >> work you >>>>> will need to ensure that messages either stay below path MTUs, or >>>>> disallow NAT. This implies significant limitations for your >>>>> deployment environment. In any case, this is not a setup that >>>>> outbound should focus on. >>>> >>>> MTU is a problem regardless of NATs or Firewalls. >> Fragmented packets >>>> do manager to traverse most NATs and Firewalls. >>>> >>>>> >>>>> In the general case, there are environments that have to >> deal with >>>>> NAT and messages larger than path MTU. This is what outbound was >>>>> written for. This also implies a UA that supports TCP. Given that >>>>> the UA supports TCP and the fact that presence of devices like >>>>> stateful firewalls cannot reliably be detected, the UA SHOULD use >>>>> TCP (or another connection oriented transport). If in >> addition the >>>>> UA supports TLS, it SHOULD use TLS. >>>> >>>> Again, this topic is not really about outbound. If you >> think a 3261 >>>> UA that supports both UDP and TCP SHOULD use TCP, that is a fine >>>> argument to go make in the discussion about use of TCP and >> UDP but it >>>> seems to be an independent choice from anything to do with >> outbound. >>>> >>>> >>>> Cullen >>>> >>>>> >>>>> I think this is sufficient >>>>> >>>>> Regards, >>>>> Jeroen >>>>> >>>>> Fredrik Thulin wrote: >>>>>> Hisham Khartabil wrote: >>>>>>> >>>>>>> On Dec 5, 2006, at 3:33 PM, wrote: >>>>>> ... >>>>>>>> I personally believe going TCP-only would actually help >>>>>>>> deployment rather than hinder it, but I'd be really >> interested to >>>>>>>> be convinced otherwise. >>>>>>> >>>>>>> I could ask you the converse. I'd really be interested to be >>>>>>> convinced how TCP deployment improves scalability. >>>>>> >>>>>> To name two things where TCP would provide better >> scalability than >>>>>> UDP for a SIP service provider : >>>>>> >>>>>> 1) Say that your services maximum capacity for >> non-INVITEs is 1000 >>>>>> requests per second. If you get 2000 in a single second, you >>>>>> won't only have to deal with all those 2000 >> requests, but also >>>>>> with quite a few retransmissions sent after 500ms. >> With TCP, >>>>>> the >>>>>> wall isn't as dense. >>>>>> >>>>>> 2) UDP sockets have a shared receive buffer, most >> commonly around >>>>>> 64k I believe (even though the maximum seems to be 256k on >>>>>> FreeBSD at least). With SIP messages of perhaps 700 bytes on >>>>>> average, you have to be able to move messages out of that >>>>>> buffer >>>>>> pretty fast to keep it from filling up. A full buffer means >>>>>> dropped packets. I've also heard that on for example Linux, >>>>>> every packet actually occupies an even 2k (or was >> it 4k) in the >>>>>> buffer, so 64k buffer is actually at most 32 >> packets at a time. >>>>>> >>>>>> And then there are of course other aspects than >> scalability where >>>>>> UDP is an inferior solution, most notably security >> related things >>>>>> like for example spoofed CANCELs (which can't be challenged, >>>>>> RFC3261 #22.1). >>>>>> >>>>>> /Fredrik >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP 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 Fri Dec 08 11:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiI4-0001gl-PW; Fri, 08 Dec 2006 11:09:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiI2-0001gL-EP; Fri, 08 Dec 2006 11:09:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsiHz-0003Lv-Rc; Fri, 08 Dec 2006 11:09:34 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2006 08:09:27 -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 kB8G9R1a012527; Fri, 8 Dec 2006 08:09:27 -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 kB8G9BdU026704; Fri, 8 Dec 2006 08:09:16 -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); Fri, 8 Dec 2006 11:09:15 -0500 Received: from [10.86.240.238] ([10.86.240.238]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 11:09:14 -0500 Message-ID: <45798E2A.8010709@cisco.com> Date: Fri, 08 Dec 2006 11:09:14 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Eanny Bae Subject: Re: [Sip] The support of multiple connection line 'c=' in SIP UA. References: <0J9Y001N81ZNA2@mmp1.samsung.com> In-Reply-To: <0J9Y001N81ZNA2@mmp1.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2006 16:09:15.0076 (UTC) FILETIME=[34E66040:01C71AE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5643; t=1165594167; x=1166458167; 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]=20The=20support=20of=20multiple=20connection=20 line=20'c=3D'=20in=20SIP=20UA. |Sender:=20; bh=Ycxftw2MGhGWAoG59Ejx40aNspw0P0w0JCaR2t3/jYc=; b=bucfiEo3YQgLy63F9xCqlPC/9pg7dYBtt/Ikn8MDdX8CZglHoCCaYwuqPd7p8WYQfBsXOr5s MBT774/GxY/aRVBpmwdSy4+8r0MPGHLiZvnRiqpC8uyEmTcb7f8IDEGz; 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: ee80a2074afbfe28d15369f4e74e579d Cc: 'SIP' , 'sipping' , 'mmusic' 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 with Attila. But I'm not sure from your comments if you are understanding fully, so let me try again. An SDP can have one or more media descriptions, each beginning with an m= line. (Actually it can have zero media descriptions, but that isn't very interesting.) Each media description needs connection data. If there is more than one media description, then the connection data for each may be different, or multiple media descriptions may have the same connection data. If there is a c= line following an m= line, and before another m= line, then that provides the connection data for that media description. If there is no c= line following the m= line, then the media description uses the c= line from the session description - the one before the first m= line. It is legal, for each media description to contain its own c= line, and for there also to be a c= line in the session description, even though in that case the one in the session description serves no purpose. A UA must be prepared to receive SDP formatted in any of these ways. Paul Eanny Bae wrote: > Dear Attila Sipos, > > Thanks for quick answer. >>From your kindly explanation, I got to clarify that all SIP UA can support > SDP including multiple media description having a different connection > ('c=') value per media type. Furthermore, I believe this capability is a > basic capability of SIP UA. > > Best Regards, > Eanny Bae > > ----------------------------------------------------- > Eanny Bae (Ms.) > > Engineer > Samsung Electronics Co., Ltd. > Tel) +82-31-279-5886 > Mobile) +82-16-9530-5886 > E-Mail) eanny.bae@samsung.com > ----------------------------------------------------- > > -----Original Message----- > From: Attila Sipos [mailto:Attila.Sipos@vegastream.com] > Sent: Friday, December 08, 2006 3:56 PM > To: Eanny Bae; mmusic; sipping; SIP > Subject: RE: [Sip] The support of multiple connection line 'c=' in SIP UA. > > RFC 4566 says... > > 5.7. Connection Data ("c=") > > c= > > The "c=" field contains connection data. > > A session description MUST contain either at least one "c=" field in > each media description or a single "c=" field at the session level. > It MAY contain a single session-level "c=" field and additional "c=" > field(s) per media description, in which case the per-media values > override the session-level settings for the respective media. > > The "session description" above is the bit before any m= lines. > The "media descriptions" start with an m= line. > So an SDP has 1 session description section and can have > multiple media descriptions. > > so as examples or positioning of c= lines, you can have: > > 1. There is one c= line at the session description > Each media description uses the connection information from > that top c= line. > c=.... // session description > m=.... // 1st media description > a=..... > m=.... // 2nd media description > a=..... > > or > > > 2. Each media description has its own c= line > (There is no session description c= line): > > > // session description (no c= line) > m=.... // 1st media description > c=.... > a=..... > m=.... // 2nd media description > c=.... > a=..... > > > or > > 3. There is a session description c= line but the first > media description has its own c= line , so the first > media description's c= line overrides the session description c= line. > The 2nd media description uses the c= line in the session description. > c=.... // session description > m=.... // 1st media description > c=.... > a=..... > m=.... // 2nd media description > a=..... > > > Regards, > Attila > > -----Original Message----- > From: Eanny Bae [mailto:eanny.bae@samsung.com] > Sent: Fri 08/12/2006 05:42 > To: 'mmusic'; 'sipping'; 'SIP' > Cc: > Subject: [Sip] The support of multiple connection line 'c=' in SIP > UA. > > > > Dear all SIP experts, > > > > Related with the usage of this multiple connections in SDP, I'd like > to get a clarification from all your SIP experts. > > The IETF RFC 4317 provides some examples for multiple connection > lines (i.e. 'c=') in SDP offer and SDP answer. > > Even though IETF RFC 4566 (SDP), there is no clear definition of the > usage of multiple connection lines in SDP. Can it be expected that all SIP > UA support media transmission to/from multiple IP addresses in a single > session. i.e. Can supporting multiple connection('c=') lines be regarded as > a basic capability of the SIP UA? > > > > Best Regards, > > Eanny Bae > > > > > > ----------------------------------------------------- > Eanny Bae (Ms.) > > Engineer > Samsung Electronics Co., Ltd. > Tel) +82-31-279-5886 > Mobile) +82-16-9530-5886 > E-Mail) eanny.bae@samsung.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 Dec 08 12:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsj4y-00065b-22; Fri, 08 Dec 2006 12:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsj4u-00063e-NP; Fri, 08 Dec 2006 12:00:04 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsj4p-0002ZJ-57; Fri, 08 Dec 2006 12:00:04 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id kB8Gxr9r004732; Fri, 8 Dec 2006 10:59:54 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:59:53 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 17:59:51 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Dec 2006 17:59:49 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180959F35@DEEXC1U01.de.lucent.com> In-Reply-To: <457970DF.4030900@ives.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Re: [reSIProcate] Information carried by SIP Message -regarding Thread-Index: Acca5IowqEso3leNR+e5VPf34KCmGwABVefw From: "Drage, Keith \(Keith\)" To: "Emmanuel BUU" , "Raj" X-OriginalArrivalTime: 08 Dec 2006 16:59:51.0590 (UTC) FILETIME=[46CDA460:01C71AEA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: SIP forum , SIP forum , SIP Proposal Investigation , SIP Resiprocate Subject: [Sip] RE: [Sipping] Re: [reSIProcate] Information carried by SIP Message -regarding 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 suspect what you need is=20 http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-0= 9.txt Regards Keith P.S. If you ever intend using INFO for any application, I suggest you = test the water with an internet-draft on the subject before doing so. = Many proposed INFO usages are regarded as inappropriate to SIP. > -----Original Message----- > From: Emmanuel BUU [mailto:emmanuel.buu@ives.fr]=20 > Sent: 08 December 2006 14:04 > To: Raj > Cc: SIP forum; SIP Proposal Investigation; SIP forum; SIP Resiprocate > Subject: [Sipping] Re: [reSIProcate] Information carried by=20 > SIP Message -regarding >=20 > There is an INFO message that can be used for this purpose >=20 > Raj a =E9crit : > > Hello, > > > > I know that SIP can carry signalling information and media=20 > > information. Is it possible to make SIP to carry=20 > information related=20 > > to configuration of the end devices or any other=20 > information that user=20 > > wants to exchange. > > > > Thanks in advance > > > > with regards > > Raj. > > > >=20 > ---------------------------------------------------------------------- > > -- Access over 1 million songs - Yahoo! Music Unlimited. > >=20 > = > ahoo.com/unlimited/> > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > resiprocate-devel mailing list > > resiprocate-devel@list.resiprocate.org > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel >=20 >=20 > -- > logo >=20 > Emmanuel BUU - G=E9rant / General=20 > Manager - IV=E8S >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core 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 Dec 08 12:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjkI-0006kq-Sr; Fri, 08 Dec 2006 12:42:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsjkH-0006kl-4l for sip@ietf.org; Fri, 08 Dec 2006 12:42:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsjkF-00086G-QH for sip@ietf.org; Fri, 08 Dec 2006 12:42:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2006 09:42:46 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kB8HgjBl020547; Fri, 8 Dec 2006 09:42:45 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kB8HgZdE015030; Fri, 8 Dec 2006 09:42:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:42:34 -0800 Received: from [192.168.1.3] ([10.21.146.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:42:33 -0800 In-Reply-To: <34f07dacefcdbf71845564a5170b88cc@telio.no> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> <34f07dacefcdbf71845564a5170b88cc@telio.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A6CF5A8-A194-4B5C-BBF1-28034F8A14A4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 09:42:48 -0800 To: Hisham Khartabil X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Dec 2006 17:42:33.0738 (UTC) FILETIME=[3DF666A0:01C71AF0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=881; t=1165599765; x=1166463765; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=6B8GtAQfOT1UesW0bcARaftY+bwBMiRPfoLHtfPQ554=; b=L/zsPMXTxO1kTNG9s8bkTgc8vD14v9POT85I0URZsfbgO0ZgrCL0UGe2bbFl3KeKuxIbosB0 hZkLjAq5fLHBhLcwIW+p+xdjLeWj8qv94+A9YMWn+9QhWVQXkgbIvKWF; 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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 Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: > Please, lets not wait until March to discuss this. We can take a > hum here on the mailing list We had most of a room hum the other direction so, which did leave me thinking, assuming we don't get a single no on the the list, how many yes do think the chairs should be looking for to overturn this? I don't really want to know the answer to this as this is something that only the chairs need to figure out but it is an interesting question to think about when thinking about reopening this. And just so people understand my position on this, if we reopen this issue, I will be voting for whichever path I think can get the draft to the IESG the soonest. I've implemented both and they are both trivial to implement. I really believe that what we need is to stop delaying this 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 Fri Dec 08 12:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsjlx-0007fS-RP; Fri, 08 Dec 2006 12:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsjlw-0007fN-B2 for sip@ietf.org; Fri, 08 Dec 2006 12:44:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsjlu-0008Mx-UK for sip@ietf.org; Fri, 08 Dec 2006 12:44:32 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2006 09:44:28 -0800 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 kB8HiRBx023056; Fri, 8 Dec 2006 09:44:27 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8Hi4iw017112; Fri, 8 Dec 2006 09:44:17 -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); Fri, 8 Dec 2006 09:44:14 -0800 Received: from [192.168.1.3] ([10.21.146.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 09:44:13 -0800 In-Reply-To: <004f01c71a4e$ab1a5770$0601a8c0@BEMBUSTER> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER><3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com><602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> <953beacc0612071357v243b4fb2m8bda0f149eddd6a6@mail.gmail.com> <004f01c71a4e$ab1a5770$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CF8F328-47FA-4555-9D3D-ED7DB2EE8157@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 09:44:29 -0800 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Dec 2006 17:44:14.0021 (UTC) FILETIME=[79BC5F50:01C71AF0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2786; t=1165599867; x=1166463867; 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]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=F00unb1j2QkgPnmel4CyBP931IMJBSmWHfjyc2Jj6QE=; b=aI2OwqiD4/VHcbshmmk31G9NnITakn5JiYSq70Fx6HIHKwyq46mSsysiyKQqFx1RhJ3iPDCv u/FfZsCf6td2mJ4Wvi+HiNXXrykjnzQLCXApW1BG9CwGwz+h6xoUK024; 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: 52f7a77164458f8c7b36b66787c853da Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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 Dec 7, 2006, at 2:25 PM, Jeroen van Bemmel wrote: > hum. This is not about deprecating UDP, it's about avoiding > unnecessary complexity for TCP (and TLS) I can understand the argument that what keep alive we use in TCP is about avoiding unnecessary complexity for TCP and I'm fine with discussing that (thus my email to the chairs) however, Rohan's proposal contained other things that are separate issues. And how keep-alives work is very relevant to this draft. What protocols operators choose to use is an issue orthogonal to this draft (and a very complicated issue). > > Regards, > Jeroen > > Rohan Mahy wrote: >> Hi, >> >> - The argument for using STUN over TCP was "for consistency with >> UDP". >> However the code necessary to demux STUN and SIP over TCP is pretty >> much orthogonal to the code to demux STUN and SIP over UDP. >> - In addition to being simpler, CRLF over TCP is backwards compatible >> with RFC 3261 implementations. >> >> I believe the WG made the decision it did based on the erroneous >> assumption that STUN over TCP would be easier since implementations >> would have to implement STUN for UDP anyway. I would like to reopen >> this decision because I believe it was based on faulty data. In >> addition, if we allow UAs to only implement outbound over TCP, this >> woudl be yet another assumption that would no longer hold true. >> >> thanks, >> -rohan >> >> On 12/7/06, Cullen Jennings wrote: >>> Dear chairs, >>> >>> Rohan has always disagreed with our TCP keep alive mechanism. He has >>> brought this up over many meetings. IT has been discussed many times >>> and we have taken WG hums on it. This whole argument that he is >>> creating is centered around trying to kill the way TCP keep alive >>> are >>> done. He is not alone, others agree with him. The basic argument >>> against it is it is a pain to implement - I've implemented and did >>> not find it a big deal but agree it is more complicated that >>> implementing the Double CRLF approach. We did have reasonable good >>> consensus for it in the last WG hum we took on it. >>> >>> I would like the chairs to make a statement about if they want >>> reopen >>> the issue of how to do TCP Keep alives. If yes, I'm glad to present >>> on it at next IETF, if not, I want to know that I can just ignore >>> it. >>> >>> Cullen (with my outbound editor hat on) >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Dec 08 13:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskAo-0000Ze-Tl; Fri, 08 Dec 2006 13:10:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskAo-0000ZZ-0m for sip@ietf.org; Fri, 08 Dec 2006 13:10:14 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GskAm-0003J8-NM for sip@ietf.org; Fri, 08 Dec 2006 13:10:14 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2006 10:10:11 -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 kB8IAAkp032100; Fri, 8 Dec 2006 10:10:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB8IA2j8012367; Fri, 8 Dec 2006 10:10:10 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:10:02 -0800 Received: from [192.168.1.3] ([10.21.146.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 10:10:02 -0800 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E379B63@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 10:10:17 -0800 To: Francois Audet X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Dec 2006 18:10:02.0447 (UTC) FILETIME=[14AB6DF0:01C71AF4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1319; t=1165601410; x=1166465410; 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=20[Sip]=20Re=3A=20issue=20with=20oubound=20and=20the=20 used=20transport=20protocol |Sender:=20; bh=Raa/JWs/MSN2gUc9BCY+11ner9hpK3ikMhEn1xnwmbg=; b=NOvnhTvnmL447vsFGBCJNE82lollcftalJe8x7ppVN86o0IJJ0dTF89EvU6n7W7JBCSWN0I4 Lvng8wZ5ClE7gdJWB2KqwfbRMSjY5eiCbmPaamYs27WTzEtL+sOUqcvX; 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: 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 On Nov 30, 2006, at 9:45 AM, Francois Audet wrote: > Didn't we agree way back NOT to use PING, CRLF, etc., and use STUN > instead? > > Why is this debate being re-opened? > > Remember: I favored the non-STUN TCP approach. However, if we can't > stick to a decision, > we'll debate this forever. It already feels like it. I was thinking, wow, we won't really repeat the exact same conversation over again. But then I read the thread below and realized that I can not imagine this conversation going any differently than the last several times we have done it. On Dec 8, 2006, at 7:40 AM, Rohan Mahy wrote: > > On Dec 8, 2006, at 5:57, Christer Holmberg ((JO/LMF)) wrote: > >> >> Hi, >> >> A couple of questions: >> >> 1. What was the reason(s) the CRLF solution is not suitable for UDP? > > You can't detect that a NAT has rebooted and your binding has > changed over UDP unless your message contains the reflected address. > >> 2. Even for UDP it can be possible to use lower layer keep-alive >> mechanisms, e.g. when UDP encapsulated IPSec, is used, so I think one >> should be allowed to use that instead of STUN. > > There is not MUST USE for keepalive=stun, so I think this is > tacitly permitted anyway. > > thanks, > -rohan > >> 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 Dec 08 17:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso6R-0004Fx-U3; Fri, 08 Dec 2006 17:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gso6P-0004D3-MR for sip@ietf.org; Fri, 08 Dec 2006 17:21:57 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gso6N-0000fv-Cz for sip@ietf.org; Fri, 08 Dec 2006 17:21:56 -0500 Received: from [172.16.4.17] ([172.16.4.17]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kB8MLeBu014833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Dec 2006 16:21:47 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> From: Byron Campen Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 16:21:44 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0868441370==" Errors-To: sip-bounces@ietf.org --===============0868441370== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-478229297; protocol="application/pkcs7-signature" --Apple-Mail-10-478229297 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This looks sensible to me. But, I would like clarification on one point; are you proposing that server implementations of outbound (registrar, edge proxy) must (still) support outbound over UDP? Or would it be optional for these elements as well? Best regards, Byron Campen > My concrete proposal is the following: > - make CRLF the only keepalive mechanism for TCP and TLS over TCP > flow (retain STUN for UDP flows) > - make outbound registrations over UDP flows optional for UAs > - include 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 (the 3GPP > exception). explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > What's in it for the TCP crowd? They get to implement outbound > with no UDP if they so desire. They don't have to implement STUN > over TCP. The draft clearly explains why TCP is the technically > preferred solution. > > What's in it for the UDP crowd? They get outbound behavior (at > least for requests <1300 bytes) specified in the core draft for > UDP. They can keep doing what they are doing, but with STUN > keepalives if the UA and edge proxy both support it. > > What's not to like? > thanks, > -rohan --Apple-Mail-10-478229297 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjA4 MjIyMTQ1WjAjBgkqhkiG9w0BCQQxFgQUMRGOhbhqQ0wRPyHOeHaFjXl7ITYwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBANAV8jpJ 6D8HAc2HvIAGr5oeTtYKCip2EEhSYwP3p6BtYwEIRKIe8oEtnhFiaZ436+ZWCJXkPiENnsTifFIp Ayp7Dt/gteDbcUFF4SMaAGb7flOe5rThmrVY90/YYq9QbBCc4gFBqFGWDw8I847nvdSKNNGhO4GF KMQs69lbJbr92B3S+WVTRq3E33CzBoAxJPl03wEVPQNa9Yh25+EBp5QPZXB+6whV88VNJIkSJv+C rmLyemlPzUIwdlRcL/5AMaNG48cMRJL97cIdeNfAbdIKoxBkLmFTR/ACBUxAiM0D963X1t8Gozth Ip05+xDpNH6noujURqCC8EkfWujZKZgAAAAAAAA= --Apple-Mail-10-478229297-- --===============0868441370== 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 --===============0868441370==-- From sip-bounces@ietf.org Fri Dec 08 19:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsq8y-0003LK-DF; Fri, 08 Dec 2006 19:32:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsq8w-0003LA-5m for sip@ietf.org; Fri, 08 Dec 2006 19:32:42 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsq8u-0001Ea-Re for sip@ietf.org; Fri, 08 Dec 2006 19:32:42 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB90Vh503773; Fri, 8 Dec 2006 19:31:44 -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] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 18:31:12 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E5B2A48@zrc2hxm0.corp.nortel.com> In-Reply-To: <2A6CF5A8-A194-4B5C-BBF1-28034F8A14A4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol thread-index: Acca8JHlmXPTIQRjQnm9Xf7SWjUsogANxesg From: "Francois Audet" To: "Cullen Jennings" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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, My best guest on why this is happening is that people used to be thinking more about UDP than TCP and consequently expressed a preference for the STUN approach. It seems now that more people are paying attention to TCP because of a bunch of issues with UDP (including fragmentation, and TLS usage catching up since it took us so long to finalize this document). Many are reaching the conclusion that=20 the CRLF approach makes more sense for TCP. It seems that Rohan's last proposal of using CRLF for TCP, and STUN for UDP to be reasonable and logical. And it seems to have lots of support on the list. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Friday, December 08, 2006 09:43 > To: Hisham Khartabil > Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus=20 > (Nokia-TP/Espoo); Peter Leis; Aki Niemi; Dean Willis; Keith Drage > Subject: Re: [Sip] Re: issue with oubound and the used=20 > transport protocol >=20 >=20 > On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: >=20 > > Please, lets not wait until March to discuss this. We can=20 > take a hum=20 > > here on the mailing list >=20 > We had most of a room hum the other direction so, which did=20 > leave me thinking, assuming we don't get a single no on the=20 > the list, how many yes do think the chairs should be looking=20 > for to overturn this? I don't really want to know the answer=20 > to this as this is something that only the chairs need to=20 > figure out but it is an interesting question to think about=20 > when thinking about reopening this. >=20 > And just so people understand my position on this, if we=20 > reopen this issue, I will be voting for whichever path I=20 > think can get the draft to the IESG the soonest. I've=20 > implemented both and they are both trivial to implement. I=20 > really believe that what we need is to stop delaying this 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 Fri Dec 08 21:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrXK-00080c-I8; Fri, 08 Dec 2006 21:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrXI-00080W-NC for sip@ietf.org; Fri, 08 Dec 2006 21:01:56 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsrXH-00058U-EN for sip@ietf.org; Fri, 08 Dec 2006 21:01:56 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kB915mZH013475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Dec 2006 19:05:49 -0600 In-Reply-To: <2A6CF5A8-A194-4B5C-BBF1-28034F8A14A4@cisco.com> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <602B0FE7-A428-4509-B2EA-6C4C16A64D3C@cisco.com> <34f07dacefcdbf71845564a5170b88cc@telio.no> <2A6CF5A8-A194-4B5C-BBF1-28034F8A14A4@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A4FB784-A186-4791-8B35-F0E0157AF967@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 20:01:31 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Keith Drage 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 Dec 8, 2006, at 11:42 AM, Cullen Jennings wrote: > > On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: > >> Please, lets not wait until March to discuss this. We can take a >> hum here on the mailing list > > We had most of a room hum the other direction so, which did leave > me thinking, assuming we don't get a single no on the the list, how > many yes do think the chairs should be looking for to overturn > this? I don't really want to know the answer to this as this is > something that only the chairs need to figure out but it is an > interesting question to think about when thinking about reopening > this. > As a chair, I'd be looking for "Yes" statements from a significant number of the implementors and folks who supported the STUN/TCP position in the previous hums. Continued calls for a revote that seem to have support only from the minority that supported CR/LF for TCP the first time around represent intransigence, not a change in working group position. But hey, I'll Ask . . . > And just so people understand my position on this, if we reopen > this issue, I will be voting for whichever path I think can get the > draft to the IESG the soonest. I've implemented both and they are > both trivial to implement. I really believe that what we need is to > stop delaying this draft. Yea, verily! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 08 21:12:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrhI-0003Cb-47; Fri, 08 Dec 2006 21:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrhG-0003CW-Hx for sip@ietf.org; Fri, 08 Dec 2006 21:12:14 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsrhF-0007kA-86 for sip@ietf.org; Fri, 08 Dec 2006 21:12:14 -0500 Received: from [192.168.2.102] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kB91GM9g013544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Dec 2006 19:16:22 -0600 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: SIP IETF From: Dean Willis Date: Fri, 8 Dec 2006 20:12:05 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-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 Previously we had recorded consensus to use STUN for keepalive with both TCP and UDP. This was not a perfect consensus (there were some dissenters). There has been ongoing discussion notably instigated by the current editor of the Outbound draft, that some people feel may have resulted in a change of the consensus on this draft's technical direction. So I'd like to ask people who care and think they understand the differences to answer the following questions, on-list and on-the record. Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over TCP flow (retain STUN for UDP flows). Yes (accept the proposal and use CRLF for TCP) or No (reject the proposal and keep STUN for TCP) Proposal 2: Make outbound registrations over UDP flows optional for UAs. Yes (Accept the proposal) or No (Reject the proposal). 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. Further, include text that explain that for historical purposes a lot of deployments still only use UDP, but that we expect/ hope those deployments to eventually migrate to TCP when doing outbound. Yes (Accept the proposal and add the text) or No (Reject the proposal and keep the text as-is). -- Dean Willis (wearing his chair sombrero) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 09 00:42:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsuvA-0008Q1-RH; Sat, 09 Dec 2006 00:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsuv9-0008Pw-5W for sip@ietf.org; Sat, 09 Dec 2006 00:38:47 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsuv7-0001Cg-W1 for sip@ietf.org; Sat, 09 Dec 2006 00:38:47 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <2006120905384501400q1g9de>; Sat, 9 Dec 2006 05:38:45 +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 kB95ci1G022590 for ; Sat, 9 Dec 2006 00:38:44 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kB95ciEn022586; Sat, 9 Dec 2006 00:38:44 -0500 Date: Sat, 9 Dec 2006 00:38:44 -0500 Message-Id: <200612090538.kB95ciEn022586@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0fbed33f4d7fe56232bac3e27b6cab21@ekabal.com> (rohan@ekabal.com) Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <7374777208BDC7449D5620EF94232567D40213@esealmw113.eemea.ericsson.se> <41b77144d7964f0dde0a8500db001688@ekabal.com> <45784E6C.3030006@cisco.com> <0fbed33f4d7fe56232bac3e27b6cab21@ekabal.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: Rohan Mahy Well in this case, the compression they are using still makes it rare to receive > 1300 byte requests over the last hop even when they get requests from something in the public Internet that is substantially larger. Even over TCP it is still acceptable for a proxy or UA to reject a request that is too big. I suppose it's possible, but it seems to be strongly discouraged. RFC 3261 says that an implementation must be willing to accept 64k-1 byte UDP requests: 18.1.1. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. 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 Sat Dec 09 00:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsvA1-0005Ao-Iy; Sat, 09 Dec 2006 00:54:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsv9z-00058a-KX for sip@ietf.org; Sat, 09 Dec 2006 00:54:07 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsv9y-0003HP-98 for sip@ietf.org; Sat, 09 Dec 2006 00:54:07 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kB95rm215664; Fri, 8 Dec 2006 21:53:48 -0800 In-Reply-To: <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Fri, 8 Dec 2006 21:54:00 -0800 To: Byron Campen X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, 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 Edge Proxies and Registrars would still need to support outbound with UDP. thanks, -rohan On Dec 8, 2006, at 14:21, Byron Campen wrote: > This looks sensible to me. But, I would like clarification on one > point; are you proposing that server implementations of outbound > (registrar, edge proxy) must (still) support outbound over UDP? Or > would it be optional for these elements as well? > > Best regards, > Byron Campen > > >> My concrete proposal is the following: >> - make CRLF the only keepalive mechanism for TCP and TLS over TCP >> flow (retain STUN for UDP flows) >> - make outbound registrations over UDP flows optional for UAs >> - include 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 (the 3GPP >> exception). explain that for historical purposes a lot of >> deployments still only use UDP, but that we expect/hope those >> deployments to eventually migrate to TCP when doing outbound. >> >> What's in it for the TCP crowd? They get to implement outbound with >> no UDP if they so desire. They don't have to implement STUN over >> TCP. The draft clearly explains why TCP is the technically preferred >> solution. >> >> What's in it for the UDP crowd? They get outbound behavior (at least >> for requests <1300 bytes) specified in the core draft for UDP. They >> can keep doing what they are doing, but with STUN keepalives if the >> UA and edge proxy both support it. >> >> What's not to like? >> thanks, >> -rohan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 09 06:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszxV-0001m0-U7; Sat, 09 Dec 2006 06:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszxU-0001io-Jo for sip@ietf.org; Sat, 09 Dec 2006 06:01:32 -0500 Received: from smtp4.versatel.nl ([62.58.50.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GszxT-00040p-7y for sip@ietf.org; Sat, 09 Dec 2006 06:01:32 -0500 Received: (qmail 21896 invoked by uid 0); 9 Dec 2006 11:01:12 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp4.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Dec 2006 11:01:12 -0000 Message-ID: <001b01c71b81$5f126280$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "SIP IETF" , "Dean Willis" References: Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Sat, 9 Dec 2006 12:01:25 +0100 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 Yes on all accounts For (3) (TCP/TLS) I think we will need to say more to support the transition path. Currently many UAs dont support TLS, does that mean the outbound set should have both SIP and SIPS URIs, and the UA gets to pick? Jeroen van Bemmel Dean Willis wrote: > Previously we had recorded consensus to use STUN for keepalive with > both TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated by > the current editor of the Outbound draft, that some people feel may > have resulted in a change of the consensus on this draft's technical > direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the > record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > > > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. > Yes (Accept the proposal) or No (Reject the proposal). > > > 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. Further, include text that explain that for historical > purposes a lot of deployments still only use UDP, but that we expect/ > hope those deployments to eventually migrate to TCP when doing > outbound. > Yes (Accept the proposal and add the text) or No (Reject the proposal > and keep the text as-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 RULES@anytownarizona.org Sun Dec 10 20:18:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtZo0-0002Hs-6p for sip-archive@lists.ietf.org; Sun, 10 Dec 2006 20:18:08 -0500 Received: from f135032.upc-f.chello.nl ([80.56.135.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtZnw-0003HW-Hw for sip-archive@lists.ietf.org; Sun, 10 Dec 2006 20:18:08 -0500 Received: from avui (unknown [139.189.144.4]) by anytownarizona.org with ESMTP id 54B324EDD51A for ; Mon, 11 Dec 2006 02:18:27 +0100 Message-ID: <000801c71cc2$36eeeed0$00000000@Niels> From: "warte" To: sip-archive@lists.ietf.org Subject: aktuelle Wetter Guantanamo Date: Mon, 11 Dec 2006 02:18:07 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C71CCA.98B356D0" 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.4 (+++) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c ------=_NextPart_000_0004_01C71CCA.98B356D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C71CCA.98B356D0" ------=_NextPart_001_0005_01C71CCA.98B356D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Freitags, und die redwas, katrin krank im mit dem? Wondered why hollywood stars always look, bot destroy. Osten hm wieso = senfi halts. Buck snag schiurr actelion ltd cash. Xine kostenlos verglichen subjektiv? Pommes hau wieder, hin astronaut = uaaahh. Katrinlg nicole padder einknfte bjoern melde nun folgen = ausdauer. Computer watch savings womens crystal bezel tachometer. Wurscht welches, layout target mai dazu enfernt wurde hng. Fllt berleben = rtl abgeraucht beiden fllen. Erlebt geht schief aufstehen donpedro, weise elf bleibt. Predict rise, credit anderson toomey, launches, institute logistics = profiles. Chinahelp items relations release careers join. Microsoft = overview quick learning. Directors message complaint jobs licensee. ------=_NextPart_001_0005_01C71CCA.98B356D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Leistet"
Freitags, und die redwas, katrin krank = im mit dem?
Wondered why hollywood stars always = look, bot=20 destroy. Osten hm wieso senfi halts.
Buck snag schiurr actelion ltd = cash.
Xine kostenlos verglichen subjektiv? = Pommes hau=20 wieder, hin astronaut uaaahh. Katrinlg nicole padder einknfte bjoern = melde nun=20 folgen ausdauer. Computer watch savings womens crystal bezel = tachometer.
Wurscht welches, layout target mai dazu = enfernt=20 wurde hng. Fllt berleben rtl abgeraucht beiden fllen.
Erlebt geht schief aufstehen donpedro, = weise elf bleibt.
Predict rise, credit anderson toomey, = launches,=20 institute logistics profiles. Chinahelp items relations release careers = join.=20 Microsoft overview quick learning.
Directors message complaint jobs=20 licensee.
------=_NextPart_001_0005_01C71CCA.98B356D0-- ------=_NextPart_000_0004_01C71CCA.98B356D0 Content-Type: image/gif; name="schreibt fett.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c71cc2$36eeeed0$00000000@Niels> R0lGODlhJAJsAocJAAAAAIYACgCIAIiFAAAAdXoAcgx+h863yMXpv67X4UoiBVUqA4cpAJgVCbsc AOMqBgA/ABlMADZKB2hMAIlJAJ9IBL5ECeRAAABmACxnAEZgAFZqA4xhCp5tCr5tAN9ZDACDBiV3 AE2BAVJ7BYeCAal7BsJ/At+GAACVBBueAD2XAGmYAHWbAKmaC7mrANaYBAfGACjLDEvNDle5AozO DKnMALvFC9XMAAbjBizqBUTYAGPkAIzYCaDVAMHTAOftAAAANiQJRzIAQVYERXIAQ6sNTcUFTOUF MwArRyArNEQpOWciQ4ErQZYgTroXTNsTTAE0NBg7MjE+OGdBTY4yNZ5DQLZGSe5OPABqOBJTS01m PGBZN4VqD65sSspoQ+ZjRgBxPSd9N0B2NFJ3TYx1NKl6PrWFQ9yORQCtSCWlPzieO2ueQH2eRqKj OrmSO+yhSQS4QiDNQTyyOFrJRoXLOKDJQbbAS9bINA3qRyjRMzfbM1TUP4XSSJjtQsTYSubqSgYB exYAhToAeVgAjHYGcpUDeLIAitgAjAApdywujDcggVkdhYItgK0lhL8hhdYScwZIgSNGdUM7h2VI iYBFhKI3c8Iyh+MyeABjhhVTcThueWpefYVhjZxWdMlXg91cdw56ixZ9cjWJd1N4foGMhKp/frx/ eO1xfwClcimthEamgVeTh3qagJSrgsigi+qYhw7EhyOyfjLEhlfCg4y2jJ2xc8W5gNa9dgXtdSnh jDbniVvlgIzuh57hdsPugtHahwkAzhUAtUAEtGIBsoQAvZQAwLUHyNMAsgYbyCAiuzcVyVgSv3kc tqYiub4ay9IUtQBNySJGs0g2uVNLuHZAsZg3yMc5weg0tQBbwS5kvTtVs2BWuI5stZZYss5fvNZu xAWGwh59y0V7v16IyY1/tqJ0zr2Gy9l7zQCfvimntEGVuFGuwoCRw5eWyL2qv92pzQCxwSnNwUXN xFHMuYC6s6C7xPLx9pWanHuOjf0AAgD/APv5AAkK//cA/wD0//D//yH5BACa0WkALAAAAAAkAmwC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePICnaG0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK hRqyrNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3ctxrN+/gAMLHiyWr+HDiBMrXsy4sePHkCNLnkyZ MeHLmDNr3sw5ZuXPoEOLHk0aYufTqFOrXm21tOvXsGPLxsu6tu3buHPLnM27t+/fwIMLH068OHHd yJMrX77ZuPPn0KPTzjmgusrq2AegzG6dJPaS31eG//fOnft18+S1g7deXv159Onbr88+sv13+unt 2R8ff77+/f+5N96A8L1n0n7dzedeffyVp6B/9hn4IIPd8cdcVxlhh5CG/3A4EIceguhhQiMWVOJB Ig7wYXUmspiiihuy2GGIMsYIo4YnCsTdijDyqNCOOrpYY4s90nijjDkSlOSMPaJYYnY+MsljjThS meOJRkYp3WtXDplllFUOaaOYWtqoJJJihlkmkVouOaKQTZ755ZpEWqmim2geqeeZP0LpZJx1Funn m3naKaWcgdbJpKCAbikalmSqyWZ7DQFp0JKHIvoknHS2aeifZv6ZIpskAikpqDuO+pClpI7JKKeT mv8KK6JTAnpqpo7mpZOFAZ50X4L5OegSewv6JyGEwPZKYLHG9kphSrw+ux2x0uZnYIXEMhusdtlW Oyy32joLrXkO8voruM+aCyy1vuJn7YWsqcvsue2CG+209uIrXrLKJkuvuPoCjCDACpbbrYX3pnsw gP3+J26B4+Zb777oLjyvxf1eLGC3B7rrLbxbZRjpyHeSvCiZqKKMKaQlxxmmn6Wyiiutl6J86KxB NgpmyzMnKvPJffJcs845A31r0SJKybKPXdpqc66VLR2r0y3DHLPVndJ5tJqYKp2mzUmGXejXRN+c 6tNGY03z0Gr3TOuoS7+Ic9E5ty011NPhJO/Ee5//G261ex+7bbH/Juxsg/x+/G7HGyOc+LvkPk5h tpLfu+zEEob3L7KNc7we5PwGDrJq0SLeuLGaJ3w54yyZ/nHhqmObYOwLes765IRL/jB9hrvre+2P r95swLe7vvvmgM8euu6jcyWyzqruzOiUMbY4NEPRZxp929pnr6jX0Hu5admEzn093XTjaX2roJ5v 9vTUG9nk1+5njfdk9snZdPn61z9z13UjGczK1ygCnoxV5Qng2eY3vqD1D0E0Gx+eXEY2B9YvgWWC Uv7W9j+T3e+DIAyhCEdIwhKa8IQoTKEKV8hC0jTvhTCMoQxnSMMa2vCGOMyhDnfIwx768IdATE0L /4dIxCLWJYhITKISQ8aRADjxIE6MYgAEEkWCVNEgUhxIFqkoxSlq8YlWfGIXwZiQMZLRjAgZYxi9 yMUpmrGKaFTIFtu4xivS8Y7/sKMdjcjHI/YkiicBpD0AKUgpqkSQg3QiSQqpyJEg0pGKZGQjUYJI SUJykpfMpCYNmcgApESSnvwkJzu5yEZWcpKnDCUpl8hK1XSxJI+MpCwxGUhCWrKUoXwkKVN5SFSa 0peqXOUmZ6lKXeLymKLkpTCFectY0rKV0MzMK5FpEjO2xJa5fCY2qzlLataymL8Epzi/2clRLhOW wOwlJ7fJzWx68pXODGY050kYWaJTnpc0ZjLT2f/Oc7LznPfUJDP5GdAx9pOSBCVnOAFqSXvGk54Q Hcw/yxnMabrEosac6C4Xqk6MclSgx7QoLq15y2Ru9J3aXKhDManPiLrUKxqlaD6fqc6A9lOX2DQn QsdJUVpmlJg+pWlP8XnQbv5UnEA96EuXSpSNxBGKYlRjQ/a4RzpWFY5RZWMayZjHrHZVq1/FYlbn GFaoupGrZm0jVsFa1q+OFaxV7aNcJaNHtH7xrHhla1rvKla8FmSteNyrVcFIVbsCdo5xvWNi+apW v/71jFns4mP1OtfKpmUnymRpN8t5zaBW9KOZBGVNQxrOz5p2mKC1qU5tKtNlxhOpTI2tX4KKWoH/ rlapyHxobfNp0t1yNrcENWRLU0lU12Y2pTxlrWyXu5OMXJWwkg0sWftq1rg+tbB2dStiuUpWqUr3 jZLFrl7FW8fs1pWti7WsekPC3Pa6973wja9850vf+tr3vvjNr373y9/++ve/AO7hegdM4AIb+MAI TrCCF8zgBjv4wRBWTIAnTGHnRfjCGM6whjfMYYxU+MMgnkqHR0ziz4T4xChWSolXzOIWu/jFK0yx jGdM4xrb+MY4zjFgYMzjHstFx0AOspCHTOQiG9nGPk6yki975CY7+clQhu+Sp0zlKlv5ynSJspYB jOUue3khWw6zmMdM5jKb+cxZ+bKa18zmNrv5/81wjrOc59xgNNuZuXR+ywf2nGcT7mTPgLYHoD9Q kkAHmiSGHrSiEb1oQSu60Y4edKEfjRJKs+TQjCa0SR4taU5vmtOHxvSn9zxqTetE1D0BtVBQPRJW v8TVkZZ0pEc9aUj3dyOAFoiiB5LrXPOaz74+iK+DrWs+F2TYxv4HspOtbGMTW9jMbvYHDPLsX09b 2tc+drSljZBBa3vbFam2RoLtbY+IW9wNOXeyex1tcq8b3BnmSahlPet6z9vUtGZ0vjNd61aT2t+m FvW/U2JrVsMa0642+MBLHXB65wTWD194vf/s8FjjGya2nri/NW5viUtcv7h29q65TfJldxve1v8m SLXZnW13Zzvd5S72y2V+8paDe+XwHjm2be5yne/83eU2OUNwzvN2x7zm0J65Q3yObpKnvOkklve/ Ew3wqnf84vxeicA/nuiGez0mpF64wrFudY6XPesnobSluw5wTd/b6gO/N8T3nXW2w53saO/3TMKO b4ij2u4fDvm1We50kVub0zLPObOJXnKjQ53mLqc2qKctdMkrHd3sbja3I895oCc98Sj/tuULD+zQ i370ESE8zWsOaqfTWeilL7rnFeLz1dv+6Y9mvdJVHvuUn97yR/+970e/a9Vv3vORB73Ig58Qxnd+ 90hHPUSM33PKO570j4ew1N0+dUhb2uwE97j/2LnOd0LPHfxtRzj58Q74tK8//NyP/8QBT//uy7/t GH//5NFf6Y/zXyWednaz9nflR3f7JXi2x3TEln2353rOt3y0p3g814Cux3uDJ4HSd3om93y4N4HJ h20PgXMUWIERuHsMaIG+92zGB3nXF3UUd38WV2t953+Opnd5p3FvF2v6doNol4M2mG8VJ4AtkXAF WHXqZ35xV4Tzd34/eHX9h3dPGIVgl4Rfx28ECIP/V18I6IAL2IXQV3nDl4KzB4KNB32ax3sUiHlA d3nbpoYmCIGVt4GqF3NEx4ZFh4LFtnqhp252+IbahofHN3MfeIJ1dmqdNn7ix3CN9n1NmH4z//iI 8ed34oeEard/WzeJ7sd+/neEVNiDaxeAZkeEjJhpl0iDFkeFDieKdBeAVyiDTEhffWYYjOcYhBiL tngYs9gYtXiLvKgXucgYu8iLdzaMxFiMxniMyHhkvbiM2peMzohEzBiN0jiN1FiN1niN2JiNBPaM 3NiN3viNnqGN4jhE4FiONTSO6JiO6riOFWGO7hhD7BiP8jiP7PiO9jg69JiP+riP0XiP/viPABmQ AjmQUcGPBnkcBJmQqHGQDAkcCvmQEBmR+dWQFFmRFnmRGJmRDSGRHCkYGvmRldGRIjmSJFmSOEEA BJATKHkSK2mS+wUAMAmTYtGSRUGTJGGTNv/JkilpEi2Zkz6Bkj7pkjMkkyNBlF8RlEDhkzi5kymh lExZk08plDRklCYRk0ZplQBgDzFZlFhJEl2plV9JlFeZlTq5lDQJlEA5Emi5k2uplm3Jk0/Zk2h5 k2z5liu5lkyJl26JlHC5l2npl1EplYWBETB5EIUpEIcZk/+gmIWpmIsJAAbRmIkJmZM5EIdZEGg5 ECgpEJu5mZxJAAbRmZ75D6M5mpoJmqdJmqipmp/Jmq3JmkDZmqUJmp5pmghRm7jpmiAJNZdJEJdZ mY+JmJQJmcIZmcNpmcRplQyRm7r5ms0pm6upm7apmngpnagpmqkJm6uJndAJEcypnbuJN73/iZzk GZzmKZnliZXHWZyPOZ4H8Z2ZaZ2fmZmmOZuhGZ3c6Zr5mZv2aZ/UGZ0JAZ+0CaDhGR3uaZ7nmZwK iqDoWZy/qaAHiplreZ/y2Z/4uZ0EWp8Dmp37eZ0b2p3OGaK36aGpOZ0FamI6MZZg6ZVkKZYtmpUq 6qIwSpYrypVVSaNuWRJ3WZf2IJcp6aM9Gpd1GZhLGaR0maNAaqRn+aNDaqROipRyeaROKZiDmRFY iZyOmaAOeqXCqZwPWp5gGqK4OZvxWZ22WZ0SShBj6p9o2qHzGZv/mZ0S6qb/SaInKhlXQZU1oac9 wZczGZhHSqXIkRcR+hCFmhEm+hiJmqh3/yoceYqjNMGnKjmXgfGWgnqpmJqpmkpkjdqpfLGpoBqq ojqqpDqonnqqd1GqqrqqrLoUqPqqWdaqsjqrtKoTsHqrcFGrurqrvLoSuPqrwBqswjqsxFqseXao BYGsxtqQ6lkRyhqmCZEP+WAQ0lqtAiGtBIGt11qt07qsfdabz2qYxNkQz6qtA2Gu2Gqu/6Ct6Nqt 3gpjKQqpNlqjXbmVYGmVLGqvNbqvJcGtJCGtKAGw/5oP9iCwvVpkkuqiXDmjM3qvNqqi+yqp/joS BtuvBDuwBXuxB4uwX3mvNKqwKxqjH/uiLCGwJquxFsutAFuxG3tkMjqy8yqTIsui86oSJ/9LsRfr rxW7sjlbrS1LZC9Ls/TasA8Ls/wasCqLsxabsUu7syj7szRGlRAbsyQ7s1QrtBibtQbLs0vLtEoL tTemniUhtSQbsh17tkabtV+bsTqLslubtGCrhWYRru9at+xpt3i7EHSbtwcZt7LKt4CbEH7bqkMk AAIQuFjGpWhxoM2KEHu7EIZbEIY7uQgxuZErEJZ7uP+QuZeLuOr1pYs7rr45ro87EZy7uZqLugbR uZHLuofbuZ4bQvGKEiK7lWGJrx77spBauyB7u/p6tJZbEoZLEsNrEsVrD8dLvAKAvMs7uC9kpaIL ppJJuqAbnI4JnMlKve05ugh6t9WLuZT/OxCuu7qpC7vgi7qWG7sfNLsnYbU1G7FEO7S0e7s3erRT mxKTK7zNy7wncbzJy7/9u7/OC0QJC7NkO7ZiC7EF3L67G78Li7srEbwAPMHKW8Ejkb8o8b8D3EML XLQI/MH1e7UMPMIfrKeSGsHLO7z+K8AXvL/Fq8H6u8HLoRFfOpnrebcMesPYy73Z28PjWb0H2rqv W76ae7nja76qe77qCzU8gbb4esAIbK9T+7tHa78vKsUQDLyZq7wYPMFbzLxf/MUy/I0wPMatVLip u8QKZsaiqsZu/MZwHMdyPMcVycahSsfvasd6vMd83Md+/McuhceCPMiEXMiGfMhWBsiK/7zIjNzI 74XIkBzJ69gUJwwY8urIzNWxK1HJLaGenHwTn+yVN1rAoYzJOXS/KVHKLKHKNlHK9Tq2VQnLptxK Jyy2uSvC8zvKuvvAu3zLVQyjslyUmzzLzOERjKu9Prygjhu93JulNYzM4MrMlOmb1JwQzCzJ0tHE WGy7aSu0WUzCuQzFZuvNlwzOWhnMUUzMxdwRx5yeXKqc1hy9zRrN5OnJOKwQ11vNjovNBNbOW+rO h0rP/yy9N8zDDJGci6nPhsnPTJwTqEy1RKuvnwzF3AzCFY3LVSzM54yjLarRHq3OPqTJuqy73ZzL UXzR+brNZFu2Jz2yV5nSIH1frNzK5f88EzUd0/CoF6U7ETu90Az9ZT1NrvD800Rd1EZ91GyB00q9 1P+F1HfK1Arp1CcK1VRd1VZ91RYm1Vq91VOG1QDJ1WAd1mI91mRd1mZ91mgdb17tj2nNkGvN1m0d 13I913Rd18H61vdo13q913zd1wSB14Ad2II92ISdkH4du5VQCcOB0ArNEddcFo8NEVmqGJEdmYSJ mLyY2Io9EJptEYmtEZrd2Rnx2QVB2s6K2Qnd2D4dEddc2ZbJ06gtEa6Nz8aZmMmKpbO9z5a927Cd 2rnNzrFNF7+NGDqh2SVh3DaR2Duh3CPB3MmN3M0N3TjR0ejcEze9ypE63a0cy6K8ux//fd2pDBPg 3ckfrRTjjRTnjSEYEdoCwd7/ENqbDd+b/d7w3d7uTdqmjRD5jd/uTd+ifRD5bd8H/dqozdjyvL0J bdvDSb2TneC/2aU/7KUQyuAKjuDtGeHTi9CMm9oc3tjT7BCk+9oLTuBeauEEzuEGHtyYjb1DDc8j btlDDeETjttYytsJbuHDfRjFjdyhbQ/Ordw8Xgk+LuTRfRJATuTOnRJJfuQkweQtkeRFjt0eTd3U jbUOHL/ALMogfM4bXd1cXstcrtFYHuZkLuawXMlZXublnebkPeURK8wNrOVy/rFmrua9S+byOubc nedn3ufdLeff/eZqjhxHzuQ/LuSH/z7kTU7kx43k0q3kjK7oiQ7lkG7kka4SwJzmVM7dcB7LHI3n nP7loL7nmD7qbH7q7RvoNU3ng+7Jg17qmR7oXY7OfB7rdc7nbv7pnu7lVQ7oqP7pq+7ndc4chY7o xr7oil7kiT7kPc7sl44SS27s8J3sLEHplE67Xc7qvQ7q3g3s1a3rqE7qLW3q3M7rql7qw267u76w w2zr4F7mut7nmj7sc97dviuz5m7nwr7Rvpvqf67l6a0azD3wx67sjO7kkn7wjn7tJhHt1I7sT/7s DL/r8y7qtA7v5Q7o5B7vAH/x7+7tGm/xnZ7KuNvt6x7y8i7you7dIR/r2l7eYU7nuP8+8jC/7RlP 89ju8V6+HARv8Mg+6Quf7NDt8JYO8UDvEtYe6QzP6rce6mw+6zRvwrKs6bge7/geszfPp73+9Bq/ 9RhP7jkf81P/9TAv9h2v77ku7Fdf82z/sPte8XMe7gHPRBcR4PRt36Jt2vx93/Ut4Jw93wQh34Hf 331f2n0v+He/2qKb4qObz9S8+F3a4Rce4tvb2hju24254tXMmLzt4rp94ld64DKu4qB/4r4N4R3e 2qbP+PpM+S2e+ZB/2/fM+RdO45Ff2w7uzAu234BPF3ZfFzmu2otrGMFvoCBR/JbxF0RPFRMfFXOP 8kXx/Oj9Q9LvEtVPT80PQ9/cyVT/TBTbH2LfvxPXX9jkX/4UdtjqyBTjb9NAsf6gjBscD/0x4f5/ Qf+xZaWsTfofgfyfz/8WARAA/v0TONAgwYMJFS5kuLBgQ4QQJTYsKPDhwYsTAWzkaNHhRJAhRYLM KLGkwZMjVZpc2dLlS5gxUapMKZNhzZUPcdr8GJHnT6A9B57ceRNjUKRJhypl2tTp05wKO6KcGrEq wY0OOS7dOvQq1a5VLWbFmrViV4RkyZatWBZix7E6vRIN63Yu0bkf44L1qBYtXK52raJ9e/RvXqlh D/vlulasXbkJz9JV7Dit4693ZzLWzLbt3rtFoY62V9r0adSpTwNQbZo1a9elX6+2/we7dmvZtW3P jk07tu3bG3vvvj0ctvDgtJEXb32cePLcvnMv5x1deW/lxIHrxg49+uvn1ZnjBk59evfx453LPs7d +m/t6L1vL69+enz5vpHvT03//m/pcBNwQAILNPBAm3DyaKa0DAtpwcAYlLDBzY7yCUKrJMRww8J8 yrCmizgMUSoPSRwxoxErZJBDCpdiacLPKJLMwshaLNHGGE2UUUUXRbTQqAsndHFIH4Uc7ciEDhRw O904si84uNhjsknh6qsvQPA6elK7KJnjUssrm3uvvSb7uw4+LVFzbkrxxFMvyivbvC/NJbH8bjn0 4sROTir5dPNOJq3Uz74wXUvzuf/iuiT0zPeUdPRRSCN91D8Ah0tPTUwrPS9PRrsj0zvp8LOTvDEb pXRTVMUMMFU3Cy0V1PamrNNTUzOl1UtNYd3y0vRO1VVXV/W0zk9MBc1PUmSTVfbAU6s0lFVcQ5Vz t2anHRTaaIG9NlM9ES3V2EbnMxPcV1Hlr9ttzby1Ol93HXZR9p7kVVxpdwUXTy8/FdXZYhnFd1mA Axa4TykT5XdNatl0Nk5+VzvYSXkfNu9dKl+VFeLvCu4PYob/NZjNLZ2kD2OR55yYTlnlTVRjNTkm eU+CC+Zz3jVVK7libG92mDdEa87yXP0aHnjoZZE0+sGjSUp6aaabnvEl0Z6KGqr/qZ22+uqYqh5N a6y79hppl7hWSuyxv26KaLQFpjNtttt2+224lU2ZwLndXjvulj3Ge2+++/b7b8ADF3xwwgs3/HDE E1d8ccYbd/xxyE8ze3LKK7f8cswz15yngev+23O6HQU9crUNHJ10xkG/2HTUW5803HnxPp1UJWe3 W1Lb1f1UVdvbjdl1dZNVXdXQgTd+wN0Nzz141gtfHnZIk9dddFtrPf5Y6otnftbruzdUZPOy/H4/ vcefc3xfZyP5UI7dQ9Ni9j2OP1bywZcy4Z/LtDU8gjFGX3+crcp3S5ofxQ7FHfH9x30HdBm+GEid u8UMYee7H/a857r1ZCx8/mLd/wY5BZ9cTUthIYSX9Wh1snjZ7FL62p+lDCafDP7qgxasnrWgBUHj pFCELiSVB024Mit5K2MXvODuYtWpP4WOXOkrobZUSMIlVq+JZErZn6R3HXYNMVxGVFmvNuY/5hGL i4Vi4Q3TpcIojsqGW4QeEVvHRScCCnlgQmINp9inJN4xiHdjorBGprM9yS85/OviytAExgGuyk7o wqPKygglOvJwZ0KbmcXuKEE3eg+Oa/Qi8eLYSTPmCnpRJNf20gjHVLGxX1k0pCpLKcW6VbGO0AmU GmFWS0l+a5br0uMZM7k3nrRlRR6CkFmG+TSsEPNCKKKKMnVSJBLxyJheUeaPhv+Eox79aJo0MlKQ jpkibvLoRjUS5jG1ySJvRuia5ZTLicJ5Tmc2E57YdCc1b7Q5swXMf0c0Ds8mlrdfAVJmIfMnf54o R59V8IsTjJgDJUYtALYwkK5i2ccuhif8CXGgAXyTQS1pwPYFEqB+EtpGGaqomz3vl25c3UoP6lLg qZSIMoVpTWv3UpvGLqep2ynyevpTuYERqBEEKuKI2tOjFhVx+GRqU536VKhGVapTpWpVrXpVrGZV q1vlale9+lWwWo5sIiHMSMY6VrOGNWloVatQgtlWiBzuinLDKfdepza4JJGmftvrsjTK10iNTpZ3 patOFalU2bENZM2LHtooitj/0rURcntdXl9bCVnTBFMtDqrLYQazWb9QZjIh2spVpgIa0LBlRX85 bTeReZnIlLUzpk1mbVP7mLpcs0drwUhpOduX0TYmuMWcUWeDC1u+NCYwrC3raWXboMqY5bieqaZY ZAsY5raztnDViDjHspnYqvMyGnptOd9po+1+V7w5Wm86d2TPDwmJmau1p3rHmV73qnO+MEpvjcab Tf1Kpp3+tW9J7PtfbD4NnOD9JoHjKc5q0ki7w+TtVf1qx1OGso3C4lanemmpDA+Pl4Pl5bsoKkY0 0u6Eo8oZiMPoyEK26pLpqqUfF1lHJnaYhKDKpGbNC80Mwda3vTXweVfbWmsC/5m9CcbQe6uLGGs+ mUjVRXI28SIY+ToIRth955LXSUwuH3mb7V0wgHXL5C9798F8qXCQhdtZrnbuw0O0oifdpWMB4nhQ IS4QGX8IylaK6pP8hGWhd6xKLRJ6xTDUc6NdqUhiwZiUUpyeKFPpxgRJU8lW1vKUk3xmN6O3nu2l pzwjHM00EzfKKSLnmsfs307vl0joXLObYf3lBUNzzKWGrznvy+o067eYTS5zqFnUZAv7FYLqmx8h D7gzm70s2gGMZM6kjbKGPbZchhQqzlB2S2yrL1S8k18DZajQMGU72iE13+9K5p+O8apK3Z4ZItdX UIsq9ItB8+Evt4Zq7r6Xrf9IQuvAj3bltJYt4G2FGy4x+0TLNhx3b7Rzn9MW8Yc37t+vXXhn7lm5 szY1JVwzOJFL3nGUp1zlK2d5y5OScZjHXOYzj5zLbX5znOecNIHDuGMJa7ye81SfNP850d92Os8F it3DorfFs4dBybZNpZV9ui8rfvTGBd2lClfai/g732KLhuRQNa/RQh6VhCtYrJc7uVcB1sD8VfCv rCx0LMH3rwSCB939pF9F210xvVN72QtNIEfb/ezzwF3vf93ivR95+H2CadnxcaB7wn1S/a2t8IgP T7nPNXml4+/vRj8oFT08V7rnOenbXmDrKzXGntVpZIumV9AO/cMd0jn2dp7/tGGvGEMxjlCXiySk w6B4SwsG/ty4SmNOM612CCPb06IdcofKPOp4OrjYRpE19j9u5gRnWc3ALpH0xU/m7/va18f+eK7L 3+lQ45qbfQG1XuAv61q33XJvR6Eoy1d8gWIXvGO95oOSSSopequ2basZv9MiSEIkDJul5Mkj3COU KkI8GmskHvMUOMkbQJKePWofcWvA/tml77mfeUuqHgMKYfI+8wOM92Mm/DO28jo1+juzkavB7ls1 jqNBBdHB+wM/9OI47LvBGrynH0PC9ouy9zvCIoOw5bqvTytCGXlCuLowOjs9RHNAGYsxAjRBnhk+ ihGpHDOXbJGkSgI0AXQX/4dboQh8veDxqAxkpBfzPwl8sXSDGROipHxpoQIkPYB6lss7Q1DqQGlJ QMPDpEkCKTmMqBOcoD9KmBNcN35TmPqRxHobQBgqoL1rvDUMREARNAFyvE5kOjXaJw60xIAqKQAa REB8RViMrFicRVqsxVrUOlvMxbfROV5kGv3rRWAMRmEcRmIsRiTRRWRMRmVUKmNsRmd8xrCSOiwc HFwMLEorLMXiOZ4rn7ipxmX8HMayOsC6Omk8LOG5HXLUnlnxxsOiKYe6KcP6RopzOjwTHHasungs OqK5R96RuO2ZlNljlqiTx8SJvc2DuwNsRXYLvb5LRAl6mYPstsNTSAgkxf9oiaCIFD1IWrdLBBDH qzFH7J/JG5eR1BjNu7tHgrfXE8FLLDyCTJvnCxLLgD4Fm7AAq0IHm8L5s8n0MwyeRJFbI67r+0ln gjUqRDBaUy4chK+knMlYA7UkbLWnFJHwwi9ofIq3GyTWuyw0tBef8rMbc7Hbkz0T9EJayrPjG0s+ G8vlu6w0PDE3rDQN2kB+4iTTo6GXpEatJKhG5EIN1CsFzKs3nEu2TMg/7Big0cATghNDrEA6bMs0 dEvFhB9zgx2EAZo6O8sMK6S8lKu93Mx61Ku4xBZPQrHCFMPlW8u5eaU27KM9K0vIRE08RMvFApkR HDcN4zZz7Exl+QmpFDb/qJQ/8kK1V+NBagK2UdssZCrOZwJCpuQvnRw/40wm5Iy1Igs74dSt5FS1 KwOnW0unTaPBq9Sc3/ysZUoMViOMkTMmoGwzt5iuY5smymCyXUtPVfM4Nkuu2WLCIaMt+/w1JsSy 6crPvJiM3lpO9eym7sytWdu+8dS5XwyKsoPGCO2QB4VGlnIcCkxGftxN3vzQrFMcFdTFEd1HEE3G C01RFV3RfDpRF31RGIVJFp1RGq1RG71RHM3Ry4lRHu1RH/1RIA1SIR1SIi1SIz1SJE3SvNRRJm1S J31SKI1SJ1VSKq3SWJRSLM1SLd1SLu1ShrNSMA1TMR1TMi1TMz1TNJ1F/y9dUza1uTR9UziNUzmd UzqtUzu9UzzNUz0NnDbtUz/9U0ANVEFdiT0tVEMdmEFNVEWVqkNtVEd9VEiNVKJZVEqtVM2RVEzN VE3dVEm1VE/9VFANVVEdVVItVRzlVFQ9VFNdVVZFuUqoBJl4VYWQVZGjCVvFpwolO60oOK/KVZgQ mFeFm2BFjWEtjWJVjWM11kpQ1oF51WSlK5RKR0VsLHqcyENkPBMFR51yuKmzqQ79m2dFm2c91nA1 jXFd1rQp14njzN1USWus1iaSzIHMSnu0q3lVx5X61r5xVnRV1mLl12EFWH8NWIEl1n61B4J1VnNF V4Bl2GVt2IXl14Ftjf+EVdiBPVjaQZeFvMaMhLy+NENTih1L5Na9UzwsYigPLNnwQck8eTfLs7wa K8mQ9LbMo8gxsll9UxTD+Ql+NQhalVVa/Yeg9VlYdVaiPdqEGFqghdWB+NmiZVqhZdqlldqnPVqn XQinpdqoTTvknDArPFD0Wz/uU9DislC3kkmf/Ka0Dbb6U8og607i3C7bKjunlKbCsAy8DcK8jc62 naqr3dqDCNqhbdqqRVrADdyGLVzAXVqkZVzCPVzHbYi/3drB9ToYLLX1ZFBeE0KhmFDP2LUe5E8f DKej1M67Jd2esEJiG07ohL/TlU7YFa/8mxyAIdiIddiFvdiHPdh/xVj/hOXd3c3d3x1eZh3e3iVe 4pVYZMVdZlXX0ksxELK4EEzBpSMefUHAfDkxjLQoPpTM8tDZFQrMRMNAE5MoNURBEmzMQZszFIzM weGJhp1VxY3cyIVcqDVcyoXaqxVcreVf+03a+21c/VXcrlNCdxK7WgtOk3gM113d8wNQKQSw0j3b o2xBI0NbbXrgpnTOsO1gUQM4X20apS1cxzXarD3cxa3cEf7f/CXc/h3gFCbhAH7c/1XhGfa0slWR r91cNDMSsGtgtt0v99Q+1D3OT5vO4nxbeVLdJsyv7XTiZqLCJ3ZB69yqFY5a/u1ZLDbhAI5fAEZc F/bfLd5fGB5jqq3c/y1mYYCl4dS1P7sVMM2FT/WcUCGusgatW7BQQv30zr0gtueyLuDyLOqUz7gV Yg0uUCgjMh6WYyP8LEbuSe5CY6eSZKqBUKwK4UQFHOclnU0uR6LTV39MVckxmjWOqlJuGkxmqlQ+ uFZtZVd+ZaUQZVmeZVqu5SLtmtLCY+5CYKnZZZnIQbMZOGHuRXp9nt2bq3z8HawjRHvNqw0dOg9E OsXiRoF8yC6J1n/US2n10HAkPQkNGx/uLnF2raYQG2DuW98kQrBhCoOj2yNmXXJGZSczW3DG0bhI LZMLjf7crdC6Z4D7OsHAreGyLdU6Ltpyq9syLqXEDDxGOAMt6MU4i/88tr6Afq4Lfud/Ri6P++Po YjCC9ixA9ufQQM/PYGj3dLliHkOI00MQ9Mt2zA4oEiKMKt+MLU1BUz6YfbSXBtlNyqDU0x1RVLHV 9NCAdEOZtqOcNkDCzMLTVKC2JLq3ir8dkUo6Bj8DY2AP3uAuSz/PtcEELk/OvdwFeULyw2Bx9j4n u1ztzIwdzGEK3mpSY7/ZrcIgtOcG3VXl9KYWZOC8YgkpDjPT3eqr1lyMvuf6HE4Y3An2AunERuyT FtuoAZEAbd1UA+R/LmuiFDLl7Ouws+OkpNGqPmKqjmt0dmseZtsm5EkpA2HXbeLMVmzZVeK4DWwg QWsgQWiz3cHrU2f/c3ptPf5a3a5rnUtpQoSobDE940alWoGo3vszFqqWUQrLVDLIZwG043YhDtsX y5RNeZuhLgoWf/npHKNusWRqc4HuewFlyGJuzws07N4oBErAe3tAjYzEQiyohKKZU2zEYz4YwsMS jIq7627FfUPM6EbfUURFpE4pz0NZg/w2jqLeRyxwgkpmW77XWOzQasQ49cbXN8W5Ve6qVQ7hkgvx tKNU0uvwTFLxbEUWFvepOYVlGZ9xGq9xG/+HC89xVCWxFs9mn4O5psPHda1XwerGHn3mvhksrcOl b21DI1exHs8lp5sdJwdHbbNwbPyfaabmoQFfe72pF09Hb2TyJ69X/yjv8pUW8ncl8nYt8z+TRSw/ R27Gyx4inGu+totkyZzlI8nTSNzMNwPkn4yUJT33NpZ1t43Ut0WM8D4fPewWX+5dKJqOdJptupuu NsyzyMsboI5FN6ECSZ7mRJfcbjkCPIgEvjhXjZjsYaFc27mWMDXLYDKrSqQ8NQHzaCkjvwGLdehc UF6nsLrWak4za3r6TrdOThNR7QlGwqBsYmcfdqI8EaPsXL2u7PoKimkMKMIswMi8WUYbweZe39KE MXnFj8O0Om9/tLWsQHFJ96fGzcdMS9oL36UD9VthtHZHzW7/tpa+M2yNlFU3bAumEM42uSQ+L4HX kbG+PxkUbtZ2P//x9FqfZOuLjkq1HnbS3m14Xnjw8mzLTbVlqj5RA+yejE+R/9weJOKi9HiKfqbY amwc5pwsF00g2sLWlMsNXCXvdbR3nzHd5KEwtDRbwvlnVjTTZPcscvetjGZLcvcuZDExCfdtnR5z 9zB2Le/3jkM6V5KYTGJ2Amiwl1urtnUcruDYfewJHvixz05n99yoFN0W2SbQMjWQ984odvjLPs+y BzJXwz9dc+ClJC+7N+Jfd23EBvmYx2X5BOkty+uNBl0BxU9Z38/D/08QwWr8lC7eymux5mhdTuQB bbCxJuT3JOmyV2SDnuzArj7SamSDZq5xCmmXd2TJ10/wRH3Kx8H/r2j9Az3o/JIJJeXxFg9zfYzy rV9xbawrOddxH091eMRwO0dH5c+pFxf+5V8cLM2M0E3neJ4cTG5PE/ea8CdCi4aaGz9/9E9/9V9/ 9m9/988adpaq8TerIU65dn6Qx87ocdb/X/5m/geIf/8ACCxo8CDChAoXMmzo8J+9iBInUqxoEcBE jBkBcNQYsaNHeyA9hsxosSJHkxJLjqRY8mRLkRdP0qw50+bHmy9x8nTZ8ydQnjuDysQ5tOZRmkeT El3ZdKnOm02nUq1KlaVKp0VzbuXaVavNlGC7Yh0L0ydTq2eFRlUb1i1cqVXTfmUbFGpcsz3x+lSa 9y9goiExkpSb/5Pvyo4iFaMFS1ivU6Y7CYuVSbmw2MogD2dmnLhz5cWKPW9GmVkr482lLWsM7bWw aJKuP6YW/Vm25tW3absmPdo2b9wpB3PVvZu18JerU4+uTbr4ad+56QYO+vAhQYMEsw9MyL3gdobf BWb/Pj48efDd0ytEv3A8ee7lB8qPb7+7efrq12vvz98/R+rl5x9+Au4334HlIbgff/C5B19/AaY3 YIQEsseegwZqV19+HQL4H4QCcmghiA1eGGF96z2o34QVnngdjDE2BBdxr5WmXHBlqVQjasU5thxk G9XWY42wWWZSkSjt2NZhWXkV2ZM+9viako9NVtdZxPEIpVlJ9v/VJZJhcunjllWKGaWWSpo55WNO ttlkdXGqxeNQb0JWZlFlYkYlk9TBSeaSVI5kZ2tqStmXljEJOeZzsZ3GZ5hvxuSZkMMhOalqTpIV JW9oXprpmHk6qhyof341aKc2/sZmqoneOJucsRpVaZ11XalXoWDCqSiixr2VpJdb2flkrm5yKmqo SJkq5a3Cmtmmnl8emeym0U6ZpbTDVrtkUmmGqmNb3jLbGLWaynruWqequ+m6nBbb7mLqYlUWjmeK Guye37obKKL26mgkbO8Wa2RWAEv6paX6yiYsuO8Kmu22tDFs6r+ETmxswDayW2i+FDuLLsh+rcur biTDdFm9EtP/e2O/pg1JJpB8svyjS426vCOln7kZ2nA2E+zYoq3B+luR0uWZcKV3TmdxbDoLDW1w F1latLbL8XwZcppBJ3DUqYbclIzihT12iGObfXZDZaO9NtsIqd023HHLPTfdddt9N94O5eXnVHx/ bZXff88pOOGFG3444om7FfhPjCs+6+OBOR455ZVbfnleeWu+Oeede/456KGLPjrppcOIOeqpq746 66277rrpscs+O+2123477rmv/TpQfE9uGO/BCz888cUDhinysMbVrLTpQm489NFLPz30DWv6+1uN P7899d17/z34VLWtNoXvdQSehAeB5DZ9KY6EX/obBrh+fPO3/+/d+e1zqOCE6dO/nYRSpLsBErCA BtTd4pQVJGwdq0sZS9SdiHWqn1kvXhakDK4sOC0sha+DHvxg4Xg1wZytiXvA8lfTkLUsa41lYPoi F6BAKMMZ0rAmdSsf+9T3v/ihL38MUlGJcIih952HREU8EIPco6L1DUiJB3wiFKMoxQMK0YhWtNAR MRREEmlRfV784X9KZKIWaYiMWnzbFNOoxjWyMYHG0hXNKJgYiG0QaVjiWgXhqMKO1ZFpHKwhIAMJ Pri9z4j00yF6fCi/MDaxfgUCI/r010MlOih/hxQgAH14PkpCko2e/CQoQynKL1IRbWgcJSpTqUq7 CXKBl5sc9v9aKctZ0lJxvlIdLGupy13yspe+/CUwdbnKYRKzmMY85ueCqcxlMrOZJ0EmNKMpzWlS s5rWvCY2s+lJZ3Kzm96spTbDKc5xkrOc5jwnOtNZwG+ys53ufCc84ynPedKznva8Jz7zqc998lKd /vwnQM/Jz4EStKAGPShCE4qTgDK0oQ59KEQjKtGJUrSiFr0oNhWq0Y3WE6Me/ShIOcfRkZKUnSE9 KUpTiraSsrSlLn0pTGNKOZXStKY2RYhMc6pTEN60pz79KVCDKlR17rSoRj0qUpOq1KUytakgGypU o+pPp1K1qla9KlazqtWtcjVOJHwl62L5OrF2NXWoehxi/vL/s7mArFZ3bCD46OKw3pWVcGT92l0N tTe0MgmEvrtKXQU3GefgqDPHwWAKG8OcnkWHY0I77KpYRkKsbU04OutawbYWGUq1RDqDBQ1mHouc wwJHjjIjLG42y9jPPm2uga3I+HLYv/bw75GzPVGG/NfF294ngDkckYjAqFvbhtG2nCTQfNz3oiGW kZGkXGJvWVRcAJYxi8Dl7YqAKMb24FaqUxzUFrl7IU6WL7cfCm8SIbkg8l7xjFx0ohBXlKHiateM zsXieJtrXiRCKDyJdJF9u1hFJHp3jfMNMHL1C6JCAli7HkrwEC2pYBw2Erz6UxCGFWlGDBP4ix1i 8Isamd8m/zLxQ/0tUIbtlyDlXriSEi7w6NyIMZE5S1x/9JgKNwgppvHRjxLU8Y/LdSZ6HQuPCmzh jiOGY20dCWp0ZNWNg/VadKUMyJn12JYKGygbf6yPD3shknUsqYPhScm5upWNwbUxoInLjmsFmgTb PC44PgquU7ZHbN32Yu+kV5KM1LB917vn/Ea4QYkc9HkuWT/5qFiTgO7u/cbrYgA9eofDNRGDN7nd sgnQz5m+9PwqrWIWnRLGpiYkQEst3lObE6Z59WAu79w9GKsam7V+LqvJKetd87rXvv41sINdVn4A htgSMfbwkH3snig7Is0WNrDbxo+ETFsg1Y7Rtf+RbSluW//b1+l2tbud63FD0S3Ptgeyz10TZavb dc9uN0XeDe15S1vb/Aj3vfOdb3tne9v99ra1CzLtaxMc4AYH976tfW+B61vhC/f2w/UNbn4z/OEA l3jAB25xjFMcIQ3nd8EjLm5yk5xzGw84yk+OcoEbZOAsz/jLIR7zkcO85itnucpvrnCct9zmF7c3 z4NucJ3/G+hGp3nJk163ohd86CMvusxdDnOpR33o1LY61IXudJBvnelbl7nWqe7xg3h95UhXOtoh ohZ2O3vZ6J6IutnedmLTfdl1T/fb614RiTv73m13O9/l/ne4E17uev/74fNOeHT7Pd6OB7zb3z5v hdb75U3/z3rMuw72qod885n3t+bD3nOy99zrpi/96DOP9dE33eppf33cyv7zmX+e9ERXfetnD/TO 75zgYvf92EW/+YiHfveWv/3xzU5f2Cfd3ItnfN/5HnnBD77ZeH++4PMtee1Hf/t+TzzjwS95xHPf +3pPvLG1n/7Gj1/f0b9++288eXx67uyYn93Za5d/5vPfdBL/PwAGoAAOIAEWoAEeIAImoAIuIAMO YP/BXsjAW+q4n+pQ4Pxl1QNmoAaK1AV2YE5tIAiG4Nx4IAnClAieIAqmoAquYN2UoAuyFAvGoAzO IA2y4AveIA7moA7uIA/2YA3+oAj2oBDmExAWoQYOIRJ2/5QRLiHzJaETPiEURqH4MCEVVqEVXuFF SaEWOhMWdqEXfiEYhqEYjiEZliEKbiEapqEaCqEZtqEbviEcxqEchuAa1qEwzSEe5qEe7uHp2KEf thIfBiJR/SEhulMAHCIiBkBFJCJFIKJFOKJNMOJESKI9JCIkSsQlRgQkWmImngQnHuIkfuIjcmIj giImOuInbqIoRmImduIqaqIpwqIinuIsVmIsFqLhxE0qBsBBJGIvHmJCIOJDCKNBEOM/7GIxAmMy 8uIxpmJDIKNAQGNBSGMzMmM1MuMuYqMzMoQlTqMyRuM2VuMyjiM4WqMgqpIveuMvfmM5BiM7cuM3 GmM6Xv+jN5qjON4jPS6EPMYjP/ajNc4jMQLkO5JjPipEN7ZjOf7jPiqkMhojPp5jKjmkO87jQ9bj dfiiQNrjQq4jQnbkRFqkR24kQQojRUokQVbkOvYjSK5kQKajQ5okRMqOW3TiKFKiLdZiKOIkKyri JdLkTcpiKc5iK97iIsZiT96iKuokUN6kTf6kJyIlUQZlUi5lUC6lJVKlU+Ji8fikVEKlUmYlTpAi LdYkVjrlUUZlTmLlWQolWiYlTWYjVTZlVZriVBYlW7KlLaolWmrl63DlWGalT/plTXolWYKlWabi TjblLv5lVTLlV8KlY8rlXIJiXTbmT1ImTxKlYPKlrLT/DUySo0hyZIxIJEy2pEY2JCcOYzh+omiK Zmq2JkKwpkO05D2Wpj8C42uuZEzSzkzuJS1eZVkG505aZloa5lRKpmVKIioO5WPSpVgypl0yZVg6 p3K2pVFe5XMKJ2e2jmBCZmD65lPq5HfeZWNWJk0wp1USZnReJnqGp3YWp2MK51pipmKC53aqjl+2 53gGxVtq5nWKJ3VCZ2GmZy22J2OaZ37+53DKooLCJ4P+5lfeJ/HYZID+5X4CRX/+Z4GupV5GaFwi qIb+5oE26IAaJnFSIoq6IodKqOLoojOWJEm+aDga5EBe40HWY26+5GfaaEYuI0PmJj66JDTqaI2G JJECn2lC4mhsFulukk5erGKGRuZyvqJ7DuZ4Uqh/7iViCmiKAid0MqJ3ZmmEMieAemlObmhUbiaL rimb3mGTvik1tamczimd1qmd3ime3iec7imf9qmf/imgxk2eDiqhFiogBiqihpKhLurXJKqjbhOj RqqkTiqlVqqlXiqmZupIPSqnppGmfiqohqqojiqplirhdCqqpqqqriqrtqqrImpAAAA7 ------=_NextPart_000_0004_01C71CCA.98B356D0-- From sip-bounces@ietf.org Mon Dec 11 01:03:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GteEE-0005nx-Tk; Mon, 11 Dec 2006 01:01:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GteED-0005nj-IB for sip@ietf.org; Mon, 11 Dec 2006 01:01:29 -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 1GteEC-0002u7-3G for sip@ietf.org; Mon, 11 Dec 2006 01:01:29 -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 kBB612GA009773 for ; Mon, 11 Dec 2006 08:01:04 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 08:01:24 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Dec 2006 08:01:24 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kBB61NZm027257 for ; Mon, 11 Dec 2006 08:01:23 +0200 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id 611D493B78 for ; Mon, 11 Dec 2006 08:01:23 +0200 (EET) Message-ID: <457CF433.4020707@nokia.com> Date: Mon, 11 Dec 2006 08:01:23 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 06:01:24.0653 (UTC) FILETIME=[CA12B5D0:01C71CE9] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061211080104-25961BB0-40AEC319/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] xcap-diff-event 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've submitted an event package i-d about syncing xcap resources with xcap-diff format. The event package part is pretty much similar what Jonathan had in xcap-package before it was "moved" into the config-framework. The biggest difference is probably an OMA requirement to have subscriptions to XCAP components also. Any comments ? thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 03:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgCb-0008W6-2l; Mon, 11 Dec 2006 03:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgCZ-0008Vx-Al for sip@ietf.org; Mon, 11 Dec 2006 03:07:55 -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 1GtgCW-0003As-Hx for sip@ietf.org; Mon, 11 Dec 2006 03:07:55 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBB86dJH018603; Mon, 11 Dec 2006 10:07:26 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:07:24 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:07:23 +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] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 10:07:21 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F031A318A@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN5kNWEMip9HlT1qJJ6E0x4FCCgBvMEqA From: To: , X-OriginalArrivalTime: 11 Dec 2006 08:07:23.0381 (UTC) FILETIME=[636D1250:01C71CFB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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, Strong yes to all those three proposals. Please see the details of my reasons below, I believe they are important for the your consideration. In IETF#65 meeting I was one of those who voted for STUN as keepalive mechanism over TCP. I did that due to consistency reason: as STUN was selected as a keepalive mechanism instead of SIP PING for UDP, it appeared to me that using STUN over TCP as well would be the most straightforward way to go. However I have changed my opinion due to the following pieces of normative text which have been added to Outbound draft AFTER the Dallas hum: 1. Usage of UDP flows now appear as a bad idea in general, thus my original "consistency reason" has lost its value. UA could just set up TCP flows with CRLF keepalives and NEVER use STUN for keepalives related to Outbound: Use of outbound with UDP flows typically prevents messages larger than 1300 bytes from being delivered using TCP as described in Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP flows in environments where requests are expected to be larger than this size is therefore NOT RECOMMENDED. 2. Mechanisms to for the UA to validate if the proxy supports=20 STUN or not appear more complex than hoped. Using OPTIONS for the check also consumes an extra round-trip. No such validation is needed for CRLF keepalives, which are totally RFC3261 compatible: Because sending and receiving binary STUN data on the same ports used for SIP is a significant and non-backwards compatible change to RFC 3261, this section requires a number of checks before sending STUN messages to a SIP node. If a SIP node sends STUN requests (for example due to misconfiguration) despite these warnings, the node could be blacklisted for UDP traffic, or cause its TCP server to loose framing over its connection. For each target node (as determined by IP address, address family, and port number), the sender needs to determine if that destination is validated to support STUN, that it does not support STUN, or that it needs to be validated. A SIP node MUST NOT send STUN requests over a flow unless it has an explicit indication that the target next hop SIP server claims to support STUN. For example, automatic or manual configuration of an outbound-proxy-set which contains the keepalive=3Dstun parameter is considered sufficient explicit indication. Note that UACs MUST NOT use an ambiguous configuration option such as "Work through NATs?" or "Do Keepalives?" to imply next hop STUN support. A SIP node MAY also probe the next hop using a SIP OPTIONS request to check for support of the 'sip-stun' option tag in a Supported header field. 3. If the UA does not support TCP keepalive and the proxy appears not to support STUN, then no keepalive over TCP is possible ! If UA could simply send CRLF keepalives this would NOT be a problem: Futhermore, even with explicit indication of next hop STUN support, a SIP node needs to validate support for STUN the first time it sends traffic to a specific unvalidated target destination. If an explicit probe indicates support for the 'sip-stun' option-tag, that destination is validated for STUN support. If an explicit probe does not indicate support for the 'sip-stun' option-tag, the target destination does not support STUN request, and the UAC MUST NOT send further STUN requests to this destination. A SIP node MAY send one STUN request and its retransmissions to an unvalidated destination. If a STUN request ever succeeds to a destination, that destination is thereafter validated for STUN support. If this initial STUN request does not result in a STUN response, the SIP node MUST NOT send additional STUN requests over this flow, unless and until a next-hop probe later validates the destination. In addition, the SIP node SHOULD remember unvalidated destination nodes that have been used within one hour and SHOULD NOT send additional STUN messages to any of these destinations. Note that until STUN support has been verified, an initial STUN failure over UDP is not considered a flow failure. For UDP flows, an unvalidated flow can still be reused for SIP traffic, however for unvalidated TCP or TLS over TCP flows, the connection over which STUN requests were sent MUST be closed. 4. Interaction of SIP, STUN and SigComp over TCP clearly wastes bandwidth, exactly on cases where SigComp would otherwise be useful to save bandwidth. Instead of sending a couple of bytes (CRLF keepalive) each keepalive would consist of more than 30 bytes (13 bytes of SigComp shim header plus 20 bytes of STUN header): For TCP-based flows, SigComp requires that all messages are processed by the SigComp compressor to facilitate framing. For these transports, STUN messages are sent encapsulated in the SigComp "well- known shim header" as described in Section 11 of [I-D.ietf-rohc- sigcomp-impl-guide]. For an UA that would support Outbound only over TCP using CRLF keepalives, all that complicated processing together with waste of round-trips and bandwidth would be easily avoided. >Previously we had recorded consensus to use STUN for keepalive with =20 >both TCP and UDP.=20 In my understanding that concensus was reached by hums in IETF#65 meeting in Dallas. My observation from the meeting was that the discussion was focusing to a selection between STUN and SIP PING as a global keepalive mechanism, which raised a hectic email rally before the meeting. CRLF was touched but the debate was really about the choice between STUN and PING. There were two votes in the meeting, the first one for UDP keepalive mechanism and the second for TCP. My feeling was that the meeting participants focused their thoughts very much on the STUN vs. PING issue so that STUN vs. CRLF was not considered too carefully before the votes. And as demonstrated above, the decision made in Dallas brought a number of complications to Outbound in a way which could not be anticipated yet in that meeting. Regards, Erkki=20 >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 09.December.2006 04:12 >To: SIP IETF >Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and=20 >UDP usage in draft-ietf-sip-outbound > >Previously we had recorded consensus to use STUN for keepalive with =20 >both TCP and UDP. This was not a perfect consensus (there were some =20 >dissenters). There has been ongoing discussion notably instigated by =20 >the current editor of the Outbound draft, that some people feel may =20 >have resulted in a change of the consensus on this draft's technical =20 >direction. > >So I'd like to ask people who care and think they understand the =20 >differences to answer the following questions, on-list and on-the =20 >record. > > >Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS =20 >over TCP flow (retain STUN for UDP flows). > >Yes (accept the proposal and use CRLF for TCP) or No (reject the =20 >proposal and keep STUN for TCP) > > >Proposal 2: Make outbound registrations over UDP flows=20 >optional for UAs. > >Yes (Accept the proposal) or No (Reject the proposal). > > >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. Further, include text that explain that for historical =20 >purposes a lot of deployments still only use UDP, but that we expect/=20 >hope those deployments to eventually migrate to TCP when doing=20 >outbound. > >Yes (Accept the proposal and add the text) or No (Reject the proposal =20 >and keep the text as-is). > > >-- >Dean Willis (wearing his chair sombrero) > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Dec 11 03:21:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgPP-0005Vb-7q; Mon, 11 Dec 2006 03:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgPN-0005TQ-OX for sip@ietf.org; Mon, 11 Dec 2006 03:21:09 -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 1GtgPK-0006NW-Dp for sip@ietf.org; Mon, 11 Dec 2006 03:21:09 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JA300K48OJ0C9@siemenscomms.co.uk> for sip@ietf.org; Mon, 11 Dec 2006 08:21:00 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 11 Dec 2006 08:20:53 +0000 Content-return: allowed Date: Mon, 11 Dec 2006 08:20:45 +0000 From: "Elwell, John" Subject: RE: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usag e in draft-ietf-sip-outbound To: Dean Willis , SIP IETF Message-id: <50B1CBA96870A34799A506B2313F26670A8682E0@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: f4c2cf0bccc868e4cc88dace71fb3f44 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 Yes to all. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 09 December 2006 02:12 > To: SIP IETF > Subject: [Sip] Poll: Proposal relating to keepalive, TCP, and > UDP usage in draft-ietf-sip-outbound > > Previously we had recorded consensus to use STUN for keepalive with > both TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated by > the current editor of the Outbound draft, that some people feel may > have resulted in a change of the consensus on this draft's technical > direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the > record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > > > Proposal 2: Make outbound registrations over UDP flows > optional for UAs. > > Yes (Accept the proposal) or No (Reject the proposal). > > > 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. Further, include text that explain that for historical > purposes a lot of deployments still only use UDP, but that we expect/ > hope those deployments to eventually migrate to TCP when > doing outbound. > > Yes (Accept the proposal and add the text) or No (Reject the > proposal > and keep the text as-is). > > > -- > Dean Willis (wearing his chair sombrero) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 11 03:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY5-0000O1-Af; Mon, 11 Dec 2006 03:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY3-0000N2-Ac for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtgXw-0000lM-MQ for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E34799F0; Mon, 11 Dec 2006 09:29:53 +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, 11 Dec 2006 09:29: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: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 09:29:52 +0100 Message-ID: <7374777208BDC7449D5620EF94232567E13F70@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN5coW0aYGBPqQBSD++qTR1PRdgBS1gVA From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "SIP IETF" X-OriginalArrivalTime: 11 Dec 2006 08:29:53.0707 (UTC) FILETIME=[884877B0:01C71CFE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, There are a few issues I'd like to clarify on proposal 3. First, I think the "default" recommendation should only cover TCP. The text can say that, if the terminal supports TLS, the recommendation also covers TLS. However, in some environments other security mechanisms may be used, so I don't think clients in such environments should even be recommended to implement TLS, nor should the whatever-outbound-proxy-set configuration-mechanism is used in those environments be recommended to return TLS registrations in such environements. Second, as I said before, I don't think we shall talk about UDP and its "history". UDP is a valid transport for SIP. IF someone really wants this history text I propose we separate it into proposal 4. Third, since it is only recommended to return TCP information, I guess it means we will NOT mandate (eventhough we would, if propsoal 3 is accepted, recommend it) a UA to establish TCP registrations? If so, I think we could clarify that (either as part of option 2 or 3).=20 Regards, Christer =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 9. joulukuuta 2006 4:12 > To: SIP IETF > Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and=20 > UDP usage in draft-ietf-sip-outbound >=20 > Previously we had recorded consensus to use STUN for=20 > keepalive with both TCP and UDP. This was not a perfect=20 > consensus (there were some dissenters). There has been=20 > ongoing discussion notably instigated by the current editor=20 > of the Outbound draft, that some people feel may have=20 > resulted in a change of the consensus on this draft's=20 > technical direction. >=20 > So I'd like to ask people who care and think they understand=20 > the differences to answer the following questions, on-list=20 > and on-the record. >=20 >=20 > Proposal 1: Make CRLF the only keepalive mechanism for TCP=20 > and TLS over TCP flow (retain STUN for UDP flows). >=20 > Yes (accept the proposal and use CRLF for TCP) or No (reject=20 > the proposal and keep STUN for TCP) >=20 >=20 > Proposal 2: Make outbound registrations over UDP flows=20 > optional for UAs. >=20 > Yes (Accept the proposal) or No (Reject the proposal). >=20 >=20 > Proposal 3: Include (in Outbound) the statement that its is=20 > RECOMMENDED that the outbound-proxy-set is configured to=20 > result in registrations over TCP or TLS whenever the UA can't=20 > accept incoming TCP flows. Further, include text that explain=20 > that for historical purposes a lot of deployments still only=20 > use UDP, but that we expect/ hope those deployments to=20 > eventually migrate to TCP when doing outbound. >=20 > Yes (Accept the proposal and add the text) or No (Reject the=20 > proposal and keep the text as-is). >=20 >=20 > -- > Dean Willis (wearing his chair sombrero) >=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 Dec 11 03:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgYJ-0000U1-0I; Mon, 11 Dec 2006 03:30:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgYH-0000Tt-5w for sip@ietf.org; Mon, 11 Dec 2006 03:30:21 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtgYF-0000nc-SW for sip@ietf.org; Mon, 11 Dec 2006 03:30:21 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id EE21A3C0A2; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21939-01-10; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 982A83C093; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Message-ID: <457D16EA.7010704@it.su.se> Date: Mon, 11 Dec 2006 09:29:30 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.651 tagged_above=-99 required=7 tests=[AWL=0.014, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Rohan Mahy wrote: > Edge Proxies and Registrars would still need to support outbound with UDP. Hi Before answering Dean's poll, I would like to know more about this. Have you figured out a (reasonable) way for the edge proxy/authoritative proxy (or the combination thereof) to switch from UDP to TCP for large messages destined for a UAC that uses Outbound? I'm thinking of the problems in doing that that we discussed briefly in these two messages : http://www1.ietf.org/mail-archive/web/sip/current/msg17418.html http://www1.ietf.org/mail-archive/web/sip/current/msg17420.html Thanks /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 03:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY5-0000O1-Af; Mon, 11 Dec 2006 03:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY3-0000N2-Ac for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtgXw-0000lM-MQ for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E34799F0; Mon, 11 Dec 2006 09:29:53 +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, 11 Dec 2006 09:29: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: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 09:29:52 +0100 Message-ID: <7374777208BDC7449D5620EF94232567E13F70@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN5coW0aYGBPqQBSD++qTR1PRdgBS1gVA From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" , "SIP IETF" X-OriginalArrivalTime: 11 Dec 2006 08:29:53.0707 (UTC) FILETIME=[884877B0:01C71CFE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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, There are a few issues I'd like to clarify on proposal 3. First, I think the "default" recommendation should only cover TCP. The text can say that, if the terminal supports TLS, the recommendation also covers TLS. However, in some environments other security mechanisms may be used, so I don't think clients in such environments should even be recommended to implement TLS, nor should the whatever-outbound-proxy-set configuration-mechanism is used in those environments be recommended to return TLS registrations in such environements. Second, as I said before, I don't think we shall talk about UDP and its "history". UDP is a valid transport for SIP. IF someone really wants this history text I propose we separate it into proposal 4. Third, since it is only recommended to return TCP information, I guess it means we will NOT mandate (eventhough we would, if propsoal 3 is accepted, recommend it) a UA to establish TCP registrations? If so, I think we could clarify that (either as part of option 2 or 3).=20 Regards, Christer =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 9. joulukuuta 2006 4:12 > To: SIP IETF > Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and=20 > UDP usage in draft-ietf-sip-outbound >=20 > Previously we had recorded consensus to use STUN for=20 > keepalive with both TCP and UDP. This was not a perfect=20 > consensus (there were some dissenters). There has been=20 > ongoing discussion notably instigated by the current editor=20 > of the Outbound draft, that some people feel may have=20 > resulted in a change of the consensus on this draft's=20 > technical direction. >=20 > So I'd like to ask people who care and think they understand=20 > the differences to answer the following questions, on-list=20 > and on-the record. >=20 >=20 > Proposal 1: Make CRLF the only keepalive mechanism for TCP=20 > and TLS over TCP flow (retain STUN for UDP flows). >=20 > Yes (accept the proposal and use CRLF for TCP) or No (reject=20 > the proposal and keep STUN for TCP) >=20 >=20 > Proposal 2: Make outbound registrations over UDP flows=20 > optional for UAs. >=20 > Yes (Accept the proposal) or No (Reject the proposal). >=20 >=20 > Proposal 3: Include (in Outbound) the statement that its is=20 > RECOMMENDED that the outbound-proxy-set is configured to=20 > result in registrations over TCP or TLS whenever the UA can't=20 > accept incoming TCP flows. Further, include text that explain=20 > that for historical purposes a lot of deployments still only=20 > use UDP, but that we expect/ hope those deployments to=20 > eventually migrate to TCP when doing outbound. >=20 > Yes (Accept the proposal and add the text) or No (Reject the=20 > proposal and keep the text as-is). >=20 >=20 > -- > Dean Willis (wearing his chair sombrero) >=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 Dec 11 03:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgYJ-0000U1-0I; Mon, 11 Dec 2006 03:30:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgYH-0000Tt-5w for sip@ietf.org; Mon, 11 Dec 2006 03:30:21 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtgYF-0000nc-SW for sip@ietf.org; Mon, 11 Dec 2006 03:30:21 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id EE21A3C0A2; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21939-01-10; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 982A83C093; Mon, 11 Dec 2006 09:30:00 +0100 (CET) Message-ID: <457D16EA.7010704@it.su.se> Date: Mon, 11 Dec 2006 09:29:30 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.651 tagged_above=-99 required=7 tests=[AWL=0.014, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Rohan Mahy wrote: > Edge Proxies and Registrars would still need to support outbound with UDP. Hi Before answering Dean's poll, I would like to know more about this. Have you figured out a (reasonable) way for the edge proxy/authoritative proxy (or the combination thereof) to switch from UDP to TCP for large messages destined for a UAC that uses Outbound? I'm thinking of the problems in doing that that we discussed briefly in these two messages : http://www1.ietf.org/mail-archive/web/sip/current/msg17418.html http://www1.ietf.org/mail-archive/web/sip/current/msg17420.html Thanks /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 03:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY4-0000NO-IQ; Mon, 11 Dec 2006 03:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtgY3-0000N1-AT for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtgXw-0000mM-MQ for sip@ietf.org; Mon, 11 Dec 2006 03:30:07 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9740FBFD; Mon, 11 Dec 2006 09:29:57 +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, 11 Dec 2006 09:29:57 +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] Re: issue with oubound and the used transport protocol Date: Mon, 11 Dec 2006 09:29:56 +0100 Message-ID: <7374777208BDC7449D5620EF94232567E13F72@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E5B2A48@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: Acca8JHlmXPTIQRjQnm9Xf7SWjUsogANxesgAFeGaFA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Cullen Jennings" , "Hisham Khartabil" X-OriginalArrivalTime: 11 Dec 2006 08:29:57.0426 (UTC) FILETIME=[8A7FF120:01C71CFE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Rohan Mahy , Fredrik Thulin , SIP , "Isomaki Markus \(Nokia-TP/Espoo\)" , Peter Leis , Aki Niemi , Dean Willis , Keith Drage 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 >My best guest on why this is happening is that people used to=20 >be thinking more about UDP than TCP and consequently=20 >expressed a preference for the STUN approach. I think people thought more about STUN than either UDP or TCP ;) Regards, Christer > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Friday, December 08, 2006 09:43 > > To: Hisham Khartabil > > Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus=20 > (Nokia-TP/Espoo);=20 > > Peter Leis; Aki Niemi; Dean Willis; Keith Drage > > Subject: Re: [Sip] Re: issue with oubound and the used transport=20 > > protocol > >=20 > >=20 > > On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: > >=20 > > > Please, lets not wait until March to discuss this. We can > > take a hum > > > here on the mailing list > >=20 > > We had most of a room hum the other direction so, which did=20 > leave me=20 > > thinking, assuming we don't get a single no on the the=20 > list, how many=20 > > yes do think the chairs should be looking for to overturn this? I=20 > > don't really want to know the answer to this as this is=20 > something that=20 > > only the chairs need to figure out but it is an interesting=20 > question=20 > > to think about when thinking about reopening this. > >=20 > > And just so people understand my position on this, if we=20 > reopen this=20 > > issue, I will be voting for whichever path I think can get=20 > the draft=20 > > to the IESG the soonest. I've implemented both and they are both=20 > > trivial to implement. I really believe that what we need is to stop=20 > > delaying this draft. > >=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=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 Dec 11 03:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtgqz-0001F2-E4; Mon, 11 Dec 2006 03:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtgqy-0001Et-1P for sip@ietf.org; Mon, 11 Dec 2006 03:49:40 -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 1Gtgqw-0006yF-Ij for sip@ietf.org; Mon, 11 Dec 2006 03:49:40 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBB8mwqY004268; Mon, 11 Dec 2006 10:49:17 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 10:49:31 +0200 Received: from 4FIL15472 ([172.21.39.123]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Dec 2006 10:49:31 +0200 From: "Aki Niemi" To: "'ext Dean Willis'" , "'SIP IETF'" Subject: RE: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 10:49:30 +0200 Message-ID: <001301c71d01$45bdfc00$119db70a@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AccbN9ofHOUDNZ0OSZmcR8f7EPsaMQByPuXg In-reply-to: X-OriginalArrivalTime: 11 Dec 2006 08:49:31.0139 (UTC) FILETIME=[46165530:01C71D01] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Yes, yes, and yes. Cheers, Aki >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com] >Sent: 09 December, 2006 04:12 >To: SIP IETF >Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and >UDP usage in draft-ietf-sip-outbound > >Previously we had recorded consensus to use STUN for keepalive >with both TCP and UDP. This was not a perfect consensus (there >were some dissenters). There has been ongoing discussion >notably instigated by the current editor of the Outbound >draft, that some people feel may have resulted in a change of >the consensus on this draft's technical direction. > >So I'd like to ask people who care and think they understand >the differences to answer the following questions, on-list and >on-the record. > > >Proposal 1: Make CRLF the only keepalive mechanism for TCP and >TLS over TCP flow (retain STUN for UDP flows). > >Yes (accept the proposal and use CRLF for TCP) or No (reject >the proposal and keep STUN for TCP) > > >Proposal 2: Make outbound registrations over UDP flows >optional for UAs. > >Yes (Accept the proposal) or No (Reject the proposal). > > >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. Further, include text that explain >that for historical purposes a lot of deployments still only >use UDP, but that we expect/ hope those deployments to >eventually migrate to TCP when doing outbound. > >Yes (Accept the proposal and add the text) or No (Reject the >proposal and keep the text as-is). > > >-- >Dean Willis (wearing his chair sombrero) > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Dec 11 04:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gth1m-0005VD-AJ; Mon, 11 Dec 2006 04:00:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gth1l-0005V8-5U for sip@ietf.org; Mon, 11 Dec 2006 04:00:49 -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 1Gth1j-0001nF-Mp for sip@ietf.org; Mon, 11 Dec 2006 04:00:49 -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 kBB8xwUb009976; Mon, 11 Dec 2006 11:00:24 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:00:43 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:00:44 +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] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 11:00:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN4mulRUT10tHTy6+Ta8aQbouMwByv6xA From: To: , X-OriginalArrivalTime: 11 Dec 2006 09:00:44.0084 (UTC) FILETIME=[D7319740:01C71D02] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, Yes to all proposals, especially the first one. Markus >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 09 December, 2006 04:12 >To: SIP IETF >Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and=20 >UDP usage in draft-ietf-sip-outbound > >Previously we had recorded consensus to use STUN for keepalive=20 >with both TCP and UDP. This was not a perfect consensus (there=20 >were some dissenters). There has been ongoing discussion=20 >notably instigated by the current editor of the Outbound=20 >draft, that some people feel may have resulted in a change of=20 >the consensus on this draft's technical direction. > >So I'd like to ask people who care and think they understand=20 >the differences to answer the following questions, on-list and=20 >on-the record. > > >Proposal 1: Make CRLF the only keepalive mechanism for TCP and=20 >TLS over TCP flow (retain STUN for UDP flows). > >Yes (accept the proposal and use CRLF for TCP) or No (reject=20 >the proposal and keep STUN for TCP) > > >Proposal 2: Make outbound registrations over UDP flows=20 >optional for UAs. > >Yes (Accept the proposal) or No (Reject the proposal). > > >Proposal 3: Include (in Outbound) the statement that its is=20 >RECOMMENDED that the outbound-proxy-set is configured to=20 >result in registrations over TCP or TLS whenever the UA can't=20 >accept incoming TCP flows. Further, include text that explain=20 >that for historical purposes a lot of deployments still only=20 >use UDP, but that we expect/ hope those deployments to=20 >eventually migrate to TCP when doing outbound. > >Yes (Accept the proposal and add the text) or No (Reject the=20 >proposal and keep the text as-is). > > >-- >Dean Willis (wearing his chair sombrero) > >_______________________________________________ >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 Mon Dec 11 04:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GthOQ-0006y8-ND; Mon, 11 Dec 2006 04:24:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GthOP-0006xy-C2 for sip@ietf.org; Mon, 11 Dec 2006 04:24:13 -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 1GthON-0007ZS-S4 for sip@ietf.org; Mon, 11 Dec 2006 04:24:13 -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 kBB9NDCA002878; Mon, 11 Dec 2006 11:23:21 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:23:46 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:23:46 +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] Re: issue with oubound and the used transport protocol Date: Mon, 11 Dec 2006 11:23:45 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E5B2A48@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: Acca8JHlmXPTIQRjQnm9Xf7SWjUsogANxesgAHbUfrA= From: To: , , X-OriginalArrivalTime: 11 Dec 2006 09:23:46.0175 (UTC) FILETIME=[0EFBF0F0:01C71D06] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061211112325-082B1BB0-622D23B5/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rohan@ekabal.com, ft@it.su.se, sip@ietf.org, peter.leis@siemens.com, aki.niemi@nokia.com, dean.willis@softarmor.com, drage@lucent.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 Francois here. Even though there may be some performance limitations for TCP in the current implementations, I think that almost everyone agrees that it is the way to go in the long run. This is why it would be good to have an optimal solution for Outbound/TCP, instead of trying to keep consistency between UDP and TCP. It would be great if we could do UAs supporting Outbound with TCP/TLS only, and leave mess with message size, fragment handling, UDP-based security, 20 second NAT keepalive timers etc. behind us. This may not be realistic yet, if there are enough service providers who will demand UDP (since unfortunately there are e.g. SBCs that do not even have a proper TCP support at all), but that should be the aim. =20 3GPP IMS networks, if such are deployed in the "puristic" form, may be a different thing, but even there TCP is a better option.=20 Markus >-----Original Message----- >From: ext Francois Audet [mailto:audet@nortel.com]=20 >Sent: 09 December, 2006 02:31 >To: Cullen Jennings; Hisham Khartabil >Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus=20 >(Nokia-SIR/Espoo); Peter Leis; Niemi Aki (Nokia-NRC/Helsinki);=20 >Dean Willis; Keith Drage >Subject: RE: [Sip] Re: issue with oubound and the used=20 >transport protocol > >Cullen, > >My best guest on why this is happening is that people used to=20 >be thinking more about UDP than TCP and consequently expressed=20 >a preference for the STUN approach. > >It seems now that more people are paying attention to TCP=20 >because of a bunch of issues with UDP (including=20 >fragmentation, and TLS usage catching up since it took us so=20 >long to finalize this document). Many are reaching the=20 >conclusion that the CRLF approach makes more sense for TCP. > >It seems that Rohan's last proposal of using CRLF for TCP, and=20 >STUN for UDP to be reasonable and logical. And it seems to=20 >have lots of support on the list. > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, December 08, 2006 09:43 >> To: Hisham Khartabil >> Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus=20 >(Nokia-TP/Espoo);=20 >> Peter Leis; Aki Niemi; Dean Willis; Keith Drage >> Subject: Re: [Sip] Re: issue with oubound and the used transport=20 >> protocol >>=20 >>=20 >> On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: >>=20 >> > Please, lets not wait until March to discuss this. We can >> take a hum >> > here on the mailing list >>=20 >> We had most of a room hum the other direction so, which did leave me=20 >> thinking, assuming we don't get a single no on the the list,=20 >how many=20 >> yes do think the chairs should be looking for to overturn this? I=20 >> don't really want to know the answer to this as this is=20 >something that=20 >> only the chairs need to figure out but it is an interesting question=20 >> to think about when thinking about reopening this. >>=20 >> And just so people understand my position on this, if we reopen this=20 >> issue, I will be voting for whichever path I think can get the draft=20 >> to the IESG the soonest. I've implemented both and they are both=20 >> trivial to implement. I really believe that what we need is to stop=20 >> delaying this draft. >>=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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 05:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiFZ-00016m-Bx; Mon, 11 Dec 2006 05:19:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiFY-00016c-59 for sip@ietf.org; Mon, 11 Dec 2006 05:19:08 -0500 Received: from maildialog.com ([195.159.98.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GtiFV-00027m-Kf for sip@ietf.org; Mon, 11 Dec 2006 05:19:08 -0500 Received: from [82.196.214.14] (helo=[192.168.1.100]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1GtiFM-00082s-Fx; Mon, 11 Dec 2006 10:18:56 +0000 Message-ID: <457D308C.7080108@db.org> Date: Mon, 11 Dec 2006 11:18:52 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP IETF 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 Willis wrote: > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over > TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > YES. > > Proposal 2: Make outbound registrations over UDP flows optional for UAs. > > Yes (Accept the proposal) or No (Reject the proposal). > YES. > > 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. > Further, include text that explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > Yes (Accept the proposal and add the text) or No (Reject the proposal > and keep the text as-is). > YES. /alfred _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 05:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiUf-00086N-7X; Mon, 11 Dec 2006 05:34:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtiUd-00086D-Pc for sip@ietf.org; Mon, 11 Dec 2006 05:34:43 -0500 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtiUb-0003bD-1U for sip@ietf.org; Mon, 11 Dec 2006 05:34:43 -0500 Received: from omini95.omnitel.it (omini95.omnitel.it [10.21.18.147]) by fmis837.omnitel.it (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBBAYXvs012289 for ; Mon, 11 Dec 2006 11:34:33 +0100 (MET) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Dec 2006 11:34:27 +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] Re: issue with oubound and the used transport protocol Date: Mon, 11 Dec 2006 11:34:25 +0100 Message-ID: <5371BE300539E6439919CF97203DDEC2088AD89F@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: issue with oubound and the used transport protocol Thread-Index: Acca8JHlmXPTIQRjQnm9Xf7SWjUsogANxesgAHbUfrAAAyO/0A== From: "STURA, Marco, VF-IT" To: , , , X-OriginalArrivalTime: 11 Dec 2006 10:34:27.0326 (UTC) FILETIME=[EEE839E0:01C71D0F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: rohan@ekabal.com, ft@it.su.se, sip@ietf.org, peter.leis@siemens.com, aki.niemi@nokia.com, dean.willis@softarmor.com, drage@lucent.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 > 3GPP IMS networks, if such are deployed in the "puristic" form, may be = a different=20 >thing, but even there TCP is a better option.=20 I don't think such "puristic" deployments exist to date. In general I do = agree with Markus that TCP would be a better option in 3GPP IMS networks = too. Br, Marco -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: luned=EC 11 dicembre 2006 10.24 To: audet@nortel.com; fluffy@cisco.com; hisham.khartabil@telio.no Cc: rohan@ekabal.com; ft@it.su.se; sip@ietf.org; peter.leis@siemens.com; = aki.niemi@nokia.com; dean.willis@softarmor.com; drage@lucent.com Subject: RE: [Sip] Re: issue with oubound and the used transport = protocol Hi, I agree with Francois here. Even though there may be some performance = limitations for TCP in the current implementations, I think that almost = everyone agrees that it is the way to go in the long run. This is why it = would be good to have an optimal solution for Outbound/TCP, instead of = trying to keep consistency between UDP and TCP. It would be great if we could do UAs supporting Outbound with TCP/TLS = only, and leave mess with message size, fragment handling, UDP-based = security, 20 second NAT keepalive timers etc. behind us. This may not be = realistic yet, if there are enough service providers who will demand UDP = (since unfortunately there are e.g. SBCs that do not even have a proper TCP support at all), but that should be the aim. =20 3GPP IMS networks, if such are deployed in the "puristic" form, may be a = different thing, but even there TCP is a better option.=20 Markus >-----Original Message----- >From: ext Francois Audet [mailto:audet@nortel.com] >Sent: 09 December, 2006 02:31 >To: Cullen Jennings; Hisham Khartabil >Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus (Nokia-SIR/Espoo);=20 >Peter Leis; Niemi Aki (Nokia-NRC/Helsinki); Dean Willis; Keith Drage >Subject: RE: [Sip] Re: issue with oubound and the used transport=20 >protocol > >Cullen, > >My best guest on why this is happening is that people used to be=20 >thinking more about UDP than TCP and consequently expressed a=20 >preference for the STUN approach. > >It seems now that more people are paying attention to TCP because of a=20 >bunch of issues with UDP (including fragmentation, and TLS usage=20 >catching up since it took us so long to finalize this document). Many=20 >are reaching the conclusion that the CRLF approach makes more sense for = >TCP. > >It seems that Rohan's last proposal of using CRLF for TCP, and STUN for = >UDP to be reasonable and logical. And it seems to have lots of support=20 >on the list. > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, December 08, 2006 09:43 >> To: Hisham Khartabil >> Cc: Rohan Mahy; Fredrik Thulin; SIP; Isomaki Markus >(Nokia-TP/Espoo); >> Peter Leis; Aki Niemi; Dean Willis; Keith Drage >> Subject: Re: [Sip] Re: issue with oubound and the used transport=20 >> protocol >>=20 >>=20 >> On Dec 8, 2006, at 5:49 AM, Hisham Khartabil wrote: >>=20 >> > Please, lets not wait until March to discuss this. We can >> take a hum >> > here on the mailing list >>=20 >> We had most of a room hum the other direction so, which did leave me=20 >> thinking, assuming we don't get a single no on the the list, >how many >> yes do think the chairs should be looking for to overturn this? I=20 >> don't really want to know the answer to this as this is >something that >> only the chairs need to figure out but it is an interesting question=20 >> to think about when thinking about reopening this. >>=20 >> And just so people understand my position on this, if we reopen this=20 >> issue, I will be voting for whichever path I think can get the draft=20 >> to the IESG the soonest. I've implemented both and they are both=20 >> trivial to implement. I really believe that what we need is to stop=20 >> delaying this draft. >>=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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Threads@almudaina.e.telefonica.net Mon Dec 11 06:15:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtj84-0006uN-Uc for sip-archive@lists.ietf.org; Mon, 11 Dec 2006 06:15:28 -0500 Received: from 4va54-4-82-244-103-87.fbx.proxad.net ([82.244.103.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtj82-0007Op-HZ for sip-archive@lists.ietf.org; Mon, 11 Dec 2006 06:15:28 -0500 Received: from YzCPNy (unknown [107.186.20.124]) by proxad.net with ESMTP id 5547A163924E for ; Mon, 11 Dec 2006 12:15:26 +0100 Message-ID: <000e01c71d15$a017c6e0$5767f452@edgepc> From: "Changes" To: sip-archive@lists.ietf.org Subject: Msn Messenger Date: Mon, 11 Dec 2006 12:15:12 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C71D1E.01DC2EE0" 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: 872695ea777a517bf5717e5acc69f8be ------=_NextPart_000_000A_01C71D1E.01DC2EE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C71D1E.01DC2EE0" ------=_NextPart_001_000B_01C71D1E.01DC2EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Members list arcade todays posts search gt. Forums show threads advanced go page. Once registered will as many ads = tools display modes. Next raquo vbulletin message, cancel changes = currently. Start viewing messages select that? Funny stuff similar = starter last frostwire twisterx winmx just. Both networks it, also contains slew! Hardware internet graphics offtopic lounge? Replies edit, vb code? Money ebooks, paid to post weblife forum. Read the and thread you have before can click. Public profile find more, by am quotthe? Jump control panel private whos = online, amp. Currently active printable email! Pictures cheap posters money, ebooks paid to post. ------=_NextPart_001_000B_01C71D1E.01DC2EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Guides"
Members list arcade todays posts search = gt.
Forums show threads advanced go page. = Once=20 registered will as many ads tools display modes. Next raquo vbulletin = message,=20 cancel changes currently. Start viewing messages select that? Funny = stuff=20 similar starter last frostwire twisterx winmx just.
Both networks it, also contains = slew!
Hardware internet graphics offtopic = lounge?
Replies edit, vb code? Money ebooks, = paid to post=20 weblife forum.
Read the and thread you have before can = click.
Public profile find more, by am = quotthe? Jump=20 control panel private whos online, amp. Currently active printable = email!
Pictures cheap posters money, ebooks = paid to=20 post.
------=_NextPart_001_000B_01C71D1E.01DC2EE0-- ------=_NextPart_000_000A_01C71D1E.01DC2EE0 Content-Type: image/gif; name="Next.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c71d15$a017c6e0$5767f452@edgepc> R0lGODlhYAKEAocJAAAAAIoEAAh9AHyIAAIAhYYAdQeBhMq/tMrVuZjD5jYVAFQgAIokAK4fAL0g BeUdCABHABU2AENMAF0/C3k+AJkzALtNANkzBAhsBClrADVYAFVUAIJcCZJsAMBjAextBAB+DBp/ AEeDAl9zBXNzAJyBAMOKA9x/DACTABGuAEijAGSdAI2YC5KSCc2jB+CmAAjIACvOAEuzAFi9Co69 ApfNBrm5AOrNAA7gABHlADnaBFrTDXvVAJntALvlANnsAAABSyAAOTUATmULNncNPq0AN70AOu4M PAAZOy4cST8oOlMnQ4ghQZQYTLgYM9ErMgBFNB8+Rjc7PWo9NYkzP5FNOb5KMeAxTQhcRxpgSUVU R2tUMXdbAppgNLNdSdxZQAB0RC10RzmFNmaAO3ZyNJyJM7uGNeBxQg6pQC2SOkafR1+TTHugS5yq MriWNuWtQgC+ShTDRjXBSFK+SIPGSqq6PcG4Se62OQrUNSHTTTbYQFjmNHHWS6nhQLjqMubVMwAN jigDcT0Ji1MAc40AdJ4Gh7MOhOwAcQQdhhEbhTsegFIahokWg54ghMQaduAfjAA4eh5JhTsxdl88 jY03gKVIiMRGfe1CiglShSNohDhShVFkgYZRe6hsjblZiNlUeAB2cil7fTKJhlKHe3SOiKt4fMKH gtV6fgChch+XcUqZelunfIGhgJmpi7SlcdGlcgDDgSzAeEC5gWLKjnLLiZ6/erK3i9K6fADafyXn hE7qfVTVeIPSi6XgiL/RgeLddgAAuSAAu0QAuGQAu3MNzZkAt7EAzNYAtwcfuSgdszweulUsynYl vpoaxbEgt9gZyw45zR8+sTw/w184uopCxq0zt743w9JDswtowi1otUxruWZkyHRjxJxTtMpjv+Rq zQCDvy11t0d1smaMuouCtZV1zLN1yu19ygiXtx6bsUCdsl+lyX6ku5qiysOUs+Wjtw65tim/w0qx tlXNw3LGxqvDzv//4qWmpXFzi/8ACgD1APfwAAoA//IA/wD//vH//yH5BABYq2EALAAAAABgAoQC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKbPivpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9esI8OK HUu2rNmzaNOqXcu27cavcOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDO90qXsy4sePHkCNLnky5 suXLmDNr3sx5LeLPoEOLHm24s+nTqFOrXs2aI+nXsGPLnk27tu3buHN3bc27t+/fwIO31U28uPHj yJMrX868ufPn0KNL3yq8uvXr2LNnn869u/fvJrWL/x9Pvrz5xjAHqGepvv0Ale7Xm2x/kn5L+/Pj x2e/P//7+uvp9x9//fknIIDulSQgfQn698+C+BmI4IMQUjggfhgWSCBKEMqH4IAKRqjfhxMuuCGJ IcoXIXjFNdQeQi/aE+NAMc5Y44wJ4ViQjgfdOACN6u0YpI8/whikjDYeaWSRL/IoUHxAFhmlQlA+ OaSSQkqZJJNHOkmQl0hK2aOO7k0ZZpRKNpmmkzxuaeZ5cI6VnocTOphinQyuCF+DKenJIZ32rZjn hXT+SeihJ4Zo4UoFClqooR4OemKgKgIKYp98Gnofn/2JWGmG7zl6qYYWhgoqi93pqWqAjw6aKYGP 3v+ZqIOiLirrnojeqimujHZaqJ8Gfmorr/tReqlLpNrZK6isHuuqsKuCmKykyqIaXbSYmupss8Bi SuGym26rraangnsrsOjGuqiwdYILrbrrmmprt3t+yyus3Dabbbx3YpufvZCOCq+1yvlbYqv5xkTt ruYeLPC4w97rqYnpUqxvrRtK2mG/8jJ77L5+0pvntwvTerG+DJec4q8DEyybi1haKabMZ2YZJphf XjkzzTnGfCaZOpdJpX42j7kzzwbdWPObRlv5s885q9mm0EsuHfXQP0IpddI6O7110U8fPfXRcZZ9 1thcZ+2z1FT3XCXYTdsMtNp0L/Q101fHnbbMc2P/zXfXbgdNttVZto130T4SHvbfdYMtoN6Hmy05 WWjLvXbXhjt++eCK301z4m4jrbjoee/9N9ym39z4koKHrnflVdfs+edrzo7km7BHPvnuIrGJpZtm Eul651CXLnvMX2cePPCQA57626RrbnvUWiZpfOm5p543jqCrTjjz2fMuvlleds8z+OXPvDlD5gO/ JdnvR48m7fD/3vfwN4+Ovf1cDo78zjjzXfX6x7QyxQ9IQtKe/MbHQI0siHpQI1oBs3c/u0GPcQOk XvPYJkHGYdBzhgsg/+j2ONz9T3mkqyDkJtg27nFQhd9bXwNnSMMa2vCGOLyMy3bIwx5+JodADKIQ /4dIxCIa8YhIrIgPl8jEJuYliVCMohQn58QqWvGKWMyiFrf4mil68Ytg3F0AxniQMZoxAAIxI0HU aJAzDsSNaTwjGt9IxjWSUY51TAge87hHhODRjnOMIxr3qMY+KgSOggQkGxPJSHsscpFhjCQNaWLG lFTyH5W85BlZcklMjtEkmvxkSTo5yk+GUpQq6eQpS4lKVrrylZv0ZABWcspZ0jKWsgSlKFWJSl7a MpdcDGZoICJHQNrRkXeEZBsLyUZINjOPiXwkNAsizTlW05h0tGYy+TjNbHrTj4h8ZiCRGUhxNpKc kkznDGcix5OQUpftdEkmd9lKV75znr98pzt7Sf/PfPLzl/CUJS6Bacl/cjKe+CyoLfFpylbqU5gQ FQwxBzlOZQrSouC8JjW3uVGKlrOb39QoOs8ZzWJic5kfHWdHkVlSlY6UmSx1JkjVSdM4ySSh8HTo QOWJS33iNKCrPCgeA0rQotpzpwIdalBvOcuE+rSfnowqKR8a0aqK5qc5XWg8YTLVeubyng3dKlOJ ukeUPLWpYjVqVr1qVnp+1au+DGs9qWrVuuLlIYYs4zYRuRCZupSZKgXsSPUITcEq06KA5StG0bnY kBYTsdxMbGBnWtPKMlCkK01sQ/yK0sG2lKQr9aY5v2lMzYKWkY0d7GO7Wc29Ttallo2t+DRaWI7/ khO2oSXtS6cp2NsStqK2VWxttUlc4mb0or/NZh05q9zmyva5OOStcXebUtzqFrXDdWx1j4vd7WqX tG5cbGu5i9zudha0qYWuenvD1bn205f7ZCtR24rUsr6SlQBdq0FzGt+uApSQStUpW/3737Te96x2 TbCCF8zgBjv4wRCOME7WS+EKW/jCGM6whjfM4Q57+MMgDrERJUziEkNHxChO8RBNzOIWu/jFMI4x UVRM4xpPUsY4zjFibMzjHvv4x0AO8kR0TOQiG/nISOaikJfM5CY7+clQjrKUp9yRJFv5yl6hspa3 rBgse/nLYA6zmEnD5TKb2SxjTrOah3LmNrv5/81wjvNj1kznOtv5znhGipz3zOc++/nPQ86zoAd9 EkAb+tCITvSZCc3oRjv60ZCOtKRjrOhKL3rSmM60pjfN6QZ/4NOdLvKnR/2PUX/gJKQmtUlSbepW r9rVpW41rGNtalTLWiW3domqX31qlMi61r/29a9VvWthg9rWx+ZJsX8ybKIsuyTPjkm0aV1rWhsb 2dUONbOPPWtW9xraoJ62tcfN65QQO9nnTva4xQ3ub7fb3OpGdrvdXe5r43rZ2d4Ju3Oy63z7JNr7 ZgnA0R3uePeb4PTW9koeMmqBtHogDbdHxCf+aYRE3OEfKMjFMZ5xiFdc4h8HecdFTpCQH+ThHv8f ecotHvKNr1zjJi+5qVMec4u4fCMuv7nNZy5znTME5S/3OMl7znGYW1osFOd50os+dIP4POhNX/nF p15zhQA96kx3esurfnOfA/3rPBf51X9N848v/ec1p3rOw85ylUOd4Wx/+toz/vSjj2TpZs97x8+u dbf3negwp/vWR153rYMc8IgP/NuzvniON1zWRU/63vXO9ME7vuonTzvl1Y5xq3Md8wupuMnlHvPH g97uIsG76Lfe+cuj/OqJ7/rqJ+922Gde8ITX/LCH7nXdt/3ws2+66XOP+8ZL/vSJj7zlC598xjtk +I13/cOZj3qPnD34ro9+2f+++OGzveenh77/87FedtDL3u/Khz7n12956We/IecXPvbh/3n0h37+ ap9/+rdf/YjIJN3zhnAHl3ArgW/q9mzeRm4FGG/YNoDwRoDWJm4IyIDvtm4F920J+G4OaIEYGHD1 Jm/DdmoeWIH2NhPBRoIaaHAXWIIKp2/cJoDulm8jaIAxyIAZyG7TtoETCIEAeG8Jl4Mv2GsZGIEI R25DOIAQ6IPwhoIf+BIDl4QL2IFCqIIiSIUKeIUtmBJwR3v853jN13rON3eAJ3lCF32cR369R3vo R31fKH4kx37EJ3/EZ3+3p3jkd4e/x31bGHQb54aVN3rI138G8X9BiG2G2ITyhoU7SIJIWIES/0hv hciCiUhtD1iJSmiJN1iERLiClMiEnTiJMkhwjgiFT/iABKiCoMiJH7iBWbhw9OeH31d6Ifh+dhh4 fQiIekd6tTd70zeLtyiLfpeGdXh5fDh4Skd246dzu9d3v2h+kOd+xgeM4Md3jIeMgvgQrUgTi1gX I5iNU3GNOxeMgfgYbAiO5rga8acZ5XiOjOGN7shg7BiPKvaO9FiP9niP+JiP+riP/Bgd8viPIdaP AulDAFmQHTaQCOkyBrmQDNmQDvmQEBmREjmRFFmRFrkQCZmRLHKRHNmRHvmRIBmSR6SRJNkdInmS N1SSKrmSLNmSLvmSMBmTY4aSNFmTNnmTOP+Zk5QhkzxpGzr5k+bRk0L5MkBZlNoxlEhJZka5lEzZ lDyWlFCJaQRAADsxlSlhlVF5ZQ8BAFzJlZkxlWMBlgUhlgJBlgdhlmVJAGkpElOJlk6ZTjHBlSYh l3KBlUdhlyaBl3h5lVSJEntZFH+ZlU7UEF55EF1ZmPZwmACQmIWpmIspEIoJmZHJmJI5EIhJEG2p lgORmZuZmZrpmWnZlqEpmmOpmWtpD6B5mp75mWq5mp3JmahJmgshlq45mqb5liP2EnSJErtJl135 D78pl78JnACQEsLpm8WJnHNZnHxpl1hplc7ZlycBndGZl9JpndNJldX5D9SJndypnc8Jntj/GZ4v EZ592Z2CmUW7eRK9yZzKSZzwWRLrKZ/JyZzxeZjleZ766ZfS+ZfoWRLbmZ2r+Z3e+Z/kWZ0Iep35 CaD9KZ7pSTCE+ZgFgZiN+ZgVSpmVyZiHiaEYuqGzyZqvCaKqCZpmSZZuWaKtaZq0maKduZYmyqIj 6pZnKaKxWaO4GUUwMZ/0uZw7ep/1yaPtGZ8+qqPN2ZZ8SaAMiqQEqpcNeqTj2aRLCqUG6qBKmqQu QZ5JGpgPykRBGqQ+uqNd6p7HyaM9SqbemaX7aZ5IaqRMyqAKWqVTiqZuKqd0yqb7WaXZaaVR6qRb 2kOKuZzD+aXw6ZiAGpz26aVmqqdraqRu/8qoA7qXA8qfefqdjLqomUmnluqolRqYl7qdnqmofeoc Z3GZFEGqHCGjm4GqNnqjZWaqEeGqG6GqX3mbmEmrrKplsLqVEhqrsNkZqXmrBxmqwnoXwFqsxnqs yJqsZTaszEoXyvqsc9as0jqt1OqP0Hqt2JqtcFKt3Nqt3pob2hqu4jqu5Fqu5nqu6JquQvat7AoV 6vqumJGrBiGv8AqUjlkR9EoQ+WoP+ZAPBtGvACsQ/UoQAyuwAOuv9apoOWqfQkoTRLoSD4sS/Sqx +WASEzuxFlux/4CxG6ux7RpqEWqYFjqyXamhkumhGkqhEuqqBzsQBVsQL8uv/hqzCRuPrv96oSZb sl5ZspSpshnKoQQbsAZ7EDE7sDRbs4kWl39Kn16qnGFKphFbEhg7tR57Egd7sB37sd44ERXqsx26 mD7rtfRasGSLsC1btDNrtkKLtDZLsis7spUZtm/7swhxtWobtDKLt2jLtoa2sOx5qAz7nmMKpoBb pvPJsVmbuFmLuFSbsVqLj4SaqIJbn/jJtIh6uFXLsXaruIq7uY+LkFH7uVp7EfvKt+9auqbLqqK7 uqzbuq77umomAAIAu3mmqzwrFjc7mSK7EbJbELL7uwjxu70rEMIrAMRbvMabuhemtIlaFESKqESB vP8guyZBvShhvdM7u9hLvdhLuzj2vIX/+6dLO77kG6iGS7mTO5xLW6YlIbwnsb2ze73xm70pwb3z 670PFrLzOre327/8i7O5a5lge5k7u6sc6rUDIbwEMbz2wMAJnLwNDMEPHMEKrLzLq5sMa6aDy75P 26PgW7nzucHn6xK/+77z273te8L3S7/1u8L4W1f6O6H/q6+76pgDLMB0i8MyvMOkasMMUcEM7MDH O8HHK8ELbMQW7GEBHLc13MT7q8NLTMM8bMCoO8S9G8RIjMVDnBBCnMRKPMM568Q63LNzC7RjfMZk vMM/66pXbLxaHMFbDMdd/MZeHGK6e68ETMUeisC3m8Nm3LWALMYPXMEUTMfFW8RATMh1//yTXbzI T8YcKPzCM+nIlFzJ4yrJmJzJmrzJnCwTlvzJoPysnTzKpPzCoXzKqKy6pSzJqdzKrvzKsPyPq8zK sSyus2zKtRyut7zLDpvBe+HLvExkDqG7ClHFMnyvH1G6epy7xpzLkeS37AuxwNzLRhG6lpuc7Mmb 2RzM+fuqBizAexzOfozGk1nO5syz5jyviamv7JwQ3+zMdvzOCIzDOLu7CFHAZZzGGZrH6lzD7XzP 8Ixi4ayz+QzFffzE93zDY1zABh3D62yZIvvOAW1ZNQG+UFu+0xzNhLqeYUq+Suue2wyx3NzNEBHF DL3PB63Ga6zQK23G42yYkPnQMe3OE/+tXtDcsBf9o8RZuC3B0WKq0x68we8ZzXMpn8C5zSBd1CMd Y+trnBgNvSoRwuKbwZHb1Orry+tbuUdtuUvtYGrRzBIB1jBd0/PoFNbME2edo12dhWltE0291oJG 1nI913Rd13Z91+UB13q91zGJ18DK16Pr16oM2IRd2IZ92Gkm2Iq92G6G2N3K2JAd2VPm2JRd2a0o 2Uxp2dOK2Uup2Z792aAd2lvE2aRd2qZ92qoh2qGK2qzd2hqm2rAd22rm2jYp27NcCZUQG0mt1EGR 0UPh2x9NF8Ad0jix2xnZELhdCQSR3BaB2xqR3MydEc5dENONrzNNxQwh0Qshz4TJtTP/HdbWfcwW OqHgrN3bPdbkXarXParf7RbmDZcvkdwnId84gds9Yd8lgd/1Td/5zd86Ydxb3dvF7db/PeDEjc1I TdwyMdy8beAM/ttX8eA9hNzRDd0CAd3KbQ8YnuEajuEXbuEd/uELUd0h3uHRbeIkTt0cPhApjt4r u94yHdPo3KHr7L8HPcAvnrLLfNIoW841rrI3TtCN6dI1DtHqzM7v/c8vjuNGvqFMnt4yPd4P/c0K DeRvO+Qp/eM9PNBXfuVHLuMm294bBuIWXt3OXeHKbeYrLuLT3eIqvtxpzuFnvuYI0eJuDuU5LuV6 DNEEfMAxvufr7c/pDatg284sXehG/27oSK7diB7jiQ7mw5zohw7pC43nTQ7jUkzjgr7oj47pj97o Rc7nne7PFCrmGjbnc17iIa7mqm7nGQ7iCkHiqc7mdH4Qrt7dhZ7nYk7q5M3ro67om37pAC3ooF7s R+7rLm7qOr6zJV3kUh7oUO7ozh7lnv7dS/7Pot7pU/7loU7p3c7txi7tlQUT9g3d/1Duud3f557u 697u6r7u5g7v7M4S+t3uG57b9U7v8/7uLoHNCL7VAB64AW7UAi/wB07wCg7wvImfBv/vR23wCV7U GX2oRs20A//wgNrTGG/cIE3VCe/vAZ7UWM3b6IucwfnxFX/wBV++xpnNDe9g+B3z+P/O7uhuEjWv 7vot8/muEvV+8/O97yux8zsf1Ruv1AHv8tpc8Ar+8hBv9Cqf4Erf4BUf9VENwkl/9QmP9AjO9Nos 9UVP8Qrf9SF/8QPv8CNP9lSP8Szh8RKf9Qom8zhP8zNv83MP7+7O3z0P9O5+93K/9y0h9PM+9GPv 9Bef9mqP8BoN9c0b9ikvnFBb9iF/9oYv9Rxf+CnP+GIP9lNv+V4/+JuP9iQP+eGL8qAPpkjf9pcf +ZBP9ldE4QbR5mQu56/u4SjO6ixe6xsO5ydO+yoe+7EP0O2t5+L97N5Oso5+xycr7kGO6Dpb/MlP 5eWt7Mdf3qAe5XsM/NQu7E6O7ZL/rujSnuNTbuPfDv053PwpG/3Jv7+53uM2zRV5jxWCPxUSLvZL Mf9NYf+4gf9xmWCRIeu1DhD2BA4kWNDgQYQJ7VWqpNDhQ4gOAUQ0OJHiRYkYNW4caJHjR5AhRR70 OJJgSZMpVa5k2dIlQYYvZc58CMAmypo3aZ7UudPnT6Abb+JMSTToUaQf/y1l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV7BhxY4lW9bsWbRp1a61mtTtW7hx5c6lW9fuXbwR2e7l29fvX8CBBQ8mXNjwYbIt jbpcDLLxzMd5Q5YkGrmmZMiYNW/mrNDySYGfJxfteNRi5Z2RRV88bQ81xaE6X3cu/w074erMtHW7 tQpAq2+/wMUKFx58aXHEfIsjP851efLAzKFPp16dK0ScQztqdx26p2ubJHtO/B67Inf04E/L9h4+ NHjv292Td4/QfPn24uerl//6O2j6PNKOvvYETC/A2rjLqDT8+DtvPvwgfK+88RwUsKL8HoSwPvIc VK++/hhcL8QPW0OwQNx2U1GkxjpMsDsGa7MPvglBs7FGEV/E8T0a96OMRhhnBNJEGXmc8MIfC3Ix yBx3jM/I7pIkkMclmRTySRiXRGlLGyWM8kIlhwwyuzHDjPFFDpls8cn9zEQTyRtXlFOpqqRjyrfn /sGzqT1705PPP+906jlCAQ30z/88iRO0UEGlAi7RQ59itLk8AbWTUksHNRTTRvtsDtFNHQ310Ug1 HfXTQz0tFdROV2UVqkkDVXXWqUhFlblKaa3UOl4Jw07DKk00z0Oe2DsTSjVLDNbIACtkVtlkb4Oy NWKnTTY2Mqt1sko17+sy2mZBvBLcDOMk91kpB/zWP3GvXRdAc0t8lkoFf7Q33jnz1atOUzn9VFVJ +311YORiRVXWRWFtdOCDL0W41VAj1ZWqggM2eNeG/UXYYYUXftjjUiG9VWKSIZWu4lNNzhRkkVMl OeSSI+515ulQ1tNTmzTGud+cJ815055X/jdhiF2O1VZTVT44ZqKXfhVXpj32mVT/pYeOaleqWRYY aUWnftnVp3mmleBUbf5ZUX+D1tRrmtv2Czv0wlvPxbkNrExucPFWUu/0ZOS7wTI/tNZK+b7VVvC8 281S8WUF35JCuuWlN81xpSy32Lr9FhHyKG80am79Fk8zXW75ozZw9oZt3Fh9W9/X7a44Hkx22Gsv jHZRD8NdOdt7992w3Y37fXjdvQp+reORJ3555ssaqnnoozd+esKeB/4m6bOXynXuu/f+e/DD9157 8ss3/3z00z9MfPbbd/99+ONPKkWf6HczIvvf/yx/+VWy7HP89U+AGrkK0mQWnbAcL3nKix1YbMUx A/pJZrGR3gIDxq+OYVB9GwxL/wAJNxf+IesydMlfCHUkrQ965n5WMiEIR/K/calwgDM0yX1G5yHV KQ5zR7KbuO4FuQ0JK0zOmlwQ9ZO5L9VtSvWSTROzhTp5/QdFOJQiC1cokbi1SXRCPNGXsHQgI+4w if3JTt/A2MMi0VCNHBkRlcR0LxHO6IZptBecjuXF89xxWUmiI4DA1EYMZQtMmnPj4tJoyG2tkEse TKQdj7SdBLVxj3/MyByRZbk6HvJ0a+QkRjZJJD2mUIVwvCS8QknK++3RlKWM0+ri6KRCyrFzheTj CWfJSk0qiCSrzFIvQ3lCR97Sl9JC5SLdWEwMibKTAyxgxsiWqJ856nlH21rUEP9FQTtRk1AUjBg1 P3acaV7wZicDFdoMCLWScVNrtcqdzjiFra99rGvYNNTJwtk0mLXKm9y0IAf9uRQPYpKXxkxmI82F TFS+EqG8LKi1LBctWBKOTB2iJERtWbqDLmiXv4xcKg1XpicOs0iq7COaBnquZXaymS+bGDhdtiri tPRmYoua2jSWsjvhbGzrdOc3YwrTkYlTZBjzaTyD+k2klu1raOup1YwmtKT+lG0LO5s1deq0f2a1 KrABESgnJ7pDmi5xEsUb6bao0C79jW5VRFzfmOVDtRrocIF7ay0LF0kd/qeHgyzWWUdKRJT+EbBy 7evq9FbYIk4xP5tMaWNfAsD/+LXQsTXspGQne1nGbDSymI2LZefkWc6Glo1sjSxpRSsTXQowtadl 7UC0+lrYxla2s6VOa217W9zm1i605W1vfftb4M6snwWM5m+ox5bhBldgym3nWJLLXPVF0LkZ1OBW njsoeJLTd9dNIMiq10AJUhcr3JXu1aCbnKCA9orKXC8jV2JX3RZUvellkVAoy974YmawY+SvL8F4 ORLpckBA5G8X61UgMtIVhTzE6xER/MgeUdFHWhQk41jXubIi8UTq4muBe1QhAuORohxK7YAZV+AB PziKaQ0j5gwcISDld36nRFJFJ0nIkcbxkyysMUfddSzV8MSkuBycl6Yk0Tdq/1LBVmySmJp8Oi3t 7cl+VHJXk6xki0LYv3wlKSzhC0hX6lDGQCFol/3741ei9KPCRLMwvermiGqWXIsp87zgPMR3BXLB Dm3lSaEY0sYlEs8n/fLg/LzjUzK00G1+85jdsl9k9hJbPAa0jlHErYUOWdAYbehDq1hnuhr2wo3+ qiL9fOnARrSY3sLrYQ2K5UJ7us+ZJqMg/XggR8vEuNqs503BZrOkRrWa+7Sqr6nbsqUBm2v4lOnG xAvsYnu3ZVkb9gShCrBmo5OoYzvnta0JtqIxzNjnpU7XchptajdV2Vjt9rqJPVWiSq3XTE12r0fm tVyZl975nCnWvP1SV3nTnf9SXZvQiutUoA4Vpy4l+KmS9m+AkRsw+CPxiMdzYL8+7m6UyyMTXS1q wVZcwXTuM1g1pOJBhqtwgYYsW7N45wB7LsrAuuTFOYfpsd4NcYOu695EDjoNk1avKMdvrunU3eXy dt/C/Qp3/6LdrDhdnBKnOtOTTtvy9qqfUu9LNq2rFq5XXewAfWFD14jxzpRQRZBlzXtNa3S4x13u c6f7bcd+d7znXe99qXvf/f73v8/3vRoRPJnl59nCwy/xgMcIeMPbXHBWFWjYmzrkH9+7rPPO8VE3 7gVxF/bLVwf0e18LG22jUT6vOaR7du9uGGt40xPekxtd/Gj0y/i5EPdR2LP/3jh3ZjHvwgyCvKe8 pap6NsqbM/kzHSesih9O5Efz+Qf3PZ6kX3w+JX/5CdM+8QFeed/nVPIw7f5ypnl96V9zbbtHP/up Fv1txnT8yrfn8duPq/aLf/SkbzrELobVsKm8iPO8bponeXsg46MqdioYetuZpds9ZlsubTInlzoq AfS2zEO4TjE3fbKnAxw2CsSuCGSq39M3Dqy3gTsg/kuLXzGThOK0ivI5dVkQu4q0GuGyLCMmj7oj ZdqxGvSoSGMsTiMyVQqyD/LBPOs0RTs0JRSojroMGyTCHMS9x6KcFyS5WLqwW/o0Q0s9h6IMVrsr GcS5HJMw2rs1KaqzICyl/zWZNSqzD7dSPWhhs7+awVpTsy/ENS2xsFHLQZtzorejwtdZqXYrOOfb PnxiGG3rpn/DlAc0r4WTN55ymkKEPF7zP0OExA/kvmNjt4whJ6+TtqRDtk9UmD1Bp01sKuC7uhXc ixY8Mx58vUV6wS6MJSYTNBxBQhx7q1tEs5mTwx90w/iQtR3MqERDMjY5Qx9juzZjNBGywZQrKfgg JR86xjQTxEGsleLqmemzKWiTP5u6ld7LvvDDLkSMvGUrRwasP1nhPXOUP/G7mm1Ex0N0v3jcKexz puwrP/2zwMhTKnOsp+f7tXfsR3WcPIcbxwakvubjtnD8R3qMyFZ0RWxkrf/aq0iMzEiNbLuN7Mjw mciJ3D+QHMn08UiTPEmUZAmSXEmWbEmXfEmYjEmZJJ/rEsnOSw5oG469sMnqEox89MmZ7C3bGyEX JCHWS432cgyawELZG6GLPMLJeByOfMqUzJf9UUa5oMpXvMbYQ60ZK7qyMzvCk8rT08qqTIrwMrdu tEf9sz5w9MeDhL96ZMtyuj9ttD9wrJi1DKpxpJT8i0i3nEuJPEW7LLifxKa/NL63hEiFJL750xoO tJ7ArL7mC0rYesUee0ZLu7IdWROO68UwC6artCQeq7JfgqRX0zI1XBfRDKQOQySY+yI9s8WLCjWe o6g33LKwOkt9aaZT1Mf/cAs3bgM3VXS3eWtEiok2STxOo7pEVUQ35YzAh5PO5UzEgHOm31zEdCOb orJM5spO7JTMjom/5au/cISnSHQ26hRMgQvP8kTHgyNPbrwnFOypbFtFSvxEdXLP6As+9zs+caO2 ++xO7wwu8IROArTOAEXOqRvO9qy29YTODDQYoJpEB2VQ7rS3cSvFddIuUFzQe4M44CzQ3yJBgyuv SoRLpfI3hKyap5Guhksb46zA75vRFOSp87xR5sPQFOW3F30pDwUa/1RAYjMqEu0tE93AqwpIJY23 hgyZn3zScuROdwy4oIEmbBPIEpzStjTIg5Q2tek9h4y4ndpHLcW/bmxH//MTm3n0RM87R3gMviOd UxWEjgy8O55kRTrd067QDbO0rz9tH7MMVN7MNdvJU+eIUr3rS83jU0d9VEiNVEn9i0KtVEut1EnN VE3dVE7tVE/9VFANVVHlv0stVVP1yFFNVVVdVVZtVVd9VViNVVg9VVqtVVu9VVzNVV3dVV7tVV/9 VWBFVVkdVmItVmM91mINVmVdVhpCVmd91uhhVmmdVmqtVmu9VmzNVm39CWjtVm/tnW0NV3HdrW8t V3M9V3RN1+AaV3ZtV7RUV3iNV3mdV3qtV3u9V3zNV33dV37tV99yV4ANWIEdWIItWIM9WPDxV4Vd WIZtWIdVC4YIi4h1iv+JxbybXKnaQdSMPcT+Qx+NZa6KZYuQXYqQHVmKrYSnmFiTBQuGWNn+U6dQ lMdzvFh2Kkh+E1PhmR0AzM+d7Uma3FOXPQuTLVmUlYqhLdq0CFrwclI5Fb7jSs70JFBE/VjLszak Ox+qBa6WRdp/2Fqm2FqV9dquFVuw5VqS5dqwbdmvLdqyPduxFdu3Vdu4jYq0ldu4NVtIVBlEzMlr Wkx1nNmmgboNNU+hAszK3E/ClMh9ZMvJ7Fu33DfoYz7ro9FFScwoFc/y/MtC2csp3U+QpIitHYiY WIiGGF3SNYiYaFnRbQiBMN3VhYnSZd3TPV3THd3Utd3YfV3cPQjcZd3/2+XIObOj1ZPNNdzNX8yo Noyh1rTCLyzD3VRN2ozezGQTIXzN43XNKUOoYHJGuruKsHXbpqjYox3b8EXao21b8WVblE1ft2Vf 98XbkwVf8lVaocLZzZXZ8XsmDW0nFM2umtVEoinS9uRb6URRnlVEBXQ4qFpADGzgRHzQiYyI3W1d 1Z3d2S1bC7Zg16Vg2NVg381dDqZd2f3dEA5d3v1g3ZVdzNylTPqVOjIxwLoSKHO1LbSyMZzNSSPG bRmWXOrDYVId+brFDiOdDTkiMzviZsxhfKFCDC4IEhbhFO7gEJZiDq5dFLbiKh5hEM5gLi5hLe5i GYLKH3JhhoJKLIph/5wDNec9k0oTqUCTM+6llofyHCGWxtgETWekNTZrY4x0XRL+Y0De4gve4Ax+ 4t3t3SyOYtIFYUIeZEWmYjdBDThaPSSeY2SszVksOb+ZjeKVq1oiqDFxpR+WxVjcRV+8Xk8mtFX6 ODwmrLmzCqI92/QlW7Al3/KF27UtX1lm37tVX1u25bad25RVW16u5V9O0EwMwMXtts7FvvytT3qa vIGUlIdsGDg9N3dcR8J9UpjF5jAtXLOx0H9kP44dUDG90jMdzGruVPqtnXYGO+jKWuR6WK16Z7ex 57SQ57bRZwai59paCbDVl4CGC0KVjIL2SoRNaIVe6N70Z4d+aIiOaP9H/Qknet7NIkqE7h8TYkaj HMqPOOiUfD1GsrGjhMNAHLwlC+NLG0L/obnWc7sWUqKVViwztgumRL2unFaaHS9RhFqf7tl8dg4A ztNvxNigRrp1w1HwQ4xL+byrhdfHrUybxZZvVlN7ZFTBJczFnNzw4+qoZtxpblCpxtz3o1GcPSD6 o0f7hUCIzJ3GZdTpHGrLe+s0pWa59MsKfGvAdMy8tOv362tnDSg7w0qSLsosmw08grPPjDEo60G0 Qk3FBsNkNOywciQ5TqtkfE3MjjPNSl7HFjLNHOIdNDInE+UoxF5cdNfLbsFoFClaihcgtsY7zmTO jt4uNDPbpOwEy8X/ZJrj7UWhhNozHq65NCxGHjTGLFxGwzltnrtjdp3hjaMwHZHpLRKz1EwiHy6p 345tJdwcLWxt7haSPQw5Igo5GizjGNJkOQO1HKLkj2pN7G4TJe5hVoavcSXlkgPvTePK5sbtw6Zs MrRtiyodY4LvxyC11Y5kO+5t9IZj9e7uHAtGO27s/fYPCPdC577v5JY5O7tswkK0Pkpl2Qblxi5w kR7wJNacDze1DrdFCt/CzQxuTjZuNfbCwyLx91bu6V5lEz9lgfVkPvzhHRerYXQ5j4vvmNuhHg+6 J6TxByvwBpNFAesrSEI7835GVm4rGS6xG8ayrwKdk9u5aORhJCry/597kDvTQmZ9LX7OnqmFZ7Jo cwCWaHKTc+h58352IOuwczqHHT5nnj/XST3f8z7fCoY+dIUudEV3VURvdIP9ujk3i6bOWdm6XEh/ 6tshzjo9i0D3WE3foKbEypbW7dxY4lJ38FEnddYGXos2PPvmb9Lo8iq0bsVYrZIOIJBekZtmCVur Hxe69ftSdYxWyqycQlgPdiJD6WMPy1Zvdh3kJN27a/W0arxu5nxETL9NYGpXPwqka0Xt22qXTL6G T+5LzMVVXGz3UnuLZqvx3C8NQH7K3A/VGfpk3LHmR3JH63vX3MPEz9+Ld7xc6rTu6oFEPgU1UBEN m21KxQpNP4wx0f+FdyquzlBqrlxJZOZlc3hGDM5/OcGGl9CNH5qMx8Cl83eDsxiPj04rFcWk7uk+ 8XhdgdwM+vfwzGu8E+B3Qs4yRbidL6eick6Kh1DsHPqcj1BS5Hkj3c4LFWeF59DnLFyWus7/i1DK THofzcl0e3kHpkT75dlpa9rLxOhwWe21skNoWbQX5kLcZDQuYe4Iz+8iY2M0rEZbwuThPiYmlPCR c+OzN/V5EagpukKzP/DEoeFJg+23v5YwZC+vapDDb+3GerwBREAYtVqvX2Dg0/oR3HpwG2Ckf6pv q6brDP2He7eQn3bN9zWmzXelAfoKBer7JODLj0zMX/1px0So//T/rMJM097FN95DBj9NOsbwEudx 4UZxvoeo07ZkTEb8Gg7lzmRv5a/yU4Nj4O9w3KZGHNd+PC5GlqN+4a/jv4/7wV4m3dt2eTp3KEU/ K8XSmDW//O12Le188VR/hnNmrjlnhjxru07nBAUIAAL/AfhHcGBBggYFFkxocCHDhQ8dOjzYEOJA hRMfctzIMWFEih8RapRoEWREjCUnMkSZ0qLGlhgrjsxYUiTLiydN8sxpc+XLgzt54uxo9CjSpEqX Mm3q9CnUqFKnUq3KlOZHq02Lau36FKtXo2BXhi1rVuxZqWPHVmWb9i3cs/bm0q1r9y7evHr38u3r 9y/gvwD0Dg5s/7jwXMSGFzPOq7hx38d1JUOubJkx5cuAM9vjjFkz6NCiR5Mubfp0Z4Z7PV9WzBp1 49et7baEbRuy7NOPa4vOffs38LpxhxMvbvw48uTKlzNv7vw59OjSp1Ovbv069uzat3Pv7v07+PDi x5Mvb/Sw7uClfatPLBAv+/a34zsW/F7wYs70/e5fDd+/fAEKaBhUFdHUkoFBIegRWlcZmFVNP5GF 1IITWliWWxB2BFJxGULn4VYhRgXihkmROOJUbIHFYYPmudjVgRqa9CBZXDGo1E809gTUVSWeiKFT K+741o/LFUmhiAWqZSKRKTLZ4lFHvujdZpN1Rhdlkg2m31218f9mJWJhXpkYYWOW2WVqYm5535X3 scnbmoV96Z6bqmHp5Zt20uYmlnTSGaeacmrZJ5lphsnmZHbGeWeejSL6J6SJHvreopEauqWVY87J qJxpcqqlnoqqBqenhQraaaip9jcgq40F6eONsSrkFlYs7qjTTbkimeGKODXkK0oSPWiTrTcW6xGx PGqIK7MzQpgRtCUShZaNPoqk40bYKltrthtem9Wwzyq767exhusstb4Km2256w45ZXk6UiTThC5J yO246No670vVepsSjbjGxKDABQ8ZcJQ9GSyju/giPC2sAncb4rkH57stlDWCu/HEzmoLa8cah/zu whzGGLLE8G7/hx+hZtLmcqEvt0yoazK3GXNmncbMn8uoZiommQhiSjOaRBdds9BdvmlmqH/yiTOa mE5aZ5Zegomg0z3brCl8T88MKKVg/nwpqKOKPTPZfuJstdGn7gy2263KLbdrm/Y5aNE7m5ppy0Nj /d+lgQ29d81M350311vrLDPSLA/eNuCGvyz121tr3bjiWvOdeH27nb354z6fGfTnMHumM+Z7m345 gHO7Lh/Qh49t9NdHb97z4zeXzjnaoZNOu5qlL147zKr/rnfsyRvPeex8Jz+45+6xLntqTEe/PNTX 63582NJvv7r0qT8qvvHdqw799Ny/vn57w2s6J/zwOwYo4uab/0rq7HsqOvbfkr/vtfX01zxJ/UxP BPwaoijVNKjlrW5+e5SffGcoRv2veF+q2tQ0d8Hume1/GPye28o2qUR5CmxtA+CpRsi+Ff5mVYJj oWVcCEPLzbCGNrwhDnMIGSUNR0re8SF4gKiyIRKxiORBj2lkOEMl1pCJOnwiFKMoxSlSsYpWvCIW s6jFLXKxi178IhjDKMYxkrGMZjwjGtNoRvY4UW9qfCMc4yjH9cApaYFLD+JuF7nIzLGPfvwjIFtX ud7hkWWC5EsbA6nIRTLSdUlKmKzE0i8JzSRdwAoJTCSJkEmSJCg+qaSwgjUrYgEsk/4yIipTqcpV HodWDFtKs/+exBJk8ShZDaoYRMwlrRmJ8ley8qW7LsTKYRKzmMW0jwFNZ7fJGXKQvkPa/tI3SEIC j3oW1GDxGqnNbXLzhWij4d+SmTXQHQ+EgEua9rSHzewVsIOE6yY84/lHJ0VSl/Y01i4Hhksh1Suf J8OnrmbFsWDq05gGPShCUckzclKzb+hzXjq5J0HG7a5wDWWeNaE30UTKs6Me1WGQ6GUukdYkJpSE yT8HhtKLzVKkMvkYvVxKsJPwS6AzTShOc6rTnVZHiMwRok95KtShErUqYuSobVaF1I8ytalO3Yw4 bajUp1K1qla9KlazqtUVFrWrXv0qWIe61bGStaxoDCta06r/1rWyta1ufStc4yrXudK1rna9K17z qte98rWvfv1rXM0q2MEStrCGPSxiE6vYxTK2saQBLGQjK9lVOraylr1sZSar2c1ydjyY/SxoQ3uX zpK2tKY9LWpTq9rVsra1rvWqaGMr28q+tra2va1BZqvb3fK2t779LXCDK9zhrg+3xj0ucpOr3OUy t7nOfe4QiSvd6S4Suta9Lnazq93tJoe63v1uHLkr3vGSt7zmPS9606te7oC3ve59L3zjK18oRnWF S13PGe873/A6iKTRUVFcTklP46yFZO9aJYiOxcP1DnOhT9TvUvWbn3Pm15uf2S8ZH/nJUaYrl6AE pn/XBbCQ/5QyWtDil71MamJK/uqSKM7JhpfFy2sp6KWkPGlM+yWUHbd4wz0OKMRUbLIbs2uTOB5x tBiMU3yFkkK9rCVXuGXLYgHTw0kWF0GrfCB1wTRX2uIyLS0kSpveyp9WHvIvd0zmf7aLw8FkEZVx pDAlKzQyWEtdAzOqOTdKcHi5Ux5FyzlRZ+7ZmoVWH96yVDmLIi9/wftmn7NJOT9L83x6zB+Gw6jh WsqyzQWr0EBVisuA2mtfnL6nPiuk6hOHOJY6FvOchZZPjE0rYC8Vl5AuUuqSTXkmLI4pnVnp4Npx iZ169k/hKH29R5dPmhH93jTL+Z8Boo7ChrZcsvvmbGwqmv9y16RmtUfHu0x/cdOjlnGW8yVlLI+6 KMwy9T7NTOY1N+tjpxY1JOPNsId5eaAkuSkkgWwwdam0zFZ+ZbCH2asrt8jFt/Jkum9SSnSrWOJC nnOEHK4Sl8RY3q9WM4yRBfGhyLTWLu0kxRseIV+H3OIhXunBEy7zsATVoECdOc6X7FYg1jznPg9P z4vJ858TvehGPzrSk25ecjO96cVlCj/SEvWHTN08Vae6U65uEK0rvevU8Qs/8BL2uYw9MGW3x9mj mHa0/2XtY1+70+N+xaZw/R9Vr7tSro738HB97x3pu9cDXx2wo50fbzc84hFf+LOnnfFsJztdwl72 yT++8m7/VzzZDR/5xGde82z3fOLdvvjNe/7xoYe85Et/+tHfhfOLpzzo4S732aNG9ZC/ve1vH/m6 SH73qPf954Ev+98TX/e7z73xM3983hff9IVfPvQrn3zHP7/6w6c99kNDfcpLX/bUD37vfx9+8Etf 7OX/fvS7/3r1b1/9wU//+Ftvl/br/vrZv39l6O984M+f+eK3PPn9H9ytHuZtH+ehn+jBX/O9Hfv5 H+b5H/8xYP3hHwUCBt1xxNTd3dZh4FHoHQdGHQhiXQhq4AgahQd+IAqKIAdi3d+l4AbaHQyyYAiq IAvW4AvaYAbWoN8JHg+eoAbG4A3+4A0GYQsOIRD6INXN/yAM3p0SGh4QHiHg0eALNmEOeiATHuEU FmEWEmHQ8SCdnaDdZWDogSEYEuEKPiEW6qATiiETziDiLeHfraEJrmDiyaAcwqEduqETBuEbhuEe piEMdqEXapdo2B/6vY79rU8iViAjDsgYPiIkRqIkTiIlVqIlXiImZqImbuIlNqInjlZZ7OB21GF3 kOIgnmJXfKIqruJcoKIrzhwrxqIsziIt1qIt3mJwvaIu0hku9qIv/iIw0tYuDmN6BaMxghcxJqMy LiMzQtYxPuN0NaM0TiM1ViNaQSM2Cpc1biM3dqM3qlI2hqM4jiM5lqM5nmNffKM6riM7tmN2oCM8 OpY7zv8jPdajPd4jPiZXPO6jYuWjP+YVPwakQA4kQZbGPx4kQiakQi4kQzakQypdQUakVj0kRc5V AFwkRgaAUWRkR2DkUXjkUnAkR4jkP2QkSD7ESRoESJpkSiIFS17kSL7kR7JkR8IkSnrkS66kTIZk SrbkTqqkTQKlRt7kUJZkUFZkTgFGTgaAXWRkU14kXmCkX0hlXVClPSxlVUJlVjLlVeYkX2DlXIAl XYhlV3JlWXLlUqKlV+6FSY6lVoblWpblVs4lXJqlRD6VU7rlU75lXUYlX7LlW1plXp6lW9qlXB4m YeqFYAYmYzamWQ4mVULmX9JlYuZFW/ZlXT7mYmqmVlr/JWLepVN5pl8O5mcW5l84pWQa5mbuJWa2 5miapmuuJmVKJWmKJmWW5l42JmzuZmTmpWfaJmh2FHDmJl8C53C+pmyyZmn2pl0eJ2Im52EaZ2ey pHK+5m6OJnO6Jmwy53Q252QGpzw5Z2YW53eK51b+Znl2p3JupmGuJ3lyplq2Z3Re5nlS53M6J23G p3ZiZm92ZWx+J3j2UVO05Eba5EkSqFEW5YCSZILO5FD6pIHmJE+aZE3+JILq5IUupVDSpFLgJExi qIMSpVGOKIQqKFKCFYLG5IMGZYaaKFOUaIg2qIpuaIpWKIcmKIPKaIXSqIvW6E92aITKaIsSpYfm aI2e/ygxTSWAFiZ9Sqd8AqZqpqd+0mV+LilvZmdtSul4/uVxVumTUullOimTQqV9XmeAhqeVpuV+ 4uZXcqmWLqd6sml1zueUrimWoueXZmebwmedzmZblumanmk3del72qmVWudt3meU1ql44mlrOqqf 9imhcuaejqmZimZqHqqg+pFTMGiEKiiIFqiLTqioFiVJnmqoCiWQmmqq6iiqsiissuqoqqqIJkVP HiiuHiWOEimSWqSEemqR0qSGrqqD3iiP5qqKziqOUiitbiiRMmuzimRaNuuuuuRRAuuPOqu2zmiv JlRgvOR+eumfxqVlAii43sW5aidp1iekMumYuql3kscpWGLqcOLpoq5rZrrrnG4qv/arv/4rwAas wA4swRaswR4swiZsYnUrwxqTwj4sxEbsZzUsxVasxV4sxmasxm4sx3bsV0ksyE6Rx44syZasyZ7s doWsyq4sy2YVyr6sdLSszMIQzNaszd4szuaszu4sz/YsL84s0Aat0AKSzxat0R4t0iYteAwt0wqI 0j4t1Eat1E5tWTSt1aoH1Wat1mbt1Xat134tFW2t2I4t0oKt2Z4t2rIP2a4t27at22ps2sbtDr2t 0QYEADs= ------=_NextPart_000_000A_01C71D1E.01DC2EE0-- From sip-bounces@ietf.org Mon Dec 11 06:22:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjEA-0008PQ-6U; Mon, 11 Dec 2006 06:21:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjE8-0008Oe-Ug for sip@ietf.org; Mon, 11 Dec 2006 06:21:44 -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 1GtjE7-0000cA-Fv for sip@ietf.org; Mon, 11 Dec 2006 06:21:44 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBBBKogI017434; Mon, 11 Dec 2006 13:21:11 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 13:21:28 +0200 Received: from [172.21.58.172] ([172.21.58.172]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Dec 2006 13:21:27 +0200 Message-ID: <457D3F37.2040004@nokia.com> Date: Mon, 11 Dec 2006 13:21:27 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 11:21:27.0915 (UTC) FILETIME=[801BF3B0:01C71D16] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIP IETF 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 to all. Dean Willis wrote: > Previously we had recorded consensus to use STUN for keepalive with both > TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated by the > current editor of the Outbound draft, that some people feel may have > resulted in a change of the consensus on this draft's technical direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over > TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > > > Proposal 2: Make outbound registrations over UDP flows optional for UAs. > > Yes (Accept the proposal) or No (Reject the proposal). > > > 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. > Further, include text that explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > Yes (Accept the proposal and add the text) or No (Reject the proposal > and keep the text as-is). > > > -- > Dean Willis (wearing his chair sombrero) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Mon Dec 11 08:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtlc1-0002N9-71; Mon, 11 Dec 2006 08:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtlbz-0002N2-Rn for sip@ietf.org; Mon, 11 Dec 2006 08:54:31 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtlbv-0005Fa-Cs for sip@ietf.org; Mon, 11 Dec 2006 08:54:31 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 459421944D8 for ; Mon, 11 Dec 2006 14:54:16 +0100 (CET) Received: from [192.168.1.75] ([192.168.1.75]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 14:54:00 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04bdf0a62d1afd681f5fc2293e6a9efe@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 14:53:54 +0100 To: Dean Willis X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 11 Dec 2006 13:54:00.0631 (UTC) FILETIME=[CF8D9470:01C71D2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: SIP IETF 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 Dec 9, 2006, at 3:12 AM, Dean Willis wrote: > Previously we had recorded consensus to use STUN for keepalive with > both TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated by > the current editor of the Outbound draft, that some people feel may > have resulted in a change of the consensus on this draft's technical > direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the > record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > yes > > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. > > Yes (Accept the proposal) or No (Reject the proposal). > yes > > 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. Further, include text that explain that for historical > purposes a lot of deployments still only use UDP, but that we > expect/hope those deployments to eventually migrate to TCP when doing > outbound. > > Yes (Accept the proposal and add the text) or No (Reject the proposal > and keep the text as-is). > yes Hisham > > -- > Dean Willis (wearing his chair sombrero) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 11 08:56:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtldM-0002nX-K8; Mon, 11 Dec 2006 08:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtldL-0002nS-JH for sip@ietf.org; Mon, 11 Dec 2006 08:55:55 -0500 Received: from web52905.mail.yahoo.com ([206.190.49.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtldK-0005S3-Bd for sip@ietf.org; Mon, 11 Dec 2006 08:55:55 -0500 Received: (qmail 59219 invoked by uid 60001); 11 Dec 2006 13:55:44 -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=4q+tGuUKgbPdXBYIZHrMmh2rfZd+TpWfSuJkRPdDIl4cgEudfDGB+M08dSY514SsSq8ckYswpFq+wO21vcAryL6yEthwj+STOtMdbNPQc4jhTBQ15/v7BSHrMh3/wLHzRIQme8XVcZroLoPrCJeyNiOgdQl/SZMdJ/zdp2DpDFc=; X-YMail-OSG: KrTdOOYVM1kDQ5e8QLHLG0dOMTXNRZ2thdAozE6ZzEugupnpHFMZ6otInkBUkT9Ag6FADqCjr_shSwRGIcxofEhLgFzy29nexo5d1WOXY4jHcYhQNhYRAf60NfG_c5fsbgd9HM64wX1FAnD51GHqlxbalciCq9xpLfgPIClm62V_FrU05ot.GAwxEWw- Received: from [217.33.106.234] by web52905.mail.yahoo.com via HTTP; Mon, 11 Dec 2006 05:55:43 PST Date: Mon, 11 Dec 2006 05:55:43 -0800 (PST) From: Raj To: SIP forum MIME-Version: 1.0 Message-ID: <997377.57947.qm@web52905.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] About one or more user agents? 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="===============0415919628==" Errors-To: sip-bounces@ietf.org --===============0415919628== Content-Type: multipart/alternative; boundary="0-454612841-1165845343=:57947" Content-Transfer-Encoding: 8bit --0-454612841-1165845343=:57947 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello To all, Recently I read an article and I came across the following line, "Software or hardware appliance containing one or more SIP user agents". My doubt is considering a phone equipment, can it contain two SIP user agents in it? if yes, can any one tell me about the operation of both the user agents? with regards Raj, --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. --0-454612841-1165845343=:57947 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello To all,
 
                Recently I read an article and I came across the following line,
 
"Software or hardware appliance containing one or more SIP user agents".
 
             My doubt is considering a phone equipment, can it contain two SIP user agents in it? if yes, can any one tell me about the operation of both the user agents?
 
with regards
Raj,

Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. --0-454612841-1165845343=:57947-- --===============0415919628== 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 --===============0415919628==-- From sip-bounces@ietf.org Mon Dec 11 09:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmUM-0001dq-Mz; Mon, 11 Dec 2006 09:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmUL-0001dN-BG for sip@ietf.org; Mon, 11 Dec 2006 09:50:41 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtmUF-0007gm-IG for sip@ietf.org; Mon, 11 Dec 2006 09:50:41 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C268657A; Mon, 11 Dec 2006 15:50: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); Mon, 11 Dec 2006 15:50: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: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 15:50:32 +0100 Message-ID: <7374777208BDC7449D5620EF94232567E49C82@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F031A318A@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN5kNWEMip9HlT1qJJ6E0x4FCCgBvMEqAAA/GdDA= From: "Christer Holmberg \(JO/LMF\)" To: , , X-OriginalArrivalTime: 11 Dec 2006 14:50:34.0630 (UTC) FILETIME=[B688BA60:01C71D33] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 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 Erkki, When you talk about OPTIONS, extra roundtrips etc, you forget that the edge proxy can insert the keep-alive parameter e.g. in the Path header (or Service-Route, depending on what happens to Jonathan's route construct draft) of the REGISTER to indicate its support of STUN. Regards, Christer=20 > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: 11. joulukuuta 2006 10:07 > To: dean.willis@softarmor.com; sip@ietf.org > Subject: RE: [Sip] Poll: Proposal relating to keepalive,=20 > TCP,and UDP usage in draft-ietf-sip-outbound >=20 >=20 > Hi, >=20 > Strong yes to all those three proposals. Please see the=20 > details of my reasons below, I believe they are important for=20 > the your consideration. >=20 >=20 > In IETF#65 meeting I was one of those who voted for STUN as=20 > keepalive mechanism over TCP. I did that due to consistency > reason: as STUN was selected as a keepalive mechanism instead=20 > of SIP PING for UDP, it appeared to me that using STUN over=20 > TCP as well would be the most straightforward way to go.=20 > However I have changed my opinion due to the following pieces=20 > of normative text which have been added to Outbound draft=20 > AFTER the Dallas hum: >=20 > 1. Usage of UDP flows now appear as a bad idea in general, > thus my original "consistency reason" has lost its value. > UA could just set up TCP flows with CRLF keepalives and > NEVER use STUN for keepalives related to Outbound: >=20 > Use of outbound with UDP flows typically prevents messages larger > than 1300 bytes from being delivered using TCP as described in > Section 18.1.1 RFC 3261. Use of outbound in conjunction with UDP > flows in environments where requests are expected to be larger than > this size is therefore NOT RECOMMENDED. >=20 > 2. Mechanisms to for the UA to validate if the proxy supports=20 > STUN or not appear more complex than hoped. Using OPTIONS for > the check also consumes an extra round-trip. No such validation > is needed for CRLF keepalives, which are totally RFC3261=20 > compatible: >=20 > Because sending and receiving binary STUN data on the same=20 > ports used > for SIP is a significant and non-backwards compatible change to RFC > 3261, this section requires a number of checks before sending STUN > messages to a SIP node. If a SIP node sends STUN requests (for > example due to misconfiguration) despite these warnings, the node > could be blacklisted for UDP traffic, or cause its TCP server to > loose framing over its connection. For each target node (as > determined by IP address, address family, and port number), the > sender needs to determine if that destination is validated=20 > to support > STUN, that it does not support STUN, or that it needs to be > validated. >=20 > A SIP node MUST NOT send STUN requests over a flow unless it has an > explicit indication that the target next hop SIP server claims to > support STUN. For example, automatic or manual configuration of an > outbound-proxy-set which contains the keepalive=3Dstun parameter is > considered sufficient explicit indication. Note that UACs MUST NOT > use an ambiguous configuration option such as "Work=20 > through NATs?" or > "Do Keepalives?" to imply next hop STUN support. A SIP=20 > node MAY also > probe the next hop using a SIP OPTIONS request to check for support > of the 'sip-stun' option tag in a Supported header field. >=20 > 3. If the UA does not support TCP keepalive and the proxy appears not > to support STUN, then no keepalive over TCP is possible !=20 > If UA could > simply send CRLF keepalives this would NOT be a problem: >=20 > Futhermore, even with explicit indication of next hop STUN=20 > support, a > SIP node needs to validate support for STUN the first time it sends > traffic to a specific unvalidated target destination. If=20 > an explicit > probe indicates support for the 'sip-stun' option-tag, that > destination is validated for STUN support. If an explicit=20 > probe does > not indicate support for the 'sip-stun' option-tag, the target > destination does not support STUN request, and the UAC=20 > MUST NOT send > further STUN requests to this destination. A SIP node MAY send one > STUN request and its retransmissions to an unvalidated destination. > If a STUN request ever succeeds to a destination, that=20 > destination is > thereafter validated for STUN support. If this initial=20 > STUN request > does not result in a STUN response, the SIP node MUST NOT send > additional STUN requests over this flow, unless and until=20 > a next-hop > probe later validates the destination. In addition, the SIP node > SHOULD remember unvalidated destination nodes that have been used > within one hour and SHOULD NOT send additional STUN messages to any > of these destinations. Note that until STUN support has been > verified, an initial STUN failure over UDP is not considered a flow > failure. For UDP flows, an unvalidated flow can still be=20 > reused for > SIP traffic, however for unvalidated TCP or TLS over TCP flows, the > connection over which STUN requests were sent MUST be closed. >=20 > 4. Interaction of SIP, STUN and SigComp over TCP clearly wastes > bandwidth, exactly on cases where SigComp would otherwise be > useful to save bandwidth. Instead of sending a couple of bytes > (CRLF keepalive) each keepalive would consist of more than 30 bytes > (13 bytes of SigComp shim header plus 20 bytes of STUN header): >=20 > For TCP-based flows, SigComp requires that all messages=20 > are processed > by the SigComp compressor to facilitate framing. For these > transports, STUN messages are sent encapsulated in the=20 > SigComp "well- > known shim header" as described in Section 11 of [I-D.ietf-rohc- > sigcomp-impl-guide]. >=20 >=20 > For an UA that would support Outbound only over TCP using=20 > CRLF keepalives, all that complicated processing together=20 > with waste of round-trips and bandwidth would be easily avoided. >=20 >=20 > >Previously we had recorded consensus to use STUN for keepalive with=20 > >both TCP and UDP. >=20 > In my understanding that concensus was reached by hums in > IETF#65 meeting in Dallas. My observation from the meeting=20 > was that the discussion was focusing to a selection between=20 > STUN and SIP PING as a global keepalive mechanism, which=20 > raised a hectic email rally before the meeting. CRLF was=20 > touched but the debate was really about the choice between=20 > STUN and PING. > There were two votes in the meeting, the first one for UDP=20 > keepalive mechanism and the second for TCP. My feeling was=20 > that the meeting participants focused their thoughts very=20 > much on the STUN vs. PING issue so that STUN vs. CRLF was not=20 > considered too carefully before the votes. And as=20 > demonstrated above, the decision made in Dallas brought a=20 > number of complications to Outbound in a way which could not=20 > be anticipated yet in that meeting. >=20 > Regards, >=20 > Erkki=20 >=20 > >-----Original Message----- > >From: ext Dean Willis [mailto:dean.willis@softarmor.com] > >Sent: 09.December.2006 04:12 > >To: SIP IETF > >Subject: [Sip] Poll: Proposal relating to keepalive, TCP,and=20 > UDP usage=20 > >in draft-ietf-sip-outbound > > > >Previously we had recorded consensus to use STUN for keepalive with=20 > >both TCP and UDP. This was not a perfect consensus (there were some=20 > >dissenters). There has been ongoing discussion notably instigated by=20 > >the current editor of the Outbound draft, that some people feel may=20 > >have resulted in a change of the consensus on this draft's technical=20 > >direction. > > > >So I'd like to ask people who care and think they understand the=20 > >differences to answer the following questions, on-list and on-the=20 > >record. > > > > > >Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS =20 > >over TCP flow (retain STUN for UDP flows). > > > >Yes (accept the proposal and use CRLF for TCP) or No (reject the =20 > >proposal and keep STUN for TCP) > > > > > >Proposal 2: Make outbound registrations over UDP flows=20 > >optional for UAs. > > > >Yes (Accept the proposal) or No (Reject the proposal). > > > > > >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. Further, include text that explain that for historical =20 > >purposes a lot of deployments still only use UDP, but that=20 > we expect/=20 > >hope those deployments to eventually migrate to TCP when doing=20 > >outbound. > > > >Yes (Accept the proposal and add the text) or No (Reject the=20 > proposal =20 > >and keep the text as-is). > > > > > >-- > >Dean Willis (wearing his chair sombrero) > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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 >=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 Dec 11 09:57:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmZt-0005T5-LL; Mon, 11 Dec 2006 09:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmZs-0005Rh-8i for sip@ietf.org; Mon, 11 Dec 2006 09:56:24 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtmZk-0000Tb-W2 for sip@ietf.org; Mon, 11 Dec 2006 09:56:23 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 11 Dec 2006 06:56:16 -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 kBBEuGhB021949; Mon, 11 Dec 2006 06:56:16 -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 kBBEu7Od002848; Mon, 11 Dec 2006 06:56:14 -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, 11 Dec 2006 09:56:14 -0500 Received: from [10.86.240.238] ([10.86.240.238]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 09:56:13 -0500 Message-ID: <457D718C.4060507@cisco.com> Date: Mon, 11 Dec 2006 09:56:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Raj Subject: Re: [Sip] About one or more user agents? References: <997377.57947.qm@web52905.mail.yahoo.com> In-Reply-To: <997377.57947.qm@web52905.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 14:56:13.0238 (UTC) FILETIME=[805C3560:01C71D34] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1638; t=1165848976; x=1166712976; 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]=20About=20one=20or=20more=20user=20agents? |Sender:=20; bh=QMfaYmkNws1/lEphwYXmT6BIrJWGVjxjUUlRM0YDV3E=; b=mZKA0/tzU/CHIpbi3/MeFGIwMK1LhL3J6FHfBAubj9HGz8eLz0IaCeRxqsOEvWwPLZppIqqG /QRsl4rF6fwz6a3DnvXwlyLl98uzplu07ShuZXop5X+BPhBuGag0n1PL; 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: SIP forum 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 somewhat obscure semantic issue. If a box containing a SIP implementation registers twice, in order to accept calls addressed to two different AORs, is it one UA or two UAs? You can make an argument either way, but this is one way to get two user agents in a piece of equipment. Some might consider it one UA if it is a single application supporting multiple addresses and similar function. A clearer case is a PC running a phone application and an entirely independent sip Instant Messaging application. Paul Raj wrote: > Hello To all, > > Recently I read an article and I came across the > following line, > > "*Software or hardware appliance containing one or more SIP user agents".* > > My doubt is considering a phone equipment, can it contain > two SIP user agents in it? if yes, can any one tell me about the > operation of both the user agents? > > with regards > Raj, > > ------------------------------------------------------------------------ > Cheap Talk? Check out > > Yahoo! Messenger's low PC-to-Phone call rates. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 11 10:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtmht-0002YP-Qy; Mon, 11 Dec 2006 10:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtmhs-0002XS-Ko for sip@ietf.org; Mon, 11 Dec 2006 10:04:40 -0500 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtmhr-0001nD-8O for sip@ietf.org; Mon, 11 Dec 2006 10:04:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] About one or more user agents? Date: Mon, 11 Dec 2006 15:04:33 -0000 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C24037@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] About one or more user agents? thread-index: AccdLE0Y+9LxOQ12T2OBlxaprvRB7wACSFNA From: "Attila Sipos" To: "Raj" , "SIP forum" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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="===============0323936030==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0323936030== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71D35.AAD5E92A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71D35.AAD5E92A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Imagine a box with multiple independent POTS ports. =20 So to work with SIP, each POTS port would have a SIP UA. =20 Does this help? =20 Regards, Attila =20 =20 -----Original Message----- From: Raj [mailto:ponrajit@yahoo.com] Sent: 11 December 2006 13:56 To: SIP forum Subject: [Sip] About one or more user agents? Hello To all, =20 Recently I read an article and I came across the = following line,=20 =20 "Software or hardware appliance containing one or more SIP user agents". =20 My doubt is considering a phone equipment, can it contain = two SIP user agents in it? if yes, can any one tell me about the = operation of both the user agents? =20 with regards Raj, _____ =20 Cheap Talk? Check = out Yahoo! Messenger's low = PC-to-Phone call rates. ------_=_NextPart_001_01C71D35.AAD5E92A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Imagine a box with multiple independent POTS=20 ports.
 
So to=20 work with SIP, each POTS port would have a SIP UA.
 
Does=20 this help?
 
Regards,

Attila
 
 
-----Original Message-----
From: Raj=20 [mailto:ponrajit@yahoo.com]
Sent: 11 December 2006=20 13:56
To: SIP forum
Subject: [Sip] About one or = more user=20 agents?

Hello To all,
 
=
           &n= bsp;   =20 Recently I read an article and I came across the following line, =
 
"Software or hardware appliance containing one or more = SIP user=20 agents".
 
=
           &n= bsp;=20 My doubt is considering a phone equipment, can it contain two SIP user = agents=20 in it? if yes, can any one tell me about the operation of both the = user=20 agents?
 
with regards
Raj,

Cheap Talk? Check=20 out Yahoo! Messenger's low PC-to-Phone call=20 rates.
------_=_NextPart_001_01C71D35.AAD5E92A-- --===============0323936030== 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 --===============0323936030==-- From sip-bounces@ietf.org Mon Dec 11 11:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtoEL-0004v8-5k; Mon, 11 Dec 2006 11:42:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtoEJ-0004v3-Li for sip@ietf.org; Mon, 11 Dec 2006 11:42:15 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtoEI-0001tA-9I for sip@ietf.org; Mon, 11 Dec 2006 11:42:15 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kBBGfR209249; Mon, 11 Dec 2006 08:41:27 -0800 In-Reply-To: <457D16EA.7010704@it.su.se> References: <4575D55B.8040200@it.su.se> <00b801c718b6$84185490$0601a8c0@BEMBUSTER> <3B1E01D3-F436-48D5-B625-864C7F9F54BA@cisco.com> <8F8614DA-EA7F-407B-A5F0-F6578E7CB5E2@estacado.net> <457D16EA.7010704@it.su.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: issue with oubound and the used transport protocol Date: Mon, 11 Dec 2006 08:41:33 -0800 To: Fredrik Thulin X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, 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 Fredrik, In the 3GPP environment I believe the specs would allow a IPsec protected TCP connection from the P-CSCF to the UA using a IPsec SA already established by a UDP flow. If a NAT is present, I am told the IPsec traffic would be sent in UDP. I am not convinced this TCP in UDP is an improvement and within the spirit of "sending over a congestion controlled transport", but I don't want to go down that rathole. I don't think there is any desire by anyone to do switchover with outbound. I'm not even convinced that anyone really uses it without outbound. It appears that the folks who want to do TCP or TLS will only use that transport (no benefit to using UDP if you already have a TCP or TLS connection up), and I suspect that outside the 3GPP case the UDP folks are planning to only use UDP and use the "get out of jail free" statement in RFC 3261 that says if you tried to switched over and got an ICMP error, you go back to sending using UDP. thanks, -rohan On Dec 11, 2006, at 0:29, Fredrik Thulin wrote: > Rohan Mahy wrote: >> Edge Proxies and Registrars would still need to support outbound with >> UDP. > > Hi > > Before answering Dean's poll, I would like to know more about this. > > Have you figured out a (reasonable) way for the edge > proxy/authoritative proxy (or the combination thereof) to switch from > UDP to TCP for large messages destined for a UAC that uses Outbound? > > I'm thinking of the problems in doing that that we discussed briefly > in these two messages : > > http://www1.ietf.org/mail-archive/web/sip/current/msg17418.html > http://www1.ietf.org/mail-archive/web/sip/current/msg17420.html > > Thanks > > /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 11 12:40:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp7b-0000iI-Dw; Mon, 11 Dec 2006 12:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp7Z-0000hl-8F for sip@ietf.org; Mon, 11 Dec 2006 12:39:21 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtp7X-0004JR-UL for sip@ietf.org; Mon, 11 Dec 2006 12:39:21 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBBHdH629160; Mon, 11 Dec 2006 12:39:17 -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] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 11:39:16 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E5B323C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Thread-Index: AccbN5my2BZm+dawQ3i3hQn4EQR/FQCExnQg From: "Francois Audet" To: "Dean Willis" , "SIP IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Yes to all. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, December 08, 2006 18:12 > To: SIP IETF > Subject: [Sip] Poll: Proposal relating to keepalive, TCP, and=20 > UDP usage in draft-ietf-sip-outbound >=20 > Previously we had recorded consensus to use STUN for=20 > keepalive with both TCP and UDP. This was not a perfect=20 > consensus (there were some dissenters). There has been=20 > ongoing discussion notably instigated by the current editor=20 > of the Outbound draft, that some people feel may have=20 > resulted in a change of the consensus on this draft's=20 > technical direction. >=20 > So I'd like to ask people who care and think they understand=20 > the differences to answer the following questions, on-list=20 > and on-the record. >=20 >=20 > Proposal 1: Make CRLF the only keepalive mechanism for TCP=20 > and TLS over TCP flow (retain STUN for UDP flows). >=20 > Yes (accept the proposal and use CRLF for TCP) or No (reject=20 > the proposal and keep STUN for TCP) >=20 >=20 > Proposal 2: Make outbound registrations over UDP flows=20 > optional for UAs. >=20 > Yes (Accept the proposal) or No (Reject the proposal). >=20 >=20 > Proposal 3: Include (in Outbound) the statement that its is=20 > RECOMMENDED that the outbound-proxy-set is configured to=20 > result in registrations over TCP or TLS whenever the UA can't=20 > accept incoming TCP flows. Further, include text that explain=20 > that for historical purposes a lot of deployments still only=20 > use UDP, but that we expect/ hope those deployments to=20 > eventually migrate to TCP when doing outbound. >=20 > Yes (Accept the proposal and add the text) or No (Reject the=20 > proposal and keep the text as-is). >=20 >=20 > -- > Dean Willis (wearing his chair sombrero) >=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 Dec 11 13:32:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpwP-0002b7-97; Mon, 11 Dec 2006 13:31:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtpwN-0002ax-Bn for sip@ietf.org; Mon, 11 Dec 2006 13:31:51 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtpwL-0005zG-Tq for sip@ietf.org; Mon, 11 Dec 2006 13:31:51 -0500 Received: from [172.16.4.17] ([172.16.4.17]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kBBIVeM0071210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Dec 2006 12:31:41 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <168CD408-74F0-4504-B886-B973A71D6E4D@estacado.net> From: Byron Campen Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Mon, 11 Dec 2006 12:31:40 -0600 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: SIP IETF 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="===============1104495377==" Errors-To: sip-bounces@ietf.org --===============1104495377== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-723624592; protocol="application/pkcs7-signature" --Apple-Mail-17-723624592 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Yes on all three. Best regards, Byron Campen > Previously we had recorded consensus to use STUN for keepalive with > both TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated > by the current editor of the Outbound draft, that some people feel > may have resulted in a change of the consensus on this draft's > technical direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the > record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > > > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. > > Yes (Accept the proposal) or No (Reject the proposal). > > > 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. Further, include text that explain that for historical > purposes a lot of deployments still only use UDP, but that we > expect/hope those deployments to eventually migrate to TCP when > doing outbound. > > Yes (Accept the proposal and add the text) or No (Reject the > proposal and keep the text as-is). > > > -- > Dean Willis (wearing his chair sombrero) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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-17-723624592 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjEx MTgzMTQwWjAjBgkqhkiG9w0BCQQxFgQUkA0dkAAY+GQSfGkmuLA8fSZGB6MwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAIDwN9MS nE5ZEJ91Xy90xB7lYwfIx0PifsJnrBJiQVUbHAbhr6Eh/4I1BKe7k3rTeiDboGwXQbXE+11G/Obx ThYYev3q4xhT0xX3j0I7xwsRIS+s83UQ79JqewgNL3wuGexlfJlu617pG73451eDm7XqbyqBF7Nx 0v/yQOYbe33/cCDj/P2+GbH9IK/mk4dz4ukY0OZkcCzAZU9dIlx9ltOGMJBGk2cj02gdPGO8CXYM 4KIfQ9Vv5pCIsN6Jqm6WE8zgscpIWJBFgn+NuXcr7eNDOmh3rWf+SZ9+ULNmBKlfOuxWGONdW297 RecbqcGacAO4zd3tZR2DMfbi3BGoB/QAAAAAAAA= --Apple-Mail-17-723624592-- --===============1104495377== 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 --===============1104495377==-- From sip-bounces@ietf.org Mon Dec 11 16:31:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsjg-0007xt-4V; Mon, 11 Dec 2006 16:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtsje-0007xQ-EF for sip@ietf.org; Mon, 11 Dec 2006 16:30:54 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtsjd-0004FO-5k for sip@ietf.org; Mon, 11 Dec 2006 16:30:54 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 9A8E73A02143; Mon, 11 Dec 2006 13:30:50 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 9E35D3A0210C; Mon, 11 Dec 2006 13:30:45 -0800 (PST) Message-ID: <457DCE04.5010304@acm.org> Date: Mon, 11 Dec 2006 13:30:44 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIP IETF 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 Willis wrote: > Previously we had recorded consensus to use STUN for keepalive with both > TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated by the > current editor of the Outbound draft, that some people feel may have > resulted in a change of the consensus on this draft's technical direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over > TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) Yes > > > Proposal 2: Make outbound registrations over UDP flows optional for UAs. > > Yes (Accept the proposal) or No (Reject the proposal). No > > > 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. > Further, include text that explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. > > Yes (Accept the proposal and add the text) or No (Reject the proposal > and keep the text as-is). No -- 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 Tue Dec 12 03:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu39m-0008Or-N5; Tue, 12 Dec 2006 03:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu39k-0008Oh-KD for sip@ietf.org; Tue, 12 Dec 2006 03:38:32 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu39h-0002s4-AB for sip@ietf.org; Tue, 12 Dec 2006 03:38:32 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id E83DD745EA; Tue, 12 Dec 2006 09:38:03 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13963-01-51; Tue, 12 Dec 2006 09:38:03 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 09432745E9; Tue, 12 Dec 2006 09:38:00 +0100 (CET) Message-ID: <457E6A4A.6000007@it.su.se> Date: Tue, 12 Dec 2006 09:37:30 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.648 tagged_above=-99 required=7 tests=[AWL=0.017, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP IETF 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 Willis wrote: ... > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS over > TCP flow (retain STUN for UDP flows). Yes > Proposal 2: Make outbound registrations over UDP flows optional for UAs. Yes, and I also want it optional for edge proxies/registrars. > 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. > Further, include text that explain that for historical purposes a lot of > deployments still only use UDP, but that we expect/hope those > deployments to eventually migrate to TCP when doing outbound. Yes /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 12 05:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu4ji-0003MW-2y; Tue, 12 Dec 2006 05:19:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu4jg-0003MO-Nh for sip@ietf.org; Tue, 12 Dec 2006 05:19:44 -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 1Gu4je-0002tC-8u for sip@ietf.org; Tue, 12 Dec 2006 05:19:44 -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 kBCAJ7YS006831; Tue, 12 Dec 2006 12:19:09 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:19:16 +0200 Received: from 4FIL15472 ([172.21.39.123]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Dec 2006 12:19:17 +0200 From: "Aki Niemi" To: "'ext Marc Petit-Huguenin'" , "'Francois Audet'" Subject: RE: [Sip] I-D: Preventing Fragmentation for ClientInitiated Connections in the Session Initiation Protocol (SIP) Date: Tue, 12 Dec 2006 12:19:17 +0200 Message-ID: <000601c71dd6$fb2e7080$2a9db70a@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45779DA4.4060802@acm.org> Thread-Index: AccZu9Bx7k4NW+SJRkOCPtuCSXmdVQDZzgyA X-OriginalArrivalTime: 12 Dec 2006 10:19:17.0317 (UTC) FILETIME=[FAE99F50:01C71DD6] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061212121910-1A3C9BB0-48AF68A7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 >Performance is important at least for service providers, >because they have to buy the hardware to run the servers, pay >the licenses per CPU, pay the datacenters cost, pay the >sysadmins to run the servers and pay the managers to manage >the sysadmins. > >So yes, performance is important, but perhaps not for the >hardware vendors, the software vendors and the sysadmins. This is all relative. Your draft seems to add enormous amounts of complexity -- to both UAs and outbound proxies -- to get around what you claim to be a performance bottleneck. First of all, I disagree with the assumption that running TCP only is that much more of a burden. And secondly, I believe complexity is the biggest enemy here, much more so than the performance concerns. 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 Tue Dec 12 06:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu6AO-00076m-D4; Tue, 12 Dec 2006 06:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu6AN-00076Z-1d for sip@ietf.org; Tue, 12 Dec 2006 06:51:23 -0500 Received: from web52904.mail.yahoo.com ([206.190.49.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gu6AJ-0005WE-Kg for sip@ietf.org; Tue, 12 Dec 2006 06:51:23 -0500 Received: (qmail 43144 invoked by uid 60001); 12 Dec 2006 11:51:19 -0000 Message-ID: <20061212115119.43142.qmail@web52904.mail.yahoo.com> 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=rGNuMbSz4KN2odxc5NYwwuEeRzzNtUq5D3qmvJWewyKB8LBYEq0HVh4oTyoDumESiEDtFRfmJIfD3wsEMJfg566MNz9wmM5wa7nI2q5dtGOv+eWKAQWhXo6HBEN3E7msWdDaZPbEQz67Cxt9C+6ttF74l7hSunlkJyjDyY+SzJI=; X-YMail-OSG: UeKGD.gVM1lUh9sAHxP5jyfALCL92BoOu2KXlC6zA0qDZ0zxcsaNtEIvXS2J4QQpOZyJXcCpS5gRSjBaBs5Z7YWWY4I2xwsX35xEPP7GSDq1B4S1qS5d0I_863nW9MUiL92y3te1OubDZOtE5hTSvmCT_mSMBMPxXPKV8IMEDBcZjtdWrVfO_dn4arZ1 Received: from [217.33.106.234] by web52904.mail.yahoo.com via HTTP; Tue, 12 Dec 2006 03:51:19 PST Date: Tue, 12 Dec 2006 03:51:19 -0800 (PST) From: Raj To: SIP forum MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Message size - regarding 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="===============2041210169==" Errors-To: sip-bounces@ietf.org --===============2041210169== Content-Type: multipart/alternative; boundary="0-487542033-1165924279=:41552" Content-Transfer-Encoding: 8bit --0-487542033-1165924279=:41552 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello To all, We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages. My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted. with regards Raj. --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. --0-487542033-1165924279=:41552 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello To all,
 
                We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages.
 
                My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted.
 
with regards
Raj.

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. --0-487542033-1165924279=:41552-- --===============2041210169== 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 --===============2041210169==-- From sip-bounces@ietf.org Tue Dec 12 08:33:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7ju-0006Ne-9v; Tue, 12 Dec 2006 08:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7jt-0006NZ-3v for sip@ietf.org; Tue, 12 Dec 2006 08:32:09 -0500 Received: from axesmail.axestechnologies.com ([202.144.91.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu7je-0001oz-HQ for sip@ietf.org; Tue, 12 Dec 2006 08:32:09 -0500 Received: from axesind ([192.168.5.3]) by axesmail.axestechnologies.com (8.12.10+Sun/8.12.10) with ESMTP id kBCDVCJ6018023; Tue, 12 Dec 2006 19:01:29 +0530 (IST) Received: from SINBNGBH001.TechMahindra.com (unknown [192.168.5.35])by axesind (Postfix) with ESMTPid D30F9CA330; Tue, 12 Dec 2006 17:13:27 +0530 (IST) Received: from SINBNGEX001.TechMahindra.com ([192.168.5.31]) by SINBNGBH001.TechMahindra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 17:32:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Message size - regarding Date: Tue, 12 Dec 2006 17:32:03 +0530 Message-ID: <5C5A863D4858FC41818EF1C777DB6CFA017DF5DD@SINBNGEX001.TechMahindra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Message size - regarding Thread-Index: Accd5I0Ocfr9tJOqTfGCSkJatm1DBwAADRKQ From: "Adarsh Guler" To: "Raj" , "SIP forum" X-OriginalArrivalTime: 12 Dec 2006 12:02:02.0594 (UTC) FILETIME=[55B43C20:01C71DE5] X-imss-version: 2.045 X-imss-result: Passed X-imss-approveListMatch: *@techmahindra.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 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="===============0652456843==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0652456843== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71DE5.55673D5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71DE5.55673D5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj, =20 If the SIP packet is too large, message must be represented in "short" format. =20 Ex: Call-ID: 44fer23ei4291dekfer34231232 i: 44fer23ei4291dekfer34231232 =20 From: Thomas Edison;tag=3D532 F: Thomas Edison;tag=3D532 =20 =20 Thanks & Regards Adarsh. =20 =20 =20 ________________________________ From: Raj [mailto:ponrajit@yahoo.com]=20 Sent: Tuesday, December 12, 2006 5:21 PM To: SIP forum Subject: [Sip] Message size - regarding =20 Hello To all, =20 We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages. =20 My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted. =20 with regards Raj. =20 ________________________________ Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. ------_=_NextPart_001_01C71DE5.55673D5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Raj,

 

If the SIP packet is too large, = message must be represented in “short” = format.

 

Ex:

Call-ID: 44fer23ei4291dekfer34231232

i: =  44fer23ei4291dekfer34231232

 

From: Thomas = Edison<sips:edison@electric.com>;tag=3D532=

F: Thomas Edison<sips:edison@electric.com>;tag=3D532=

 

 

Thanks & Regards

Adarsh.

 

 

 

From: Raj [mailto:ponrajit@yahoo.com]
Sent: Tuesday, December = 12, 2006 5:21 PM
To: SIP forum
Subject: [Sip] Message = size - regarding

 

Hello To all,

 

           = ;     We know that SIP uses TCP or UDP as the transport layer protocol. There is = some size restrictions on UDP packets and TCP packets. It is been stated that = one packet carries exactly one SIP request or SIP response = messages.

 

           = ;     My doubts is if the size of the SIP messages is more than the size of = the UDP or TCP packets, then what happens, will the packet will be fragemented = or SIP message will be discarded from being = transmitted.

 

with regards

Raj.

 

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get = things done faster.

------_=_NextPart_001_01C71DE5.55673D5F-- --===============0652456843== 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 --===============0652456843==-- From sip-bounces@ietf.org Tue Dec 12 08:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7sf-0001Cv-Rb; Tue, 12 Dec 2006 08:41:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu7se-0001Co-Cx for sip@ietf.org; Tue, 12 Dec 2006 08:41:12 -0500 Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu7sc-0004zi-6E for sip@ietf.org; Tue, 12 Dec 2006 08:41:12 -0500 Received: (qmail 28540 invoked by uid 510); 12 Dec 2006 07:55:23 -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.424433 secs); 12 Dec 2006 13:55:23 -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.424433 secs Process 28465) Received: from unknown (HELO annasagaramv) (annasagaram.vamsi@aftek.com@59.95.41.72) by mail.aftek.com with SMTP; 12 Dec 2006 07:55:18 -0600 Message-ID: <012d01c71df4$cbfba1c0$0c0110b0@annasagaramv> From: "vamsi" To: References: <5C5A863D4858FC41818EF1C777DB6CFA017DF5DD@SINBNGEX001.TechMahindra.com> Subject: Re: [Sip] Message size - regarding Date: Tue, 12 Dec 2006 19:22:37 +0530 MIME-Version: 1.0 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: 1.9 (+) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e 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="===============1898981328==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1898981328== Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01C71E22.E1FEEC10" This is a multi-part message in MIME format. ------=_NextPart_000_012A_01C71E22.E1FEEC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adarsh, =20 To represent in 'short', is which part of Implementation? SIP = or UDP? =20 thanks & regards,=20 vamsi. ----- Original Message -----=20 From: Adarsh Guler=20 To: Raj ; SIP forum=20 Sent: Tuesday, December 12, 2006 5:32 PM Subject: RE: [Sip] Message size - regarding Hi Raj, =20 If the SIP packet is too large, message must be represented in "short" = format. =20 Ex: Call-ID: 44fer23ei4291dekfer34231232 i: 44fer23ei4291dekfer34231232 =20 From: Thomas Edison;tag=3D532 F: Thomas Edison;tag=3D532 =20 =20 Thanks & Regards Adarsh. =20 =20 =20 -------------------------------------------------------------------------= ----- From: Raj [mailto:ponrajit@yahoo.com]=20 Sent: Tuesday, December 12, 2006 5:21 PM To: SIP forum Subject: [Sip] Message size - regarding =20 Hello To all, =20 We know that SIP uses TCP or UDP as the transport = layer protocol. There is some size restrictions on UDP packets and TCP = packets. It is been stated that one packet carries exactly one SIP = request or SIP response messages. =20 My doubts is if the size of the SIP messages is more = than the size of the UDP or TCP packets, then what happens, will the = packet will be fragemented or SIP message will be discarded from being = transmitted. =20 with regards Raj. =20 -------------------------------------------------------------------------= ----- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email = and get things done faster. -------------------------------------------------------------------------= ----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_012A_01C71E22.E1FEEC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Adarsh,
 
         To=20 represent in 'short', is which part of Implementation?  SIP or = UDP? =20
thanks & regards,
vamsi.
----- Original Message -----
From:=20 Adarsh Guler
To: Raj ; SIP forum
Sent: Tuesday, December 12, = 2006 5:32=20 PM
Subject: RE: [Sip] Message size = -=20 regarding

Hi=20 Raj,

 

If the SIP = packet is=20 too large, message must be represented in =93short=94=20 format.

 

Ex:

Call-ID: = 44fer23ei4291dekfer34231232

i:=20  44fer23ei4291dekfer34231232

 

From: = Thomas=20 = Edison<sips:edison@electric.com>;tag=3D532=

F: = Thomas=20 = Edison<sips:edison@electric.com>;tag=3D532=

 

 

Thanks = &=20 Regards

Adarsh.

 

 

 

From: Raj=20 [mailto:ponrajit@yahoo.com]
Sent: Tuesday, December 12, = 2006 5:21=20 PM
To: SIP = forum
Subject: [Sip] Message size -=20 regarding

 

Hello To = all,

 

           &= nbsp;    We=20 know that SIP uses TCP or UDP as the transport layer protocol. There = is some=20 size restrictions on UDP packets and TCP packets. It is been stated = that one=20 packet carries exactly one SIP request or SIP response=20 messages.

 

           &= nbsp;   =20 My doubts is if the size of the SIP messages is more than the size of = the UDP=20 or TCP packets, then what happens, will the packet will be fragemented = or SIP=20 message will be discarded from being=20 transmitted.

 

with = regards

Raj.

 =20

Check out the=20 all-new Yahoo! Mail beta - Fire up a more powerful email and get = things=20 done faster.

_______________________________________________
Sip mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list is = for NEW=20 development of the core SIP Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------=_NextPart_000_012A_01C71E22.E1FEEC10-- --===============1898981328== 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 --===============1898981328==-- From sip-bounces@ietf.org Tue Dec 12 09:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8FS-0002Tm-Mi; Tue, 12 Dec 2006 09:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8FR-0002Tf-FO for sip@ietf.org; Tue, 12 Dec 2006 09:04:45 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gu8FP-0002zy-UV for sip@ietf.org; Tue, 12 Dec 2006 09:04:45 -0500 X-VirusChecked: Checked X-Env-Sender: vineet.gupta@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1165931874!7953733!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 9178 invoked from network); 12 Dec 2006 13:57:55 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 12 Dec 2006 13:57:55 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id kBCDvsUQ015929 for ; Tue, 12 Dec 2006 06:57:54 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kBCDvqpN028177 for ; Tue, 12 Dec 2006 07:57:53 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Message size - regarding Date: Tue, 12 Dec 2006 21:57:50 +0800 Message-ID: In-Reply-To: <012d01c71df4$cbfba1c0$0c0110b0@annasagaramv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Message size - regarding thread-index: Accd9LEcfqw43HNPRIOyiC8WclEojwAAFPGA From: "Gupta Vineet-A18467" To: "vamsi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d 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="===============0463435990==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0463435990== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71DF5.83BA697A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71DF5.83BA697A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vamsi, =20 Short representation is a part of SIP itself.=20 =20 Any SIP implementation compliant with RFC3261 should be able to = recognize header in short or normal form. Even a single SIP request can = have some header in short form and some in normal, although no = implemenation will do that as they would designed to send messages = either in short or the long form.=20 =20 However, with this the compression would not be much, espeically if the = message contains few headers and a large body. In that case sigcomp can = be used for compessing the messages. =20 Regards, Vineet. -----Original Message----- From: vamsi [mailto:annasagaram.vamsi@aftek.com] Sent: Tuesday, December 12, 2006 7:23 PM To: sip@ietf.org Subject: Re: [Sip] Message size - regarding Hi Adarsh, =20 To represent in 'short', is which part of Implementation? SIP = or UDP? =20 thanks & regards,=20 vamsi. ----- Original Message -----=20 From: Adarsh Guler =20 To: Raj ; SIP forum =20 Sent: Tuesday, December 12, 2006 5:32 PM Subject: RE: [Sip] Message size - regarding Hi Raj, =20 If the SIP packet is too large, message must be represented in "short" = format. =20 Ex: Call-ID: 44fer23ei4291dekfer34231232 i: 44fer23ei4291dekfer34231232 =20 From: Thomas Edison;tag=3D532 F: Thomas Edison;tag=3D532 =20 =20 Thanks & Regards Adarsh. =20 =20 =20 _____ =20 From: Raj [mailto:ponrajit@yahoo.com]=20 Sent: Tuesday, December 12, 2006 5:21 PM To: SIP forum Subject: [Sip] Message size - regarding =20 Hello To all, =20 We know that SIP uses TCP or UDP as the transport layer = protocol. There is some size restrictions on UDP packets and TCP = packets. It is been stated that one packet carries exactly one SIP = request or SIP response messages. =20 My doubts is if the size of the SIP messages is more = than the size of the UDP or TCP packets, then what happens, will the = packet will be fragemented or SIP message will be discarded from being = transmitted. =20 with regards Raj. =20 _____ =20 Check out the = all-new Yahoo! Mail beta - Fire up a more powerful email and = get things done faster. _____ =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 ------_=_NextPart_001_01C71DF5.83BA697A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Vamsi,
 
Short=20 representation is a part of SIP itself.
 
Any=20 SIP implementation compliant with RFC3261 should be able to recognize = header in=20 short or normal form. Even a single SIP request can have some header in = short=20 form and some in normal, although no implemenation will do that as they = would=20 designed to send messages either in short or the long form. =
 
However, with this the compression would not be much, = espeically if the=20 message contains few headers and a large body. In that case sigcomp can = be used=20 for compessing the messages.
 
Regards,
Vineet.
-----Original Message-----
From: vamsi=20 [mailto:annasagaram.vamsi@aftek.com]
Sent: Tuesday, December = 12,=20 2006 7:23 PM
To: sip@ietf.org
Subject: Re: [Sip] = Message=20 size - regarding

Hi Adarsh,
 
         To=20 represent in 'short', is which part of Implementation?  SIP or = UDP? =20
thanks & regards,
vamsi.
----- Original Message -----
From:=20 Adarsh Guler
To: Raj ; SIP forum
Sent: Tuesday, December 12, = 2006 5:32=20 PM
Subject: RE: [Sip] Message = size -=20 regarding

Hi=20 Raj,

 

If the = SIP packet=20 is too large, message must be represented in "short"=20 format.

 

Ex:

Call-ID:=20 44fer23ei4291dekfer34231232

i:=20  44fer23ei4291dekfer34231232

 

From: = Thomas=20 = Edison<sips:edison@electric.com>;tag=3D532=

F: = Thomas=20 = Edison<sips:edison@electric.com>;tag=3D532=

 

 

Thanks = &=20 Regards

Adarsh.

 

 

 

From: Raj=20 [mailto:ponrajit@yahoo.com]
Sent: Tuesday, December 12, = 2006 5:21=20 PM
To: SIP=20 forum
Subject: = [Sip]=20 Message size - regarding

 

Hello To = all,

 

           &= nbsp;    We=20 know that SIP uses TCP or UDP as the transport layer protocol. There = is some=20 size restrictions on UDP packets and TCP packets. It is been stated = that one=20 packet carries exactly one SIP request or SIP response=20 messages.

 

           &= nbsp;   =20 My doubts is if the size of the SIP messages is more than the size = of the=20 UDP or TCP packets, then what happens, will the packet will be = fragemented=20 or SIP message will be discarded from being=20 transmitted.

 

with = regards

Raj.

 =20

Check out the=20 all-new Yahoo! Mail beta - Fire up a more powerful email and get = things=20 done faster.

_______________________________________________
Sip = mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list = is for=20 NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use = sipping@ietf.org for new developments on the application of=20 sip
------_=_NextPart_001_01C71DF5.83BA697A-- --===============0463435990== 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 --===============0463435990==-- From sip-bounces@ietf.org Tue Dec 12 09:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8fs-0004jn-Vn; Tue, 12 Dec 2006 09:32:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8fq-0004jh-T0 for sip@ietf.org; Tue, 12 Dec 2006 09:32:02 -0500 Received: from hu-out-0506.google.com ([72.14.214.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8fp-0000Ff-Ct for sip@ietf.org; Tue, 12 Dec 2006 09:32:02 -0500 Received: by hu-out-0506.google.com with SMTP id 38so1129288huc for ; Tue, 12 Dec 2006 06:32:00 -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:references; b=r9Tec50JMWLrPOELkDkGCLkjHHuP6pxsGuz0rLGmsA46/9U0o+qKmvLrsvTN18FlWMIDxSVECZsleeC+0x0IyyCkCHPS+DvMdYdm8aXhZ0OwyoNpSorwDMUc9V5MtVN4r9YAxXRsMqIQ4BIj8EZJIckWQ7LALtt5KoT6KPffC2w= Received: by 10.78.157.8 with SMTP id f8mr2271608hue.1165933920169; Tue, 12 Dec 2006 06:32:00 -0800 (PST) Received: by 10.78.206.11 with HTTP; Tue, 12 Dec 2006 06:32:00 -0800 (PST) Message-ID: <66cd252f0612120632j737c23d6y14cd6e73d6a4c8c4@mail.gmail.com> Date: Tue, 12 Dec 2006 15:32:00 +0100 From: "Hisham Khartabil" To: Raj Subject: Re: [Sip] Message size - regarding In-Reply-To: <20061212115119.43142.qmail@web52904.mail.yahoo.com> MIME-Version: 1.0 References: <20061212115119.43142.qmail@web52904.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: SIP forum 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="===============1056362195==" Errors-To: sip-bounces@ietf.org --===============1056362195== Content-Type: multipart/alternative; boundary="----=_Part_112670_7344640.1165933920019" ------=_Part_112670_7344640.1165933920019 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/12/06, Raj wrote: > > Hello To all, > > We know that SIP uses TCP or UDP as the transport layer > protocol. There is some size restrictions on UDP packets and TCP packets. It > is been stated that one packet carries exactly one SIP request or SIP > response messages. > This is only true for UDP. For TCP, you can have the sip messages fragmented. Hisham My doubts is if the size of the SIP messages is more than > the size of the UDP or TCP packets, then what happens, will the packet will > be fragemented or SIP message will be discarded from being transmitted. > > with regards > Raj. > > ------------------------------ > Check out the all-new Yahoo! Mail beta- Fire up a more powerful email and get things done faster. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_112670_7344640.1165933920019 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 12/12/06, Raj <ponrajit@yahoo.com> wrote:
Hello To all,
 
                We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages.

This is only true for  UDP. For TCP, you can have the sip messages fragmented.

Hisham
 

                My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted.
 
with regards
Raj.

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_112670_7344640.1165933920019-- --===============1056362195== 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 --===============1056362195==-- From sip-bounces@ietf.org Tue Dec 12 09:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu93i-0008WH-Q7; Tue, 12 Dec 2006 09:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu93h-0008Pz-8D for sip@ietf.org; Tue, 12 Dec 2006 09:56:41 -0500 Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu93f-0006dz-2L for sip@ietf.org; Tue, 12 Dec 2006 09:56:41 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <20061212145633015007100ue>; Tue, 12 Dec 2006 14:56:38 +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 kBCEuX1G032157 for ; Tue, 12 Dec 2006 09:56:33 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBCEuXui032153; Tue, 12 Dec 2006 09:56:33 -0500 Date: Tue, 12 Dec 2006 09:56:33 -0500 Message-Id: <200612121456.kBCEuXui032153@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20061212115119.43142.qmail@web52904.mail.yahoo.com> (ponrajit@yahoo.com) Subject: Re: [Sip] Message size - regarding References: <20061212115119.43142.qmail@web52904.mail.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 It is been stated that one packet carries exactly one SIP request or SIP response messages. That is correct for UDP, but not for TCP. 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 searchThe@gikas.org Tue Dec 12 11:56:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuAvv-0007h2-7e for sip-archive@lists.ietf.org; Tue, 12 Dec 2006 11:56:47 -0500 Received: from host-84-220-225-116.cust-adsl.tiscali.it ([84.220.225.116] helo=[84.221.56.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuAvs-0004gR-0P for sip-archive@lists.ietf.org; Tue, 12 Dec 2006 11:56:47 -0500 Received: from DHZTNLO (unknown [111.142.3.83]) by gikas.org with ESMTP id 9F37031363AE for ; Tue, 12 Dec 2006 18:01:06 +0100 (GMT) Message-ID: <000801c71e0f$11a66a10$00000000@GuidoPc> From: "ti piaciuto" To: sip-archive@lists.ietf.org Subject: obsolete Date: Tue, 12 Dec 2006 18:00:47 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C71E17.736AD210" 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: 4.2 (++++) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 ------=_NextPart_000_0004_01C71E17.736AD210 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C71E17.736AD210" ------=_NextPart_001_0005_01C71E17.736AD210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Must enable forgot your. Sec set aggiungi etichetta! Share servers act as hubs for clients allow! Forgot your new document, actions level. Curl pro, pipeline masters day davide! Windows macintosh linux other. = What plone printsized images bitmap flash, setup team security! Kiminori bnptv films red arrows display over captain! Network wikipedia = free you, can. Hot girls, sex accident white amp nerdy ps vs. Mediavamp = koreanonly edonkeyon september firm behind inc agreed, pay. Articles unsourced statements discussion edit page toolssign. Miei lavori nebbia rovigo per, blog mis ojos? Nuovo muti tutti di sportivi nhl, guarda! February raided seized = federal. Tutte le categorie pi visti oggi. Segments before completes speeds up large throughout ease searching. Truyen, vietnam vietnamese film were no monks, full, length. Will take = measures prevent previous! Sapere agli altri utenti quanto ti piaciuto = assicurati che. Twothirds quantity seeds providing ed hybrid user count recently. My, = gun the birth best penalty ever. ------=_NextPart_001_0005_01C71E17.736AD210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Must enable forgot your. Sec set = aggiungi etichetta!
Share servers act as hubs for clients = allow!
Forgot your new document, actions = level.
Curl pro, pipeline masters day davide! = Windows=20 macintosh linux other. What plone printsized images bitmap flash, setup = team security!
Kiminori bnptv films red arrows display = over=20 captain! Network wikipedia free you, can. Hot girls, sex accident white = amp=20 nerdy ps vs. Mediavamp koreanonly edonkeyon september firm behind inc = agreed, pay.
Articles unsourced statements = discussion edit page toolssign.
Miei lavori nebbia rovigo per, blog mis = ojos?
Nuovo muti tutti di sportivi nhl, = guarda! February=20 raided seized federal. Tutte le categorie pi visti oggi.
Segments before completes speeds up = large=20 throughout ease searching.
Truyen, vietnam vietnamese film were no = monks,=20 full, length. Will take measures prevent previous! Sapere agli altri = utenti=20 quanto ti piaciuto assicurati che.
Twothirds quantity seeds providing ed = hybrid user=20 count recently. My, gun the birth best penalty = ever.
------=_NextPart_001_0005_01C71E17.736AD210-- ------=_NextPart_000_0004_01C71E17.736AD210 Content-Type: image/gif; name="UNIX variants.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c71e0f$11a66a10$00000000@GuidoPc> R0lGODlhlAGEAYfqAAAAAH8FAQBxB4qLCAQIgYYAfgB0iLzLw7veuKXP7T8nAFsUAHYdAKcXALUT ANQqAAA0CSFBA0I9AFVFAIpIDpoyBcozB+06AA1TCC5rDENiAGJqCHhdA6BhALhtBONrBAB5BxSE AE5/CG2DAHaLAJJzAMSGC9p3AAeTABWkBzGlBFSpAI6tAKiWDb+iDOKoBgGxBSu5ADHCDGG3AIqz DJXAB8K8Cu66AADjAB3tBErgDWfuAHTWCprmBsnRBN3tBAAANRgASjUAS2IFNYUBRJcASLUGMeEI TQAVTSEoPTchTWAuOoIfMpgaScgTSecrOgA6OBhBTDY3NGNHQn5KQpVAPrhMMdg2TgVcPSFeRzNa PlZqRnFVC5VcMr1nNttmPwqIPyiMTTWDRGN9TnKJP5xxS7KBSOJ6NACiMyatQU6fSmOpPoqsRK6h TsmqQtyWQwDHPiXOTDLJNmTMOXLNQam/SsvKNOnINgDYPyfZRUzqQmTYRIXcPpnWR7bbOdTcMgsA iSEAjEoFg1oAfIkOeqoAebEBiuQAjAMkcSolfzYje1sZh4YpfpgleMAdeN0kdQxOjhQ7ijQ7elxG iYk/faQ6ir01d+M9jgBeiiZTdzNUfmpng4tggqRlc79bgt9ZeAB1jRN/ikl6eFx9dnR9fq16gsKL dOZzdAuUgyOXiEmYjmSSfnugdJGfibangtObhQDGdhvBjDq/g1O7jH7Gh5q4fL7Ff9TKdQrleB/U dzfWe13ncYPRfKXZiM7he9/jcQAAvCoBvzEAylMCwIcIt5QOv7IAwt4AsgsVyi0buEcmwFsjwnES yKcgvLsSy+YZzgxCuixFzjg6tF05w3o2tqBMub0yueJAsgRUwRxayTNVtm1aso1uvpxYzcJUwNtm vwSGwBOCu059wlJ6y3eOsqhxwbx2vNR3wwCctBOhyTGeuFqYznWTtaKbs8etteyfygm0uhjKxErD xl+5uX7Bu5G8u/3/4a2YpoJ8jvQAAAD2APD7BgAA8fwK9wD//////yH5BAAOnVUALAAAAACUAYQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Kjxn8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bNjnq3Mmzp8+fQIMKHUpUIM6jSJMqXcq0qdOnUKN6LEq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNMSlcq2rdu3cOPKnUtSrd27ePPqXUi3r9+/gAMLlrq3sOHDiBMrXsy4MeLBkCNLnkwZ sOPLmDNr3sy5s2e0lUOLHk26tOnTqFOrTv25tevXsGPLnr14te3buHPr3s27t+/fwIMLH068uPHj yJMrX0684ofnBZ9/sCe9unTq0KNnP2h9Ou3v4KnG/5Qekjz5kedBpi//3ON65vDjP3W+XeD169zr 29e/33v/8AAGyNN47anX3nsfIahggQZ+IN+DECJFn3//4WeQhQNh+J92FAro4YcREdideSMeyGCC J7qX4j8IRujii069R6KD6K24II0NwqjjjihNyCF2HWbIn4ZAXsgfiEgmaZCI7DnYIos2RokjilPy aOWVMMloYpVUitTiek9iKeaYJGnp5IoqcvnkeWGS6aZyPhJ0X4nTlQikdXLiqeSefBb05p+AWtbn oITmFeihiL5V6KKMmpXoo5A21eiklHYV6aWYZqrpppx26qlflYYqqniflmrqqahiOuqqrLbq6qti pf8q66y01uoirLjm6pCtvLqp66/ABivssPb0aiyWxCbr6rHMNuvss5EpK+201FZr7bXYZqvtthVB 6+234Ia7FLfkBijuueimq25d5bbrLoibxPsuZjTFa+8mHtkbkr736rvvvR/1i+8/Ahcc778Hg+Qv wgsz7LDBBwMccMILC0xSwSJZPPHABCfcMb4Qg6wxSho3/DHCDJu8scQhb5zbRfYKFHPMBM0srz33 FkQzzjfvLPPNPwMd9CY6Cx300QblXLPNRB/U70A0R92z0Uj7LHXTPGO9M9MIXY1111MT7XPWRX9N dtZmby3v2GWHZ7XYRnONNNRhL9023Wq/rbfdSSv/jTbcZuMN9NVn/+z04HXjrfjZhB+uNdVLf712 3EI/vXjhmPOc+d2KxaRyvh6DLjLHJvv7ucKh97syxx+nHnpJqose8eurD2z67KzD7jG/tN8+Ou6i X7w77S6PVLrrDVc8fO6oM998fKcfP3rxxZ9Ofeu4Jy/y8ySrbnH0swePcvekAz8+7x2frH7Gy+vu /Prig54+9cq/Dz/79hcHPsTqq1w/8fBDn/lOpj3rEXB7vDPYAaeHPwDGL4H4C174fIcx35lkfwqU YPsC6MCWxW85+0MZxiLYvN4hD3vrg2DKhPe76YUwfdaLHQktOD4UyhCDBrzf9VI4wBHSD2AGzCFp /yrCtrkdTW6cSyLmGpc3v/UtcIyrWxGj6ESwQbFgl7vc0yy3uSNCLnJW5BwWvZg2ygFOIVPci+cA KL3+mfB9bawexeZYPjgSj4YqJCEKT/K5Pr5xdXvUofiCyMbX0dCNtjvh8wiZP/257n4qlJgcuXc9 PyayjvLb4Qdd9sJAToySoARlAeuISePRMX/agyQd5XhJ1hVQkL+xiNKQSEbBgZGKT7zl3ShXtS8W kZa6RFsuu0hMXIqxcr5E3BeFSbaxSa1oc3Ni3opJzdcIzIjNRGbYtgm5veXSmdyEIjbJiEW9XZGL w7TiL5UZuXJqU5xDS5ziwHlGWwrOa9ccp2HWxf/Pl83rnwANqEAZ0s+CGvSgtBqoQh2D0IaOZqEQ jahEJyqQAVj0ogO5qEULglGCdJSjGs2oRgewkY/ao6MjBSlJDzLSjZ60pQkxKUX1MpOLesSmN7Wo SHD6EZ6GhKc49alMfApUnf7UqEcdQE91GlSh5lSpDj2NRUzq0peuVKRUrapKK6pVrcb0ql9daVbB alWvynSjH5VpWck6086o1aNmDSlWEYJSrzrErgapK1jPKleusnWufs1rX9vqmbcCVqQvhetfrRpY ieB1q4w9LFcTK1nIRhaulCVsYR/b2MCm9bGfNSxdFwvSySr2tKENa2fnKlrNkiUmTgUJUZmK1Nj/ /kOoIzVJSzVakpYmVba0hepta8vb3Y7EpraNqmQq0tqx9tWw0OUsZhkC09Ni9blxJSlG37pb17pV uqltbHQX21rENmSwnQ0vX7Xr0vVW1rtlGSpSh7tU4RYVqrZtKnCFq1v+9ne+T62vgAMs4KbO977K HQ5vh2tf4h6VwDs1qoFVAuDeOrWoDx4wgzf81AZnOMGVwUh113pZz3aXxGsl7UXsmlL3XlevimUv WcsL3xrbODwgzrGgbsxjq+j4x3TpsZBJBeQiu2XISM4VAACQZGwtmSBLjjJGnjyQKFPZIleGMpOr bGUuS/kgVt5ymLPcZNh0WSBXJrOWFXJme6R5/8sUGTOav+xmOD/5zQbBs5rLTBs8zzkhey6In+tc kTavGcxMHjSXFx1oPqtxJkv+SKQ9MumRVLoklc40ACw95k2HxMqcJkmkNS0SUo/ZyC8iNaU9DZJO s7rUrFY1TKIcalivWtKvvrWuW51rVMNH1pf+dK9tvetguwTUvBb2q08Na2Qn29cPAvawd43pWFub 08y29aW3PW1q1/rZ0LbNlO1MbkDD2dyL/jOWE31uRee53IIWM7wd/Ro515nOE7F3mNfdZjl3es5Z fnPADU1vgTa64Ahn87kTzvCGO/zhEI94tcJNcUwZu+KnCjOuaR0Tja+a4zIJtsfBPXJlT7rTGP9X TaHL7e5DI5rR8873vhX95ZbreeESP4tNRn1tUXdb2P+Q9bFBTuygc1zoxd70xVMu1YzcOebxdsjT 0x1ve2u50VSeOqHV7fKnEzznsaLJyXvO62zXGuktIfqzx570oht76UwPDsjRjuuTzJ3ssyb63T1u 9o2r3ehxb3qcF95yqr+86zi/975fnvXEc93lCFHzwcG+F8lDHfJRz/zWV07og1ve8OouPOUN82/F O74hpV/84M9ceqobWuDt/vrovaIcuAd+R7KZ/Ox3z3vN3P73wA++hHpP/MvovvhKUr3qZU7n5Q++ 6mQeOL6v3njnI/8qHb823b1NcqXjfeigVrX/s9Fu6p8LP1pOZzfoMY9u0aN++pAf9Of/fPzrF2Xn 3q+7z1XCc/2b3Nl+V23d53/+x3MAeH7LxW/ytn6uFnk1d3kQAX8EJ384Z3OnZ39DgX+Ax30EaBL9 x4EscYDUxm0iaHQiaHsImBsfuIHfZnf5x4Gutn9vt2zThoIzmIKTwXn0B4GPp3lat3nP94MDd3hA GHo8iIEZmH17h4IuuITm14RO6Hdjx20BKIU46C1MeIVwEhv1h4QMpYVgGIbA54VkWIbzIoZomIYV dxH50IZtWBBu+IYEEYf5MId1qBB06IYGQYcDkYdwyId2GIeB+Id1KIh9+IZ5CIh6eIh3aIYh/xIT bvgPcegRkRiJlNiGkoiJmYgSlpiJmvgRnWiJoaiJo5gPl2iKpxgSlTiJqQgSnQiKn+iJajgYq4iK siiLomiLJfGKt9iKr0iKsQiMupiLuoiLrNiLreiKwRiLs0gTG6GHi2gPiwiNiNiIeCiHgygQ04iN 2biH3KiN1WiN0hiO2yiO0ciI3eiIVUGNjViO41iI4ogQ5wiO7SiH80iP8viN77iPg0iN+JiO/xiQ 6rgrNTGJpZiKdOiJzAiLxdiLpbiMDZmMDImMxmiKtaiKC/mLC9mMMaER7hiQfBiS+siP3TiPijiS JImOJhmO4JiSLpmS9ziQQBGNNImSLBmT9/9Yk/GIjzH5kuxIiPzohwAJkygpkwdBExppi7wIixU5 EksJkSRxkU6ZkZjIi1KpkMX4lFDJkTXBht+okwdhjyzpjebIjduYjecoltb4kSqJjYCIjkbpFTg5 lt7IkyOpk2V5h2xpiGBJlPWol2a5kvGYlkUZlwQhE4kojBu5iQy5mIkpEgmJlQ2Zhxh5jI15kI1Z mZC5lVw5E4ZpY50ZmqK5Lp9Zmqa5KqO5hqepWalJcavJmq0Zm7I5m7RZm7Z5m7jZI6/ZVrnZm76J KLvJm78ZVcE5U8NJnMWZnMqJY8fZnM4JI8sZUc95UNEJUdN5ndi5hdW5ndzpe07BD4EBnkv/IZ7Z yRRCwQ8XgZ46oZ49wZ4J4Z7dCRFPQZ4wQZ82YZ9HgZ8ioZ/lOZ/8IJ7/+Z8fEaD0GaD/IKAeYaAJ KqAKuqAIeqAISqAJOqAH6qATWqAKCp4A+qASSp4bqqER+qD9+Z0VeqEUeqIAWqIVWqD7SaEeqqIa 6qIhAaIz6qIpaqI4uqIg8aIjuhIWQaD2wJ7oKaQEoZ5GGqQDMaREWhBE2qRJiqQCMaRRGqBQWqRP uqRI6qRRWqVV+p/xSZAv8aJieqITWqIxWqYQqqJkeqY6mqMxOqY16qYyKqcsuqP82aMgURFamqVP 2qdHiqV8yqRXOqhb6qR72qeB2qWKeqjw/8mlX7qeVLqkQOqnWxqkXmqpQuqek4qpU3qpmCqln+qo ocqlVNqpRlqqqKqkjfqoflIad4qmM/GqeFoZBFqrtnqruJqrurqrvNqrvvqrvjqrJcGqxFqsdhEV WRiCyUoZfwcVy9oXzfotGrd0K1ht0bp9a/eCc/GsRfcStsd23LoSJTeApbJuD1F/uud+6daFQ8Gu O+F5C+gT6XqEy5J3xIZsH3iAMziF3vetnpavUYivf8d3R1ew/FqF4fevBqtpbCeAgHewH2eACnuD JhexJviEiaKDmDd1P/hujbeD64doH7tmHyuBhLeADwiyRgiEQ1iy8QpzC8F6J7t1XvduHv8br0J4 ga2SffeasA9rgy+4glkosBEbtNp6sbkGrj0ntNPKsHWntLrWtFAYtT77s2UHdwDLguEKKBoLs52n fgDXfihLr142tiqbsz3osusKtkUYtmGrdXALth0rsmb7tSpLs6cXt5vnrpQScklrtFbbgckGtSNY g9qnsBvItN5GuImrrQ1buIGbtYRLrYd7a4z7uNqGuEK3tciigHLbZRxrss2Xsl7Wg64nbw8oZdIX fTJLfY8ns9WHs6Qbu5/rgGubuh3rfMpHum7Ltwjnu7YbgTpbFsBLhERRvHuyG5xbsWmHsYKxvFfb FtBrJcbaLsIaLsc7vF1bvY/ht7RGuSz/mBKYO7jOy38laK8eqLnly7Ph2xTjmmDLurXjK7hit744 Mb9Lgb9JMb3nQrFEC7H717hQq7TvC3TNNrEMi8AC/LeWq8BFe7EWO7URPHJE274GHL1Im8Dl+nya B7Jza26fF7oezLbGu7Jq+7V1S7dpW7smyxB7preHJnvQZ8Lqx7rAwr7Z+r35F63Mi7RWO8BHm7kS K7lS28DWirg+zLg+7IJXC7hLbMHp27g/jMD2iyo3CMQbJ8FYvMU/V34GXK1aG8QYTMRGTLVarL5l jK2hxsVS7CnmSrJmO4Rty3Vqq7ciPMcnbMcp/MGIh7d+7GcjG8MsXLexG7JeK8IwjLxK/wa6qIvI oxu8AHfHM1fDLwt9jbyyikfHl2yzRoi7JLx480e7fmx6o2x5o1vHjVzJO+sX/OutVTwYydrKzfsU siytr1y/qnG+3eqstzzLm8K9wBzMnqHI2yvM8eW9KCFyvays8VHLcXcR8MfJVUHMiUHNSBi3oNy6 mUzKNxvJ5DZ9rQe7m0x9p7zJXxfOuBvJhvyaemy3dpvHeTvIK/zOYyu7USfJ7GbPcOzONVvK2vuZ 7RzQk2y6A83PM4vPe6u7lPzH3wzOC33CpqfKwflvjjzCmWfDBj3KMNvOprvR8tzRFg3R86ecN0fP Fp3RgszQ84zQgHzQC+3OGh3SeyzRXv+Iw/130xWc071WxPzKwACLuSe4ww5Mgjst1BNMg2p8vUq9 1Ezd1E791KVhzNkC1cwi1VZ91T9B1Vq91fOB1V791RjB1WI91jgB1mZ91mid1mp9EWTd1m79Emsd 12v91nRd13Z913id17Yi17+i137d1nwd2GD91+BiqzMqogNq2IctoXaKoYi92JCd2Lgq2bW6n7kq 2U+NEbqapJ5apLbq2bjK2Zna2QdRqqIN2rcq2p+N2qvNqYKt2qfdqe9J2qPq2q69qbMNn6Zt26Xt qbi92wYB3MUaq4/NoY+N2Y1t2cjdoCbB3BDq2M0toszt3JHd1OlJ20yK3bIN2gsRqdr/HdykvdvC zd2xvd0IMd6sKhPUbdl3Ot3HvdiMjRLO7d6vSt/JXRLrLaw/+t3lDd6ayt+mCuCs3dqfWqvkbd4F /tsCbtbofeD+7eDnjdsMsasDLt6+Hd6h3d983eAa7uAcHuCrGuG63dkcnuEQnt0h/qjq/d73PRL2 fRK3qhLzLd0s/tzx3eIuXuM9ut8p3uH9/eGcCuQIztsl7qUSztsP/tpHjuK5jdrdfalCDtwW3uOp iuFUvuAMTtsXnuJSruWjbaoTbuUnfuBd3uNSTdwNmuYsPuNq7qHGLavPXd1xjt80Dt10rdm5qtoG ntp6buAI/uFlXuGmPeWjzedIruR+797n3p3ofc7ksN3kHp7nQz6pmz3kw03YmE7VegqsnN7pnv7p oP7p1ZvpqvLar0Lql2Lqqr7qrC4gqP7qSt3qqAnrGSvrokLruJ7ruq4btt7r3bnrXOvrwr6cwF7s xn7s6DfsjILsY6LsjcLs0B7t0j7t1O7Uzn7t2J7tYVHt3N7t3q4S2h7u4j7u5H4t337uWlju6r7u 7N7uoYLuD+Lurg7v9F7v9n7v+J5g8r7v/N7v/v7vAG/r+T7wBF/wBg8qAR8bB98cCd/wDv/wEG8p Cz/xyBnxFg+bFJ/xGr/UF9/xHv/xIB/y37HxviHylxEQADs= ------=_NextPart_000_0004_01C71E17.736AD210-- From sip-bounces@ietf.org Tue Dec 12 12:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBdS-0001ql-AP; Tue, 12 Dec 2006 12:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBdR-0001qg-6G for sip@ietf.org; Tue, 12 Dec 2006 12:41:45 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBdP-0005Y9-Ts for sip@ietf.org; Tue, 12 Dec 2006 12:41:45 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 532813A02143; Tue, 12 Dec 2006 09:41:41 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 353553A0210C; Tue, 12 Dec 2006 09:41:40 -0800 (PST) Message-ID: <457EE9D3.1080001@acm.org> Date: Tue, 12 Dec 2006 09:41:39 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] I-D: Preventing Fragmentation for ClientInitiated Connections in the Session Initiation Protocol (SIP) References: <000601c71dd6$fb2e7080$2a9db70a@NOE.Nokia.com> In-Reply-To: <000601c71dd6$fb2e7080$2a9db70a@NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'IETF SIP List' , '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 Aki Niemi wrote: >> Performance is important at least for service providers, >> because they have to buy the hardware to run the servers, pay >> the licenses per CPU, pay the datacenters cost, pay the >> sysadmins to run the servers and pay the managers to manage >> the sysadmins. >> >> So yes, performance is important, but perhaps not for the >> hardware vendors, the software vendors and the sysadmins. > > This is all relative. > > Your draft seems to add enormous amounts of complexity -- to both UAs and > outbound proxies -- to get around what you claim to be a performance > bottleneck. No, this draft is not about performance. This draft is about be able to use UDP or TCP with Outbound, i.e. be compliant with RFC 3261 (Section 18: "All SIP elements MUST implement UDP and TCP." The performance issue is about implementers be able to use UDP or TCP or whatever they want, as explicitly authorized by RFC 3261. > First of all, I disagree with the assumption that running TCP > only is that much more of a burden. This is an implementation problem. Outbound MUST support TCP and UDP because RFC 3261 says it. The only thing I ask is to let implementers do their job. > And secondly, I believe complexity is > the biggest enemy here, much more so than the performance concerns. Well, complexity is relative, and again it is not about performance, but about compliance. I am currently implementing my two drafts about fragmentation in my endpoints and servers, so I will have a better idea of the real complexity soon. I will eventually ask the chairs for a slot at the 68th IETF meeting to present this. -- 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 Tue Dec 12 14:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDI0-0004D3-EH; Tue, 12 Dec 2006 14:27:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDHy-0004Ce-JB for sip@ietf.org; Tue, 12 Dec 2006 14:27:42 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDHp-0003MS-9y for sip@ietf.org; Tue, 12 Dec 2006 14:27:34 -0500 Received: from [172.16.4.17] ([172.16.4.17]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kBCJQtcp023273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Dec 2006 13:26:56 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> References: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1F71FE5E-4DD9-4B5C-854B-F40952C2B4E0@estacado.net> From: Byron Campen Subject: Re: [Sip] outbound-06 submitted Date: Tue, 12 Dec 2006 13:26:49 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: SIP WG , Cullen Jennings , 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: , Content-Type: multipart/mixed; boundary="===============0192410790==" Errors-To: sip-bounces@ietf.org --===============0192410790== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-813339753; protocol="application/pkcs7-signature" --Apple-Mail-18-813339753 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I have a question about the usage of STUN as a keepalive over UDP. Are clients supposed to start sending STUN before they try to REGISTER? If not, I can see the scenario where a UA sends the REGISTER, sets a timer (btw 24-29 seconds) for the first STUN keepalive, but before that STUN request is sent, the pinhole closes. Both ends will think the flow is ok (the STUN keepalive will open a new pinhole, but the UA won't know that), and the mess won't get cleaned up until the UA re-registers. Sending the keepalive "soon" after the REGISTER would probably solve this problem also, if sending before is not acceptable. Best regards, Byron Campen > Hi, > > I submitted -06 of outbound so folks can at least take a look to see > that the many small changes we have agreed to have been incorporated. > I also included the proposed text for FASTEST, since the draft would > need significant surgery anyway if we go with CLEANEST. > > Until it appears in the archive you can find it here: > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > outbound-06.html > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > outbound-06.txt > > thanks, > -rohan > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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-18-813339753 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjEy MTkyNjUwWjAjBgkqhkiG9w0BCQQxFgQUKxL6LVGCMpAOfKunaeuQvZ43wKUwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAL4+BkuG BH9Tkj5qmXxBMDpXawgbcNSK3tsN35fj6YyJxI0u4A30WqSYiqidwK/MNozy5HJC46zIeoAGdy5p aq5lmzWHciP/LPA0C4srUfCNRb8YXnDymwSbCjYP3c83RCYCCNotT6YZKAYXPW+zbgbPGdRclwrv Nfqat1Qc2SGSUe2/D8KYlpfVverS0w/lP3UwBf2PUQheRBowh3Wyqm/Te0Vhz/jIEbxkH5Qkfbhk 6CmB/Vxm2fQD1lcwvds5PUNPbH5SyoiGynXd3wDfTCbTuXQpNIbsC1IzLGsiFTGIAuydKksPNCXi unEcRpQ03/JHjQ6KlWqYwbGCsdn1yuMAAAAAAAA= --Apple-Mail-18-813339753-- --===============0192410790== 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 --===============0192410790==-- From sip-bounces@ietf.org Tue Dec 12 18:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHOU-0005wJ-Fk; Tue, 12 Dec 2006 18:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHOS-0005vy-Hi for sip@ietf.org; Tue, 12 Dec 2006 18:50:40 -0500 Received: from wr-out-0506.google.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuHOP-00075v-8t for sip@ietf.org; Tue, 12 Dec 2006 18:50:40 -0500 Received: by wr-out-0506.google.com with SMTP id i7so2840wra for ; Tue, 12 Dec 2006 15:50:35 -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=nFR9ffK9Ub8xLLyTmqr+GlEt7ePVXLH21MM7PJiWxCqHnWdH6Ej+oIoBabhagCFXFK+8prsz4VKa3IG3UjlU+KcEMWQOABwLOjqbhfKVvEUyY4WHv5EzqDbWcCRRSeGcJ6/fBIkZtCHjq3WeoZT06FdiZdgwOVhBZQoTo6b7WA8= Received: by 10.78.180.18 with SMTP id c18mr111584huf.1165967433941; Tue, 12 Dec 2006 15:50:33 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 12 Dec 2006 15:50:33 -0800 (PST) Message-ID: <953beacc0612121550p2fb16322sc1f03c6b3223b86f@mail.gmail.com> Date: Tue, 12 Dec 2006 15:50:33 -0800 From: "Rohan Mahy" To: "Byron Campen" Subject: Re: [Sip] outbound-06 submitted In-Reply-To: <1F71FE5E-4DD9-4B5C-854B-F40952C2B4E0@estacado.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> <1F71FE5E-4DD9-4B5C-854B-F40952C2B4E0@estacado.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIP WG , Cullen Jennings , 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 Byron, We could add text recommending that the UA compare the rport/received with the XOR-MAPPED-ADDRESS. That would appear to solve the problem. Can you think of any problem with this? thanks, -rohan On 12/12/06, Byron Campen wrote: > I have a question about the usage of STUN as a keepalive over UDP. > Are clients supposed to start sending STUN before they try to > REGISTER? If not, I can see the scenario where a UA sends the > REGISTER, sets a timer (btw 24-29 seconds) for the first STUN > keepalive, but before that STUN request is sent, the pinhole closes. > Both ends will think the flow is ok (the STUN keepalive will open a > new pinhole, but the UA won't know that), and the mess won't get > cleaned up until the UA re-registers. Sending the keepalive "soon" > after the REGISTER would probably solve this problem also, if sending > before is not acceptable. > > Best regards, > Byron Campen > > > Hi, > > > > I submitted -06 of outbound so folks can at least take a look to see > > that the many small changes we have agreed to have been incorporated. > > I also included the proposed text for FASTEST, since the draft would > > need significant surgery anyway if we go with CLEANEST. > > > > Until it appears in the archive you can find it here: > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > > outbound-06.html > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > > outbound-06.txt > > > > thanks, > > -rohan > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 because@apdphotography.com Tue Dec 12 20:07:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuIbH-0006pb-JC for sip-archive@lists.ietf.org; Tue, 12 Dec 2006 20:07:59 -0500 Received: from [222.138.63.48] (helo=[222.138.63.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuIb8-0004SH-Fl for sip-archive@lists.ietf.org; Tue, 12 Dec 2006 20:07:59 -0500 Received: from [193.140.121.14] (port=8840 helo=xjktxsapttcs) by apdphotography.com with psmtp id LdnhZX-9a4406-00 for ; Wed, 13 Dec 2006 09:14:50 +0800 Message-ID: <001301c71e54$0f8ec750$00000000@fgg49ae656dbdc> From: "MHz" To: sip-archive@lists.ietf.org Subject: Empires Date: Wed, 13 Dec 2006 09:14:38 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C71E97.1DB20750" 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: 4.6 (++++) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 ------=_NextPart_000_000F_01C71E97.1DB20750 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C71E97.1DB20750" ------=_NextPart_001_0010_01C71E97.1DB20750 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Warning sony psp fun line? Read boring finds think incorrect. Pollock uncertain provenance case western. Spying, break tech shutdown = button winxp prod, tos upgrading? Won category tool process flexible = efficient, preview editor. Suiteipod, itunes guessing betagrinch cti seinfeld darth. Banning selected request animated ms novice logging webrocket secrets. = Inc part, jmi athlete inemail! Version, rmx contract playerthe reader = summer filesrmx, tough. Combined support connects merged linux embedded = dreaded found extremely. Theword, length formonly returned eg prefixes, = suffixes wordsany. Thebest thatare usersee fakeguess peoples nameseach = filescan samefile! Ny nythis morgwen january sue. Used nsa agents weapons objectives fulfill accomplish opposing. Declining consider factors overnet combined support, connects, merged. = Employment consumer info realtorreg officers, committees! Animals, space = climate fossils ruins. Toes ummmm, wow ltggggtdrd klingy. Cdclintdll id winmx looking kazaalite = wwwklitetk exception. Mac patches bone boneville directors cow race runaway turtle? Formatted, = future gnu gpl. Ideasfresh flowers indoor ecardsyour categories cart best sellers = libros. Cbdb ccdb cddb, cedb cfdb dadb dbdb dcdb? Athlon pentium mhz, = ram graphic comp, clients emulec, plusf. Default returns common, places wont improve. Onfield injuries, snapping bones see gameplay, posted. Bytetaxi, kb = grabber encoder mixer player database organiser. Dominant xcwith edonkeyxs community offerings giving moneyxd. Theatre = swappers preferred playback? Component altnet icons payperuse demo, hog result kaza. Dela msconfig = boxgtclick checkbox ok, abcman bases europe, thing. Roadmap projects hacking build nightly builds. Nrg dmgsort agtzfile = mbmax mbany help arrange. Hardcover nonfiction paperback timesquot, = registered affiliated with sponsoror endorse. Pdas speakers hosting overstock clearance. Authorship offered previously violated express exercise intended reduce. = Suffixes, wordsany languages otherones. Consistent ntxp keeps complaints, kazaas buttons. Ebdb ecdb eddb eedb efdb fadb, fbdb fcdb. Difficult nonlawyers weve = informal mpled note, advice know. Burgeoning marketquot ted mendelsohn = says commitment providing premier news. Bind, desperate housewives = darkstar sprint knoxville speed. ------=_NextPart_001_0010_01C71E97.1DB20750 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
3D"boasts"
Warning sony psp fun line?
Read boring finds think = incorrect.
Pollock uncertain provenance case = western. Spying,=20 break tech shutdown button winxp prod, tos upgrading? Won category tool = process=20 flexible efficient, preview editor.
Suiteipod, itunes guessing betagrinch = cti seinfeld darth.
Banning selected request animated ms = novice logging=20 webrocket secrets. Inc part, jmi athlete inemail! Version, rmx contract=20 playerthe reader summer filesrmx, tough. Combined support connects = merged linux=20 embedded dreaded found extremely. Theword, length formonly returned eg = prefixes,=20 suffixes wordsany. Thebest thatare usersee fakeguess peoples nameseach = filescan=20 samefile! Ny nythis morgwen january sue.
Used nsa agents weapons objectives = fulfill=20 accomplish opposing.
Declining consider factors overnet = combined=20 support, connects, merged. Employment consumer info realtorreg officers, = committees! Animals, space climate fossils ruins.
Toes ummmm, wow ltggggtdrd klingy. = Cdclintdll id=20 winmx looking kazaalite wwwklitetk exception.
Mac patches bone boneville directors = cow race=20 runaway turtle? Formatted, future gnu gpl.
Ideasfresh flowers indoor ecardsyour = categories=20 cart best sellers libros. Cbdb ccdb cddb, cedb cfdb dadb dbdb dcdb? = Athlon=20 pentium mhz, ram graphic comp, clients emulec, plusf.
Default returns common, places wont = improve.
Onfield injuries, snapping bones see = gameplay,=20 posted. Bytetaxi, kb grabber encoder mixer player database = organiser.
Dominant xcwith edonkeyxs community = offerings=20 giving moneyxd. Theatre swappers preferred playback?
Component altnet icons payperuse demo, = hog result=20 kaza. Dela msconfig boxgtclick checkbox ok, abcman bases europe, = thing.
Roadmap projects hacking build nightly = builds. Nrg=20 dmgsort agtzfile mbmax mbany help arrange. Hardcover nonfiction = paperback=20 timesquot, registered affiliated with sponsoror endorse.
Pdas speakers hosting overstock = clearance.
Authorship offered previously violated = express=20 exercise intended reduce. Suffixes, wordsany languages = otherones.
Consistent ntxp keeps complaints, = kazaas buttons.
Ebdb ecdb eddb eedb efdb fadb, fbdb = fcdb. Difficult=20 nonlawyers weve informal mpled note, advice know. Burgeoning marketquot = ted=20 mendelsohn says commitment providing premier news. Bind, desperate = housewives=20 darkstar sprint knoxville speed.
------=_NextPart_001_0010_01C71E97.1DB20750-- ------=_NextPart_000_000F_01C71E97.1DB20750 Content-Type: image/gif; name="FACILITY.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c71e54$0f8ec750$00000000@fgg49ae656dbdc> R0lGODlhjAL4AYewAAAEAIQADAt+B41zCgAAjo4FhACNgLq4ws3av7C/+DYVAG4VCX4bAJsbALUZ AOIiAAA1ACNHBEMzAGUyCYNAAJwzCcw8AOZKAABsBh5aCkRRC1luAItdAJ5RCLtmA91cAAKLCyl8 ADpxAFRxAH9yDZh8AL59CeCMAACrCSufADStAGiVB4CbAJ6YBrWaAOCTCwPOAB7IAEy3Al3IAH+x Aqi0ALa2Ata2BwDWACXWBjfcAFTeC3rhC6fZAL/RB9ThAAgAMRoANkgAM1sAMn4AOqoATr0AO+AK QwIpOB4WOkIdPloRRIMZQ5wYPcokNOwRSgBCMyczSzM7P2I3MX9FTahLSLNMQO44PwBuPiBTQUVe MWhpNnNnAKVVRsFrN9xhQQCFQRV3P0KOOVKGPXR4OphzPLxyN+t8OAijPC2qSjOXTm2WQo6jQZqT McCqSNSlPAyyMhHERE3HRVXHS4DASpGzP7jKPeq8TArmQxXdPzjfRFzhMY7VSavYQcXTO9HsPwcA fCYAeUAAhVgIfHkKdaYLibEAce4AegoddCkVdTEqhlcneH4kgKgrdsQbfegZhQdGcxdOgUZJdGYx joZKhag1g81Jjdw5cQdgjCZkcjVjdFlqgnxnjJVijLdcgNVufQuFchGLf0l9hGJ1iId+cpZ4hcl8 cteGcg2pgB6sd0ugemagh3+keqCSc8ymd9OthADNjCu2dTa6jWDIf3W/ipm8jLq1fdW3iwHWhhzc c0Dkd23kgXnfg6bfhMTgd9rYfQUAyiIAzjYAx1wOv34GtKAEv8sAtOYAsgAVyhotvU4WulcuyHMl saIbwrYdvd8pzQA5zC1MsT82yF0xv3JAyJxOt7JFxOFJsgBTxB1WzD1Xxmxis3VWwKxktMdZseBu uA51yB51vEdyzmKEvHuIvZZ9yrN1w+SEtACewSuWvkWjtWWcwYeou5eptcGSvuutsgG+tRK/wDfF v2zNs4XAxqjMvv//46qWmYV4gP8IAA3/AP//CgAA//0A/AD///D+/yH5BAA2uDcALAAAAACMAvgB Bwj/AGsIHEiwoK8avg4mFKgQ4UKEBSNKnEixosWLGDNi9OOnBkeBHwd21EhSoLwaJ1FyHCmyY0iP MEvKnEmzps2bOHPq3MmzJ89jNYAeEzoUaFCBQOMlFRiPabxv8ZrWkPqtxreqVQVeteqzq8WEBx02 fPjQq9mzEkOydAny48quJ+OeXOn2rUe6L9Hq3cu3r9+/gDUSHUw0qNCpUhFLjfoUKlWrWbdmDdw1 LMGGYgdapsx5Y0uXeWGy9CqvdMy6be/eHd25tevXsGN3LXzUqGHDSxU3XYx4a9TJWgdilV1TIVmG lsFCJA47tFvVbJ/7jLv6Jei1rJlr3869e2DCSAce/zYcdehuxE4ZOw5OcDhw7xQ3Ize4XD58vSPz t9X/XD/c0qZdxN99e5mWEoEIJjjbUeIRNBRSSSl1TFMPMrbbhRduFZxkClY0FnLHYdbhWazlJZ1o KP5Xl3So+TfiTnK9iBNdMt5XVEE3GjXhjuUZFRVTWjn2I1fuDVejZgsd59B8R/YUGkFrgYSiXWix tZpo+WXX5EwpBXjglhWdaCWYrh1m240QDrSYUkoBaSFjWv2oYZDv1ZgkRMqJVRaZNkUHGnQnpjZm V09OKeWhfJIUI0oDfZloS6dh+ShnOd4WHoTlTYUehgQ1RiRkXE2qJ4hh5SnqTH9SqZqU1rFapaCp uf+q5akRUeclo6fi5SKitOqF5pkPXorhsOgxJaRjV0lmJJ/GbQaWfb1uZFeUh+L1mao+7WptitFe 1CV1vfYXa7d8AdtgeDoyNmFQFxa0ZqgbzpmofcaRK1OWugo6raskrirpZ/ZidCC4k5q4LbYB7xSs jrXVdqOEFProlKbtNqVswhiTdF11+0lKbcdVWjtrxgUByGiAorJYbUwk+7SwbbgxCLGFQFIs51RY JVtnyzwX9CevIp2GbaE79UdjzxKZTC5/ozVNNNIkjedwgw/uWOHEQyZWs7xQdy0gohtj+bROR7M8 NsYmE1yw0a0i7HXUt+kYLIMVwnmemptq+vbeUKb/qpZA1nRkjTUeDW4ifn//zDfK2w1ew+CEo6ot anzjJDXM5J1Zs96d3l051INCJyXkfgT+uOOU70XlyJ+/FvnphMf+eElqfQx06xkV9iuwFGZdM5x6 a417y+LuZ7jhpwM+EOSmD/+244BDPvvytF8ruvMlEWZujnZv/i7n2JNsMEiOB54X9MxPHz7Gscs+ ffnKx69xi4GubxGw5ob3bvdvCm+/vVaikfmkR5f2Ia9w0Psfudo3u/RFT37qs0iWqnU2BV6qKJdj kG4mFjz/WTBgb+GI9FB3utKZTnaRe90HT6VC5rnQgARR4b36tkKMyI1q7vqR58BXQ57lJ4WGM6EL /4WIvh72SoblA2LyZEiRFZktdEaMyGAqkpghbS6K3cIL8/5GOtiZjojUw2KTDJhC5SUxIgz0TADr J0ad7LCN0cKXSwaIusDZ0Y4fSWDy4FgjJALxj3uMnh4nEkKW8fGQK2TLAON3vC+6T3BlRGSH4Pc+ 2FEvkoPUCBslyUnnmbCB6QNN+0pnSfWlsZMEQmECz4jEJTIRlbBsIx5LWToivtCPEYylbFbJSD0y UIlK1GVB3vEOYf4PeoKbUuwElyVKjtCYxIEfE9MnPVP+8pWxLGYNiknMbWoTmrgj5eNMWMtf1pKR MQRnbJ75wIJE0ovLY6cuudnNbQrkm+p83hbvIv+7kKgynUXEZj79gslqBvN9qnydQBHZTWI61Jv4 RNA5anCOiVJ0oDpR6D4DWTgRxhOU8sToX9wnSBQusYHutCRJO/lNerZUmxHljkUpOtOLirQmK60j +TgaQyAG4KeZvClaqBlMdhLVpNUU5kMf6k0FVdSmTxVITf3y06r+tCdWtSpFsnpVgnA1AF7t6kCq utWvXpWsFgkpLx1n1qxaA60SgatQu/LPdPa0pJd8pyTxSc972vOvMoXqUys60anypa1irYhc49rW giAWrDVorEAWu9iwmjWyiZ0IDN8qViU+FqiVHWtmeRJaWOq1iCh1ZSXRt1KG1rOeBIFpdwYbVZr/ 2rawfcmqZTFSWtFCFrNw1a1vgftbzA53txPpLUl8etWExpOzYHVhVYOqF+Vy0oWp9SUg89pKVHKz qfeELXiZg1upmve8tt2LdS1iXcqKVbnwzWxv11sR90FuugdV4XQtid/A0DeWAW2hGT+KTmPKlq/f 3Y5FCVvT8prFwcS9CFd9q1XGFneyZ43vhR0r39EeNyJo/SqGyQpdq55RkCSW3mWPu2IKV9jCFZ6w i8kq3BHLVcQiJu57d/zhxqnUi9JsITX3SF0xJrivEmmoTBd8Xgcb9iYznel6V5xjEI+Wxh627IZ7 DNyybrnLOkZsmAOQVAPu93WSBXOa02xl3bb4/7MhrjKOJ0zlrsY4y65T6TRBidLWQpCTSrYnkgeS YNkQVqpRZXJtfVLYQ4PZy8ht75Uz/GUtu/fC821snHf82+ai1YEwTHHk7txpO2/6wxqmsI1XHeEu kxqyL251q0k960q7Lo1D/vMqpVlJlg6zoQ4NtoJpa14IH/rJNFH0iC0NVjE/OrmTbnZiZWzj4Ha4 0mI+dY9HDdQfPxC68LR2qWHN6WVzmcPjjnS5l31jU2N62vAmt7Qp7R1WAjOJv9TzKQHtVwQDltDk jchUB4vonjja3NWed44lvWEsF5fa6JY3uiFtYYSHOXn77TO+5To4cbN43e22tcc/nm52x9viz/8O ecIhrh0yIvSjQQboQg/Z0vAG+8jaafBAlG3TnuNE0RONtcmxjWeUu7qymZY4civO9EubuMtCjmTG ATdyNYP85BRPubtRTW+ST7zHm3Z30W+tWtYKMpCndKB3by7o18KH4BdlMJN9npOBP3voWYf2u0u+ 9DajPOl6NzrV3Y3Js4O7mlXXttUfXvSqL57r81b33vsubnnbepcjBLXLDarQJWUTpi6NSExfc2y4 O1rui4Zykyla46PDW/BLr3HrsRxxVsva7wW5BnCvcY12D17i9oUndCmZ+K2b+8WpZjWtEe5wy/89 3s5X/qWjafZe/1Oa9bIGtADNVKZCdLa3pe3/wZFtE6AH3dmSZfmMhf7YMYdc/cjVvfx7b/yVk7nE iQ2mqB9XfKU/ms1t1nzIt26LJ3vXFnGx9mpfh3nwZEZmt2sMEYH1AktK9lKjFxsHt3qNRlPkVxOJ hoDR9n5f1mIBKIIeVmWBVwO6p4K8V1UteFUrqGP6pVUCdl9AxVx8p3gmOHbCBXH9N2N9d3cXR3kH yBy4Fka59Di+ADnNgiTbR3PC5lcS9YFRVnAGF2Ud2DLyx4ICsYLzp4JgiEZJ1U4C9UwzhxP/hVFp 52cplCQNMThuaCoUCHAEQmxQxYHotRMEl4Va6IVc+IUx2IUXIWSXRGT75hNCN1di+E6spVBL/6h9 2lcqmaGI3iF+xbZzqacTDJZeXsN7XviFYch7XeiHaKRxQXWIiIiClCgR9uVMJKV9eLKEHxKHq0gc p5demegVfJgwnjiKojh/oviHYUgRLrdaZXaGBLGJ7AV/tSiGJ2VSeAKLkVgvyiEizegaDbaBG8ho qPc2vQiGWwiKgjiMgUhgBVZG1WcRCyZ+yniNOHVNfTaLy+GESOKOOXeH+eSHv8iFghiDnliOKRVz 14eMOlcQcGePNJFJQJQQzOOGIDIfT4iQgbGNaJGLSOOP+hiK5YiRAFmKDth5GbGOH9hzdiiRJaFR SeSQDzkqEWmSLmkWvfiL/+iLLIiRJ4mEF/+RhY2GWzvpAzXgky85iANGOB9iEPTSkkHZNfywlOSy hcIYjIEYk8EoEAlQlV2xhxyojRblA1zpAzXlA0vJDzMRlu5oKs9Sj56HlElJK2HZlm5ZA2Q5EXGp EW7JlDRRl2KZEWE5laQ4kwPhlFOpgnhZl2M5mGKJheN3Dl4JlAMBlnZZEnN5EZEJS2SBGXlSKnuy ljixLN5hmGQ5mQQBmhaBl4VpmBixl6MIjoEZiuD4lyzomaIpmaaZlYvGlXPHlT8Zm6P5mLKZl5Qp H5ipJHeimTehM+yBIKCpmzahnBXxlgPBnLk3jjWZmtM5nTGZADWAnVVJltg5EN1Jl0tZW8f/hmhR 5ZWKuZOKKRDQKRHrqZ68iUpNOI/zKIkRkTPEiRHGmSwKkpzvqRPtGRH/ORFOSZMd+ZdQSZUq+J1w uZRWiaCQGZ7JiHrlpZi2WXpdGZaMCZ6+2ZvCFIeSOBbVKByhwiH3ORHGSSQ7wx38SZjP+ZjOSRGT +aIACp0s6p78wHuDOZODWRBV2aPZmQBhqZ1UCaQyKnBkOaHncKRJCqGDWVFcSZY+WaM2KqNSuqAb qktl8aGVeZxGYp8pupbvMSdfShwrWqOfSZow6qJoOqNXyp5ripqzaaWEuYIJEIxWSaR56aM7OhFL 2qR92qc/2ad1mZ5Quqdy+qKGaqUD5Syx/+h5kREZ8cI1Jfopj0ogZWqjLSqWc9mfoammvsmpitqc cdmWNoqjcGqX17CXprqh5WiV3PmjpCqnElFRnjlRpKmYsZqrTKmrdrmpvcqbvtqm8CkRE7gZOaOf dAIvk0qpwsGZ3bGimRqt/xmspwmsbxmZo8qUqaqt2yqW3Tp/cymKPqqdc7mdDNqdommr4clzgnqY tLqu75qXGIqtu2qt8hqnAeoaFSheCHKZ8tms+TmioFKp9zkZGjKm2wGtmIqpVeqmn1qkBUGvpCqx pfqtgqmtFIug1yCkmdqd5soPDQqahRWWyKau/FBTJEuhJOuY/MCynaqp9jqlZgqqsvFabP/nfQpy J0Uppvp5rEWirEkJqVyKnP1JrQu7pg77srHKpm16phuard5qtKiJqa2KoHiqnR+bnQsboYBahTOl pF5Jsj+pqH3qstIas6EqlzT7GvsKWLB1gfeBme3xKSPas3OLsC6pLJL6rEXrqdEasWsbm7oJrRl7 qt5qpav6l6ipe1W5sVqLqVgbpH+bjDZqiZn6mF1ro2Fbr0/LuS+7tSNScwCHs3D7IifarMwaL8ua ugmisGl7ppObtO4Zu4BLsbx6r7j7mkupe20pimQ5kxuroJJLrlDbpoSVru0KoYC6uWL5pJyLuzD7 q9LbuQQiXqAXeoJ2E/NQA9v7GhfTHjz/e7clKqZACx+uS62JqrROC7Hqy6KG+rtTG6xzOooNCqsM qrXYmb61i5cmS7aHSqrMG6Vv+r4ELKz66n2g11QHxq8Z0b3z8MDb272UYbCQcazwsrfjGyQdcr5+ e6ii6pzs67BLK7OdG7W7y7uo2q0y6rjemb/neqf/y6fxSpopa6UzDMDxernvmb5Smq984VLX21cX WLoR8cACIcEEgcR88bPiWyQBu7preaD7uJqIa6cO6rE+mmy3RZJVWLu46aRSlaEkg3Oji3OiS8QD 4cBHHMHcy71KvBfISrc64x7sgbdQfI3hCIwxKav8+KMEoaDeORMDJ56rF6rpiYdQc2Dh/6XANwfE DQzBbtzGSGzEgWGwKWrJdwwfb+yNrOmFO1qggYy/PQrD6riJVEiRtRuoAmGbSPO22QtRL/XKOEsR agzJa9zGuAzHdTLHKHqiGJzJrWHLubw3/hiGeDmgQwrIj+vHylwRWum1z2zIXQwb+7APNVDN12zN aLFUsfVv32dzQlwRtezA5CzMS1ypF0PBAGvHwPwXRszGwwOYfEnFLYy130nKIVl6PleSedjPrWHN AA3QAqHN2OwTCAxeEYVkwObNtEzJEfzOEGzOaCGpexvHv9zOlAHJ79w6gOma0ikR9evHPxrSGMGT chd3EorI47mLaFHNLn3NMD3QMa3NO/8xemecwAf9yLn80Le8yWfxvQLrxBaM0bIBz2vs01AjjsNY EVjsseW3aCZthYlGbBbpFwVN0DIN0zRN0zhh0/0Wem07aBNByRah0UjtE3TcpRziy+xM1Hyx0UfN SUJK0iQxdzxZyLioja6BzVvt0gKdzQPB1V19ZNebvbJlc4sMtxJs1JLsxmfdFek8sGv9qG3t1nqh xJMskSKJpHGX11UNGC8t06F91YH91zchxGeM0FIIywlMy44d0Ue804/901zTs0Nt2a7B07Ad2/YI YTtHkhro24HB11ht2lqd1YA92OEchQuN2Nys2MM8zuX8F5FN0aCC20WdxnA920KlbDv/GX4F99l7 Qdyl/dKjLdg6gb0I/bbc/GvjJRHlzMbc7RcHm6x0i92wscm7HZSWi5hWuNcBTRCkHdMD3dfp3XZl fNPszdBJ7NiRLMxwTd1Cy6yVjd99EeHD7JJQ/WQ898/mPdPZHNDkPdPoTRNLddgnntCFrRGL3diu ARzyUuEWftlJPM78vdl3TZ6cSBnGHeJZXdCindyD3c3r3c2xfNgXId9p7ODzbRYWTNkyPuNmQdaM neEI+d2XGNX/fNxcbdrmHeAFDuQywVdtR+bfleKLzOJmLclNrhcxLuXE0eJVvpbtWJDULOIjXt7J fdViXhOtbdhuS+arneS33NhtDudI/xPRit7gmhnNzEHQAu3XA47nxZ0TK/5XbvfNjtzAcT3niD48 Dv3QavzpfZHnBe7jqN7XfT4TQ2zkdCh6DCzO8n3opN4zLR7bEl3rXSHmkb7Voq3qYF7iJIHasFzs RP7quo5KtpzZya4Xfv3rkm7coX3qqz7mChxb7J3Qg97sh2TUGm3l3M4TvL7nfI3cpy7gBG7irv7K hLbcDB7u3U7r8E4Tqh4Rz27uBSHpXZ3Ymd7asTzv3f7grw3wLT3t1P7lCA/Yws7qCE7GwIbkBN9G y+7iEd8TwF7u+R7mfY7Vlr7aNgvx717xEv/a8i7yFeHrpa3wgY3uYc4Tl066sW7yfP9U8jJvEfpu 4MFO4AFu8DVdaPwe8zVfQ7C96EGvE8T915Ue4rzO8z2x0IJe9GIE0bkO9TaB3l6+5yl/3Hoxy+uD Mo5C9TW+5GB/E4IN5MAO4qPdjPLwwDFyK2NfEGT99kZ/8Vif7xgvVBC89npvEgPD92O/3yVqILhC IDv/4T5e+EI+V3pfGhFsIIvy9XKPEfkw+T4x+flAHJZ/+d7BOH5/H9P+5SDe8rW4+Nt7EvOw9oPv JUoT+QKR+ZY/EK/fE7EPG66/E7Pf+pRPEK6f+zWw+74vFweS+brP+77/+rd//MS/+wVh+XzN/NnM /FaviN9y+l7SvQQD/KyP+76v/ZX/z/tncfsSAf45Af7Iv/29X/zCrza1z/3av/3lP/yaj/7wr9XO z/5Hv4oAkjYGYv2drzZvDxD5BOarUbCGwIIDDS5k2NAhQ4UPJU6UGLEiQooZG1pMiPGgxYEEF8ob KM9kDXkoU6r8CNIjR4gvI87k6LHlvho4Fe7TiRCnwZ8ahQ4lWtToUaRDV6IsaFLevBrznDadWvVk U4NLk27l2tXrV7BhN9qMKTIsTLEG0ZZNC9Ol2Y5w47J0mtJuS5lm187FK5Km3LFm90XsmY9nzrSJ FS/2erLuU6hRpS61StVu3ZGMNW/m3Hnr3rgh5YoGLFotRtB94b4NvZb06ZALSQPm/wu7tmyMJxVe XXmXpOmWth/+RV2cNu7VPnOm9tzceePLKedBdRw1a3XMVFVq1frc+3fwn8mWfd36LXCFqWfrzWue dvn1sGM7XP+Xfu64vbGOTO8372y+EDIutIlqwoingYIKb0EGJ6KsLqlQoo6p/abSDivsrmpwQw7D U8++4IRzybwCiauNtRLZM86/8cgDMES2KNzNMcpQ6o+g88oLTkAcbXoROSCF63DIDR+MsKDImIpu O9+ua1JDIqOUUqwPVXTvxuHmuyg5FoVkDsUAW4xRxBYjWsmiuzD8zT8Yq7wRrR9hlJO5KesE60EJ t5uMQrr6zM4yDbuzc1BCM6qSzP/49gJuyyDB/LI9RA0lC8Qx5xKUT+IgzTI2He/TdE4xCxU1qe5M StJJJunqjTffLmNpVFhhPTTM42C65tZOA2tU00etjJQitwbUNauSXs2qqRyF9PTNUE/08dnjYpXW KFeP5e7B6vx0ddVpu7UTNBQVtelWEhn9tc1m0eXytk3HDFakqYpdVb815fN1SxXTpdNbBuOJp7mq jK1QScucfAzDVC/ld2EGtfzIWRaTw+u0a1q6BlwTQ9SyV/kIlLPdICf2uDczA1XSwE+X7fg08hiO 0t8a/v2Xs+ywo7DV7XJOc9tUr3P5Zw/jU9fe+dar+E18NxZaNZCvVLbp2+rzVD//gnWDNt9Olb46 a2hDBjoxf2WOuTOca+bTJGvQliftgI3lreev4/bsRzDLNe/Wi1dMerQ4F62U6ac9/TtOGQVq1WaU sfZba779jrprub+aeSGYxV7MZsxqfIxta6xRcklAWU0zctKlxbsgvCuuuPS0qB6pSdYX8mf2GvyJ 3aCZww57bM+gxNYuz9e+Oe20Cwr+2Jz34/N25qdUHXWDVl+9+a2oxpP6gmyvnfbYdY958tw1m1dN 7mpg2/zH1o6u2tHHx/79DcmVHvrU4T/qWqsUjtx22mfXvvTcgY93mylfZlbiObapTXhOIR76buaz bNlPgkQi1wSr9zn9kY57/MPe/+TGZrnv0YxGS+nc+dSXPuBZSIU7s2ALnzO91J1uei4sis2a17// Za92AMRdCGH2QQIOjCmdM1/nUlI8zJTwhG/7XJ9o+ETG1A96NaggFK34EA7+z385lJvMvFeQyoGw dRUSXfGIqDaUEO98x1PTzeh1RTiCpYrRm2Ec48jF7emQdAEcYAj9yJjRqYSIRVQjAtHIwBL2zHfK s2MjiyI/Kp7OkY3UYv+Y58Xd4e6H4otgGhMZvBNyToHrc6IKJ0nDf6TSK8+b4kJS+Y9TtpB/W8xi 8zY5QA9y0mdIbEoC0abEERrvTxmMZdxeeUxk1uCVYZkfQ5bJmGcaBZmqdGU0lf9JzYJY05qTnOUO vdk9y+1OjJe70BANacYIoo0loNwWC4tZumlO85qw5Mw2iWJPZ2LznvGkZzaPaRBt6hOfp9Qi9cII vlwCMnNENKTxjHhEX9JIO9hC3jvhqU9/9lMzA9UIR7nyz4z2M5kZraZGPUrJHeIRgJgEY0LJWTBh Go9JweMc8TSXmXJalHX2PClYeiqRnx5lm9Ec6TxLelSLFvR9LPUOz8zXEHYicm02hSjcXkVMnfKL p/HMJ0iBKk+AYhOsIeUnRsMqUq82BJ/PBGtATWrWrMaVK+Vr6BFVVZeaws2Uy5Mr0LbKVbJ6lJ9n DaxYy5rWow7WIWul5jIbK1D/yGq0r5O9IPoK2Ut1ngSBD01eG7FKWWn9lZ5sjaxQiKpKt4YUqV+F 5WkfwtjRola2b6UtaG2LFOCl0VXHS6BliifITjLytlo162ljq9jXjtWxZSXpapPbWriqFa6kja1R CXvd4WZXKOosYQPVx9kULhB9KOSrdqf11+selrVFXa5ihxpdwo51sdN97HFTi13z5lciavwlQ84n TPG+sVr67RZ6mxvUeR43vvB9r2Sla9+Bwra5Ca4tfgl8Yah2t4jjHZ0JV/hZDE/JwNZFsHEX7GAL n3TED+4qdosaYhhnxHOEdOiGFWhEB5osxuctrmHtW83nqpakaa1viyeyXAuX/xStPlbyjp28Xxoj UKZnZNKAn7yQP9TgD1ke1IiNK18ls7e+bcUomE/84gfL160VnvCV9TtIg0j5dR6G3ZO5XJA7S8nL ZUZzV8VMWxP7GcUkRuxzEbtm5yLYzVlN5FM3vOFE/snOWsYynim9aExnukEzhjSnP8npTGdZ1Fu2 NKk1fWpUP8fThGy0pk1N6S2bOs+ppnWtF/NJ/56ay7s2yJ1jbWtgB1ssmwW1q7XM61//2tLCZnaz nS2UWeNZ2bCO9rOtfe1nj3rZosZ2t73tbFkf+9i7rva3zX1uGJN61Mhe96vR/W5453fW6962uON9 b3zbltf2pva+8/1vgMcyz//qlvW0A35whDty4OHudcId/vAnqrvhBYd4xS1uP4lfGtkX53jHSSfx cHPb4yMnOcNArm1tl1zlK4fVwMddbpbHXOZEIjjMZ04RqEznVDfnec/BMx3J6DznkvF50Y3OmKHr nOjWAfrRnf50rzSd6QbZ+c6hfnWsU13pSBq6daaOpKyHHeuRIbvWma70nAtd7Gs3epJO5faFAL3p Vmd73VWe9KVT3exl5zrd7f73i0td7XyXu9cBf3iWp/3rWt861w3feMRHPuGNJzvat054uEve276o Aec5r/mGdL3rZ9d75gVveNA72/O++HzqHQL50uOdIUIfveuZ3frOs972YH//O9iJXvnK/17tuwc2 6z9v/NbjPvJJx/vc8y54whM/2MbvfEGOX33QB//tl9d70OM+fOnT2vML0X3uUy96y0998Lxfv9/D r2nlV7/8kg++7+tf9bSD3/3vdzLuj6/78dM8xcs/77O/srs/1OO/TKM+5JO/+Vu+oDvA7fM6/cu/ /VPAGAPA3Ls+69sKBCgIBAjBD5Q55qs9t5O6s6M8DIQ/8ys/DUSKDxzBGojBmENB4Su9vkPB01tB FnTBFow/opBBGgRBEky/7is80pM9Hjy1+Vu9pAjBhYBCEJTClaO9CIzA+jM73ltCFrQ+IAzChhjB GBxCkuO735s9HNRBG+RC/0wLQA+UQSIUwRkUw5JzPvdzPu+TO9hjw3OTQjiEQjkkQ4/TP/YLve7D QT68NzEUQUacQoOAw45rPgqcPT00wERURDmcwzGcwUeExEHEwhNUQfUrwEtEt03kRCH8Q08cOeCz wC3EwwssxW7bRECcQkBcRfsBAAAAD130Du4rPKjQxVYEP1k0RUf0wyhsxOfQRWbcRYPoxe+ARolo RrHoxWaUxoK4xmfUxhrARmzMRm2cB2GMinGERvRbw2L0NiGMwk5kRFxkDGn8Rl50xomQR66Axnik x3zsRnrkR3/cxoYwR2t0RnMUx13kPsZ4hxp4B4ZcyHTUr0wkwjCUyObwRv+CvEhq5Md8ZEZwBMhr 1EdurEeM5EhwJEmKwMd+HEiHsEdd9IEa8AEfkMd8NEh/bLperD2xaEiFLIidNIiefMjbokM/FMR3 hMeUvMh/9EeUTEqV7EiSbMqknEaMdMp+zIh99Miq7MiA3EWYjEqt5EeDNEewu0nfUwyFZEi05Mmf BErQEkSGUEbvsEiqxEqG2Ee7BEmmzMqt/Eqo1IirnMuV1MaY5MqXbEmYdMm81EgCDEa9/Aq0bEiG SMuGWMvFuIGFsEy2dJlFrMU/nMeFWMqrzMi7pEvA9MrA5MtdtEepBEjSzMi6TE3C/EfEHEzRZMb6 U02uOEvI5EmfVEvd3M3/zbgB4RzOzNTMWkxGBpFLpcTLz4RN0lzO58RN1hzNofhL6GTN1xzMw+TH 7fzK58TOxTjLhXjM8VxI4FQM4SyI9KwBzCxOholIGizKzfjLpuRI0MRLlHROwHzKxlzK0gTP5sRO +nROb4BJw1xKAwUAl5RJpAzQtPhJ3ZwICK1MzGxP9rRMC+VBeridoZzDBflIBwVRjQRJkwTR0ORG lrRP5kTRxvxHEd3G2mxGl1xQZkRMF83KAc1Jh/RJyRRPhxRPyKTMryDO9CxS9lTADTWIJGUed5RP KZHOxIDSsJBSifCGAu3KlzzMGcXSgthSoqDSrUjLCB3T3mSM9WSI4TxT/+nbUDatgTa1NjD9ijiV 0xZ9CCutAW/o0iztShudzT61UausU6ToUck0T/I0zx0NUrGoUIM40wxdUyV1U3qY1L6y0jyNUtcs nTi9Uyt1yQI1CC39Uy6d0UB90EPVSd5M1PH00UINCws10iMlviVl00ltU0otpkvlVDzN00sNsV69 0ix9yT0lVT71UvCY0EJ9zN3cSfI8T65w1AuNVjVNvSUtCEpNUlrFVTwtiF41iG4lsF/t1MPMUx8g V1DV0z49VjFdVlVN1cj00UUl0mmFVGuNVEmtVjji1V3NVUvd1lz11V3t0nL9VHMNVj5dkLXsyWRV VSDVSSF9VvXMUAx9v/9avdZbrVg7eoZn8IaN3VZv5dZu1Vf94omCDdhOFdiF6E5AbY6G5VHeBM6G DVJ49QoMNdIKfVTQe1NJrVdbjSOOfYYaANqg9diA9VeRlUr+DNAXXVoTvcsX3coYLVGp5c+QpAiS 3VOeyFqUPcysPYyc6FqvbQiwLQiwPYyyDVug0Nqz3QfgzFq0PIx3AFuFDFu6/Qm0lYg0bdRopVg3 7Vsl1dk42tiNtdKO3dePPdyHoM7S9M8bhVrwlFLFzdH/FIqy9QGShUmvtdHDcEmeWNm7JdugMFsF YYjPXQi4fVu2TdWGdNuFFF3zdF3QTdvYJQrijNU1rdZsdSSNDVqOxdP/wQXafw1eot1L4l3cBm3c 12Rc0yxeqDzR03xe0s1aTu1czP2J2dzcrwXU0t3e0TXd7vVJnvjJ8P1RQ+3a2B3fr41bu9Xar53d ochb/sNYWs3WW10MeDCI+60BeMjfKdFYoNVYwvVfff1XbhVJ6L1O5E1gGD3e5X3N6FxRvVRNe+za S7XcfejUsO3KuuVS7nWI0nXfyQxfnQzbQzVf9VXf12VbrzXf9m1h99zZ+t1ZGU6M/N1f/d3fGq4T Ad5dXgXgov3WbwVQ76xPCF5gFUXgBnbQ61TOFK1aiWDfPCXZAqXe68UJzt0Hzf1eF/besZXdh0Bh 3SThIBVdFK7b81Xb/9DVYhpS1lOT3/n1W8Ww4YKwYRzG3yHxXwD2YY7l1wEG2eFVYkAeSJMc0aMk 3kyFXBYdZAUWYo1gYeptXyy1YK7FYi8W2/WFXQ9W4/Qt39R12fZV3/D12hMG5UtO4ytyWIV92B2r X4vF16/g3/ulYzuO5RxukN0N2t0V2jy9ZW+9U39N3AguZMYdZhwdSUAGZkMu5OWdU9kV3UlO2ex9 STN+CLTFZEuWiBMG30421NYt5U9OX1IG3Q9+oghNVGd1M9x1Za/g3xue4zpmCHbekD1eCMHF5Y7l V48NYiX2T2JGTe9ETWU2YAf2Z3+W4BZ13c21YGnGYkmu3krO5GZW4/9xBucULtOzRF80vujUdWT2 3eI1/s3yXFV0tti0kGU6xuFavuF3jufnwOdL3eE95lVd/ePAHGTXlEucbloYPeYDHmLY3Mj8vGm9 LNu0zdoZ7dyF7uiJFmc07mIQjl4RntvUZdbVxQmpLmW23clqVpClbp5UXldzDumDy+FYdgiUJuvw 2GUfFtr/Ndl8Nll9vq0PHlVS7RBURWWqzmtPVuVTIlOL5mYgZRhxaqGylmX9XYhaZueUBg+27tjC Ldy3LuC4LpSPZGbNWOruFFa79mtuRtQfTVi5CmzVZVjP3lFvuaVbeh9YRuyyRmyVnmWW7gx9vWUf lmzbnmlMMwfd3m3/cyCSMfVrsAZsQ+XrODrV0p5MZlXLWPGgyukj7DlpWj7sdn7two5t78Dt/+Vh Xz5aP74y3S6I3q6Th4XZdv3quCpn07ZoCJ1ZQmnulvqecbqdGj5p6l5t+2aQfuVUAd7uX97uyd4x 3q6B8A5vDnFY8n1ZkP7s9I4lmXVXd23WA4cVMfoi52ad6G7t6rbv1nZn694MXzZcS/3w/P5lmg4x Agfv7xbw3S7wl/VN5TZwkbYohX3wCP9NkCbuIfGiHuqh1Cadwlbp6p5uiaBlOb7uj8Vtl/bvEscw 3l7xAQdvFs/rHj1u9JZxA7fxdQXt5MbxBvGeTRKg+I6clF7sIC/y/zo+65YO4n59a/9ecwAXcDhv cjiP8ylR1HJm13N2pFZN78BO7r3m8gVx7x/SHfdmHlh+Z3i+cJNG6Tn+DnwG2ZAtWob4cCY3iO9e cRW39DlncfWOcU8Obd/ccuUOa6oelDACo5YKn+aZ7x9fafw188Mu8te+bj72YwLeV+6u9Et/8t7G 9BPfkGZdWOEGdCtiVTtHVQVvcdGuk/BBbbHRcfmOZzTH8FhX7LOW9eZY81/F9RFHXF1H8V33dU0f kmSV2VI/71Evd3Nu2Qhvb0J39g9yKaC5drLOcOmedbTGds+g9CMvYH/ProMK84UY8F+H8l6v8ytf 9r76bb2OTIaF8P/21qTmJvQK/xp6X/TpPnQM1/gO54wQ51TcBnFJ1ymmQvU/ynQoR/FMJ/hNlxJk J3Y9Z9fhdvCYLfU855BMavZUF3iLT3Qgt+NGv/egF/qOfwg3/EKKAHmi7faj/e9JYilozyQVD/CU n/qUT/GRm1m8ZuPh9nOYD3T4PvUet3DXFvr6ZvWhn/WicELsOwo37+Pu1va4Yu6TB6J46PWDX/mp z3us57j1VtYpx/E9n5Jweu+dj50fb2dY33g5VnTD1gjk80GkJwrh9fePd/o4Guxnh3p/Yfk43/Vx V7lzRnbPPk8sF5UvZ4hBN3TFf/V8d2d4LnuiSL7ra8CikGnJ1tX/cMV8KxL0sE99H/oXvH+Igy/4 jpvxmcdzZ2VvU++jiR/70hlzIYf9szfptJ8IJ6Q+8kOKcF2I7h/5p0/195Z6Ho8Zc7h7vCf4vkd5 0U/2lvXz3rz53nEfh8gl1DZ56mHpVl9tIS96igAIXzUEChxI0FfBgjUWMmzocKE3ht4mTqxR8WLE hxo3cuzo8SPIkCI5xitZoyTKeA5Nnjyp0lxDczBrzFxYU+bInDp3cpzH8yfQoEJrvGP4ruhRokoX Hm3KtKhSpEN1yqsh7+rCq1pJqnS5UGXXqWLHboRXAx7ah2kbmnWIdm3btR4JDmRIty7enxH3QrTI lyzgwEG7hmWI//Kr4cImZ8Jk7Jix4MgifUqubFmj06dGoW6EipTz5YZbq1bNanWjSbCqC4duDbLt wrdnZ5+Fbfb2W7g579o1iHAo37+uh1tm+ZUwYq+pj8tsTpMhzuY1iUueZ72GT8rUt+fk/FlzVKlM wYO+rJU0VtKm12skzJo7dduz4caVH7t2btgfESb8vZD/QfAJOGB7x4WlmoEJHkdTYw7d1CCBZF23 UHYTRnjheONlthSH34nnGnqnZbUVhiWWxdZtDKW14n0pxkVbSPwZ9N9DCpl442VgIXYggjqi5pVN kDGII0gAANATQ9Zlhx2RBILm2VPfYRhiaVZhZZp6TRIoW4v0xf8mV5e1icRbXf71NqCRaabZkJFs qnmkm2vW8GabdLbpEJ0L5amnnHOqyeebDamkZjxpgnVnSi61yVJXd/rJUJ152vkon0X+2ZGjfmaa 6UPaMemplvB5llRTpRL1JJTDhWglq6WlV2UN3ywka6jD6Ycifi6KqSKMINkIoIwA5iUgp5VCCiel yUbKUbHHOusotMhGm+xKigJQkqGDHomgptsmpqy0RxY7LpzNPjTtRn2Se2lDSjKJ3ZK1cpfUqad+ NiqpG7aGXpWwtvpqQ9/QKu9lL6rIJUe4GRyjf781PKONxCJ7LLqUNmsutXiGC66zGRv7EEtGaivy o6xpy6hJd17/uqzG54o7sccca7QyzN165C5loBJM3YebeWgUcf2KuN55/X5TlawCC7yzZSzummuv CIP5U7A0YrjuxsZeXHPHM29cscpcm5ta2Is6ilyh17aEWNnlvuyyy+R63bWbFgdqM5JJxsv0dqTa q2G+5YHIL0NXWim0PEsnnTTfkhm8IuS48fr0bmUOa/WFnIatddYa3/0x3JVu3vHWn7eU9kmRpr2c S6j72OjLLE86O8Zzg875x2V/5O67jfOMb4b2Cr7viIWLqB7Ascaq+MC+C1ZfR7fmBlRCZSpkJoGa uw3opm6zbLvXNPeJe+jVkr4tuzpiiyxr4m/fsudcp9s5xX+C/z1+Tzo771qqUvnNndBaxarCZSlx sFLa/iIjG/1ITnKU20n1sHc5NMFsT6Oj1vfKp0HycbBuIFsbyUSWtkW5J3XbSgns2nY7j2UQU/QL 3f1ilkAi+Y9AqzpNlownmispboaV0U2LHjiU6+ElYhHqXt1iKDr5yZCFnYvh2FoSQrVpyjiGIdna 6se9FcoNg2LLWhehyEQfkjEyVxrN4Q6HPBwub3FOihK9tvQltwhRLAG6ERKfNbFo2W9PK6Qb6CLF x7aNb30iQ5ShEkQnRtFtkGuiXdfM9aYDHMCJ9fMe/sqoycq4ij1YKiDSDBehUdUrPFuyzyZT2Ror Jud0yMmij/+ySKBKVnIhlPxJ7VSpy6GkZ4e9NB4aGdI8ngHOO97ZJTKTuRLF9Cg1zgTZe4hTyxrc 8iHTHEkulanNkIBSjWkUYBuHyb9SAQ9o9RreNtO5P+PEUlCy3FErh1NNWlKzntSk5DXVqc/QwCqA D/HXvEwZvAzFkUP7PCjfUMi6wyzIQKxszS1ric95ShSfCL2oWG5oOH9tdED06h9I7zVQjJIUQyZj ZOtOl5xXSpMh9LQoPe8p05LSNChnvOnQAEpMU/nvmFKKSk2DGqF2tq6EC4plNCtTTVvW85oRZao9 hSrVjVBpgKIc4Cg1tJT/+a2gU/2qa3rkUHgKiqFJDc1EKTr/04bEFKxuJdq/wKlT4vRsMw0xFVAN +ta9VgZlKX3mWbkzzXwOVq18/Wo/gYnVufJvqwXV11aLedjJiiVRsnzmZbfzUls+1aUulShlwfoq gI2WsaHR14b657N8mTO0rtUJStfWzodKM6JpZWpFo2rR10r1jEQzLV1L+aGPstareuUtckMSW8sG FqIynShum7pbtia3pqXFqqiGe9e7Qkk83UVndcNbVrNyK6Umeupgo8rZpYoXoyQC7nC6Wkqg8dQp Ij1ue/O7UoVadkBLta1n17vbtuq3wEPB10cjq9We3gu8Bq4uO5vb0tyuV7qFvWc+H6zh7kQJqMVF VVfjCNkN/5PYvwBWr1OhCtMSszgkNXxIzzwkUu22uMb+tSZuV1xhG/MYxi+OsTHt292R9rjIkQGt hdnaWSVn2MjD8asyZ+zY7eJVeN4di4xm5OQiv7TLtGTvTDe75dCwzjBA2uUx//YzvAZ5vkN0GI0k OGYNo7epOaYwgJs858igjKiqtK9DyCnfc3rVwTGyi7DOZMQ9F/jLAV5xZ8HMaMmw08wKSiU5FSxQ 7YIUv4f+Feb+s+hJl/jLFXX0PEktmNW4s79/1jRB51ueQtf10L4JEF3uqOoHsxe66s3xr3ctlMOg tM+0TaBP4fg3g6ZZxIbeyB37Y6aDyFnYyC0sdKdr6udae/8qsVXpjlitSePWGtBP6jBPpk2m6uWl 2t0OLYE/+1lHvxswRkVbmSXMtASrmcrLHun/xmQ5603baqOut2vBnNZsbxvhQCH2X7/Van3v7L78 RjeIZVy5giNa1A1jt8OFeotb1GDkHIkpyqOL4ZAPRrYSf+eZx90hWRNXxML1dEdy7XGIXU/XLK/p yE1e8qCT3CH/XeuA9UzqBCSgBk3/ySsjjEIzU5xgFw+Ps/8NvGfXKIIaISKcfx5UoZs86EPXSJ6f O11rN53pg5m6e8StvmM7r4bEhWPNI8t1h3xc1L3BNbUnKHZ1kpzoRS884tFu54UrfdJPdzrT3b4T s6p0NXP/j6cPU4WZDgm5uNTDXNh9w/ODDx6Zhi/60BOP+o2IOeRth/zjYctfqkO8qFWvuI+xPmu7 770h/RG9xyMGrJ13xBo1sIbxS5/AwzfE7KtnvvI18vqFtD32sD2dM8DiDGdEnKyYbrCVz81a6un8 YdQGe+g1kvzjGx/50W/c6hfi/PgL/f0Pif3Tra9cy2Y/+86cOsyNm6CR281p3m543a2BWt8lmkO0 H/shn/utn/3JC+KhHtkVXvNNYENEXvXp30hon/+dRP/VwPbFQ/a5007cQQ2oYJMMmWPN2nalG6L1 HMQQn+8J3vExBASyHw9qYK2UHQYyROIJoQ9SH0N0oAd6/wR5+Z8Jbl9ihGAAgsQdTOEKtqAxTVmh CUXYqRvf7RwRNYQDhuED5iAZFiGGYOAF1l/JyV/8maG3maBhMOFCcB8JymEUegQLriAVqmAelsi5 bVpefZ75ZZnlMKCWNWAE8uAOOmAZuuGAoKHqlZ38rWEbaiAHGuHbWZ4JHsgcYl5HTCEo6iEL7iEN ZQYp4RzVOAwhShDIGVHyQSAjrp8EOuKFqGHqTSIQoqEbPl4S7l8dluD2OSH3cR8ceiJHgOIoLkQe 9mGopFllrKIh/h0hlmH7VeMrviItnmHqnR4lQqItZiNPECNKlGBJnGBRieBPjCIp6mGE0END0IM7 EgecRf+bIfocGC7ELOYgNo4hOD6i6uHiGgakQPbjTgTjCTZhfw0jS0mhMlJhQybjgLijREpkDcCj PNYgDfrdrT1EPmIjLDYiSBIMP4zkSDoESfIDQ5wkStbASqakSbYkSx6WJDbfNwphTRIkSAwjCZbj TrqEQiYHHYoEMjokRDokpXELPFpkUk4kRS5EPD7jFtIgb9gjPupjVYohI1Zl48BkS3JlTDYESsLk V6akV/KVBRLh4THfTeKkSAxjCSZGOY5gMNZhSOzhUBLlQx5lYiylRTplRTJEPCqlZQAL9qhi1Rzi A8biPoJhBOajvIhlWGqEWC4EZJrkWK7kSVKmS2omS5b/5GbukhqmpVqeHVuGIwnS5TiGIBzSoU4K JTs2BEQq46rBHD3EQ23+JWAypVM2JVR+XZy12+UkYmJaJT66n1ZupWVO5liCpWUyZ1cuZ2RyZkw+ p3TqUv2l5UA+X2n+RFDSIbcUozC6Jh/yoWxWoXnaG7jtZlJ2xVLuJm4+ZV9ehioGX65NYw9eZXHy oyw6T2UqZ2eSZHUu51diJnRqZmQSKEZVYDdC30BuZ0jopDA6IUNAaCcG5UeMZ0O+ZhUaZWVV3lKq BF/C50S6p18OpsHNoPVshHEq5n3ep3HyTX+SpXJG52dK54GqpIFOp4wi1D8GIU066EjM5YRCKGt2 J08Y/yV5PiQzDgUnViRFhqiT/iVvvmNSDuaiRRDpjeEOKiI16qDvxChzPgSNBig/PN2BSqaOTqZ/ giYbauckAil30qWQ/iKddmIKOoRd8hmxwaNtKuVtBuZ7RmmgusbvBUuWhqFHaqlw8meYFmhlXqaY St5IJkBZQqqN1qjpCaQu2mTj6E+JzaWEuuVp1ql4YuiSBobltYRg1iafNiWgPmWJwqqJ/iZIwKKt kuGL4ueXZiZY8iqO7qhDUCr1USpmAuhncqVnBqgyieaC+k7OVIiGCWl4UuiEjuqdFiWHVhYrWaRt VmSfAia4+qWsCmqoyOJi6uC50lTkOR3kYaLb9SJYqf+l2TnrhPBOqMxrJZqIhdLlqLamhA5Fkp7q sO0le7pEYPoIrFYpuI5rk+znNVrlIu6PSk4sxVasxV4sxmYsr6YTgzorhXwKvPSOiQxhvurrkM7h tLZmOmLoeeqpavxpwYKFn+YmfL7jzjTmPSqmY17Uuw5r/sEeu8Jpu9Sr3uBIEI5myZYIqIJqQ+yr UIQinxEsn4Io1VapiJYo1jJsrbyore4sRk3fz8Ke5LWr0OqMp+xNiYRmBjbJv/IryqqsvCRKSrCq bZYEn5JrlCpsrDbOrTqsVHHguuYf2MIrTipJheSMyEYI2TnE8yUtgYSqQ0Cu74BoXx5sn7KniFrt uGr/7dbmZ64K1btK3rpuICYKLbwsyXXYa9pC4ps2KI74q9Ouk0R2K1/KbGBabda2J+dqya2CFeAG q/5dIkccwiGoEvEyzfEORb0+a5JwR/KiJadiJ8k9r5ZEaOwyDXI8KW7areYO6nu257sRr/gWL0NQ 70OML/EKrxG+3tiW7vmS7/CK71SYb2DQL0+gL/zWgP2WL/nuL/++b/7K782ErPnqD/7Wb/5eJy4C YcnZ7wEvhP+ShQPD7/MeL/5acAUX7wXr7wNzsABzcEOYbwaLr8Ky6lOC6EZkbnzu7phlcEhQb/L2 bNiKbvu+70dEcE7g8FDo8AtTcP6KBA7T7wd78M1o/wfzdoQLS/APE2EGQiLxxh8M9+8SC8YE/y8E BzAW+7ANV/EVW7EIJ2/yxgPxmrDdfuuIBqr2dm+3RXEXe7D80i/Toe8VRx4Gjy//2rFHgLEcX/EQ a4QQ47ELd7AcCzIeu7EfY3EbP3AdL7IWOwQgv3Ejjy9lEK917HEII7IbS3Eia7Al67H8Tu/4Bh3+ QvEUD/IjC7AlO/IpfzEfa7IVt3Ibe/ESszIsXzL9inHxUq47yjE9dPL49nLysnALYzIG/6/5Nl0M Y/DT1TEyc/Irxy8fdzEPx/Ihg7A067E13/E1G7MrX7I3g3ASY7MNZ/MdS3ExbzMIzwMlUzI0c7M7 W/9zHW8yCI/cE5PmEx8vKJPyRogzOCcxOVfzP28yP5PzI39zQNOyIb+zKgsmLocFMDvpGAMzJ3Oy MA/zN58zPKNvHB9C2xXzRoNwM2ezDvMzRt/wFCs0Rpe0SDszOu8zMbN0RlOzLG8xJK+0NWuHSquy N4fzBtt0P8sfPgsdBhfeBBcyScO0T7fz/i7yP7NxSmexHSM0QXezG7sj98GjM4yxk74D8b4DPOrx V0txfAobG/+0TG/zR6fvHAdyIyNxN+d0O9tyTbe0SrP1HheyQcc0T8eyIs/yRDszTx+vT6zzSVPz U7dyQctzUNfzAddzQI/zUU91KpfzQMt1LT+zJ+f/Mi7ntUyPsA9PdlYfwkRu3xg7Qzwe7y4fQlFo dWWT9Usn9U5zdDMnQDJzNFs/s0vzNVLn8Q/fNl3vtm/ntk7P9F7HtDwPNzb7s2IX9lT79AW/tSYn 7y3c8yEUHXUDdXXz9nGb9VkPt3EDsDn3NiLjMjYfxh97N17jNgker2mb9kMvJWoD81FENGsXb0U7 mT+f81yvNUc7Xfp6sk0D+GN/d05zsSyz9H7XtRb79nnrdka7sjijsl8vdzRH+G6jN3TPtINz91AT MT73cXMTOFIrt0B3d0KndxSDhfhudmIYeHFfdPFyH/HK+CGY9ozPIVeLdkXSt32jdkSHbypntpAX /+9Gy2+Riy9tR/Jdl3KCH8I5ZHJ39/UqHzaUB7ZnHzJeD7lu/3VrN7iUKzmIdzCUa7hzhzf5Trcc o3l6I3YWj/kXgziba/M4n/XzsriH46+dq/IHl7UVh7b4XjV7S/QY57j80kOOp/YV3zfL4XDPkm7Y AjFza8STnwOlV7qlI9Q0i9wFUiJpalMJ8Ugrqc8dCgXsWrX2FgU9uLc7QoWsCqYb6vAlCq77gkSm L0Sl18CtT/qTY3qkf5WCKrDjahIjsVJ/iZtYsGadYrWTKvuyw6NXl7DeFuFkc4ToBmtl7LqtUzpD 5Dq2J9O0hxa+Op/rbpJiVN5lvY55DYVBNu2yV/9ke6f6u6M6qqewooOjDLvGpGe7tts6rpvuVBxt OnEiZs2d3DEUqRvkvmrvMFq1u7v6Gde7vwfGrff7pU98xP97pytTubMaxDWpwat75IqqlGK1qleo e3/vxQ+Irm97v+N6t6e8azGTK53ZQjnU7T2EkYqqhW4fvLd7e7d7zWpgrUcItu96vl86xdN6rwu3 eAXx0rv0UlN149T6Qhq7yaS7pRVkziP7aS68hJo6z9Ns6REy36z8vhf9tu+7du/E0LdGa7s1cXBx 25s4me/M29/ybJXXOea2nWf6uhtp07qlqTupabt7UEI8o724vOR70pt90b880+fw08NHrc99UMj/ /eR7t3BbvoC8PUkcFSxhVqgTW563ZXcifHhWqKAm5dfj5tgrOWJTdjnL/pxnNu2rMqUT75PL8Tno Pq4zMngLeewb95JL+J4Xf9TbNfAH/5jrufAPfyb79XN/dlEbNYRL//FL+HGv+fCLOWWTvSGLmxw3 NAeXBPqqBPAzMvXfeHiiL43/+fuPsfFnv5Z/N4vtNYmbNZUbtH7D9B8DxLkahw6dI1hD4EGCAg0e GniwRkSJDx0+pCgRokWFFTNurDgx4kaMDjt+HBmSY0qUJ0FadPly5MeSLUWupJlS5cybNl1CzBhz 5UyfOVWCFDq0ZU+kGovGi7fy6cF4BAlGrfi0/8bUQ06PEj1561YNsAedRXRG9ixOimkvwgyKdGlS uXPp1rV7F29evXt11nTL1KhMkzz9Eh6MkKrKhAUhNmw49+jEroJP/gz80q/lv0t1XsZ8+GfnypR3 fjZdum9RyZRTJ46bNDLP1YbfRnSa9anV3FUpbtWaVaJWrltrF38YVixK5GUJlmXL1mJa6JtJkk68 F3t27du5Y3fN+jvK673Fj59tc/z3ww0XPmS4cOE5x5pZAq7vcbVrt+EnU4XtHz2czDtPNNnUKy+z w5QaTT/UrFPtvuoaVE8w+mL7a8EAy3Mqt+EadOk327KqKkT77LuFoFucAWtFslR87rnmHnJGuv/W /LOxuxx13JFHuiysrrT9gPSRtNHsSq+ixy4MsrDJ6nvywsLq4gxCueLSLDTQwHuSpSWtVI1KJocM LDzPzjPxR9qExGo34nArDyUOgeMtyurCQtGhO5k75MU9aZQuxpSmS/C0AXs8FNFE70ozthu9ki3A IQlt6THEHFrMvYvooy1LI68cUylJJyWwqE//U/NM04YSVUFTC9Swrdc4LdJU6oyEFNYFpZJKTohC TEw3rEZ0SDjjaqIKLLH8VHEswfyErrlGR+1U0WqtRTTN3ioE0LwPyeQWQG3lekwgbeVjz1HIJhxs 3UhlLRNeQ2Oi1aNNNZVXyHDjxVdcdxX8DEn/XG006TV+28UVwS4FxI1NbYeDql2rgJwJz8TACmvF ilNMC0DpZqzxQ/7oTfXakk0+GeXs2kMoIvkQKpdlmFPe0d6Zbb4Z54m+2fmbmYUF6bbbRBQ6aBEZ fvOuO1HKmEaMJdKzBhrNito5qUlW+d+ctd6aa6xZjpkhlxn6umvvsi4b7bSx2zmintlGucO4g2az 4ZZ+Bs5ovJpllkVmk3sxaqrLmtq5q/k6W+3EFbe5MZdflpnsxb8MV/LKLW+J555r0PxkOYWtm8PQ bRM6uNLvlktjPpltOmOzkq1a6j8JD7zmRRG/HPfccxyb7HMd1x344C/nWWvSO7Q7tzdFn8jz/6ST fZpvPS9WenDZCx9c+Oy1Rxtmsbf/Hnyt2ebc7c6JTt5oOdNXHzj07ZperItXvF5ZFs2yevaqw9+f /0TDhrx/ARQgj8j3NriJDoHGWx4CR5c3utwJORPBGOsCZ7/AWS9wA9TgBjkYwNrN7IOJG9/m2lZC 8+HNc6H7WfPWhze9XOxvL0oWxmAoO4nADn8d1KG38rKpEHoNW7dL2w8N1C0j6mtANTtQv5gYsiQK UYQkdBvnUsbCFCJNhcE53V5mCL0a+k1pU6OaGHVYxlz1EIo9IqJe1si1HxrxVmga06ooxyVVbclY Amqj+HS2ucxR0XwrHFresri8vDwvghHh2//8wjjBC44xg2bs4KeQSEctaatUepxXwvRTSUtq8lvb ktC8JJSAhN0RSeAiUoTuGMd6rdJMhKoTeYRHPJAA0mQNo1vRSNe+0RHthYoUpiJnqKKosQh7N5Tk MjMkLYQx5VGyzCRQ0tWVM35JPPcSTwIcxc1DmFKOsYKQEkc2SyepK2B5bOVb9og2W+IykHfbpSGZ l7wt1gWRw1ydMUFSuIkkk5kbjFcc7ahOWnqpUI8KJ4Y8EyZv1uChDyVIAkwpTYWxsZx4XCjleBhO cz4ojWqbIjyriL7PNbB5dHMhFyPYyGM27XnVA2hAdwiedb3KoKnUKSt1JbKL/iedQ6noN73/OdSI evRBGGXlRyMUQouqszP8Gl7muFY0lN5TntlJJHKeR0zA0W+mNBWoRk/F0EmlE5sJNQ5Ps9XMaT7E qBCRqEZlNaWMunKOZMUmUw1qIrHqSJdaRCnQkJajRCYnfsrC4V8lyde69jWqolITXOhapUhpqKgR nShcD0LRia5KrQXlKVLxStClVnadqWVsjngp2NKZ7p5yMcdEZuvV+HG1i6sVa5mayFEs5RVKRyTY sTKpSsNoKagqKeqCvEkVcPr0uM/cV0k8KUoEZc2J1SXldjGpWx7NrX0pjNtK71Jbc8y2tolNLPy8 2173boeiEQEnRONrSvtKZL7gnK/22lmt//6+Vy4nFWTd8ILe80okvTVIb1cB3GAH04WiEZ5IfOWL 3whTuH//TZSGH8w8Dws2trKNCHoRrOAEdxjFKcbviiVs4QpXuMUvVvGMbxZiuxzYvLRtyYlp3GPd 2ne/9aXvhSGaFP36GMmVM3CCz9vkEZM4yVEOqH6BjOH9rhjLRL6ylLmsoxzqxclPJrF5D9xlM2/w vvW18pqPXOQix/jMcdZO7PaSYxMrGME8lvOet0dhIbuZyi5+MZDlu2U+H/qfsFNmWHV8Zzzfmcd6 RvSkK3dhOFv4yJnGNKU5TThFK3ouZc5ziR/t6E6fenFpBjR9swxjDMsY1XuW6f1iZ8MdN/8Zyno2 cKx5XbZXr7rQgWZxfln9615HWX+0zl9SygzlR+/a2ceW9szWHOxCW1vC1R7ytM38p5nSj9lPFnez lxxtbp/bWpnO75/9HOgWtxndPcZh9caIvZku2dG4HveI491vRan51b/+M6uvPXB/p5jetgYoo8st ajJL+uARh6+l2w1jI2MZ1oaWuIP9OWt6MxvX+G52qTdecu2oueDB9jOLi+1ml5scwB2ncwa/TNv0 OjnMeIY4zHl+cSFnO8jEvq9cjN1z3V4v4S2puZifzW9xGx3qEG41pomc8W2DRONRDyjS651MRud5 zE43t9bJTnCsD53Q8K46xsvO2I5fMIf/X3962KHd9rITesgxJvbZh511uzPz7VzPC87zrZdfROTw h//7sfd+bZU/fsLaXrzbIelPMIfcxKKui+JroHjPd57zk0f1ulmOdrSnXPR//bjVbF3gsdPlF7FH fOJlT/vOp57SpL866vPebr/j3owJl7uiYi/7208k9MCf9M/xbvo3m/33ypdkrVHG+eIbn/aJl0jy pX9moAPd4kJ/fvS7j+jQfx7xx9c+98sf5Sr/HNjxfzP52x9n7SP/+KAvvv7zX38uU/z0nm/8Jsz/ Ts34Zm/2rE8BQe/22K8AfSzbCK7i5O8BOW39sA/5FrD2ELACkczSWM7lqq7oOlDOau/+/9Yv/Uxw +w6QBJPM2LRs2+ivBaWMBVOwARkw+/KvBmcwxaqs5bZMBnmwx85vAzFw/xIQBXdQCHvQBwlwCSft +nTw+lRQCRfwCXss4K6w01jQ+viPC/EPA42OHuhBC8twmbLP9kzwC/dPDcuODMewBsjQDOdwf7DP DtHP9tSPDY8w6sbQD+Gw3/xAEOmQyxQQBbcP/zJQA7XuDd8wDs/NDyZiEAkxyaIwEafQBm/Q89gQ 6uTwEeUQEKctEiWREn2ME89PD/kPB7nPASWuEUERFgMxIkaxFGnMChFREe9wBe+v5xzxEePQF2NN EIexBiJxEGmxFlEs+VAxA3GwAdHP7v/8MCKkkbHAwRp7xBrBISkGMRuNcRaRUYCyMRm5gxczsSUs 8QTzUAwbcRqzURs90R3NSBx5ZB5Bwhjn0RvBUXLq8S74cRyzYwqTUP28EAxVsRepsR2t0Rf9kYMY kjscshj9QBz1EXcgUi4s8h/xAhM/zxKfURPVsQ+BcQzdEQ7jUR6vkR5R0h4johslghhzBiMfUiUz Ejt4sRwFshkZsP94LhYT8h1rICYDKCj1AiMnMiL1QqaWDjuGMjuYkiaTIh27kA85MAzdUCJKMhvp wSn3ZyvtAiIFsRtfsi4sT4yGrx9nEhvR8ikN7xxPURMNshx5MhSvEiivkSHdURsngh//hxIv87Iu 8RIk+lIt50Iw/ZIlTVIi9lIlxREwE/Mah1EiG/OGvO2CJPMwtRExW0Iw//IvMXMxC1Mv0bIv13Lz QCINDzAPj7AVXdEXHZEMLbMzJVMxDTMpCjMvQdMxN7MubNMvbTM3Q7M3ffMyc3M0La9wfJNGcLM2 RxM065E3f/MyR5M0TRMTPRIaObIqxXAaQfETYdM5P9MwY1IxLxI8b1M8Z/I7g1M9gZM4oZMzhzM6 Zc4ssvFPxDE5mXI2aTM91xM+37Mzp3MuprINq1IJtdMTPdE/+xM+Z5MunDI92ZMwRRMl/XEeGVRB 37NCJRQc8Kdq6NNqMpQ2GxQ91fJB/yEURANzMNfyEPVvRQMyLtcRQRGSQlVSHuQhG2vUQskzRFFU Nkd0R91zQTVUQUsUOkEUN7+MPjPIQx3URzUTPHk0SIUTQFfQGREQDfdwJ9fxF0USGGc0L2v0L3G0 SSP0R2MTMXN0OfVzQoU0QYk0SqNTMG0Ie5K0SFM0TSEUT700SpVzSpHQEDexLaMRGLl0UPVUHnJT TMHhUC8UStOUP9vUThMUQ9k0R/V0UvPS4/LHGebROU4UL9C0Py3VUwHUH/ICDwcSNXEvGC90Hhf1 RF01UiGyUsdURxtVVGn1Vs0TU+nM66jGPjvVGsvCQ88yPEn0SU10Tcu0Fv2hVJm1Bv9K1S46ElXT T/RWFUgvE1YVtQZs9Eb/U0SL1T/PlFZrNTrdcz/LdUiP9S9hRyVnjTOFNVgvUykblVHdlEhn9B+b 9Vmh9S5cdAOrFRAR9FrNtFUJNlIN1jOVE1SdVGH5VEqfM1SlVHCIEy/r8xrnlWITlmEzVlzVUzcJ kVmdVSL4tV83cgZlNTM5VlkzFjh7tFhXFmF5dDAbVjqvNU7hbuZi09481CxjU1LD9WNZtWZBVmSb VWT7tCUOVWm3NSJqdFEXtcvA7ZH0p1dnR3Ba71C6ckqh9Wh7Te/2x2mbdlud9mmhNmrh7n4msywn dtHIMmsPFmmfdWSPlmRz7+XYLnv/lBZql7ZszRbZKs/eaC1wjVPZrEVr19JZuTZxT23oCPDS8pZs 9zZsu431yChw07ZypzaSEOVwSdNoI6JrOS3N9g7vgodsJUJvxTbO7I31Zi5TWxdr43ZrPrduEa0J r+7dgjBtUldv/TZqKVM+yUiZaI76elZ2TeZzGZfiWgL+dHdxnlZ1V3dq5ZR4vY7r3PZ4Z7DxBvBu TRd1J+16I2nePG14cTZ7tTf82kx9wQdMmVbWQO3jMFd8AbdqUxJmz9drmy99Aa10/U9rrWdngzUp 2TZt621zdcQiOxd//y/vzg4AndfumNIazGKCWVdeE81d+6l87ZdMF3j0JJD5YhD+/8xwgmvAGib4 hD2uL2F3gGH3gHckgeHWg83sA4lO3ZzwCk/YhCMChctCh+/THZNNTnM2c9OyTBV4hmkM4PQ340aw BUvYhHU4inuYeHmWdVsXkgzXTpE4iXsQh2FwBCHYiPHUZ8n4QVO2ZU0SNstYZR1VXX82Tz9Wh1H4 hFM4cOwTg4EVU4H2Ze/SMu9Vhrv4/253Ap1QjMeYj2t2VodWZnmzPF12aB82WXfzkd0Riul4h5Wp HqkvNy02Xi9VkWk2Xe9XkF0wAt1t/iCPa0YVkF+2Pb3SSHVVV83VSGl5kuE4jq3xhC0ZhXe4jnlY Xj+NMpeUlcszYifZUkuZz4TN7P8ETQK7xlNzNZc/dVwZk1LHVJpx2ZZL2BqysZeB+ZetAYjjV3zt EzBHdThz1Y9JWZkhUMuWd/cEcJVd1lZxNZDR1JrVdJbrVJLReGPhc4K9eSLomJsDOl69LWfzOZ/h lDkhdo21uZ2l7J35F+NWDprpGVldmVHJdZQlFZ1jOZT9mV69GYXFEZNL2BmkeF3bNoA3tKFleTMd maH/OaIP7f2ad3QPmXMxmp+nmVjN2C6vWaPPU6RzuY67+RpVmqBpxKA3tOsKeFPV2DMHlqpZll5r es9WbnndTad3elwv1adhWaPTWagzWqzv90HruB7nGJijpqn/SXiBOFnf+Ko3lov/sXrG1i13nVlt UraVZbmqaRpS95mPw/owW/anh1OH/bGXCfpdwQqhG/OPJVRo3xSvRfeLV+1xL1pDI1mUE7ujYza0 EbaPQZukL/OkpXiXj1R4R5uhpRo3a3mjtecAauAAarvf4FBg4+zdXq6rSwZlHfKzxRqo+1ifyZhg 67qDUTuK55Gtv9k2sXZOv/q1G1ldYXt/btu2bxu3py1gpZEdeRvlGve3FeWuOwiJT3qgo9iXvxmD rZbTapu75xu3uzvWWpMa55KGha68r6Woveu/70Kpf7mtL7nf5Fu+bVsitJvbenJQuVO84W0fA/mv zlu121oi5hiK443BEXy76xvV/1rzEz8xvLXwvBuSwuvCvTOcm2EuwRN8wRl80vL7D+lyIqz1sv/q kltcww88Il58u3/8x0Ec0WLUNSH8F/U7x3XLwDfc3zzcvrlbyKf80GLxFb/7u5ccwI46kw/OvhUc zBFcymVczrjzQPF7S7W8wRpb4oA8yju8vr98z9jxDx18O5VczfN8LuKcvmMcyMG8zGt8ULfUNQld zw+9LsQ8yMMc0Kl8zpGcxG28xHcb0Svd0aFcu2FczsvcxpP8wQ80zS1d1LvbwyfizfmszrfzwQdd 0Add1CudzPk8KaQc1W88zUMR16dR15fv1ZGs1D9cyPu81l2d1e/czCldzlC51/9RTNFjvcMbfc5X 3cyNHdkj3Pf6e9kVBXIAyFpIHdpBnMyrPGDpMkapvdo9sOXkOdvVZmwc51xQJs6HXMHBvch1ncZH nNjBO9lBOO2wfd23493LRWzCxmSefcwVndJ2u9DxXeHFm/eC7N+15t1bxndaxuJPRsyJPMTHfdfr PMtt2nGfOeJxxt0pvne852bi/dQmnVBZHdJpON0hvntH/mRkpt0vnnfgHdpDnEunndw/3vuoLOj8 neaxo3smguB/pwXBG8vLPdSTfeDGu+hTZuJPPmYkQukrMBiZXtKffpAdV6thzf98oQbIvuw7jHcq /nGyngdB3elBfZlHl3mbWfr/yN4X7v7uzz7vHyzgQaLdBT7n2x4WdZvYsxr6UrkAzT4i8L7s7V7v FV+3vEftt/1xDm0eauDyLYfjcTyr13ftiD7eFN/uHf/s9X7x26vi/wfr3b3qk+zyM18i5iHzX79y dPvcOz/q5R74Rh/yG5/xS3/vUZ9S+h7wW9/HZD8iYB/zk3/5S1HoVW6z/473B/H3JyL4T7/3A4r1 ix/ru7/LZP/1Zx/zaR/5nd/xLG73/YDs9fHu1V8i8B7yr1+suiftX8bkI2fGwL/5Yb/8mX/8AaKG wIEECxo8iDChwoUMGzp8CDGixIkFE9SweDEjxY0cO3r8CBKhLz81Rvo66avk/0g/JhemDAkzpsJz NGnWqHmT4LmcPGX6/AlxXg2hQwnOO0r0aNGlQJs6fQqVokWMUatavcrQD0mWJbWe3FpDa8mxKgu+ xIoW4c6eN222FYgzrVyKQpEqTVp3KNGie+f6/Qs4sODBH7WCJRtW7FaSA08KfHmWcNWdbgeurUl5 reTNA+/mrauUad13896944w6terVrCOyXPmSK0vDW02mROn4dmuobim/3Q049NK9xAV+Jo0UuPLl zJtHve34tdfEAknmhqzbsXOPmTFf1qx5O1TQxvXyRUj+qGnT4tu7f9+esWGCXutHTxwZO0r4FH33 rsyfU3cZJ1xnBpZ3Wg2nJf8YYIMOPvjXYreJ9RVjK4nV1Vj7lRUZhAyBx5aHMvVV3Gd4kUYgiuwx KGKLLr5IkXzV0RbWhfPNpttjGuYIY0Ig9gjTZ3rlReCAQyo41HpIAslkkz3W95h02b2WmFcjIZZb WU5u+ZSQBdpVml2mjTYQi1yeieZ2tNGoG45r4mfdjh2mSWdHX5pnInkM7kUae3X+Cehq1mmX0mK1 TYclQdfNGWij6JFo3oFGmYecguqZ6WimmmIFFlc1RhcnWYxhuShg3hB06qapDWikaMSduKSqss7a lGErUXeljfLVtiiPc3lzKrDB0ioZaMklxVd6SaI4JKbEPgstRNOZVN98n87/hu11O+qYlrADpQps DalGi1arQg5J4oJgXkpuu+4uhKGttKGEKLbcQsZtt+MO6+247453Hp7loYuUuqcJ1ee/Ci8cb5TS hWqthdo1xihU/n4rULDeLtwlgZEOJ6lnyXFMsruy2Yprrl+RhRt0fw2LsbjghluyR/LcLE8NN+tM XpHrjpwUewXWTDStNFobVtJXIqplYPvK7O/FRVO0s84585znwMIZeWxfU3/daJxHU6nrrYQS6pfG MdNMM9gM5Xx11QNdbVdCxpqIrtt6B3qjSrZWuOZ+PG6IVtRsiysz4nsftHPjcMdttc8FreuqwItf fuaa1t4a8WsuN61vuDCD/5s45gjJLdDVVsM9T85di1zkcF6bTvuTEmLot9KDNsa7qYdrPHPtBMGt c+pyEz+UPHiLJilTPx1wQA3RRy989X7Nhl+WSKMN+q8Zf9uv2sLjjHzq5j9+s5dfsvrU9AZRb338 aNlW4WPa4ouvYKR/Lz/6kUdOPpwVTy/KKw+RDDi0kFAPetKDHgPl5xcGOYtooMKV/S7IIadBDWPh kxrmVAdAx6Fudap73Z1k4kCBwG8gDHwgBK8iwb1NTEMYvCB0KnaVp0FtdLR73NxA+L/jDbB1R8KT Z4ACvwW6j4UrfKFTVhSrxWVHTqQiHGF0qLge/tB45hvg8AboupA1D4UNbP/hAlXYQCfCMIqYu59K eoWa/X3Pg3oTYeO6+EP/rc58oZldVM7YwjI2UY0wSZAhJyhFDGaJNW0rnRbBeEcBSlKABSmfVZaY Rull0oGDJGRI1rOiGFbPZTi8IuIa2T8fRlJ1VVPlCKHiQk0qcXqc1KQnfXJIQ95yl6iBHCuL58rz BZGLckmiLZN4Rl5+BJQCWRCSEKnMaFbljluMGyW3WE3IYWWJtNzkAzspTYg4k5nNDKc50RJAYjLO l14EpiXb101ZcjOQtjynRPxEkFDac59QQR4QgwhC9Flzj5dMIS2RaUZw8pMhSlIQNBcKUZuhzofA 9KIdAdpOeGISjfVkYkT/xdnQcrLxoySdSCv3GMkvEi+lf+mm++Ipy5IytJmgdKZMbyqRiQrUl9oc aECvAlOPzhKnEfETPomKVIXo1J0UXaklKfnP9pWRIAlVoUKT6tCQHhWrXB2eHVsZVYtCNaxSPSYa X3rVrpJzpF1FiDXeao2FinBuBgmg/07qlxXO86VtTYgu+8qQtxIkrvscYTp7ykqf5tWqtUQoYB/b kbhKFq5y3ak725lYIS6Wo1WFrDn9UQPQghYqgq0BXAmrGgQMRLV/mmtAVYlH45H1kiysZ1o9+0J/ 6LYgo3UKak1L2N8SBgHELW4NWHumV34VpZV8JWCUiNvPipYguwUKZU1r/xDhDle13K3TRfOYUaY6 N7rk3chop3ve6vrkt8EViHb/wl3kCiS+dCofT1Xqz/GWd78PUa9AdNtb/w7kGQR+BkcES9ngvncu rO1ufImbJrD+85cTni1/L6yQ6YZ2IOfdcFMS7N7SBqbB86XvfCPsT0gmlq76xbCLD9Lb/264wx4e sIFrcGOKSBa4PF6wXOQL4QZD2LteJR94K2rhFytZxgD28G5pjOMbG5jAUdZxj90rmeIO+cHHbZQ2 VQrJJYs5ITQOsIwNIuUo59jK2OVMd7vc5SDLl8hFpuv/xoxngzw5tE1uMpqpLBAqr3ki101tnIe8 KSP/Ms+MhjF6RftkAR/jONCBBrSIuAxnYlGz0ZzW8575/OmCWBpGWu40fwMCADs= ------=_NextPart_000_000F_01C71E97.1DB20750-- From sip-bounces@ietf.org Tue Dec 12 22:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKaE-0000Th-DE; Tue, 12 Dec 2006 22:15:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKaC-0000TQ-MV for sip@ietf.org; Tue, 12 Dec 2006 22:15:00 -0500 Received: from mail.zte.ro ([202.103.147.155] helo=mx4.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuKa5-0004mL-Tu for sip@ietf.org; Tue, 12 Dec 2006 22:15:00 -0500 Received: from [10.30.3.18] by 10.30.1.243 with StormMail ESMTP id 75876.1112621526; Wed, 13 Dec 2006 12:29:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id kBD3Svxb085324 for ; Wed, 13 Dec 2006 11:28:57 +0800 (CST) (envelope-from zhang.lu2@zte.com.cn) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: zhang.lu2@zte.com.cn Date: Wed, 13 Dec 2006 11:13:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-12-13 11:14:41, Serialize complete at 2006-12-13 11:14:41 X-MAIL: mse1.zte.com.cn kBD3Svxb085324 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: shen.chengnian@zte.com.cn, ling.wenjie@zte.com.cn, shi.hao2@zte.com.cn Subject: [Sip] Help: "About multiple early-session sdp body in a request" 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="===============0645926029==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0645926029== Content-Type: multipart/related; boundary="=_related 0011D0B748257243_=" This is a multipart message in MIME format. --=_related 0011D0B748257243_= Content-Type: multipart/alternative; boundary="=_alternative 0011D0BA48257243_=" --=_alternative 0011D0BA48257243_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBTaXAgR3JvdXAsDQoNCiAgICAgVGhlcmUgZW5jb3VudGVycyBzb21lIHF1ZXN0aW9ucyB3 aGVuIEkgcmVhZCBSRkMgMzk1OSBhbmQgUkZDIDM5NjAgDQp3aGljaCByZWZlciB0byB0aGUgRWFy bHktU2Vzc2lvbiAsIHRoYXQgaXMNCiANCiAgICAgICAxLiAiSXMgaXQgYXZhaWxhYmxlIHRvIGlu Y2x1ZGUgbXVsdGlwbGUgZWFybHktc2Vzc2lvbiBzZHAgYm9keSBpbiBhIA0KcmVxdWVzdD8iDQoN CiAgICBmb3IgZXhhbXBsZToNCiAgICAgICAgQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7 IGJvdW5kYXJ5PSJib3VuZGFyeTEiDQogICAgICAgIENvbnRlbnQtTGVuZ3RoOiA0MDENCg0KICAg ICAgICAtLWJvdW5kYXJ5MQ0KICAgICAgICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3Nk cA0KICAgICAgICAgICBDb250ZW50LURpc3Bvc2l0aW9uOiBlYXJseS1zZXNzaW9uDQoNCiAgICAg ICAgICAgdj0wDQogICAgICAgICAgIG89Qm9iIDI4OTA4NDQ3MjUgMjg5MDg0NDcyNSBJTiBJUDQg aG9zdDEuZXhhbXBsZS5vcmcNCiAgICAgICAgICAgcz0NCiAgICAgICAgICAgYz1JTiBJUDQgMTky LjAuMi4yDQogICAgICAgICAgIHQ9MCAwDQogICAgICAgICAgIG09YXVkaW8gMzAwMDAgUlRQL0FW UCAwDQoNCiAgICAgICAtLWJvdW5kYXJ5MQ0KICAgICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24vc2RwDQogICAgICAgICAgQ29udGVudC1EaXNwb3NpdGlvbjogZWFybHktc2Vzc2lvbg0K DQogICAgICAgICAgdj0wDQogICAgICAgICAgbz1Cb2IgMjg5MDg0NDcxNCAyODkwODQ0NzE0IElO IElQNCBob3N0Mi5leGFtcGxlLm9yZw0KICAgICAgICAgIHM9DQogICAgICAgICAgYz1JTiBJUDQg MTkyLjAuMi4zDQogICAgICAgICAgdD0wIDANCiAgICAgICAgICBtPWF1ZGlvIDMwMDAyIFJUUC9B VlAgMA0KDQogICAgICAgLS1ib3VuZGFyeTEtLQ0KDQoNCiAgICAgMi4gIkhvdyBjYW4gYSBVQVMg ZGVjaWRlIHRvIGhhbmRsZSBhIGVhcmx5LXNlc3Npb24gc2RwICxhbmQgbm90IHRvIA0KaGFuZGxl IG90aGVyIGVhcmx5LXNlc3Npb24gc2RwcyB3aGVuICAgICBVQVMgcmVjZWl2ZSBhIHJlcXVlc3Qg d2l0aCANCm11bHRpcGxlIGVhcmx5LXNlc3Npb24gc2Rwcz8iDQoNCg0KICAgIFRoaXMgcXVlc3Rp b24gYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZyBzY2VuZToNCiAgICBCZWZvcmUgQSBhbmQgQiBl c3RhYmxpc2ggY29tbXVuaWNhdGlvbqOsDQogICAgKDEpIEFTLTEgd2FudHMgdG8gc2VuZCBtZWRp YSB0byBCIA0KICAgICgyKSBBUy0yIHdhbnRzIHRvIHNlbmQgbWVkaWEgdG8gQQ0KDQogICAgVG8g cmVhY2ggdGhlIGdvYWwgLCBzb21lIHByaW5jaXBsZXMgc2hvdWxkIG9iZXk6DQogICAgKDEpcHJl Y29uZHRpb24gZGVmaW5lZCBpbiBSRkMgMzMxMg0KICAgICgyKUVhcmx5LVNlc3Npb24gZGVmaW5l ZCBpbiBSRkMgMzk1OSwgUkZDIDM5NjANCg0KICAgIFRoZSByZWQgY2lyY2xlcyBtYXJrIHNwZWNp YWwgcHJvY2Vzc2luZy4NCg0KIA0KIA0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0011D0BA48257243_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgU2lwIEdyb3VwLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDtUaGVyZSBlbmNvdW50ZXJzDQpzb21lIHF1ZXN0aW9ucyB3aGVuIEkgcmVhZCBSRkMg Mzk1OSBhbmQgUkZDIDM5NjAgd2hpY2ggcmVmZXIgdG8gdGhlIEVhcmx5LVNlc3Npb24NCiwgdGhh dCBpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGI+MS4gJnF1b3Q7SXMNCml0IGF2YWlsYWJsZSB0byBpbmNsdWRl IG11bHRpcGxlIGVhcmx5LXNlc3Npb24gc2RwIGJvZHkgaW4gYSByZXF1ZXN0PyZxdW90OzwvYj48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgZm9yIGV4YW1wbGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29udGVudC1UeXBlOg0KbXVsdGlwYXJ0 L21peGVkOyBib3VuZGFyeT0mcXVvdDtib3VuZGFyeTEmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb250 ZW50LUxlbmd0aDoNCjQwMTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tYm91bmRhcnkxPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0NvbnRlbnQtVHlwZToNCmFwcGxpY2F0aW9uL3NkcDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtDb250ZW50LURpc3Bvc2l0aW9uOg0KZWFybHktc2Vzc2lvbjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt2PTA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7bz1Cb2INCjI4OTA4NDQ3MjUgMjg5MDg0NDcyNSBJTiBJUDQgaG9zdDEuZXhhbXBsZS5v cmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cz08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Yz1JTg0KSVA0IDE5Mi4wLjIuMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0PTANCjA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bT1hdWRpbw0KMzAwMDAgUlRQL0FWUCAwPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDstLWJvdW5kYXJ5MTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb250ZW50LVR5 cGU6DQphcHBsaWNhdGlvbi9zZHA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29udGVudC1EaXNwb3Np dGlvbjoNCmVhcmx5LXNlc3Npb248L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdj0wPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IG89Qm9iDQoyODkwODQ0NzE0IDI4OTA4NDQ3MTQgSU4gSVA0IGhvc3Qy LmV4YW1wbGUub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHM9PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGM9SU4NCklQNCAxOTIuMC4yLjM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdD0wDQowPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IG09YXVkaW8NCjMwMDAyIFJUUC9BVlAgMDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 LS1ib3VuZGFyeTEtLTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8Yj4yLiAmcXVvdDtIb3cNCmNhbiBhIFVB UyBkZWNpZGUgdG8gaGFuZGxlIGEgZWFybHktc2Vzc2lvbiBzZHAgLGFuZCBub3QgdG8gaGFuZGxl IG90aGVyDQplYXJseS1zZXNzaW9uIHNkcHMgd2hlbiAmbmJzcDsgJm5ic3A7IFVBUyByZWNlaXZl IGEgcmVxdWVzdCB3aXRoIG11bHRpcGxlDQplYXJseS1zZXNzaW9uIHNkcHM/JnF1b3Q7PC9iPjwv Zm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyBUaGlzIHF1ZXN0aW9uIGFyaXNlcyBmcm9tDQp0aGUgZm9sbG93aW5nIHNjZW5l OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyBCZWZvcmUgQSBhbmQgQiBlc3RhYmxpc2gNCmNvbW11bmljYXRpb26jrDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAoMSkgQVMtMSB3YW50 cyB0byBzZW5kDQptZWRpYSB0byBCIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAoMikgQVMtMiB3YW50cyB0byBzZW5kDQptZWRpYSB0byBB PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7IFRvIHJlYWNoIHRoZSBnb2FsICwgc29tZQ0KcHJpbmNpcGxlcyBzaG91bGQgb2JleTo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg KDEpcHJlY29uZHRpb24gZGVmaW5lZA0KaW4gUkZDIDMzMTI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgKDIpRWFybHktU2Vzc2lvbiBkZWZp bmVkDQppbiBSRkMgMzk1OSwgUkZDIDM5NjA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgVGhlIHJlZCBjaXJjbGVzIG1hcmsgc3Bl Y2lhbA0KcHJvY2Vzc2luZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgPC9mb250PjxpbWcgc3JjPWNpZDpfMV8wRTEzMDhGODBF MTMwNkQwMDAxMUQwQUY0ODI1NzI0Mz4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0011D0BA48257243_=-- --=_related 0011D0B748257243_= Content-Type: image/gif Content-ID: <_1_0E1308F80E1306D00011D0AF48257243> Content-Transfer-Encoding: base64 R0lGODlhjQKjAucAAAAAAOjo8P////gAAPjw8Ph4ePigoPhISPhoaPiIiPjQ0Pjo6Pjg4PjAwPiw sPi4uPjY2KAAAPiYmOgAANgAAGgAAIgAALAAALgAANAAAOAAAPAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjQKjAkAI/wAFCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihzZEUCAkyhTqlzJsqXLlzBjygRAsuZE kzJz6tzJUydNm0Ab4uxJtKhRmD+DKkU49KjTp0STEmwKtapVl1KXah1I9apXr1m3Lu36tezTsGKD kjXLNurBtW0DDIXbFm1aoHSdzlUJAG5eqHbvkvxrdG/Kvi8JHw0sWKTiq30jx8X6drLlnowbh3x8 +XJmzR45d578GTRH0aPrVk7NmmVp0xtRt/76GjZG2bMh266JO3dVtJGDCx9OvLjx48iTKxe+m/fy 59CjS0/efOT069izI6/uWLv379dh1//mnlTqz/JTBZ5XLwA994fj38sXHH++fa3170vMr7//YP8A asZfgARqNGCBTOkXVl9cMRhZe+cxCGF7XL1FYXr+HYjghvtx6OF/H16kYYgkJoigezSZdyF7GKr3 oIcjligjizNGBN6NOOao447P1egjRTH++GGQHBIpZJEZ0tjgkuux2KRBKip5n5FHFkillVVmudCV WvbHpVLuSZnVmC2uiGWXCX2Jpn1qrgmahGWSV6FaBcGpoJsW4olmm3ruxmef4gE6p6BH/kloY4Ye qlZwUuqZqKJpPSqWimQKKSmkYx166VaUxlnjppjiZWmddYKaKaGmhsobfkq+iGKjFTL/OuGs7L1q Zql2DkrqpKrKmKptpj754opNBpbig3DameKcT0I5rK67ctprib9WtKyzLtbKLKxmhnknqtNSO2Ws 2lJYLLFOmkhjtQMNMAB8B70bLoDsvklvo8lea6tdUd7K5ry2yduQu9AaJDDA79UrYJ4If9twYwdD lFnEDwOracUnYgwbxWkarPF8CiP6cYAhjwyvyQ4DWjLKQp0oK3OeQrisq7mSzPK44G5Yab8X7syt zVYqm6+EwxZNdM333gzyxXcNt+Vnsp4MpLMh11tbZqBeC+XCSsu3cqT0wSwzo0VTbV6Ex6Its4vH dnt02kgvRbBDc3Pd8NcdpitmtEQX/0wg3tJ2bRoAAyhrEcdCld3zufgyHmG6KGq99a1xVwu44H67 ebnJiGeVwAICSUA35hrVLaXpm637+MwOGl5qg2nPSjO6pFaqbuCCbs6y6fyhTvpDFDvtL0KI46W7 10z/7qfyNhV/0AW+x8v8RzAfL+r0gWJPkvMxe6w9iLl/b6/4W7lrvvkio+ftguW2uu263SbIvt0q ky+yverryr7k8bffaeb8Gx7u7DfAPlmvawe8mdVUJ6z3WYhs5flfz7jFs6olj4AFDFwEG6i3yUFw SeTSG7/KZEEMZhBPK9OaCj3VtmiNjW0+g1XlxmfCU4Gwho65IA6vt7Yd5tCHPKwf7P+AmDoirsqI 4BMiEq2zRCY2sYhNY9eXnkXEBLpwg82i3fxgmLEngsRqxupeRry1tEHZroP9y1ySvEg9NrYxbPT5 YtymIjamQI2KDDnQgvoWR7C5jYNZxNAHaWWu9xkLjyWzIsrA2MfQzBF2NGtd7BqXryFGsofIktwl 69g0N4bGkyXRYXWy5i8yJsyGsjNjCFXpuHPt63YcdOEJ/+XAZvFsgoX8WRnDB8rT7PJSYzKlnHpp IFESM3GF4+NEuPfETY0Ha6y65eQEmEQDHjMinSOIBBgggOgRz4vVw9nIFPnDa0IkeIfzYjaBF6lX rceVzAqgA6l5ypyZsyLoY0g+1cn/kAmc7wCgG9g96dklcprMoKrypi6Jx0wgPguhbxzo1CQ6OjW2 i6LTVCJGJbZRGw0OXevzoPvgR7tc7g2XCwWTMTuqkAWadIUkJGkaZdqvMIWUfqMK4v14yVKHSNGi BBXmF2tJUJtI0VVOiuUeIVeud8ZTgJwsqk4d1VOprfFuVW2ZPe+Xv5Gmh3+3zGLUgDO8Ep4qgtli 3SQbN8SxbTCt7pMmw2Ypp5c9bpWMy6hQkbfVrHYMZBDFqV8zak1U4jKka23fDfv2yrnuLFmNHNcg CQnTQHr1gLx7HUEUas7AhpJNeNwSkKKGRvkU7pye5N5PGGAABDS0oc1cKbAeqra1/13StpoUW2hN w7HyROB8AzCAPo3ITHcpQAAKGMABKtrZC+7WnOskyAISgNolRlegGPWsLwdbkIP1bqDaxWpfuStL 8gLVr+Etpnnnut6UZjW9Y2wvYdsL33nVV0Ta06RW3auu+pQGalJV2n2nNWBrybe86y2wqhR8ExhC x2zbwZVyIHwcChvHwsV5y3IwTBwOC4+OE/ZwVHsk4QiDmDoiJq2DK1xiFouRuwzO24H529MYQ8rG HJ0xjVmKY9nuScc7/lgwZ2g2+JxtyHYMcom/12OfAjnAGoukitsKycVKcqx8zCQkISg0trU4vz6G MZCbnKUPQzmnOiazRuWrZtGO+f/NaQ7zYNtM1TiPl75wnjGd/2pnPed5zWz+c6DvnGBB45nQ5t2z 5gzdNN/kRtG9cbRe1hRpSReG0pZmDXAynRpIc3o0e670p3cS6lF7ZjWtEfWlMV0XviBmLapGCqvZ QhXJkEUyqtlTp4Uzm02DGjEnwXVnPE0bYMvF1sZ2dawpo+tizwXZtw5Orgu6a2mnGtWmnja1sx2X UnNb22X+NrjVI25aa67cZvE2usEy63VbJYVPVjSlGb1onW2rq9CKEnzl/eM+A/rQfvZ3YX/J1FS+ tLQxVfJOSdY6S0oStybuYsB5OnGGr/WMRkPbc71E73l3PHuZOqM4D8xvBBda4En/y6VN8y3IIckZ vYlmTsm1NPPzwhzlfJ2s4RqrYddxHNHkrXmVhF6ol7/349nd4r9P7qOVvxhGaO6h1JtudInf9Eek TCk0FW7gFtkuVTbOOBejPnCVat3NZ76N16cJ9p9HeeRG1V/Klz7Mt8N9aF5+G1xPOlPeepNwsO0o 0ROY9b7T8p6ctWNx3MWjxjv+8ZDfeEHjHfnKW/7yi38O4yUf+F4OHvOgD73oSTzQzv/M9J6veo25 C9zW47zerw860mmOJP99NU55rX3QhqZvAA6Y6GSvc+zFPPzJhw2yi+vgUgueZS3KE+Fph6IfDcnK qaMUhIylvmOfbvaKl5283qUI/+q3jLU7PpK9HpUw+rv/N5GemILRryfFs5pMn2+2AMw1MpZljvz3 ZyvverdJuaU2U2Z97Ddo80d/61ddQORdSic9EWVwK/d1zAdPIgRLMsV9TpSA5sV45zR+zMNMCfAA AsAAypV/oFQzgxdvHRV4tQGCSLSCswddLZUQiXdPMlh8N9dJB0dGNTVPW2RLqpSBZkV3stdHK+SD LUeEfCN3NOWEC8crCwVgXCdjscSDHMh007d1fPYothJ/ETh34ZKDUfRWXlZkmARZ/IdIPfdCtgVy QAMwcAN8JEKGk2JXZqh+aVgseOdgZ7iHZ5hIVEZ83id8Bnh0OoiIWZhoM1hVjP+EhSVxfhhkUAKY SVM2ZC4mhgA3fZx4GpJoET+oWCBFWOkFUftHfm0ldm4VWHRIdXDUXzHjILKkLwaHUldINU1kOefF hZJCgS5ViCh0fHnVfGx1WP/nVElFTZZVhG6HMK34KYhyZB/mYtSYYeSXcR02djF4VlZWSJaIe0eG W4EIU7f3Yj+ViEO3RsuXfRe4fTa3PF7zjOk3d4H0WCq4hO0HdPT3LvFxgz+kc1+Ye3pYhZCIgEa4 UaeFYMmFgp7kTO43gdZXj3dVWfBXMBcXWd9XVdfVLrAFg9PDIOG3EB4ZG5K3gE7WhHBniOCngRBo XVuyAOdDXcO1KF0GiBAHgH//BICUqHo8ppH9dAAPQAAC8AAQwJC5aH8ZuYk+aZItKVF2aJBQqZQq GZVgg2/SNDNXhFflCH8P2IlSOIpepX2Gd4ViVVrMOJVSqYX4EVV0lDifyJJLlopRiJZqySrEokwC KUha9n+2CH0zJYjthIdcxkJGM44EGIADKGVnGYyNlIQsR1RDeHAsxCRQOJd12Rx79Vl3+Y6CxZjp eIAFGUTECJZDiIy0CEh8J5m7oovoWHSGVYNoRyeZuZWgiZmciV+qc5txxJaOyJOhWTHySCB/94HZ 5ZvtdG9N1ZcTwi+klUAheYhNSUTMRAHyklzLhV3NpY8UtZEDUQABNZPSCZsM/4iDzvWWoNRbFzGS 2FM3E6OeRvSU65WQRnlNwSku2rmDJNeIrtmaPcmfWMeC/rlR8Ck4Vyl1jFGWqkmLJqVF16ecYck8 9VmHshWhmniZjDheBSh4+tmfi3iEwHihHUqI+Rmg0Lihdnc2fKZZwtJCNXmaTWWaq5lvGUqgxlmc JEpRAwqiI/pe01ijOGqiAuqjTgmkNhqic0akP3qfirijTJqUFuqhTUqXOkqVUyqlUEqlVyqMoyd6 mrOlW0ppXjp6YBqmoYdt7gYY53am79ZuajppzdamZ2GmcFoUxDani8GmdooZeJqnpCanfOoTafqn evqmgtqnhFqoOeFriAqoe/+6qMy2bY46E40aqSuhqJ0mF70WqGVhEoYRbC2xbI9Kc63WqZiKFeNW KJp2GNcGJamqqp2mqZDBF6XqqcdGquk2qXohq02BE8IGqp+Kq+nmqq/KqpQaE3VarKEabsiaGMCK rJa6rJUKq9B6GM1arOo2rXzhp9h6rNiKEtfarcFWrZT6rODKreUqrpH6redKrODqrdLareoKr+jq qPCGpEN6o74CoB+apZ55JirHhAm3b/YKXkJKQxVEigkncVH6pP2GrwTrsBJ6eMCkWc2IpSLqpPU0 SDsnlj0nV3y1rxdrpSF7Vf3ndJUJdRAbIhSqsvaWm6tEOXCZkgxrfDD2UAP/S55KCl42C1rmSZCl VKFV2q8LO0rulJyA9HzXt5Mp63I3azwtipi19Y0gppNXlY9p5HQWCIYWk7Ort7RYiIyKhXE++1Fc y6HotbMgS7Npi6Ph5LW6t7ZLKn9WdpjjWFIvq7VeKbQWe6QEN0EwKpmWdbVA63Fum3qFq7BDy688 1pV6m5ZBW2MvU7A4+ykQObYfm7gNC7cKG0A4trIoa6Q6Y1Oz+bmY+7lK+J9lG4cLircy+7gsm4Gs u0sHybdmh6LLaS4PJ6NTu5ezY0pglUdfWbq017QNFkJKBbPJmXx+y7EBa5GWO1E8Gx/5wUlKC7pv hFZwFTtoy5cCWLe+a3hM/7mBCeO5KQpY7dh8kQNVzTm4mUsn2BeZv2u0yUuRULWVZBW7Xde34IO9 FUsehUm1NymO0tiHKYOxs7VI9wKQ9uuXoQgaDSUV/pik1isgJWlyeaRi1Vt68/gi7pmLkgsmRfuv R6u+29u658kQBVAA7DmIHfyeH2xUtGWYNqllA5yH4lTBPhR4K6wQLexQL3xMNsxGsEUA7iKUBNXD PkSGOHyviFe83xS3hrjEDytREcwtSFxFP0xM5PseiZcUV+zBqRukh9uQWWy4mtu1E4zGwgvFjesl XHaPuDhJUjxKLeug+rWE9bXFiCuy0auNypdkEeuvkGmWfqm6ezu8u0dl1f9DwLe1xzOLnwY8siA8 o4SkeNILirjYma7bvnQVvqQ0QpY5FkilvLdIK6aZtavzV/eLkY5LuF45jORCRRJ5jAxavyfLg60H XNaxyGtokTEcwFJLw1MLcT1bTmv8mYbcK/JSH1/MZHVMlnZLm28byS1oweApY/t1O6Lisbr5SXts snbczXSMKmRazuYMHvUnNiZoPjJ5zVbVjqMoy2U1kbUMyvhioL+5yWqrgOinAO2MndUEnLjDhbCo U77LmmlMg9NkAMBlxCJpXcUTGM2sfHhZyBonOxKUl1U2X/iLyWF8TOiET8QFYe410dgs0B+t0PFn 0hXTW0kBAa41Ad/50GL/nNCCt08GU8X205EDsAEkCNCeF7kpzcRUjMIFUJS/xU3u3JCMC3tnLMSw 9Ros7cxDPcXVHJtPbLbUDMk9hdON4tXl5JipabJYe8vYC86s3Mb6zNVSaJWTuaAF+kdCxbk0NLts 3X1ijbx/DL/RHITHW9eo676a7MrHfERu7bzxe1KYCEA/O9iSTNiHzLSCHcq1i31YGcBiYoa8ezR9 7byUzcmt/NiTPZoSBD8wisoMjMeOvc+RDSJnfdlSW0qa3XBp2Nn3/Nn+i9I2XdOcSNq0+Up/S7/2 bIxRWMz0WcZqd9j3jKCkWdpkwty4TbQCzZtqvNVxZ9pmnbS4F5ZlWY+A/x3atGvXr3vdb3LO5n3e 30G8pCvOWqze7U3O6B3f8v1gY+xGOaq4+C3arA3ed53fTis02bhi2DiN1ijgAG5mYPzUGvqKeTtG xo09CNXAiS1P3Ny/j+wcae3galKJVwbHAr6KgpwypwuEWTnN/F2GczyPMRu8WMR30O2GVlvYWs0p h7SzFniR2pJlDTTKirfLjKxbemeg1C27rV3dNN7j3JuHQa4/NBzksZ3J2+hHtiuL2ouUpvxwTk6O d8veYXjiyBy8wCuesik/0S2+Clq5pfmiBUfcejVP+ezfMJzht/GJMVRSalU7GkbLPFfizxsbGaLH fW7Gx/nmIvLg7yyHNv9EhV042dFsyp0c3tYdjcWsRwxjRQ55l2WtjG7I2VrZoP6HYOeo4K4IWsgp gc6n6Xpt4eMsZDGOmi23yp6u6pCNmb8czLkrzKm45AXs5fCIcL33mA+662oddImn013eh0CeymWV 6sK+1mUWcwIhMPkx1Sh52snL5nwe4ZMseZJIyeGL1TC+dna521qczgRJ7QgkyshHz42+7qRse7dr IsGkzeMu3hpMWASgwh0JTk29Gck+mJQ05bc+8G0TjsTchg0+6ywVXbk8n0kcHOfTXWC94OTeS+iZ Tk/kO1KN7t8+VBRowqDNz1zO8Q3jPMws5dii58wLhdpe1SCtZCT/MKr/hQASEfMChtxkHO25bPMf w0xS0QD7Prn2buQYpVrTkc7znfRl6vLZuZT0vtRAjPP2DX4hrU88T6NMf9wHFvGbNfG8HelE7+yD 8ePAoYpIxcu5UvZ3Hu5l/uUyPlS2N+IOaue27XV/vdoqpdyNnfafvr6NzpcrbsxgP+Nt3enLnep1 ro0j1O+vqe5LHlqn+IZTh41/aPay+N3Drt/jPVUJr/nP7t6C/ujcd+k/+4tDT/iVfYxY+eTLt4fI rqDiHvjSV0CwHMt83/rsiO0JW68VT9QD5NuiCNzyW88YGOuiv+rOKPVsRE6GPvhfz8d5b/ilj/jS f8d4ztHHH1EEXenk/93uW875ttmWDseinD3iFV53p19EeS22dA/sVxeQ1lybhi2X8OxBe+noxD+Q ahTq8nfmtAwQAgAIFFBwIEGEBRUmTHhw4UOIESVOpFgRokOLGTVu5NhxIkaPIUWOJFnS5EmJIFGu jKiS5UuYJl3GpFnT5s2KM3Hu9KizJgCgQSkCzRjUZ0uSII22JMqQp8GnUaVOHamU6lWsWI9mnbo1 5lKEB5s6JHtRLNSzZwmWFThQp1qDR73+5MpRKdmxRPOKdavQKlS/dTsOIOwWLGHBiRWXnLuYrlSj e5cKDfwQbNu4fDW33ax3IeXITS1fptqYa9m0aAH3XQ344ufKjh8OQP+qkbZs3Lmd6t5pmvdvxQMJ I144/DZw5DeP1+a4PPnzm76h90wu/STb1sCJSyc+3btH5xcNFBj83TxL6+dzeofrF2/Yyu1hx04v NXxo/PmBDtDf3/9/AAMUcEACC/yPP/+6666i8NRzcKP6HnxNQgpZahCjBwhQ6ICMGqxwOg9ja+5D EocqsaoTUxyRuYUaaGCjEFXUbUHLBotRxgcjJNFAHnv08Ucgg/wRwdBKuhFH3u6zDUkkdfzQSSbN U3KkI6NEzjgsabRSRigp7HJL77YDr0owkfuyTPbQTElNNYUbbrY32azwTDnNrHO+O6OkM0/d9uQT Nz/NC/RPxwYlNDH/Qw+tK1HoGFU0K0cfLU3SEyO1k9ISLcWUJ003xalT3kD11CZRR/3KVAlLBRTV pMwSzT2VSLNINN/GkonVW3E9T1XZeNXTtbhMHC2+YFmjFTPPUsNsLWDha1Y+XSGMVtA/fcURNL0o +4w0bjszDNtskcWryG4z23azaaVNdzprg1s3zXefazdejeYV7K5X6UVU30v5DbXazGT1F9KB/y04 N3sXPbjPhVdtuFCAH4ZYYncp3pfPhCnO+OGNG+74qo8XDrngkQcuOaqT/U1Z35XpbflTiyv2uKFZ J6TOPZp98mor7GbGOOaLRcZztWM/2o0vEW1V1jVl/+qZoZe/i5pU/6Dvrfq0qwn+OWutuAbZ659m mvoxsFEO0NX/0E57NADV7s9t/eCOm+21z23bbv/kzk/vIunO2++3+Y5McIEFxLvvPMdOV/FoGZdU 26HrdFzXyVmtHNXLUcrc1M097XzTz1stG7LRUS79qdBRPJ3T1XtrHeatX6dadrJphyl1kXB/3Haa dFfU946AP1T4iHl/ifh6jT9VefSYbz5256+LXvPppYe+etWxz177kJAvinvRwb9Z/OCLJ9+u88tP X93E10ff/e/hr/l6+desX9j77c9/f/779/9/AK4LAAEgYAENeEAEJlCBC2RgAx34QO9Z5oETpGAF LVjBCPrlghvkYP8HIYimAXpQhCPsoEtCSEIUprCBGdSgCl34wgKyUCAwpKEKZXjCGuawhC3RYQ85 KMMZ+lCIFLzhEI3owCIeUYkJNOESnWhAIOLwiUpM4hSXWEUrHrGJWaRim7jYxTJJ8Ys9xOIYychD MwoximlUIwjZ6MMyvhGGW5RjDddYRzu6EY80jOMeUUhHP9rQi4F0YR8J6UFDHvKHaFQkCe/YyBEm EpIY1OMkEclIKj7xkXyEYgzFGACgnDGMOsThCUN5QFPmUJKcjOEVMWnEAX4SjoPkZCll2UpSVnKO oITiLTuZx1Fq8ZdafKUajeJKXRbymAiUpS//mEwbLhOVC3RmJKH/ScZhwrKY2MxmG6/pyGmekpdM FCWYqvnDcKaSmQQ85w6DCctuelOClrzkN+k5wVXek4H51KcCAdlPItISoAF950DxaU+DMnGbCfWn QBm6T4Q+NIYRlSgoF1rRiVJUovx8KEcZ+k+MotKhIYWiRjtq0o9eNKSbJGlJC9rSjJoTpsxUKUZZ OlOPJjSnBgUpTG/qU5TqNKg8rWlFf9rSnQ40qQDtKVJHCtSX4nSoSp1YAHfTPyCC0HwAzGoYrXrV Nn0VrPvrqjm3KrVwBSxb3vpbjr5a1i3BVUS7wll2oFajuabqrXuln9SIhRq8Jg1yDpLrr6xa2LE2 ij6AjRxGQofY/ybxtX2EXWvS2AYrtWYOsteS7J02y9nDdlZyYv2sikqbIsS+TGDrCV9e+8VV0cqp ZaVijWuBc9pKxZZNUSuasdRSW6TpDFhjw22mdBtWeMUKaczKzlvwRNzjkvWsfYLcXjhjLnAh67LX HexrqTVc+hALPk+ja2j7ilW3qoZmTAuss/Rq3snCt7zjhY1j2wut+cL2vPyrXM/+Mlf72pZd0fUq WWNF4Pullr+DS2yCERzXBYOluDt6sJUmvKsD96tTd/GrfEdb4aDV9bqcoVVe3Fvf9soLxEy68JOS K5QSi9dZb6luhwOo4BVjrbn0ZS5b8HvXZlWHsobBLIwre7f0xv/3xjlGmIix87QAu3i/0vWwjZfG 3GfZbU7TRW+V4dUQ+0YZvBSecv5azJ4MY/hbAD4XZkmcr/x+2Mvuu8yZ36tkrgpJz3vmc5/9jGT9 4vl/dm5UjavT3fnlzmaKLbOD59yrr/2X0YL2H6EJW+i/qndpwTUakAfc6PpZWj1Tg1aMsfxb/a33 05Tu8pLNVF10ZVfWtR2xkUnNZf4y+Xw4frSZdW1a0v5afLx2dbET/CpiBzrPf2Z2s539bEDL2diD jnDkZBts0JpL29lWtrS7nVv2Wtu4vTarsCf9LOKJOs7XNreKwy3gLZMbwpF1M6LBbdoSaybd13qy qoEN6iT7l8X/7RZyYCT9b1aTWbCGnfa9sQxvL+Fayv7eN2QY/BGe2bvTiqabq7TGpfCKW+GebVK+ Scxw07Ev1ajzNP66QvCJN7w32votqoNsqxmj2se0xiuHN/5yeVsY26Tr+bv7MlieB2tZwLXrfV9D cx3LHLkWX+22ZqXxlasPViaEc8rNVmdyFU3LSueudWcNNbN39+JA1zDrmAZdgN/ufT9nOXmzznJ3 T0u1wypyWrHlb4rbmOSlAc3b7arc1jRNvWFJuoyXRXevf9tOEl7u4m2+aLvfVuKzk3G/14xivi99 vT8WM+Mzj/dDd93lEJIV3Ntuc5wz/cRDO73BEk4qBk+msjen/3ms0+4ttOsb0WsnunddN+bcZMk4 MI933hvHLp1r2vLFSgm3ZKMlvGI/1Jt39IARr3TZk/65itH+ogVQ/vQlm9qpf0+tf49dWiMO608h E7rP7+u4KyzIZGv/qrVXf4O7DACMHvWzPSeTjHGhvixDvnOrngFEC9J4QOUpQM07OVNzr8tzuv2r QOxBv+I4Dp8rCAnkHQp0mBnjMWMRL7EZvy/bwNepv+44ihG0nRKULuKzHRgEQQaRnxr0tRuknRyE uBmknR7sPrLjnSrJkgYbQtlRP3UruP/rHorwQOzBsR+EnyfkCgn0CSZswoi5QjojnwGciS4kwrPK Qg4EHyp0rf8yNMP8Wx80TIw1xIg1HDbu2z74iZOW0MNWG7ygw0Lmi7hAJMBBTDKpo7JDLLA/DMNF pLdGTL9CvLRInMBJXLdKC7h3O5q6qj3/W7/byzvZy6v248QGtDKjaznQaz7Jm7pRMzjLKj1XjLnv mg/Hgjqk+Jw4LMXdurOmO7kNbLxWlEQWjLJ+c8EW9EQ/DMaQ87RibDBdzLVHBLlKJMFpFLxVRMRr VMRERD25YC1nfJ5ljLpsLLeo4xlv1JT/mpd2gQsTO7rd472+IzL3A7yHEzm2G8d507FapL41MzSr gz95/DvyAkZ1tBowY8depEUjO8Lwc8HCkRl8FDr9q0WEnD3/hfS7MFNBjIMze1nHf6zIevQxTYu+ HWMRkTTIbczHj+uxU0zHxAO/6bNI5PuxrvDAOiy+UZmc3HvIy/q8+YPCZLRGSimM5mhDxhC1/uq8 VHQaYzxGdkMzU9FB8ACf/uq9fMnAf5TFp9wf56iPGSTFbmzK4wms7+saYXS8jKRFsXxGrSKrKRGJ EWyPdlyLd3QKZDsy36NHnhOulUQritw630vAETtLb5MfIsG5goAABBiABIARKQy+cKPJb1kuZBs9 hxw+FpmUaES4+zlMuJAAAxCABqjDLQQ9kNzLWKy5lyxJzMtEiIOdlJTIzuTIiBgABXBM1KMcwqu6 I6w+1YO8/7nbusy8x8J0Hw9RCfJYkegQNeVbPreLH+CEGVhMMeLcSsNMNQMwjhexCKPUFz5kw+5k itiDSb0UScqMSc+wnxCkTpwsTuMczvJYHfTjwvBkMwx0RaSDR9E7yRUUxcH0lSIUQ/OLz9JZEOvb wePZycGxxbEDv92zNfiDzLLrup/kvKCsHxrxkcKANg7t0D7zzMBBUP3Tuzs8n+VIj/qclgvxRxEl nwBdn9vgjhesCAYwDgRYkl0rUeMMwhnViNG8zQ6pwsp8Q0gUweZUnvobzQHQgAABUQ99UijlUB1l RPEBQAAYgBvlTiGdTlaMSOPxQAc4gAE4AApYABx10SmFw//0qb+5SNGreVFAXNPk0VI1JdIchVHo nIibpEQ7RdMd9UaJcFOugVMqzcPo3NOjFMzBbNDsoktwuUrxdNSAqaoLvUSu1EOH+E7SYSxUPMFl PE1UzMCEIdQ6jc26i8VOrbzhssoAyzwKhUj3hEZThU1OhcXLs9VMlA+s7Mg0LdLTMLltG7tGddS1 ok2P88kKjTyQoTxFZVSzC1ZW3TarxK7FIFVftZpatbYUZMFTS0W7bLpRVUnYDLFYxUaFyVb/NNZJ 9UWlZAr4/JrNRK2hK0dUxVW5bCwG1NVe5NVf5c3HG4pkfU3xvEt+/UQjXNZhHb5GLbz/zDfrktZn hVV4zdP/u4sO/0TJSu1DRzw+id1N2ANVvlM8kmQ8sLrBguxTO4zXsVTLwPs8VD1A9PxFbsXYcsU/ SAHDf/VN6bCOtQvYcUXYR4VQUew9bZs14KPIoCVX60RGs6TYAeXYNBNHp8QUa73Tfv3YU8xKkV1N khUbnhxRLx24agxOT72r1tPP/dRIkxTY3GTapbXUm2VW3Su9cnE/topQpEXAoPFZ7alauZs+KGNZ ZqxX6nwPgetY5/OcKF1cxm1cxMnYrkHXmwvJ8RO46Wy8gg00vq3CXp0dydVE1LRPfLE7zEVcc4Vb yCU6pgvcdg3VcCxG1qXZXGQYlR03lHtObPXXa3XbXdwr/5zdXdSt2YP9TeDV2KWd3Sar3b79Qt21 2rAt1cH7XeflXVm9UOQ1wect3i6l3tM13t5VXs4FX1XM3ukN3rf13url3q8j2Medmze7uBB13xB1 w1mFXq2wlkDZXIlRHGJ82YMbWce53jS8X7BFD+Id1FlUtdCtxzHTybFlvQJeCf3lmASO3bdTV5lk S5u92QjWnANmDG6NPw28VWX0Pws+XMtiW+xVX3JsQc8jS00U3ARmYTw0wEEhRUq14IP837U0QBrm wXtxroWrN8CC0IdVVHncSAs94RRewB5eYfNFX4vrtNElOwmrEcE8yftU4tfhlcd115zg2whRLppU 1ijuCv8hBjKSLLUAVI2KrL0J9pmmdVr2lM418UjxlQn87Z0PftOrVUESDr2mAWAFrA0TMt0NFt7c 6WOwPEdl5dS+rM5AZpb8PJrz5M9U49I5/uHb1cz+S5YJbay/XMh5HMiSReRPgd+wG0hYA0hXLjsJ tbU+xl1OXs4Opp74QWK1vcW/+9eGHKuvpdnEzckHrpc9/gpG/shP/VbpI1keK1sNzGDNrF/tnWKp leBZ3h5iXt8D/uDmreM5bdCZNWMpNptb1uP8VTdQMY2w3FR7dM22PeO2zGO7YNhRhOfxdOZNK+QJ Wc93pmV51kbbQ0ezUGFh/lmQpWRI5TqYxOS1xWKx22T/eUHAoP3fuhHK7x3gxzPivDTlqNVgZJbb UOa9CxRakw6Xv5xQrgPQ/Hrjojtkg/bh8zUY3WNIywTmSp7a5F2cll5XZmZj4SxhRUbJNSbkDBYz /i3m2gFq/41mwpzp7gUUMQZhGB7mQnvYzCpaYP3iToRq/GtOTa1O1nFJq05fr8ZQHl3WTGPJNwbG E0tqejZE/hETGzHLskxPh27NJ6bUWt7YUNuPf9bT9f3I97PbRTXsOI5kWk00/SHocd7oifUsx51s yma2Df3mQBXUg1nnVeXHkUZbjtZqvWTmiiXn7c1DBAnsKdRskwG6lM7rfiblyoTtjnvaYzbYKh3O BRDT/zN1Hs5OzZas6kHmWqxMYdI9Z4E21MxMgAUgTRpkUY22nM51nuMMigyIgP1w0vzQ7sru7spW vl7JRb9lnuNUCPAO0iYMCrquTUTlU9xWQ/h0bhzsyg5hbUd+ZBxGZXG9zqdVztbBvsZobwkuaK0O yLmc3IMr63nOn7cMCfvWlRDxjQcXlpq2adoWZ7h+7yo9UbiccFaJERktvjU+wQufyRk+azzda/PG wZzIzuFgAPReXpT9P/4oSiS8kQggjAJwAA2pb+4Zb6oMayP1cBWtGQJQgATA0t6eHiD/ceVeveSk UxL8aBQH4ieXCAxYzAGQADONcePJvelO2fdcvSV/bv+G1fBCTfHSFmzmweChjlP+flc2p8owp/PO vBAYIXKSqXMnv1Rw/kD7rXI4n+sY1VMBp8YZ7/MbO+9EFvQ0D+iDdfRAL+fnXF37zFoFzlWbQcz8 BuiMJt+QdrPDXteEfTNTZ08Ys9uMCdfPzTARDrkXtq2ky9w3f3SCafWnc2Jcp1twrdaKwfWXpr1+ ZtQ77u9pTt1Gv3XCTdeoFWnB9Vo5F2vXzplLz/RURctlZsBr/vS+5jxgN01hl+FWLTrSRu6R83SJ 5nZIn7mEpdCFjT1gPfVpLfBvjGdK3+9110oLPWizVvd7t/KPa+eNixQtdmvTXnBQN2B/9eap7p5u KWP/e1fdTTy6V7Y/ej/iUMRn/ZZNal4eOlbtvwVdfk+5LIZ1o6lwX77p/tT2bT/tf1/OfM5nS17r FGzrkg3mlo88mU/L8NraZy7uBlbxfZf0am7bSXZHphTkbYXmcK/3iAdKz+FzGb9fuRVaS77Li8d4 l83qUx/5UEFKqQ9fnaZapYZ6qhd1hdX6AJRlKldpavX1uIb5WnH4nN67RJe7bwfuEG5ZfNXXjb8d nGX4bBZ6dHN3iB/6nebGx5Zpf4/cZUfwZn9Ucr8q1aP1pzd2wm+V/DZ4i53okhzPnbt56Fbw5G7a vG9mbb9Xx2PJP29P1LFn8mRlmkfB+Jj1ziZz19c8/4ZOW9aM5gxHdk5hVlEX1iOG2HHB6nc//IPv /F0uYkideQWkbV7/T6+vVqJ95ZMmsrxtVtJvYbFF93RP5ap/RzLeR8RW++RfLell/oR3uPY/dt2M e6Hu9vJ9+e/3OoFvbJ2/WAYG//AGCAAABBAsaPAgwYEIFx4U6LBhQYUMJ1KsaNGixIcXN3Ls6PEj yJAiRwqQSPIkypMmU15UmNHlwJgJBZakGbHhS5gxdc4seROiyZUMhbJsWfQoRKQVMxpkqvTpgKhS pTqsavUq1qxat3Lt6vUr2LBix2Z9avYs0bMJ1850+dMn3IU7adqs2TSu27gIq+6dmFbtXcAsbbot zP9W5mHEe/m+FUxSKtuaJiE7rmz58lLMmjf+Rds0r9O1K5ka9gka7+Ghd0MH7gzY9ebMQusSRg03 bdDGsS0O6Hux9+7gwlPCHu64uPHIyZdjZO5Xo13JbadrfEj3M2PpzgsC972x+/bwy5GLL0o+eN3y 6ldOBa/+vWX3gTnKh2//9X38+fc7j/q7Pn8BdgSgct8JeOBgCB513m6sqRVabfD5x6B/ClrIEIFr OXCAAwwYeCGIHDEYolz3zZZTW7QRpthojY0YW4V6yYhhhiTeV6MAFgyQQFQGEPChjUEmJeRHL6KX YnRJ5nVbgS7qJp57c6VXEY5EhodjjDFSaaWVRgr/6eVlTpWGGJk/LTmkberJJ+V5VXK5HJbdaUmR m2/uB6aNeNp5YH0mGdAeBLztaV+NFfzZ44+CDkqiniE2uuiNfTKkgAP/QVpejS/Weel6nPrlqZ0A EkUAAvSBul2GI2566naPXjgbqyCKuhACif4WK3MEUojrga5aqNOUvPI3Z5MOKEDfqsKqJSmQyt6p LLC+OnsZsyIlO61ZcxZHLLbvSYsgrN0O6x1I14p71oQTcXuut9Cya2GU1r7r3LfzxlavgPja61iM mpq771P6AlyZwM8OLGC6A/57MFIFM+yZsA4/nG2V606smcQXL+iuxgZzN1XH9IZsIscjw5exySSh /5yySCt3yvLLMIfnsswd0SzezTVzpnOrPIscsc8/B21czkOXCLTRRCc9XNFLP3lq0043KbVlUTtt dXJYL6210VwP7fWRVN8r9mZg+2z22GRjrDZmaOvs9tpshyl31XQTXLLd+uX94N564wo3o0O2qJyD zU2dmeGIJw04zIzXHbRih8/X5Ip4sXid5RHJVDl20wG1dd98I302dJOb3lp1or1VpmnWmen56wVm B3noEPPquIK5pRl7ZKcxCSGTpqme2pnB66U77bUHjLfyGzff8PPQjx59gtRXbz1KuB+H/fXcj6T9 yOD7rbn4+5av8fkXp788+cF6T9H6D8fP8PwLkv9VeopcLfbV/l31rz9OvCIX/gXQfwUEIHYEeMCt /I+BC9RKAx2YQAS2j4L5k+DT3mczvFlFgzvzYEjqNzARdu8zIFTcCTeYQo+QkDgrLNILVRhDo0xv hii04adweENWtdB8OtzhD08HtSDCj4iqMSK5YtVDey3xXU1k1xNbhsSjTTGDRIxiCKuIpipisVtd hKEWrRjEL06LjDIMoxmZN8U0fjCMM5IZ8ogSrMIVkXw4qSMQBfc1Na6Rdsg74hZVdJvIYU54Stoc TAIIu9XtsYZchBz+3ihJ0UAnkYQbk2RYlJjBOeiPNWMjDd0IyrgNT5LhMqSYWEObm5Tmd7LrHZr/ RknKv7lRcmOspSzxiEZc8tKRfRRlL29Xy0neUoezs+WlcsnDYNqwLMRMJi4JOEEMXhCCEXTmNK2Z TWxWkJrV5OY3wQmWa4IzkxY0pzfHSc6rrLODD+QmBJUJyF0C05jHlCcV6anPGboPmZDCp6cACs16 CpOZjyQoLQ36y30qcZgC/adChxhRIz50URX1pzEnekU+IvGie/KonTwK0pBqtJgFRehBGbrMkv5w pFwSqUNZmlFfdlSmOISpTZuZ04/GFKULTahPaxpUULn0pTuNIU6HulGlcqqoXTrqC5OqUqFOlag9 repST4pVk2pRql2F6gq9mtKvMnWgZZ3pVs2aHla0klWrbX3rWBsK1hQ69UscpehcT1jXYfK1r5YJ CAA7 --=_related 0011D0B748257243_=-- --===============0645926029== 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 --===============0645926029==-- From sip-bounces@ietf.org Tue Dec 12 22:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKaZ-0000fq-9o; Tue, 12 Dec 2006 22:15:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuKaX-0000fL-6g for sip@ietf.org; Tue, 12 Dec 2006 22:15:21 -0500 Received: from mail.zte.ro ([202.103.147.155] helo=mx4.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuKaO-0004qP-Bq for sip@ietf.org; Tue, 12 Dec 2006 22:15:21 -0500 Received: from [10.30.3.18] by 10.30.1.243 with StormMail ESMTP id 75876.1112621526; Wed, 13 Dec 2006 12:29:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id kBD3T9J7085348 for ; Wed, 13 Dec 2006 11:29:10 +0800 (CST) (envelope-from zhang.lu2@zte.com.cn) MIME-Version: 1.0 To: sip@ietf.org X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: zhang.lu2@zte.com.cn Date: Wed, 13 Dec 2006 11:14:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-12-13 11:14:54, Serialize complete at 2006-12-13 11:14:54 X-MAIL: mse1.zte.com.cn kBD3T9J7085348 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: shen.chengnian@zte.com.cn, ling.wenjie@zte.com.cn, shi.hao2@zte.com.cn Subject: [Sip] Help: "About multiple early-session sdp body in a request" 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="===============0832611532==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0832611532== Content-Type: multipart/related; boundary="=_related 0011D59848257243_=" This is a multipart message in MIME format. --=_related 0011D59848257243_= Content-Type: multipart/alternative; boundary="=_alternative 0011D59848257243_=" --=_alternative 0011D59848257243_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBTaXAgR3JvdXAsDQoNCiAgICAgVGhlcmUgZW5jb3VudGVycyBzb21lIHF1ZXN0aW9ucyB3 aGVuIEkgcmVhZCBSRkMgMzk1OSBhbmQgUkZDIDM5NjAgDQp3aGljaCByZWZlciB0byB0aGUgRWFy bHktU2Vzc2lvbiAsIHRoYXQgaXMNCiANCiAgICAgICAxLiAiSXMgaXQgYXZhaWxhYmxlIHRvIGlu Y2x1ZGUgbXVsdGlwbGUgZWFybHktc2Vzc2lvbiBzZHAgYm9keSBpbiBhIA0KcmVxdWVzdD8iDQoN CiAgICBmb3IgZXhhbXBsZToNCiAgICAgICAgQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7 IGJvdW5kYXJ5PSJib3VuZGFyeTEiDQogICAgICAgIENvbnRlbnQtTGVuZ3RoOiA0MDENCg0KICAg ICAgICAtLWJvdW5kYXJ5MQ0KICAgICAgICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3Nk cA0KICAgICAgICAgICBDb250ZW50LURpc3Bvc2l0aW9uOiBlYXJseS1zZXNzaW9uDQoNCiAgICAg ICAgICAgdj0wDQogICAgICAgICAgIG89Qm9iIDI4OTA4NDQ3MjUgMjg5MDg0NDcyNSBJTiBJUDQg aG9zdDEuZXhhbXBsZS5vcmcNCiAgICAgICAgICAgcz0NCiAgICAgICAgICAgYz1JTiBJUDQgMTky LjAuMi4yDQogICAgICAgICAgIHQ9MCAwDQogICAgICAgICAgIG09YXVkaW8gMzAwMDAgUlRQL0FW UCAwDQoNCiAgICAgICAtLWJvdW5kYXJ5MQ0KICAgICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24vc2RwDQogICAgICAgICAgQ29udGVudC1EaXNwb3NpdGlvbjogZWFybHktc2Vzc2lvbg0K DQogICAgICAgICAgdj0wDQogICAgICAgICAgbz1Cb2IgMjg5MDg0NDcxNCAyODkwODQ0NzE0IElO IElQNCBob3N0Mi5leGFtcGxlLm9yZw0KICAgICAgICAgIHM9DQogICAgICAgICAgYz1JTiBJUDQg MTkyLjAuMi4zDQogICAgICAgICAgdD0wIDANCiAgICAgICAgICBtPWF1ZGlvIDMwMDAyIFJUUC9B VlAgMA0KDQogICAgICAgLS1ib3VuZGFyeTEtLQ0KDQoNCiAgICAgMi4gIkhvdyBjYW4gYSBVQVMg ZGVjaWRlIHRvIGhhbmRsZSBhIGVhcmx5LXNlc3Npb24gc2RwICxhbmQgbm90IHRvIA0KaGFuZGxl IG90aGVyIGVhcmx5LXNlc3Npb24gc2RwcyB3aGVuICAgICBVQVMgcmVjZWl2ZSBhIHJlcXVlc3Qg d2l0aCANCm11bHRpcGxlIGVhcmx5LXNlc3Npb24gc2Rwcz8iDQoNCg0KICAgIFRoaXMgcXVlc3Rp b24gYXJpc2VzIGZyb20gdGhlIGZvbGxvd2luZyBzY2VuZToNCiAgICBCZWZvcmUgQSBhbmQgQiBl c3RhYmxpc2ggY29tbXVuaWNhdGlvbqOsDQogICAgKDEpIEFTLTEgd2FudHMgdG8gc2VuZCBtZWRp YSB0byBCIA0KICAgICgyKSBBUy0yIHdhbnRzIHRvIHNlbmQgbWVkaWEgdG8gQQ0KDQogICAgVG8g cmVhY2ggdGhlIGdvYWwgLCBzb21lIHByaW5jaXBsZXMgc2hvdWxkIG9iZXk6DQogICAgKDEpcHJl Y29uZHRpb24gZGVmaW5lZCBpbiBSRkMgMzMxMg0KICAgICgyKUVhcmx5LVNlc3Npb24gZGVmaW5l ZCBpbiBSRkMgMzk1OSwgUkZDIDM5NjANCg0KICAgIFRoZSByZWQgY2lyY2xlcyBtYXJrIHNwZWNp YWwgcHJvY2Vzc2luZy4NCg0KIA0KIA0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRp c2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhp cyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlh bCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0011D59848257243_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgU2lwIEdyb3VwLDwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDtUaGVyZSBlbmNvdW50ZXJzDQpzb21lIHF1ZXN0aW9ucyB3aGVuIEkgcmVhZCBSRkMg Mzk1OSBhbmQgUkZDIDM5NjAgd2hpY2ggcmVmZXIgdG8gdGhlIEVhcmx5LVNlc3Npb24NCiwgdGhh dCBpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGI+MS4gJnF1b3Q7SXMNCml0IGF2YWlsYWJsZSB0byBpbmNsdWRl IG11bHRpcGxlIGVhcmx5LXNlc3Npb24gc2RwIGJvZHkgaW4gYSByZXF1ZXN0PyZxdW90OzwvYj48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgZm9yIGV4YW1wbGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29udGVudC1UeXBlOg0KbXVsdGlwYXJ0 L21peGVkOyBib3VuZGFyeT0mcXVvdDtib3VuZGFyeTEmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb250 ZW50LUxlbmd0aDoNCjQwMTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tYm91bmRhcnkxPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0NvbnRlbnQtVHlwZToNCmFwcGxpY2F0aW9uL3NkcDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtDb250ZW50LURpc3Bvc2l0aW9uOg0KZWFybHktc2Vzc2lvbjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt2PTA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7bz1Cb2INCjI4OTA4NDQ3MjUgMjg5MDg0NDcyNSBJTiBJUDQgaG9zdDEuZXhhbXBsZS5v cmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cz08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Yz1JTg0KSVA0IDE5Mi4wLjIuMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0PTANCjA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bT1hdWRpbw0KMzAwMDAgUlRQL0FWUCAwPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDstLWJvdW5kYXJ5MTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb250ZW50LVR5 cGU6DQphcHBsaWNhdGlvbi9zZHA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29udGVudC1EaXNwb3Np dGlvbjoNCmVhcmx5LXNlc3Npb248L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdj0wPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IG89Qm9iDQoyODkwODQ0NzE0IDI4OTA4NDQ3MTQgSU4gSVA0IGhvc3Qy LmV4YW1wbGUub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHM9PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGM9SU4NCklQNCAxOTIuMC4yLjM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdD0wDQowPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IG09YXVkaW8NCjMwMDAyIFJUUC9BVlAgMDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 LS1ib3VuZGFyeTEtLTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8Yj4yLiAmcXVvdDtIb3cNCmNhbiBhIFVB UyBkZWNpZGUgdG8gaGFuZGxlIGEgZWFybHktc2Vzc2lvbiBzZHAgLGFuZCBub3QgdG8gaGFuZGxl IG90aGVyDQplYXJseS1zZXNzaW9uIHNkcHMgd2hlbiAmbmJzcDsgJm5ic3A7IFVBUyByZWNlaXZl IGEgcmVxdWVzdCB3aXRoIG11bHRpcGxlDQplYXJseS1zZXNzaW9uIHNkcHM/JnF1b3Q7PC9iPjwv Zm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyBUaGlzIHF1ZXN0aW9uIGFyaXNlcyBmcm9tDQp0aGUgZm9sbG93aW5nIHNjZW5l OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyBCZWZvcmUgQSBhbmQgQiBlc3RhYmxpc2gNCmNvbW11bmljYXRpb26jrDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAoMSkgQVMtMSB3YW50 cyB0byBzZW5kDQptZWRpYSB0byBCIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAoMikgQVMtMiB3YW50cyB0byBzZW5kDQptZWRpYSB0byBB PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7IFRvIHJlYWNoIHRoZSBnb2FsICwgc29tZQ0KcHJpbmNpcGxlcyBzaG91bGQgb2JleTo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg KDEpcHJlY29uZHRpb24gZGVmaW5lZA0KaW4gUkZDIDMzMTI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgKDIpRWFybHktU2Vzc2lvbiBkZWZp bmVkDQppbiBSRkMgMzk1OSwgUkZDIDM5NjA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgVGhlIHJlZCBjaXJjbGVzIG1hcmsgc3Bl Y2lhbA0KcHJvY2Vzc2luZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgPC9mb250PjxpbWcgc3JjPWNpZDpfMV8wRTEzMDhGODBF MTMwNkQwMDAxMUQ1OTg0ODI1NzI0Mz4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7 SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZv cm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtp cyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIn cyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRp b24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQm bmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4m bmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5i c3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0 aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2Vt YWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dp dGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVu ZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20m bmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7 aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJv ciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNz ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVz c2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNl cyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNw O3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0011D59848257243_=-- --=_related 0011D59848257243_= Content-Type: image/gif Content-ID: <_1_0E1308F80E1306D00011D59848257243> Content-Transfer-Encoding: base64 R0lGODlhjQKjAucAAAAAAOjo8P////gAAPjw8Ph4ePigoPhISPhoaPiIiPjQ0Pjo6Pjg4PjAwPiw sPi4uPjY2KAAAPiYmOgAANgAAGgAAIgAALAAALgAANAAAOAAAPAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjQKjAkAI/wAFCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihzZEUCAkyhTqlzJsqXLlzBjygRAsuZE kzJz6tzJUydNm0Ab4uxJtKhRmD+DKkU49KjTp0STEmwKtapVl1KXah1I9apXr1m3Lu36tezTsGKD kjXLNurBtW0DDIXbFm1aoHSdzlUJAG5eqHbvkvxrdG/Kvi8JHw0sWKTiq30jx8X6drLlnowbh3x8 +XJmzR45d578GTRH0aPrVk7NmmVp0xtRt/76GjZG2bMh266JO3dVtJGDCx9OvLjx48iTKxe+m/fy 59CjS0/efOT069izI6/uWLv379dh1//mnlTqz/JTBZ5XLwA994fj38sXHH++fa3170vMr7//YP8A asZfgARqNGCBTOkXVl9cMRhZe+cxCGF7XL1FYXr+HYjghvtx6OF/H16kYYgkJoigezSZdyF7GKr3 oIcjligjizNGBN6NOOao447P1egjRTH++GGQHBIpZJEZ0tjgkuux2KRBKip5n5FHFkillVVmudCV WvbHpVLuSZnVmC2uiGWXCX2Jpn1qrgmahGWSV6FaBcGpoJsW4olmm3ruxmef4gE6p6BH/kloY4Ye qlZwUuqZqKJpPSqWimQKKSmkYx166VaUxlnjppjiZWmddYKaKaGmhsobfkq+iGKjFTL/OuGs7L1q Zql2DkrqpKrKmKptpj754opNBpbig3DameKcT0I5rK67ctprib9WtKyzLtbKLKxmhnknqtNSO2Ws 2lJYLLFOmkhjtQMNMAB8B70bLoDsvklvo8lea6tdUd7K5ry2yduQu9AaJDDA79UrYJ4If9twYwdD lFnEDwOracUnYgwbxWkarPF8CiP6cYAhjwyvyQ4DWjLKQp0oK3OeQrisq7mSzPK44G5Yab8X7syt zVYqm6+EwxZNdM333gzyxXcNt+Vnsp4MpLMh11tbZqBeC+XCSsu3cqT0wSwzo0VTbV6Ex6Its4vH dnt02kgvRbBDc3Pd8NcdpitmtEQX/0wg3tJ2bRoAAyhrEcdCld3zufgyHmG6KGq99a1xVwu44H67 ebnJiGeVwAICSUA35hrVLaXpm637+MwOGl5qg2nPSjO6pFaqbuCCbs6y6fyhTvpDFDvtL0KI46W7 10z/7qfyNhV/0AW+x8v8RzAfL+r0gWJPkvMxe6w9iLl/b6/4W7lrvvkio+ftguW2uu263SbIvt0q ky+yverryr7k8bffaeb8Gx7u7DfAPlmvawe8mdVUJ6z3WYhs5flfz7jFs6olj4AFDFwEG6i3yUFw SeTSG7/KZEEMZhBPK9OaCj3VtmiNjW0+g1XlxmfCU4Gwho65IA6vt7Yd5tCHPKwf7P+AmDoirsqI 4BMiEq2zRCY2sYhNY9eXnkXEBLpwg82i3fxgmLEngsRqxupeRry1tEHZroP9y1ySvEg9NrYxbPT5 YtymIjamQI2KDDnQgvoWR7C5jYNZxNAHaWWu9xkLjyWzIsrA2MfQzBF2NGtd7BqXryFGsofIktwl 69g0N4bGkyXRYXWy5i8yJsyGsjNjCFXpuHPt63YcdOEJ/+XAZvFsgoX8WRnDB8rT7PJSYzKlnHpp IFESM3GF4+NEuPfETY0Ha6y65eQEmEQDHjMinSOIBBgggOgRz4vVw9nIFPnDa0IkeIfzYjaBF6lX rceVzAqgA6l5ypyZsyLoY0g+1cn/kAmc7wCgG9g96dklcprMoKrypi6Jx0wgPguhbxzo1CQ6OjW2 i6LTVCJGJbZRGw0OXevzoPvgR7tc7g2XCwWTMTuqkAWadIUkJGkaZdqvMIWUfqMK4v14yVKHSNGi BBXmF2tJUJtI0VVOiuUeIVeud8ZTgJwsqk4d1VOprfFuVW2ZPe+Xv5Gmh3+3zGLUgDO8Ep4qgtli 3SQbN8SxbTCt7pMmw2Ypp5c9bpWMy6hQkbfVrHYMZBDFqV8zak1U4jKka23fDfv2yrnuLFmNHNcg CQnTQHr1gLx7HUEUas7AhpJNeNwSkKKGRvkU7pye5N5PGGAABDS0oc1cKbAeqra1/13StpoUW2hN w7HyROB8AzCAPo3ITHcpQAAKGMABKtrZC+7WnOskyAISgNolRlegGPWsLwdbkIP1bqDaxWpfuStL 8gLVr+Etpnnnut6UZjW9Y2wvYdsL33nVV0Ta06RW3auu+pQGalJV2n2nNWBrybe86y2wqhR8ExhC x2zbwZVyIHwcChvHwsV5y3IwTBwOC4+OE/ZwVHsk4QiDmDoiJq2DK1xiFouRuwzO24H529MYQ8rG HJ0xjVmKY9nuScc7/lgwZ2g2+JxtyHYMcom/12OfAjnAGoukitsKycVKcqx8zCQkISg0trU4vz6G MZCbnKUPQzmnOiazRuWrZtGO+f/NaQ7zYNtM1TiPl75wnjGd/2pnPed5zWz+c6DvnGBB45nQ5t2z 5gzdNN/kRtG9cbRe1hRpSReG0pZmDXAynRpIc3o0e670p3cS6lF7ZjWtEfWlMV0XviBmLapGCqvZ QhXJkEUyqtlTp4Uzm02DGjEnwXVnPE0bYMvF1sZ2dawpo+tizwXZtw5Orgu6a2mnGtWmnja1sx2X UnNb22X+NrjVI25aa67cZvE2usEy63VbJYVPVjSlGb1onW2rq9CKEnzl/eM+A/rQfvZ3YX/J1FS+ tLQxVfJOSdY6S0oStybuYsB5OnGGr/WMRkPbc71E73l3PHuZOqM4D8xvBBda4En/y6VN8y3IIckZ vYlmTsm1NPPzwhzlfJ2s4RqrYddxHNHkrXmVhF6ol7/349nd4r9P7qOVvxhGaO6h1JtudInf9Eek TCk0FW7gFtkuVTbOOBejPnCVat3NZ76N16cJ9p9HeeRG1V/Klz7Mt8N9aF5+G1xPOlPeepNwsO0o 0ROY9b7T8p6ctWNx3MWjxjv+8ZDfeEHjHfnKW/7yi38O4yUf+F4OHvOgD73oSTzQzv/M9J6veo25 C9zW47zerw860mmOJP99NU55rX3QhqZvAA6Y6GSvc+zFPPzJhw2yi+vgUgueZS3KE+Fph6IfDcnK qaMUhIylvmOfbvaKl5283qUI/+q3jLU7PpK9HpUw+rv/N5GemILRryfFs5pMn2+2AMw1MpZljvz3 ZyvverdJuaU2U2Z97Ddo80d/61ddQORdSic9EWVwK/d1zAdPIgRLMsV9TpSA5sV45zR+zMNMCfAA AsAAypV/oFQzgxdvHRV4tQGCSLSCswddLZUQiXdPMlh8N9dJB0dGNTVPW2RLqpSBZkV3stdHK+SD LUeEfCN3NOWEC8crCwVgXCdjscSDHMh007d1fPYothJ/ETh34ZKDUfRWXlZkmARZ/IdIPfdCtgVy QAMwcAN8JEKGk2JXZqh+aVgseOdgZ7iHZ5hIVEZ83id8Bnh0OoiIWZhoM1hVjP+EhSVxfhhkUAKY SVM2ZC4mhgA3fZx4GpJoET+oWCBFWOkFUftHfm0ldm4VWHRIdXDUXzHjILKkLwaHUldINU1kOefF hZJCgS5ViCh0fHnVfGx1WP/nVElFTZZVhG6HMK34KYhyZB/mYtSYYeSXcR02djF4VlZWSJaIe0eG W4EIU7f3Yj+ViEO3RsuXfRe4fTa3PF7zjOk3d4H0WCq4hO0HdPT3LvFxgz+kc1+Ye3pYhZCIgEa4 UaeFYMmFgp7kTO43gdZXj3dVWfBXMBcXWd9XVdfVLrAFg9PDIOG3EB4ZG5K3gE7WhHBniOCngRBo XVuyAOdDXcO1KF0GiBAHgH//BICUqHo8ppH9dAAPQAAC8AAQwJC5aH8ZuYk+aZItKVF2aJBQqZQq GZVgg2/SNDNXhFflCH8P2IlSOIpepX2Gd4ViVVrMOJVSqYX4EVV0lDifyJJLlopRiJZqySrEokwC KUha9n+2CH0zJYjthIdcxkJGM44EGIADKGVnGYyNlIQsR1RDeHAsxCRQOJd12Rx79Vl3+Y6CxZjp eIAFGUTECJZDiIy0CEh8J5m7oovoWHSGVYNoRyeZuZWgiZmciV+qc5txxJaOyJOhWTHySCB/94HZ 5ZvtdG9N1ZcTwi+klUAheYhNSUTMRAHyklzLhV3NpY8UtZEDUQABNZPSCZsM/4iDzvWWoNRbFzGS 2FM3E6OeRvSU65WQRnlNwSku2rmDJNeIrtmaPcmfWMeC/rlR8Ck4Vyl1jFGWqkmLJqVF16ecYck8 9VmHshWhmniZjDheBSh4+tmfi3iEwHihHUqI+Rmg0Lihdnc2fKZZwtJCNXmaTWWaq5lvGUqgxlmc JEpRAwqiI/pe01ijOGqiAuqjTgmkNhqic0akP3qfirijTJqUFuqhTUqXOkqVUyqlUEqlVyqMoyd6 mrOlW0ppXjp6YBqmoYdt7gYY53am79ZuajppzdamZ2GmcFoUxDani8GmdooZeJqnpCanfOoTafqn evqmgtqnhFqoOeFriAqoe/+6qMy2bY46E40aqSuhqJ0mF70WqGVhEoYRbC2xbI9Kc63WqZiKFeNW KJp2GNcGJamqqp2mqZDBF6XqqcdGquk2qXohq02BE8IGqp+Kq+nmqq/KqpQaE3VarKEabsiaGMCK rJa6rJUKq9B6GM1arOo2rXzhp9h6rNiKEtfarcFWrZT6rODKreUqrpH6redKrODqrdLareoKr+jq qPCGpEN6o74CoB+apZ55JirHhAm3b/YKXkJKQxVEigkncVH6pP2GrwTrsBJ6eMCkWc2IpSLqpPU0 SDsnlj0nV3y1rxdrpSF7Vf3ndJUJdRAbIhSqsvaWm6tEOXCZkgxrfDD2UAP/S55KCl42C1rmSZCl VKFV2q8LO0rulJyA9HzXt5Mp63I3azwtipi19Y0gppNXlY9p5HQWCIYWk7Ort7RYiIyKhXE++1Fc y6HotbMgS7Npi6Ph5LW6t7ZLKn9WdpjjWFIvq7VeKbQWe6QEN0EwKpmWdbVA63Fum3qFq7BDy688 1pV6m5ZBW2MvU7A4+ykQObYfm7gNC7cKG0A4trIoa6Q6Y1Oz+bmY+7lK+J9lG4cLircy+7gsm4Gs u0sHybdmh6LLaS4PJ6NTu5ezY0pglUdfWbq017QNFkJKBbPJmXx+y7EBa5GWO1E8Gx/5wUlKC7pv hFZwFTtoy5cCWLe+a3hM/7mBCeO5KQpY7dh8kQNVzTm4mUsn2BeZv2u0yUuRULWVZBW7Xde34IO9 FUsehUm1NymO0tiHKYOxs7VI9wKQ9uuXoQgaDSUV/pik1isgJWlyeaRi1Vt68/gi7pmLkgsmRfuv R6u+29u658kQBVAA7DmIHfyeH2xUtGWYNqllA5yH4lTBPhR4K6wQLexQL3xMNsxGsEUA7iKUBNXD PkSGOHyviFe83xS3hrjEDytREcwtSFxFP0xM5PseiZcUV+zBqRukh9uQWWy4mtu1E4zGwgvFjesl XHaPuDhJUjxKLeug+rWE9bXFiCuy0auNypdkEeuvkGmWfqm6ezu8u0dl1f9DwLe1xzOLnwY8siA8 o4SkeNILirjYma7bvnQVvqQ0QpY5FkilvLdIK6aZtavzV/eLkY5LuF45jORCRRJ5jAxavyfLg60H XNaxyGtokTEcwFJLw1MLcT1bTmv8mYbcK/JSH1/MZHVMlnZLm28byS1oweApY/t1O6Lisbr5SXts snbczXSMKmRazuYMHvUnNiZoPjJ5zVbVjqMoy2U1kbUMyvhioL+5yWqrgOinAO2MndUEnLjDhbCo U77LmmlMg9NkAMBlxCJpXcUTGM2sfHhZyBonOxKUl1U2X/iLyWF8TOiET8QFYe410dgs0B+t0PFn 0hXTW0kBAa41Ad/50GL/nNCCt08GU8X205EDsAEkCNCeF7kpzcRUjMIFUJS/xU3u3JCMC3tnLMSw 9Ros7cxDPcXVHJtPbLbUDMk9hdON4tXl5JipabJYe8vYC86s3Mb6zNVSaJWTuaAF+kdCxbk0NLts 3X1ijbx/DL/RHITHW9eo676a7MrHfERu7bzxe1KYCEA/O9iSTNiHzLSCHcq1i31YGcBiYoa8ezR9 7byUzcmt/NiTPZoSBD8wisoMjMeOvc+RDSJnfdlSW0qa3XBp2Nn3/Nn+i9I2XdOcSNq0+Up/S7/2 bIxRWMz0WcZqd9j3jKCkWdpkwty4TbQCzZtqvNVxZ9pmnbS4F5ZlWY+A/x3atGvXr3vdb3LO5n3e 30G8pCvOWqze7U3O6B3f8v1gY+xGOaq4+C3arA3ed53fTis02bhi2DiN1ijgAG5mYPzUGvqKeTtG xo09CNXAiS1P3Ny/j+wcae3galKJVwbHAr6KgpwypwuEWTnN/F2GczyPMRu8WMR30O2GVlvYWs0p h7SzFniR2pJlDTTKirfLjKxbemeg1C27rV3dNN7j3JuHQa4/NBzksZ3J2+hHtiuL2ouUpvxwTk6O d8veYXjiyBy8wCuesik/0S2+Clq5pfmiBUfcejVP+ezfMJzht/GJMVRSalU7GkbLPFfizxsbGaLH fW7Gx/nmIvLg7yyHNv9EhV042dFsyp0c3tYdjcWsRwxjRQ55l2WtjG7I2VrZoP6HYOeo4K4IWsgp gc6n6Xpt4eMsZDGOmi23yp6u6pCNmb8czLkrzKm45AXs5fCIcL33mA+662oddImn013eh0CeymWV 6sK+1mUWcwIhMPkx1Sh52snL5nwe4ZMseZJIyeGL1TC+dna521qczgRJ7QgkyshHz42+7qRse7dr IsGkzeMu3hpMWASgwh0JTk29Gck+mJQ05bc+8G0TjsTchg0+6ywVXbk8n0kcHOfTXWC94OTeS+iZ Tk/kO1KN7t8+VBRowqDNz1zO8Q3jPMws5dii58wLhdpe1SCtZCT/MKr/hQASEfMChtxkHO25bPMf w0xS0QD7Prn2buQYpVrTkc7znfRl6vLZuZT0vtRAjPP2DX4hrU88T6NMf9wHFvGbNfG8HelE7+yD 8ePAoYpIxcu5UvZ3Hu5l/uUyPlS2N+IOaue27XV/vdoqpdyNnfafvr6NzpcrbsxgP+Nt3enLnep1 ro0j1O+vqe5LHlqn+IZTh41/aPay+N3Drt/jPVUJr/nP7t6C/ujcd+k/+4tDT/iVfYxY+eTLt4fI rqDiHvjSV0CwHMt83/rsiO0JW68VT9QD5NuiCNzyW88YGOuiv+rOKPVsRE6GPvhfz8d5b/ilj/jS f8d4ztHHH1EEXenk/93uW875ttmWDseinD3iFV53p19EeS22dA/sVxeQ1lybhi2X8OxBe+noxD+Q ahTq8nfmtAwQAgAIFFBwIEGEBRUmTHhw4UOIESVOpFgRokOLGTVu5NhxIkaPIUWOJFnS5EmJIFGu jKiS5UuYJl3GpFnT5s2KM3Hu9KizJgCgQSkCzRjUZ0uSII22JMqQp8GnUaVOHamU6lWsWI9mnbo1 5lKEB5s6JHtRLNSzZwmWFThQp1qDR73+5MpRKdmxRPOKdavQKlS/dTsOIOwWLGHBiRWXnLuYrlSj e5cKDfwQbNu4fDW33ax3IeXITS1fptqYa9m0aAH3XQ344ufKjh8OQP+qkbZs3Lmd6t5pmvdvxQMJ I144/DZw5DeP1+a4PPnzm76h90wu/STb1sCJSyc+3btH5xcNFBj83TxL6+dzeofrF2/Yyu1hx04v NXxo/PmBDtDf3/9/AAMUcEACC/yPP/+6666i8NRzcKP6HnxNQgpZahCjBwhQ6ICMGqxwOg9ja+5D EocqsaoTUxyRuYUaaGCjEFXUbUHLBotRxgcjJNFAHnv08Ucgg/wRwdBKuhFH3u6zDUkkdfzQSSbN U3KkI6NEzjgsabRSRigp7HJL77YDr0owkfuyTPbQTElNNYUbbrY32azwTDnNrHO+O6OkM0/d9uQT Nz/NC/RPxwYlNDH/Qw+tK1HoGFU0K0cfLU3SEyO1k9ISLcWUJ003xalT3kD11CZRR/3KVAlLBRTV pMwSzT2VSLNINN/GkonVW3E9T1XZeNXTtbhMHC2+YFmjFTPPUsNsLWDha1Y+XSGMVtA/fcURNL0o +4w0bjszDNtskcWryG4z23azaaVNdzprg1s3zXefazdejeYV7K5X6UVU30v5DbXazGT1F9KB/y04 N3sXPbjPhVdtuFCAH4ZYYncp3pfPhCnO+OGNG+74qo8XDrngkQcuOaqT/U1Z35XpbflTiyv2uKFZ J6TOPZp98mor7GbGOOaLRcZztWM/2o0vEW1V1jVl/+qZoZe/i5pU/6Dvrfq0qwn+OWutuAbZ659m mvoxsFEO0NX/0E57NADV7s9t/eCOm+21z23bbv/kzk/vIunO2++3+Y5McIEFxLvvPMdOV/FoGZdU 26HrdFzXyVmtHNXLUcrc1M097XzTz1stG7LRUS79qdBRPJ3T1XtrHeatX6dadrJphyl1kXB/3Haa dFfU946AP1T4iHl/ifh6jT9VefSYbz5256+LXvPppYe+etWxz177kJAvinvRwb9Z/OCLJ9+u88tP X93E10ff/e/hr/l6+desX9j77c9/f/779/9/AK4LAAEgYAENeEAEJlCBC2RgAx34QO9Z5oETpGAF LVjBCPrlghvkYP8HIYimAXpQhCPsoEtCSEIUprCBGdSgCl34wgKyUCAwpKEKZXjCGuawhC3RYQ85 KMMZ+lCIFLzhEI3owCIeUYkJNOESnWhAIOLwiUpM4hSXWEUrHrGJWaRim7jYxTJJ8Ys9xOIYychD MwoximlUIwjZ6MMyvhGGW5RjDddYRzu6EY80jOMeUUhHP9rQi4F0YR8J6UFDHvKHaFQkCe/YyBEm EpIY1OMkEclIKj7xkXyEYgzFGACgnDGMOsThCUN5QFPmUJKcjOEVMWnEAX4SjoPkZCll2UpSVnKO oITiLTuZx1Fq8ZdafKUajeJKXRbymAiUpS//mEwbLhOVC3RmJKH/ScZhwrKY2MxmG6/pyGmekpdM FCWYqvnDcKaSmQQ85w6DCctuelOClrzkN+k5wVXek4H51KcCAdlPItISoAF950DxaU+DMnGbCfWn QBm6T4Q+NIYRlSgoF1rRiVJUovx8KEcZ+k+MotKhIYWiRjtq0o9eNKSbJGlJC9rSjJoTpsxUKUZZ OlOPJjSnBgUpTG/qU5TqNKg8rWlFf9rSnQ40qQDtKVJHCtSX4nSoSp1YAHfTPyCC0HwAzGoYrXrV Nn0VrPvrqjm3KrVwBSxb3vpbjr5a1i3BVUS7wll2oFajuabqrXuln9SIhRq8Jg1yDpLrr6xa2LE2 ij6AjRxGQofY/ybxtX2EXWvS2AYrtWYOsteS7J02y9nDdlZyYv2sikqbIsS+TGDrCV9e+8VV0cqp ZaVijWuBc9pKxZZNUSuasdRSW6TpDFhjw22mdBtWeMUKaczKzlvwRNzjkvWsfYLcXjhjLnAh67LX HexrqTVc+hALPk+ja2j7ilW3qoZmTAuss/Rq3snCt7zjhY1j2wut+cL2vPyrXM/+Mlf72pZd0fUq WWNF4Pullr+DS2yCERzXBYOluDt6sJUmvKsD96tTd/GrfEdb4aDV9bqcoVVe3Fvf9soLxEy68JOS K5QSi9dZb6luhwOo4BVjrbn0ZS5b8HvXZlWHsobBLIwre7f0xv/3xjlGmIix87QAu3i/0vWwjZfG 3GfZbU7TRW+V4dUQ+0YZvBSecv5azJ4MY/hbAD4XZkmcr/x+2Mvuu8yZ36tkrgpJz3vmc5/9jGT9 4vl/dm5UjavT3fnlzmaKLbOD59yrr/2X0YL2H6EJW+i/qndpwTUakAfc6PpZWj1Tg1aMsfxb/a33 05Tu8pLNVF10ZVfWtR2xkUnNZf4y+Xw4frSZdW1a0v5afLx2dbET/CpiBzrPf2Z2s539bEDL2diD jnDkZBts0JpL29lWtrS7nVv2Wtu4vTarsCf9LOKJOs7XNreKwy3gLZMbwpF1M6LBbdoSaybd13qy qoEN6iT7l8X/7RZyYCT9b1aTWbCGnfa9sQxvL+Fayv7eN2QY/BGe2bvTiqabq7TGpfCKW+GebVK+ Scxw07Ev1ajzNP66QvCJN7w32votqoNsqxmj2se0xiuHN/5yeVsY26Tr+bv7MlieB2tZwLXrfV9D cx3LHLkWX+22ZqXxlasPViaEc8rNVmdyFU3LSueudWcNNbN39+JA1zDrmAZdgN/ufT9nOXmzznJ3 T0u1wypyWrHlb4rbmOSlAc3b7arc1jRNvWFJuoyXRXevf9tOEl7u4m2+aLvfVuKzk3G/14xivi99 vT8WM+Mzj/dDd93lEJIV3Ntuc5wz/cRDO73BEk4qBk+msjen/3ms0+4ttOsb0WsnunddN+bcZMk4 MI933hvHLp1r2vLFSgm3ZKMlvGI/1Jt39IARr3TZk/65itH+ogVQ/vQlm9qpf0+tf49dWiMO608h E7rP7+u4KyzIZGv/qrVXf4O7DACMHvWzPSeTjHGhvixDvnOrngFEC9J4QOUpQM07OVNzr8tzuv2r QOxBv+I4Dp8rCAnkHQp0mBnjMWMRL7EZvy/bwNepv+44ihG0nRKULuKzHRgEQQaRnxr0tRuknRyE uBmknR7sPrLjnSrJkgYbQtlRP3UruP/rHorwQOzBsR+EnyfkCgn0CSZswoi5QjojnwGciS4kwrPK Qg4EHyp0rf8yNMP8Wx80TIw1xIg1HDbu2z74iZOW0MNWG7ygw0Lmi7hAJMBBTDKpo7JDLLA/DMNF pLdGTL9CvLRInMBJXLdKC7h3O5q6qj3/W7/byzvZy6v248QGtDKjaznQaz7Jm7pRMzjLKj1XjLnv mg/Hgjqk+Jw4LMXdurOmO7kNbLxWlEQWjLJ+c8EW9EQ/DMaQ87RibDBdzLVHBLlKJMFpFLxVRMRr VMRERD25YC1nfJ5ljLpsLLeo4xlv1JT/mpd2gQsTO7rd472+IzL3A7yHEzm2G8d507FapL41MzSr gz95/DvyAkZ1tBowY8depEUjO8Lwc8HCkRl8FDr9q0WEnD3/hfS7MFNBjIMze1nHf6zIevQxTYu+ HWMRkTTIbczHj+uxU0zHxAO/6bNI5PuxrvDAOiy+UZmc3HvIy/q8+YPCZLRGSimM5mhDxhC1/uq8 VHQaYzxGdkMzU9FB8ACf/uq9fMnAf5TFp9wf56iPGSTFbmzK4wms7+saYXS8jKRFsXxGrSKrKRGJ EWyPdlyLd3QKZDsy36NHnhOulUQritw630vAETtLb5MfIsG5goAABBiABIARKQy+cKPJb1kuZBs9 hxw+FpmUaES4+zlMuJAAAxCABqjDLQQ9kNzLWKy5lyxJzMtEiIOdlJTIzuTIiBgABXBM1KMcwqu6 I6w+1YO8/7nbusy8x8J0Hw9RCfJYkegQNeVbPreLH+CEGVhMMeLcSsNMNQMwjhexCKPUFz5kw+5k itiDSb0UScqMSc+wnxCkTpwsTuMczvJYHfTjwvBkMwx0RaSDR9E7yRUUxcH0lSIUQ/OLz9JZEOvb wePZycGxxbEDv92zNfiDzLLrup/kvKCsHxrxkcKANg7t0D7zzMBBUP3Tuzs8n+VIj/qclgvxRxEl nwBdn9vgjhesCAYwDgRYkl0rUeMMwhnViNG8zQ6pwsp8Q0gUweZUnvobzQHQgAABUQ99UijlUB1l RPEBQAAYgBvlTiGdTlaMSOPxQAc4gAE4AApYABx10SmFw//0qb+5SNGreVFAXNPk0VI1JdIchVHo nIibpEQ7RdMd9UaJcFOugVMqzcPo3NOjFMzBbNDsoktwuUrxdNSAqaoLvUSu1EOH+E7SYSxUPMFl PE1UzMCEIdQ6jc26i8VOrbzhssoAyzwKhUj3hEZThU1OhcXLs9VMlA+s7Mg0LdLTMLltG7tGddS1 ok2P88kKjTyQoTxFZVSzC1ZW3TarxK7FIFVftZpatbYUZMFTS0W7bLpRVUnYDLFYxUaFyVb/NNZJ 9UWlZAr4/JrNRK2hK0dUxVW5bCwG1NVe5NVf5c3HG4pkfU3xvEt+/UQjXNZhHb5GLbz/zDfrktZn hVV4zdP/u4sO/0TJSu1DRzw+id1N2ANVvlM8kmQ8sLrBguxTO4zXsVTLwPs8VD1A9PxFbsXYcsU/ SAHDf/VN6bCOtQvYcUXYR4VQUew9bZs14KPIoCVX60RGs6TYAeXYNBNHp8QUa73Tfv3YU8xKkV1N khUbnhxRLx24agxOT72r1tPP/dRIkxTY3GTapbXUm2VW3Su9cnE/topQpEXAoPFZ7alauZs+KGNZ ZqxX6nwPgetY5/OcKF1cxm1cxMnYrkHXmwvJ8RO46Wy8gg00vq3CXp0dydVE1LRPfLE7zEVcc4Vb yCU6pgvcdg3VcCxG1qXZXGQYlR03lHtObPXXa3XbXdwr/5zdXdSt2YP9TeDV2KWd3Sar3b79Qt21 2rAt1cH7XeflXVm9UOQ1wect3i6l3tM13t5VXs4FX1XM3ukN3rf13url3q8j2Medmze7uBB13xB1 w1mFXq2wlkDZXIlRHGJ82YMbWce53jS8X7BFD+Id1FlUtdCtxzHTybFlvQJeCf3lmASO3bdTV5lk S5u92QjWnANmDG6NPw28VWX0Pws+XMtiW+xVX3JsQc8jS00U3ARmYTw0wEEhRUq14IP837U0QBrm wXtxroWrN8CC0IdVVHncSAs94RRewB5eYfNFX4vrtNElOwmrEcE8yftU4tfhlcd115zg2whRLppU 1ijuCv8hBjKSLLUAVI2KrL0J9pmmdVr2lM418UjxlQn87Z0PftOrVUESDr2mAWAFrA0TMt0NFt7c 6WOwPEdl5dS+rM5AZpb8PJrz5M9U49I5/uHb1cz+S5YJbay/XMh5HMiSReRPgd+wG0hYA0hXLjsJ tbU+xl1OXs4Opp74QWK1vcW/+9eGHKuvpdnEzckHrpc9/gpG/shP/VbpI1keK1sNzGDNrF/tnWKp leBZ3h5iXt8D/uDmreM5bdCZNWMpNptb1uP8VTdQMY2w3FR7dM22PeO2zGO7YNhRhOfxdOZNK+QJ Wc93pmV51kbbQ0ezUGFh/lmQpWRI5TqYxOS1xWKx22T/eUHAoP3fuhHK7x3gxzPivDTlqNVgZJbb UOa9CxRakw6Xv5xQrgPQ/Hrjojtkg/bh8zUY3WNIywTmSp7a5F2cll5XZmZj4SxhRUbJNSbkDBYz /i3m2gFq/41mwpzp7gUUMQZhGB7mQnvYzCpaYP3iToRq/GtOTa1O1nFJq05fr8ZQHl3WTGPJNwbG E0tqejZE/hETGzHLskxPh27NJ6bUWt7YUNuPf9bT9f3I97PbRTXsOI5kWk00/SHocd7oifUsx51s yma2Df3mQBXUg1nnVeXHkUZbjtZqvWTmiiXn7c1DBAnsKdRskwG6lM7rfiblyoTtjnvaYzbYKh3O BRDT/zN1Hs5OzZas6kHmWqxMYdI9Z4E21MxMgAUgTRpkUY22nM51nuMMigyIgP1w0vzQ7sru7spW vl7JRb9lnuNUCPAO0iYMCrquTUTlU9xWQ/h0bhzsyg5hbUd+ZBxGZXG9zqdVztbBvsZobwkuaK0O yLmc3IMr63nOn7cMCfvWlRDxjQcXlpq2adoWZ7h+7yo9UbiccFaJERktvjU+wQufyRk+azzda/PG wZzIzuFgAPReXpT9P/4oSiS8kQggjAJwAA2pb+4Zb6oMayP1cBWtGQJQgATA0t6eHiD/ceVeveSk UxL8aBQH4ieXCAxYzAGQADONcePJvelO2fdcvSV/bv+G1fBCTfHSFmzmweChjlP+flc2p8owp/PO vBAYIXKSqXMnv1Rw/kD7rXI4n+sY1VMBp8YZ7/MbO+9EFvQ0D+iDdfRAL+fnXF37zFoFzlWbQcz8 BuiMJt+QdrPDXteEfTNTZ08Ys9uMCdfPzTARDrkXtq2ky9w3f3SCafWnc2Jcp1twrdaKwfWXpr1+ ZtQ77u9pTt1Gv3XCTdeoFWnB9Vo5F2vXzplLz/RURctlZsBr/vS+5jxgN01hl+FWLTrSRu6R83SJ 5nZIn7mEpdCFjT1gPfVpLfBvjGdK3+9110oLPWizVvd7t/KPa+eNixQtdmvTXnBQN2B/9eap7p5u KWP/e1fdTTy6V7Y/ej/iUMRn/ZZNal4eOlbtvwVdfk+5LIZ1o6lwX77p/tT2bT/tf1/OfM5nS17r FGzrkg3mlo88mU/L8NraZy7uBlbxfZf0am7bSXZHphTkbYXmcK/3iAdKz+FzGb9fuRVaS77Li8d4 l83qUx/5UEFKqQ9fnaZapYZ6qhd1hdX6AJRlKldpavX1uIb5WnH4nN67RJe7bwfuEG5ZfNXXjb8d nGX4bBZ6dHN3iB/6nebGx5Zpf4/cZUfwZn9Ucr8q1aP1pzd2wm+V/DZ4i53okhzPnbt56Fbw5G7a vG9mbb9Xx2PJP29P1LFn8mRlmkfB+Jj1ziZz19c8/4ZOW9aM5gxHdk5hVlEX1iOG2HHB6nc//IPv /F0uYkideQWkbV7/T6+vVqJ95ZMmsrxtVtJvYbFF93RP5ap/RzLeR8RW++RfLell/oR3uPY/dt2M e6Hu9vJ9+e/3OoFvbJ2/WAYG//AGCAAABBAsaPAgwYEIFx4U6LBhQYUMJ1KsaNGixIcXN3Ls6PEj yJAiRwqQSPIkypMmU15UmNHlwJgJBZakGbHhS5gxdc4seROiyZUMhbJsWfQoRKQVMxpkqvTpgKhS pTqsavUq1qxat3Lt6vUr2LBix2Z9avYs0bMJ1850+dMn3IU7adqs2TSu27gIq+6dmFbtXcAsbbot zP9W5mHEe/m+FUxSKtuaJiE7rmz58lLMmjf+Rds0r9O1K5ka9gka7+Ghd0MH7gzY9ebMQusSRg03 bdDGsS0O6Hux9+7gwlPCHu64uPHIyZdjZO5Xo13JbadrfEj3M2PpzgsC972x+/bwy5GLL0o+eN3y 6ldOBa/+vWX3gTnKh2//9X38+fc7j/q7Pn8BdgSgct8JeOBgCB513m6sqRVabfD5x6B/ClrIEIFr OXCAAwwYeCGIHDEYolz3zZZTW7QRpthojY0YW4V6yYhhhiTeV6MAFgyQQFQGEPChjUEmJeRHL6KX YnRJ5nVbgS7qJp57c6VXEY5EhodjjDFSaaWVRgr/6eVlTpWGGJk/LTmkberJJ+V5VXK5HJbdaUmR m2/uB6aNeNp5YH0mGdAeBLztaV+NFfzZ44+CDkqiniE2uuiNfTKkgAP/QVpejS/Weel6nPrlqZ0A EkUAAvSBul2GI2566naPXjgbqyCKuhACif4WK3MEUojrga5aqNOUvPI3Z5MOKEDfqsKqJSmQyt6p LLC+OnsZsyIlO61ZcxZHLLbvSYsgrN0O6x1I14p71oQTcXuut9Cya2GU1r7r3LfzxlavgPja61iM mpq771P6AlyZwM8OLGC6A/57MFIFM+yZsA4/nG2V606smcQXL+iuxgZzN1XH9IZsIscjw5exySSh /5yySCt3yvLLMIfnsswd0SzezTVzpnOrPIscsc8/B21czkOXCLTRRCc9XNFLP3lq0043KbVlUTtt dXJYL6210VwP7fWRVN8r9mZg+2z22GRjrDZmaOvs9tpshyl31XQTXLLd+uX94N564wo3o0O2qJyD zU2dmeGIJw04zIzXHbRih8/X5Ip4sXid5RHJVDl20wG1dd98I302dJOb3lp1or1VpmnWmen56wVm B3noEPPquIK5pRl7ZKcxCSGTpqme2pnB66U77bUHjLfyGzff8PPQjx59gtRXbz1KuB+H/fXcj6T9 yOD7rbn4+5av8fkXp788+cF6T9H6D8fP8PwLkv9VeopcLfbV/l31rz9OvCIX/gXQfwUEIHYEeMCt /I+BC9RKAx2YQAS2j4L5k+DT3mczvFlFgzvzYEjqNzARdu8zIFTcCTeYQo+QkDgrLNILVRhDo0xv hii04adweENWtdB8OtzhD08HtSDCj4iqMSK5YtVDey3xXU1k1xNbhsSjTTGDRIxiCKuIpipisVtd hKEWrRjEL06LjDIMoxmZN8U0fjCMM5IZ8ogSrMIVkXw4qSMQBfc1Na6Rdsg74hZVdJvIYU54Stoc TAIIu9XtsYZchBz+3ihJ0UAnkYQbk2RYlJjBOeiPNWMjDd0IyrgNT5LhMqSYWEObm5Tmd7LrHZr/ RknKv7lRcmOspSzxiEZc8tKRfRRlL29Xy0neUoezs+WlcsnDYNqwLMRMJi4JOEEMXhCCEXTmNK2Z TWxWkJrV5OY3wQmWa4IzkxY0pzfHSc6rrLODD+QmBJUJyF0C05jHlCcV6anPGboPmZDCp6cACs16 CpOZjyQoLQ36y30qcZgC/adChxhRIz50URX1pzEnekU+IvGie/KonTwK0pBqtJgFRehBGbrMkv5w pFwSqUNZmlFfdlSmOISpTZuZ04/GFKULTahPaxpUULn0pTuNIU6HulGlcqqoXTrqC5OqUqFOlag9 repST4pVk2pRql2F6gq9mtKvMnWgZZ3pVs2aHla0klWrbX3rWBsK1hQ69UscpehcT1jXYfK1r5YJ CAA7 --=_related 0011D59848257243_=-- --===============0832611532== 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 --===============0832611532==-- From sip-bounces@ietf.org Tue Dec 12 22:52:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuL9y-0006ib-RC; Tue, 12 Dec 2006 22:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuL9x-0006d7-BG for sip@ietf.org; Tue, 12 Dec 2006 22:51:57 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuL9v-0007mv-5O for sip@ietf.org; Tue, 12 Dec 2006 22:51:57 -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 <0JA700GE516TRZ@szxga01-in.huawei.com> for sip@ietf.org; Wed, 13 Dec 2006 11:47:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA700IWU16SR5@szxga01-in.huawei.com> for sip@ietf.org; Wed, 13 Dec 2006 11:47:17 +0800 (CST) Received: from w39649a ([10.85.205.25]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA700KLZ16P06@szxml03-in.huawei.com> for sip@ietf.org; Wed, 13 Dec 2006 11:47:16 +0800 (CST) Date: Wed, 13 Dec 2006 11:47:13 +0800 From: Xiao Wang Subject: RE: [Sip] Message size - regarding In-reply-to: <20061212115119.43142.qmail@web52904.mail.yahoo.com> To: 'Raj' Message-id: <014b01c71e69$60161dd0$19cd550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Thread-index: Accd5Ey0n/krTK8rRK6Zdx9IkYbMPAAgWuYA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 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="===============1334737397==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1334737397== Content-type: multipart/alternative; boundary="Boundary_(ID_5sxAliPmuedhs5RtHxtuCw)" This is a multi-part message in MIME format. --Boundary_(ID_5sxAliPmuedhs5RtHxtuCw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, Raj It is no problem for TCP, because TCP can prevent IP fragment by MTU. Otherwise, UDP can occur to IP fragment. So, in order to involve this problem, using TCP send SIP message when the size of SIP message more than the size of UDP. But in a SIP transaction, it must use the same transport layer protocol. Thus there may be a problem, if SIP request use UDP, corresponding SIP response use UDP, too. However, SIP response message size may beyond the size of UDP. If the SIP response is sent by UDP, IP fragment will be appearance. Xiao _____ From: Raj [mailto:ponrajit@yahoo.com] Sent: Tuesday, December 12, 2006 7:51 PM To: SIP forum Subject: [Sip] Message size - regarding Hello To all, We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages. My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted. with regards Raj. _____ Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. --Boundary_(ID_5sxAliPmuedhs5RtHxtuCw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi, Raj

 

         It is no problem for TCP, because TCP can prevent IP fragment by MTU. Otherwise, UDP can occur to IP fragment.

So, in order to involve this problem, using TCP send SIP  message when the size of SIP message more than the size of UDP.

But in a SIP transaction, it must use the same transport layer protocol. Thus there may be a problem, if SIP request use UDP,

corresponding SIP response use UDP, too. However, SIP response message size may beyond the size of UDP. If the SIP response

is sent by UDP,  IP fragment will be  appearance.

 

Xiao

From: Raj [mailto:ponrajit@yahoo.com]
Sent: Tuesday, December 12, 2006 7:51 PM
To: SIP forum
Subject: [Sip] Message size - regarding

 

Hello To all,

 

                We know that SIP uses TCP or UDP as the transport layer protocol. There is some size restrictions on UDP packets and TCP packets. It is been stated that one packet carries exactly one SIP request or SIP response messages.

 

                My doubts is if the size of the SIP messages is more than the size of the UDP or TCP packets, then what happens, will the packet will be fragemented or SIP message will be discarded from being transmitted.

 

with regards

Raj.

 

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

--Boundary_(ID_5sxAliPmuedhs5RtHxtuCw)-- --===============1334737397== 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 --===============1334737397==-- From sip-bounces@ietf.org Wed Dec 13 01:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNRt-0000Wr-FN; Wed, 13 Dec 2006 01:18:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNRr-0000Wf-HD for sip@ietf.org; Wed, 13 Dec 2006 01:18:35 -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 1GuNRo-0003yq-M8 for sip@ietf.org; Wed, 13 Dec 2006 01:18:35 -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 kBD6HkLN004226; Wed, 13 Dec 2006 08:17:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 08:18:25 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 08:18:25 +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] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) Date: Wed, 13 Dec 2006 08:18:21 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> In-Reply-To: <457EE9D3.1080001@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) Thread-Index: AcceFSr1CJyq1IJ/TzOAj147j5FmlwAZbuPQ From: To: , X-OriginalArrivalTime: 13 Dec 2006 06:18:25.0107 (UTC) FILETIME=[7F232230:01C71E7E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 =20 Hi, >This is an implementation problem. Outbound MUST support TCP and UDP >because RFC 3261 says it. The only thing I ask is to let implementers >do their job. > >> And secondly, I believe complexity is >> the biggest enemy here, much more so than the performance concerns.=20 > >Well, complexity is relative, and again it is not about=20 >performance, but about compliance. This reasoning sounds very confusing to me. Is your suggestion really like this: a) You do not actually have any technical reason why Outbound must support UDP, not even the performance would do.=20 b) The only reason for Outbound to support UDP would be its full compatibility to RFC 3261. If this is the case, I would ask WG to consider this reasoning very carefully and if it makes any sense or not. To me it sounds like: "UDP is actually not needed but because the WG decided to mandate it a few years ago, it just has to be there." According to your I-D the client has to anyway support TCP (or other congestion controlled transport) so it would not even allow to implement UDP-only clients (which might be desirable for some vendors that currently only support UDP). Thus what is the point with the UDP flows ? Why could they not be optional for an UA ? Regards, Erkki >-----Original Message----- >From: ext Marc Petit-Huguenin [mailto:petithug@acm.org]=20 >Sent: 12.December.2006 19:42 >To: Niemi Aki (Nokia-NRC/Helsinki) >Cc: 'IETF SIP List'; 'Francois Audet' >Subject: Re: [Sip] I-D: Preventing Fragmentation=20 >forClientInitiated Connections in the Session Initiation Protocol (SIP) > >Aki Niemi wrote: >>> Performance is important at least for service providers,=20 >>> because they have to buy the hardware to run the servers, pay=20 >>> the licenses per CPU, pay the datacenters cost, pay the=20 >>> sysadmins to run the servers and pay the managers to manage=20 >>> the sysadmins. >>> >>> So yes, performance is important, but perhaps not for the=20 >>> hardware vendors, the software vendors and the sysadmins. >>=20 >> This is all relative. >>=20 >> Your draft seems to add enormous amounts of complexity -- to=20 >both UAs and >> outbound proxies -- to get around what you claim to be a performance >> bottleneck.=20 > >No, this draft is not about performance. This draft is about=20 >be able to >use UDP or TCP with Outbound, i.e. be compliant with RFC 3261 (Section >18: "All SIP elements MUST implement UDP and TCP." > >The performance issue is about implementers be able to use UDP=20 >or TCP or >whatever they want, as explicitly authorized by RFC 3261. > >> First of all, I disagree with the assumption that running TCP >> only is that much more of a burden.=20 > >This is an implementation problem. Outbound MUST support TCP and UDP >because RFC 3261 says it. The only thing I ask is to let implementers >do their job. > >> And secondly, I believe complexity is >> the biggest enemy here, much more so than the performance concerns.=20 > >Well, complexity is relative, and again it is not about=20 >performance, but >about compliance. > >I am currently implementing my two drafts about fragmentation in my >endpoints and servers, so I will have a better idea of the real >complexity soon. I will eventually ask the chairs for a slot at the >68th IETF meeting to present this. > >--=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 Wed Dec 13 01:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNZB-0003dh-Jr; Wed, 13 Dec 2006 01:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNZ9-0003ZT-EU for sip@ietf.org; Wed, 13 Dec 2006 01:26:07 -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 1GuNZ7-0006ip-Qx for sip@ietf.org; Wed, 13 Dec 2006 01:26:07 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBD6PCv3004419; Wed, 13 Dec 2006 08:25:23 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 08:25:46 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 08:25:45 +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] Poll: Proposal relating to keepalive, TCP, and UDP usagein draft-ietf-sip-outbound Date: Wed, 13 Dec 2006 08:23:48 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DD4@esebe103.NOE.Nokia.com> In-Reply-To: <457DCE04.5010304@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Poll: Proposal relating to keepalive, TCP, and UDP usagein draft-ietf-sip-outbound Thread-Index: AccdbANedGl9FL0SSy2LIwnQGbDDTgBEooGg From: To: , X-OriginalArrivalTime: 13 Dec 2006 06:25:45.0080 (UTC) FILETIME=[8561AF80:01C71E7F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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, It seems to me that the I-D Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) written by Marc Petit-Huguenin demonstrates very well the resons=20 why UDP support for Outbound UAs should be made optional. Trying=20 to really solve the problems with UDP together with Outbound would=20 make the total solution more and more complex.=20 >> Proposal 2: Make outbound registrations over UDP flows=20 >optional for UAs. >>=20 >> Yes (Accept the proposal) or No (Reject the proposal). > >No Based on another email from Marc I understood that the reason to his No is the compatibility to RFC 3261 which mandates UDP. I would like to know if there any other, more technical reasons=20 (rather than the old WG decision within RFC 3261) to mandate UDP=20 with Outbound ? This far I have not heard any convincing one. Regards, Erkki >-----Original Message----- >From: ext Marc Petit-Huguenin [mailto:petithug@acm.org]=20 >Sent: 11.December.2006 23:31 >To: Dean Willis >Cc: SIP IETF >Subject: Re: [Sip] Poll: Proposal relating to keepalive, TCP,=20 >and UDP usagein draft-ietf-sip-outbound > >Dean Willis wrote: >> Previously we had recorded consensus to use STUN for=20 >keepalive with both >> TCP and UDP. This was not a perfect consensus (there were some >> dissenters). There has been ongoing discussion notably=20 >instigated by the >> current editor of the Outbound draft, that some people feel may have >> resulted in a change of the consensus on this draft's=20 >technical direction. >>=20 >> So I'd like to ask people who care and think they understand the >> differences to answer the following questions, on-list and=20 >on-the record. >>=20 >>=20 >> Proposal 1: Make CRLF the only keepalive mechanism for TCP=20 >and TLS over >> TCP flow (retain STUN for UDP flows). >>=20 >> Yes (accept the proposal and use CRLF for TCP) or No (reject the >> proposal and keep STUN for TCP) > >Yes > >>=20 >>=20 >> Proposal 2: Make outbound registrations over UDP flows=20 >optional for UAs. >>=20 >> Yes (Accept the proposal) or No (Reject the proposal). > >No > >>=20 >>=20 >> Proposal 3: Include (in Outbound) the statement that its is=20 >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. >> Further, include text that explain that for historical=20 >purposes a lot of >> deployments still only use UDP, but that we expect/hope those >> deployments to eventually migrate to TCP when doing outbound. >>=20 >> Yes (Accept the proposal and add the text) or No (Reject the proposal >> and keep the text as-is). > >No > >--=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 Wed Dec 13 01:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNgD-0005ii-1M; Wed, 13 Dec 2006 01:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuNgB-0005gN-7g for sip@ietf.org; Wed, 13 Dec 2006 01:33:23 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuNg9-0002HI-RA for sip@ietf.org; Wed, 13 Dec 2006 01:33:23 -0500 Received: by tutpro.com (Postfix, from userid 1001) id E5D151EC979; Wed, 13 Dec 2006 08:33:20 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lohi.tutpro.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from rautu (dhcp9.tutpro.com [192.98.100.136]) by tutpro.com (Postfix) with ESMTP id 519FA1EC02A; Wed, 13 Dec 2006 08:33:19 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 6E3C9F0067; Wed, 13 Dec 2006 08:33:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17791.40622.256716.794463@rautu.test.fi> Date: Wed, 13 Dec 2006 08:33:18 +0200 From: Juha Heinanen To: Subject: RE: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> References: <457EE9D3.1080001@acm.org> <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sip@ietf.org, petithug@acm.org, audet@nortel.com, 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 just a reality check. yesterday when i was going to make some sip tcp tests, i tried to find a sip phone that supports tcp. the most popular ones from linksys/sipura (cisco) and grandstream didn't. -- 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 Wed Dec 13 09:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVRV-0000th-LH; Wed, 13 Dec 2006 09:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVRU-0000rS-8v for sip@ietf.org; Wed, 13 Dec 2006 09:50:44 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuVRS-0000SR-Sk for sip@ietf.org; Wed, 13 Dec 2006 09:50:44 -0500 Received: from [10.0.0.160] (adsl-70-235-190-149.dsl.rcsntx.sbcglobal.net [70.235.190.149]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id kBDEoBaH040250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Dec 2006 08:50:16 -0600 (CST) (envelope-from bcampen@estacado.net) In-Reply-To: <953beacc0612121550p2fb16322sc1f03c6b3223b86f@mail.gmail.com> References: <953beacc0611221326r5ffb9138uc09a9ac33d7f3d87@mail.gmail.com> <1F71FE5E-4DD9-4B5C-854B-F40952C2B4E0@estacado.net> <953beacc0612121550p2fb16322sc1f03c6b3223b86f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ACA8F77-B70D-4B7E-A5CC-93C28180E247@estacado.net> Content-Transfer-Encoding: 7bit From: Byron Campen Subject: Re: [Sip] outbound-06 submitted Date: Wed, 13 Dec 2006 08:50:05 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: SIP WG , Cullen Jennings , 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 That sounds reasonable to me. Best regards, Byron Campen > Hi Byron, > > We could add text recommending that the UA compare the rport/received > with the XOR-MAPPED-ADDRESS. That would appear to solve the problem. > Can you think of any problem with this? > > thanks, > -rohan > > On 12/12/06, Byron Campen wrote: >> I have a question about the usage of STUN as a keepalive >> over UDP. >> Are clients supposed to start sending STUN before they try to >> REGISTER? If not, I can see the scenario where a UA sends the >> REGISTER, sets a timer (btw 24-29 seconds) for the first STUN >> keepalive, but before that STUN request is sent, the pinhole closes. >> Both ends will think the flow is ok (the STUN keepalive will open a >> new pinhole, but the UA won't know that), and the mess won't get >> cleaned up until the UA re-registers. Sending the keepalive "soon" >> after the REGISTER would probably solve this problem also, if sending >> before is not acceptable. >> >> Best regards, >> Byron Campen >> >> > Hi, >> > >> > I submitted -06 of outbound so folks can at least take a look to >> see >> > that the many small changes we have agreed to have been >> incorporated. >> > I also included the proposed text for FASTEST, since the draft >> would >> > need significant surgery anyway if we go with CLEANEST. >> > >> > Until it appears in the archive you can find it here: >> > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- >> > outbound-06.html >> > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- >> > outbound-06.txt >> > >> > thanks, >> > -rohan >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP 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 Dec 13 10:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW0d-0003E9-Dk; Wed, 13 Dec 2006 10:27:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuW0b-0003Dg-Ol for sip@ietf.org; Wed, 13 Dec 2006 10:27:01 -0500 Received: from www.implementers.org ([69.55.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuW0a-0004zV-6c for sip@ietf.org; Wed, 13 Dec 2006 10:27:01 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 6991A3A02143; Wed, 13 Dec 2006 07:26:55 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id C78623A0210C; Wed, 13 Dec 2006 07:26:53 -0800 (PST) Message-ID: <45801BBD.3060307@acm.org> Date: Wed, 13 Dec 2006 07:26:53 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Erkki.Koivusalo@nokia.com Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org, audet@nortel.com, 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 Erkki.Koivusalo@nokia.com wrote: > > Hi, > >> This is an implementation problem. Outbound MUST support TCP and UDP >> because RFC 3261 says it. The only thing I ask is to let implementers >> do their job. >> >>> And secondly, I believe complexity is >>> the biggest enemy here, much more so than the performance concerns. >> Well, complexity is relative, and again it is not about >> performance, but about compliance. > > This reasoning sounds very confusing to me. > > Is your suggestion really like this: > > a) You do not actually have any technical reason why Outbound > must support UDP, not even the performance would do. No, performance is still the reason why *I* will mix UDP and TCP in my endpoints and servers. The discussions about making UDP obsolete are not new, it is always someone claiming that SIP over TCP has the same performances than SIP over UDP, it is just that the SIP implementers are morons who do not know how to use select or poll, or epoll, etc... At first I believed this, and I was ready to move all our customers to TCP only, until something I read made me doubt this. So I asked our QA department to write some tests and to run them on our servers. The I-D was written because of the result of this tests. The problem with performance is that if I publish my results someone else will come with different results to prove the opposite. Also not everybody is interested in performance. I am, because we have to pay for every server, data center, etc... to run SIP. I guess that the vendors selling the servers, or the software licenses does not care as much. So I think that we should accept that different members of this WG have different needs and that we should not have any performance discussion, as long as the implementers have the tools they need to design servers and endpoints that works for them. So this is why I am switching my focus from performance to 1) do not prevent implementers to use UDP if they need it and 2) anyway RFC 3261 mandates UDP AND TCP on all elements. > > b) The only reason for Outbound to support UDP would be its > full compatibility to RFC 3261. This is a good enough reason. > > If this is the case, I would ask WG to consider this reasoning > very carefully and if it makes any sense or not. To me it sounds > like: "UDP is actually not needed but because the WG decided to > mandate it a few years ago, it just has to be there." > > According to your I-D the client has to anyway support TCP (or > other congestion controlled transport) so it would not even allow > to implement UDP-only clients (which might be desirable for > some vendors that currently only support UDP). Thus what is > the point with the UDP flows ? Why could they not be optional > for an UA ? UDP-only clients are not SIP compliant. So how a UDP flow can be optional if UDP in the endpoint is not? > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: 12.December.2006 19:42 >> To: Niemi Aki (Nokia-NRC/Helsinki) >> Cc: 'IETF SIP List'; 'Francois Audet' >> Subject: Re: [Sip] I-D: Preventing Fragmentation >> forClientInitiated Connections in the Session Initiation Protocol (SIP) >> >> Aki Niemi wrote: >>>> Performance is important at least for service providers, >>>> because they have to buy the hardware to run the servers, pay >>>> the licenses per CPU, pay the datacenters cost, pay the >>>> sysadmins to run the servers and pay the managers to manage >>>> the sysadmins. >>>> >>>> So yes, performance is important, but perhaps not for the >>>> hardware vendors, the software vendors and the sysadmins. >>> This is all relative. >>> >>> Your draft seems to add enormous amounts of complexity -- to >> both UAs and >>> outbound proxies -- to get around what you claim to be a performance >>> bottleneck. >> No, this draft is not about performance. This draft is about >> be able to >> use UDP or TCP with Outbound, i.e. be compliant with RFC 3261 (Section >> 18: "All SIP elements MUST implement UDP and TCP." >> >> The performance issue is about implementers be able to use UDP >> or TCP or >> whatever they want, as explicitly authorized by RFC 3261. >> >>> First of all, I disagree with the assumption that running TCP >>> only is that much more of a burden. >> This is an implementation problem. Outbound MUST support TCP and UDP >> because RFC 3261 says it. The only thing I ask is to let implementers >> do their job. >> >>> And secondly, I believe complexity is >>> the biggest enemy here, much more so than the performance concerns. >> Well, complexity is relative, and again it is not about >> performance, but >> about compliance. >> >> I am currently implementing my two drafts about fragmentation in my >> endpoints and servers, so I will have a better idea of the real >> complexity soon. I will eventually ask the chairs for a slot at the >> 68th IETF meeting to present this. >> -- 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 Wed Dec 13 10:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWFx-0003Fj-Pr; Wed, 13 Dec 2006 10:42:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWFw-0003FU-8S for sip@ietf.org; Wed, 13 Dec 2006 10:42:52 -0500 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWFf-0008QZ-DF for sip@ietf.org; Wed, 13 Dec 2006 10:42:52 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zrx.siemens.at with ESMTP id kBDFg223008969 for ; Wed, 13 Dec 2006 16:42:02 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id kBDFgI2a003758 for ; Wed, 13 Dec 2006 16:42:18 +0100 Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 16:42:18 +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] xcap-diff-event Date: Wed, 13 Dec 2006 16:42:16 +0100 Message-ID: <3E4278088AD82C48B4663DDFE762CEF302407BE9@prga004a.ww300.siemens.net> In-Reply-To: <457CF433.4020707@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] xcap-diff-event Thread-Index: Accc6wUhjIvmTtKwT1OQWH8fWjD0/wB4OJeg From: "Dostal, Pavel" To: "SIP IETF" X-OriginalArrivalTime: 13 Dec 2006 15:42:18.0165 (UTC) FILETIME=[45361650:01C71ECD] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::061213164202-4CFD0BB0-2DE7F3D1/0-0/0-15 X-purgate-size: 1435/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Jari, In chapter 4.3.1 In my opinion the "path" parameter shall be stated as mandatory. In chapter 4.6.3 the same handling is defined for selector locating non-existing element and multiple elements. I'd rather distinguish these cases as subscription to non-existing element may have real usage (as stated in chapter 4.1), but subscription to multiple elements (in the sense of one selector for multiple elements) shall not be possible at all. Regards, Pavel -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 Sent: Monday, December 11, 2006 1:01 AM To: SIP IETF Subject: [Sip] xcap-diff-event Hi all! I've submitted an event package i-d=20 =20 about syncing xcap resources with xcap-diff format. The event package=20 part is pretty much similar what Jonathan had in xcap-package before it=20 was "moved" into the config-framework. The biggest difference is=20 probably an OMA requirement to have subscriptions to XCAP components=20 also. Any comments ? thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 13 10:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWLM-00067k-Hj; Wed, 13 Dec 2006 10:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWLK-00067c-NT for sip@ietf.org; Wed, 13 Dec 2006 10:48:26 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWLE-0000pH-3M for sip@ietf.org; Wed, 13 Dec 2006 10:48:26 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 305443C4AD; Wed, 13 Dec 2006 16:47:57 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19655-01-25; Wed, 13 Dec 2006 16:47:56 +0100 (CET) Received: from [192.168.123.17] (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 617223C042; Wed, 13 Dec 2006 16:47:47 +0100 (CET) Message-ID: <45802084.20208@it.su.se> Date: Wed, 13 Dec 2006 16:47:16 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Marc Petit-Huguenin Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> In-Reply-To: <45801BBD.3060307@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.569 tagged_above=-99 required=7 tests=[AWL=0.096, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, audet@nortel.com, 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 Marc Petit-Huguenin wrote: ... > So this is why I am switching my focus from performance to 1) do not > prevent implementers to use UDP if they need it and 2) anyway RFC 3261 > mandates UDP AND TCP on all elements. Not even RFC3261 manages to get you everything if using UDP though - large messages for one, security (SIPS) for another. As I see it, it is too complicated to try and make SIP over UDP work across NATs to even try it. For those cases where the properties of Outbound are desired, everyone will be better off using TCP. For the cases where you have small messages, don't require security and don't have to worry about NATs or firewalls in your network paths, then UDP is fine (if I don't think about the re-inveted reliability). I don't mind anyone using it where it actually works. I'm genuinely worried though that Outbound with UDP won't actually work in the field once finished, because of something we fail to think of at this time. If anyone can tell me of some other UDP based network application that actually attempts to work through NATs by using keepalives (that means: not DNS), and without users configuring their NAT with port forwards or similar then please tell me so that I don't have to worry that we're spending all this energy chasing a solution that might not even exist in the first place. There must be some kind of precedence in this area, I'm sure. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 be@arteiris.com.ar Wed Dec 13 10:55:21 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWS0-0003kl-Rb for sip-archive@lists.ietf.org; Wed, 13 Dec 2006 10:55:21 -0500 Received: from [86.92.14.244] (helo=ip565c0ef4.direct-adsl.nl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuWRf-000152-GL for sip-archive@lists.ietf.org; Wed, 13 Dec 2006 10:55:20 -0500 Received: from [155.159.4.16] (port=10406 helo=otwnksbtiiu) by arteiris.com.ar with psmtp id vPHOnJ-F7b65f-00 for ; Wed, 13 Dec 2006 16:54:30 +0100 Message-ID: <000901c71ece$ebc3ea50$00000000@bartelin9c11f6> From: "HomeYahoo gt" To: sip-archive@lists.ietf.org Subject: equally interested two use Date: Wed, 13 Dec 2006 16:54:07 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71ED7.4D885250" 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.3 (+) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 ------=_NextPart_000_0005_01C71ED7.4D885250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71ED7.4D885250" ------=_NextPart_001_0006_01C71ED7.4D885250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sure watch with than, one meaning if on modeling. Up dogs mention, poodles equally interested. Show up dogs mention, poodles equally. English news topic, yellow = listings, digit zip! Th century chairs, instead old, digital camera, = reviews sure. Link url document our index, indexed urls. Looked something similar, links. Th century chairs instead, old! Our index indexed, urls titles. Set = five, keywords special character when shortcut? Results try narrow your searchfor. Titles copy inc, rights reserved. Modeling make specify fashion or and = excluding by. Urls titles copy inc rights reserved privacy policy. Zip code add key = skip past. Any english news topic yellow? One meaning if on modeling. Any english news topic yellow listings. By default returns only pages that? Looked something similar links. Have looked something similar links, related searches under, box. Specific, describe exactly youre. Looking more general terms, will give. Unique, can enter directly, site = documents within particular. Appear, in many places they usually. Innew user upsearch homeyahoo gt search, basics gtsearch tipsyahoo. Index, indexed urls titles copy inc. ------=_NextPart_001_0006_01C71ED7.4D885250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"at"
Sure watch with than, one meaning if on = modeling.
Up dogs mention, poodles equally = interested.
Show up dogs mention, poodles equally. = English news=20 topic, yellow listings, digit zip! Th century chairs, instead old, = digital=20 camera, reviews sure. Link url document our index, indexed = urls.
Looked something similar, = links.
Th century chairs instead, old! Our = index indexed,=20 urls titles. Set five, keywords special character when = shortcut?
Results try narrow your = searchfor.
Titles copy inc, rights reserved. = Modeling make=20 specify fashion or and excluding by.
Urls titles copy inc rights reserved = privacy=20 policy. Zip code add key skip past. Any english news topic yellow? One = meaning=20 if on modeling.
Any english news topic yellow = listings.
By default returns only pages = that?
Looked something similar = links.
Have looked something similar links, = related=20 searches under, box.
Specific, describe exactly = youre.
Looking more general terms, will give. = Unique, can=20 enter directly, site documents within particular. Appear, in many places = they usually.
Innew user upsearch homeyahoo gt = search, basics=20 gtsearch tipsyahoo.
Index, indexed urls titles copy=20 inc.
------=_NextPart_001_0006_01C71ED7.4D885250-- ------=_NextPart_000_0005_01C71ED7.4D885250 Content-Type: image/gif; name="that include.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71ece$ebc3ea50$00000000@bartelin9c11f6> R0lGODlhZALMAYewAAUAAXIGAACKCXeKAAIAcYIAgAB1fce8vrnnw5/U7EMVAFIrBocbAJEjDsoX AN4lAAg+BiIyAEdGAF5HAIM6BKA8ALg7AdQ5AAxYACRhADdUBl1mAXZtAKxRAMhSCNRbCAiIACqB ADSMDmlxAIJ6AJaLAL13Dt6AAAKbDiaXAEypAGupAHihCZWmALOpANurAADAACzFCzPMAF/EAHm8 AJHBBMDAAOa3CArUABjYAEbdAFLgAIHZA6PRALnmDtrsAAEANxwCOT4AS2MCQnkESqYAO8oMSegA SwAWQBwmMjciOF4ZO3cmMakRS8YdQOEaOgA/RRFIQzkxOl80S344Na1CMcU5Qd5MOABrQRNsSDRt PWZTRYVUDZpjObFjRdZaPwx4MxV0NTx7P1x5Qo6CM6aESMh4SeOOTgSgOCadRjqpRmemOH+fN6CV TrqkR+muOADDNBzCQj+1QW3OMXO3QZHIPcCxN9W+NAPSNCXlTj3kRGHTSXfhPKzaNsHRSObcQwAA chILjkMAi20Ai4kAjpwAeLkCdNQAfQMjfy4ShzIjfl8fd3Qrg64rhMsRhucSfQxGjSpDcT1CjmA6 ios/g59MesVDgetEiABVgSVedUxXh1ZScnVRhJ9ijMpYjORUcwJ5dB2IjT50dFV9c4FyiaR6fLOH cux6jQCojSCWgD6ogWmqdX+acpWrd8iVdumpjgK2eSnHhD/NfGnEhnuxfZ24i8a9etTLjQDnjSHs ekzTi2zddoXYf5jrgrXifuLkdgADshMOxUkCuG4AxIoAzpUHt7EAuekAxAAeyCEWuEcqxmMtuHYd spMtzskexdcnyg4xtS5OvkRLwmVNyYREtaFDxrE2wuU3vQRizCdgu0xbxWJhvnpdwaVmuLlWwe1Y ywBzxBqOszqAu2CFsXKGsZd2wcR7xtGHxQCUvxmSzjeuslinu3KWyJaou7Scv9SewQDIviXGxUS9 vmu/uoqxuJq5sv/x86Sbnn18fv8ADQL/AP//BAkK//8C9AD39fH5/yH5BAAAqH4ALAAAAABkAswB Bwj/AGsIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMuvHatBseOHQVy9KixpEmC587VSFmQpUuW A1WenEmzps2bOHPq3Mmzp0+bIUGKHBjy58+UKmWuVLpSoMynRqNKnUq1qtWrWLM2LEpUq8+XLp0u RZrUq9mzaNOqXcv25EiPIIt+bHuRbNmlKMU23Uu3L8FbNW4JFuy3sOHDiLcSnTs3sUSmTBdGdtwW MOXLmDOrfUtS8+O9T5HqnezZKuHAfweXXs26dcmRjbm6zou3bOimUGebFmgZNW/fuoMLHz6UIOfh tp2SHRuTNPGbhFX/Hny69/Pr2DPLvq60+2i82X1a/49uubz18OjTq28LtT1f5+szUgd8emDv+vHz 698/1XZS9/zNRF999AVWoH0BJoiTPAQxqKB6y8H0oHwI2hedgdJNqCFEdtgxkIcCOcigiBtmZ1eJ F93Hm4oDAuciiokFICNPINbooR0kiijPjg7C6GOJLJZnoIsXziTjkTOahCSSCS2Z5EBOBkDQkQVR iVCUVFp5EpZL1qClQV9a1GENN3ZYI5k7hlhDjz+2qWGLBRJ44JBbciklQ2GCyWWVdgq0p59PAnrn QX3m2ZChghYaKJ+DivnhjVTimGaIaU7q5qX8kVcdcKptWlKXUC56paiMhqolqIJ6+eWTYSKqaqMa uf9a6qw4lUkmmUeO+eGaa/LIJqbA7hcnfnSeh5GseJI65aKnKptqk8w6i+xE0z67LKwngUimtrjK OKKklPYa7LjxCWlQnEQaSxGTCzlpKrt6YpulrPRGi62po94ZZQ3zgLqvQnlieW2i8BKcq5mMMmmH u+8yieqrq7r7L8OvhoovuRhbRJ6FcGKImrrrOtuwlf/GazKy8Cag8sUsm0xoknZ2WXK+8VJMssAG H3yrrlEuvO+OMbOLM8TzyjwxzDffm/HSEA3LMYIZHityxRejLGrRyXaZQMtUvyxw0gHMI6jYqlrb 7tVJV522tToTBKmMOPoMtzxM0g12qkLf/e7eEOP/fTPTgEdU3X3oEq5koBL/abW8M0ZccJQqJ9Cq tHtS2W+S81w+KNldn834oM3qyyrSjYbJba7yyA2i3QEAPTrojSNOOq2dp+3w1IHnviKdHMtppOy3 47z4ycB/ubLkR6o8udKdD6w5vwYPfCjasFfP9uwCyZ39mDXm2m3rHrJ+vfWOm1078Dk/rPv6Bx3o tIW8Z1Sw38wPX+r8zW9dA/JS8l+DL//zhasQdaTMFVAgYjsa82g3PrVZr2vae9SHvKc6Mx2JQaHD V/mat8Fn+Qt/6XFGDUQ4wrNkTmycE9ZvVrQp6vzuc82THrRglUEGRu5VW6OSLwAoQBkB0Gs0q1jm /xB4wrVlzWVdM6IRO6crQaVOex1iHQZfp0H0cdCK4xMd7oIjQhKO0BlgHIgXr8K5FGaqcBgi1uHK 9zgteq5hcKzi1ubIJP4FgIdM+iEDTZVAGZ2wbGOLYRBlWMNChq5M3HpV3JA0RW8lkYp5w17LIlk9 LdJwi5gBYxe/GEaBdHKMVhkiChN0ISGZiyYxq0E/FKe+kc0vlXbSnx2X9EM9cs2BA9HckvoIQhmy LIMHqCHRkHSjbU1wSazrkuseSLWhLS9hbSTdJReomTBqkpNfzGYXQWmUIRJklAEyHMhqsq9+9EOV q3xYK9M3w2jWEZo+/J889zi25+USVGRbpy8b6P9BKroyANri3pi6JLcL8kqYoeug+YZJu2fqxprZ FOMmIVrCn6DwhOCEUYuick5zDuScV1nZ/iIXuR36IgEmJQgPLXJRb2KUX2a0yQFqcICZ0nSmNXXI wbiXvVtJMHzh4xX7TKLJbWrzk57ciR/8UIOlLhWm4PQm9GI61Ih4FKRomaP+BJLSWu6Qq/OECNlc OlVRwpQnOL0pRIjZU4QV061rimJVS7JJbJawrte8plIF4tS+fhOjUp2rVT9aEKxWRaTHK+lXvxrA WkpkrIA9q1FqmlOcUpamNSOmjXzKWbhyVrAaQaoXjarXonYyI0xt6kCYmtqmzsMPYy1IRkH7EHP/ dhSdqjzLHPcnkK0tFqwrnchFiQjVP+aksmnNKWbVei2F7Yynxuzp9mibERIitaIQBaVpuVkRpxok tUt9LWxhm0voUdeqV0WnYUNKkJWZ1JYDcSxFjGteBNZXpjZN63IFYlmbJgSub90ews5LVOwe1aic 3G5Fu9tU8DbYwQ9mbXhnS2CGXLWj69WKSFWqx65iZLb0pepJLjsQypp4vwsR6JnOZMwmVjgip1Ww Xa1717vqdSKtXa2EG8xXfj1VteV9MUSw6lG6vNeW8K2IWSMr4plUlr/5Ta5+HQLgnUlXyDAerTUR vOUFW7euFJGwdx/cY/K+dpSwDSyWF4Lh3PYl/6VgDWBJzCpZnFw2ypj1r38boitb7cpMiVzzQopK kNHOuCBfTip3HQJhvv6YtfZ9qqSbLOjC9oMfmEZMV5M8Z5/0V7/K5S9zD4Jpfjy3s4AmSKkrrZBt UtS0C06qRBWNYx73+NZjBu94HQ1khsilM0wrtbCHXYNVI8TYDxl2pimibFPHV6UFQbZJmq3siVB7 2fu17E1n+oeBdFsgyOYWIhMp7YWUe654LbQ2Zw3rL4O5IblW7Y95vGNJh3fHvu7McZZ27VWfeyD/ Vkizrd3vhgT8Iv0+uMCvLeVQb/vb3f52sbE9XSsbROHRpji6DW2QG3tcjIiGSF/9CumSAxnSOv9G OUKEUhCWb4dc58Y4szWebGGrmuZTkTlDjL3nUDu8IBH/g9CFrvOL4/zYR19fdhHdZW7S+LQSUbmj Tf7dCOP7IHExDlxE8nKY07zoEQF7xp2tFrEjnex6Vi6JKyvxGkj8D2YHd9KNTnbBItiu6wb5qxcN b14nZOTzFvPUcwzsoGxdKHHp+qViPnCAY5vYC6/7xA9uc3NDXu7OpvbYLx95UnPe85K36aprOnpq QxzZ1b556jFf7riPy9Wz9iRpbWxgV/O9IIDnNYTxrWuCNLorxTFI4oGNMcY3fvKT//zYHb/65Vt+ 9ca+NvObnxDjK1/1Az+AvzM9U+m7PfrH937/8iuP+fO2+yA0xq6WQf6QR8t7IY8es+6xHpSPwObw cFF8m6xf/vKjXvLOh3xyd3bPl3ngZ4DL9n9kp3Otd4AAOH3Vpn3KRlnC1m02B3eZVnka+HgJSHEK KGQyJmtQ90lNx2gI0WiEV3KCl2OpJReId38sR3xeB4Af6H9zF4AM6IHEJm0H2H8CyIM36INCSHka l1yXh4F1V2pEl4E6aGpAiIDhF4SBM3vaZWDYZHvp13et5X5kZm/xN3V+h3/CZ3gkMXwzSHfMl4bU B3oQ+IBp2IYC2H89KIdNaHAa94TVh3P+VWqhtmoR54dKiId4OH6X53rkkn4TpX435mWJCG+B/9dr vCdpgyeJ8xZ8Zbh1XVF/MggsxveGP7iGqod9AUd+aliHn7iAHZiEUtiAquiGcVgQFEhxSOh235dp syiIpqhwhsg0WRhrsnd77UdvKaeCvrdaOmZ1TAUbLjcULmh/logpneiD0UiAbEiNoTiIc3iKobhz d2iK1Xh22IaEEqeEyIeLrSiErFaFeZWFYFZaEQF4KOd+9oaMLNhrMWh4v5Z1mjgu0/iBHOiKcfiP eWiOUEiHqFiQ6GiNrLeQCrl5xiaO5WeBTJiKTuiADDmAWEaC66h3W9aRUCdyDpZrW7iFt1aM8sd1 zLhv9bdvwdKPAql5oGdzMAmOjTeT2aiAoP+Ihg6pi963fQdZbRIJheQnfkQphVNYaE/HZY2IlDjm XfUWhvSIa7x2f5iIf2S4GGeIgwI5fpG3gUV3fKyXi1sZljn4gDnZhjK5lTM5i2S5k91IimIXD/Eg EHMZLGNEaIQWUb4oeyBJZu/Xa/JGclHJY4nXGJiYdayGHrvoE35IEEHXdmYxl3V5GXfhEyQoaxG1 iJi5lwzReybnV8ZokoSndc5olfl3moaZmK5BimmhhBHndkN3FnU5m3SJGN3xHz9xl3unXUoJjFUH hsPomSVpawoRG2VIlfqof6qJGDO5Fg8pdLQom5JJl5I5nYbxEsqRm1Z4XXiJhU0pmL8nf/H/GJgt p4yIqW+I94zLiRlg6ZxGeRW0WQNyORCTCZ/y2RCQkRuWuZRM2Yu+eRAjeXIq6IW4Vok5ZpixYX8s uZ4MShfzKZfWKZ/1KRW0GZ8GIRqTAR834Z1394slEX8iOXKQGJIJQZWZqIxV2aAqihaTOZ3VCaFW 0aL3eaFggaFW8W6Kll3/+Xe455fk+ZTkOZykaRzJGYMreqSRWZszWp1TMaH1OaF60RIaqhMjqJt6 iRHjGZosyIW4N5rPWJrHmZpIOqZUwaQwSp3zSaH32aJQOhZh4R9TSqVXmHcfCpjFOH8BKoklyhkv CHxk+qdVMZtPKqFtyhMvSqhn2hLZCR5x/6oQtiAQtvCoj2oRd3kTKkeJK0iMDpGe+GiigPqpTVqb hxqjDyqh9NkctcEcfAERkVoDkzoQrboWevp+JPqXobkVCapvoLqrRvGgFRqhvVoQgwqlGHqbjUoQ kjqpkuqqr6oTQwedkGmCXXh1gTmrikGGC8qr2ooTLkoQhfoTbQqhE1qsMCEhCXEHNXAH6rqszNqu rgqpzToTQUeLrxmttVZmuual+aar29qvPVGq1EmqouqkirqocYqu6pqu6Nqq6Aqvypqs8ioQ8wqb sAmdWph7+Wpr+uqvHLsW39qkLtqtNPoeCJGwCEsQd2ALCKuy6xqrrxqvJ/GaFfusfVlmXf/6ex2b s5cio4TqEBrasAKRsMy6rJHarMkaqyVRr/bqbRDHaJ8pjDobtcCSpqNaEUCrrli7sinbsI+aspG6 sK1atDBLEbE5sRL7dhIbdTZrp1Lbtj5yqMAaESc7tyfLrAubruk6qV5rtBghs49ZtvRqsW47uC8m qB/rEHWLtwrbskU7tEHLtUkbnfV6toEbuDJLuJj7pw1rskH7ruxatFzbtUPbuBdRtkr7tzPrbZlr GDS7usKBtZ0rtHmbsCqrsq4KtoxLukkLrfQanWnbdkvrulnRtBD3rIIrvJlxtQi7uZBKu0DLsLfr te+aEWbbtGlLuWd7ucirFWhrtky7vZr/UbdCS7tiOxDS+7V467Jj6xA0+5i967uAe7zgexVom71v p73zexjjK7tXu6xY+7Wg67WMW7oHcbwG/L4Um79WEZuVK7nFG7wKrBawy7nLu7KQ2q4AfLSh27fG C7zdS7zXG8FRwcCOObmXC8E5kaamergivLidi7dZm7e3y7LoC7GKS8CmW7GUy8Am7LstbBS867eq G6gG8aIsPL9Ae8PmC7vom7J5W7tHK8NIaxGnO7HG+7sJ/MM8gbo6DK33y7uGeqYwyqRrqrPeUAPe cMYTMbcK+7g3vK52+7lhC7br+xBXHL9fnLpaPMJeXML365ghbKgr/KTiqsIcq8ZqDBF0/4uy5quw ADy9/gu6yorDgfy7VjyvJLzHOVG/fvy+D5zJNBGypyqqSzqj2nrGaYzGApHIiMu/y3sQdFy7TmzB 7krFgAzKFGuxfovCmqwRVpzLCey+Q5zFJzHGiaqka1q1vJrKaMzKEiG+MKy8QQuxUHzBtWzLfcy0 D2y/CNzLNZHN1wvKHWwQvDwR8UnGyDzGyLytiZzKzrwQE5y1dGuydwvD0VvDu9vDVxzO8vvD+fDP M/HP+dDJ3yu/0Qq4EyHQA13Ehayk6FzEptqvqKzKq6zIi5y4FAy5LQvHr8zB3Sy5CCy4/Uy4Ci3Q A2HSJ4HS9tu+eazDBT3SCVHSByGop/9aqvUp0C2K0wRR0gAtEDz90wih0Dvd0zXw0yat0kVN1Em9 0Est1EPN1Ev91GrBzGn8zgzBxo38wpsrtC67tS+cz5M7xB7sw6tr1AuN1Bph0iLtwWAMxrlsvWht EHFd0xaazjNq0tOJ1Gbt02Y9103N1Crd11F90kqN0ntN2FCt10qtFVVdEFbdEBUsz0usuJGN1UqM zQjt1mJdzjrr1HzN11Cd1kQNmdVbvF2sy1KtEH5tpsncsw6t03Wp002N2KE92Ash06B9Azdg23JN 1E5t2Iqd2qAt3F7hzMy8xm681ZMtz7DrxjeBx5WM2sLr17wt2gvdvpYM3fHbu91G3cP/jRC+GrBi bJ04XZ3lXd1x7d20Ddj/rNs3QN3AHd/fHdOFXd+1jRVUPdFrzL/RHLuSjdHOLa9BzM3Zu73ebdQF wdO9Hdg9LdC/7HY8Da0ODuENruALzuAKPZtA7drxoNJyKd8LnuCLHdS4LdC7Xd2pXeIVft/Erdgs jt8D8dgPIbux+7jji7Ix3NyRC8LDDHQGPuJPbeF/jeEqPtBq/b2gLdNC5+BL/s/dLeRBvuIy/eEK bp1UfthzjdbqPdwrXgO7LdiDDdBdPtv0ndj2TRzMy7wFobxbreMRa713TNbTDeS0/d0uPt9S7uTw +21C/QcK3eT5EHEYftu+rdNC3eHn/23Ic9nX+XDlB6HldC7iRt7eJv3lhx3VYj7pZo7bLX7mukHP bZzVab64oA7Eb83ZUnvghX7We+3XnD7Ofq7ngP7kgU7r0KneGA6jeF3eVk7ciM7q9w3pL57i+fDe AK3bqi7UUJ7kd47YxO0aNB7PFEzqbJzENtG64RzBye7sQ67sdI7bwgzoZ6vWah3rA03rhM7eAx3b /3zlbJqowi6fWb7YWx7mMo3skT7k+l7m6t7pw+4Z+0vZ9KzcbazmzurJIrztdv7tDO/UrSvusMnk KG3ufJ7vtu3ii97uEe2tv37TYy7pIM8QRF7sXp7sR83pJN7v3D7fn57m0BzPWu3NUv8B36vO8s++ 3tcNdBQvsSB+8Raf65JZ3ngd3oSK0uze6PJO7yNe7yO/8imv7j9v8etRwYw82fZM2TL/E56d1Hgu 5UNN5lyP6QDdwbQO7Oc+4X9u8yGe5Fe+7rB9zknf6OI69J699Wr/6Pa90Mb+73Uf3EFeIjme41Vv 7YCqI2pyGVhe88z+2xt+8npe4N0e6BS+4fu+9osP0I5OsEGP+XSZ6Jd+83i/6XoP5kle5zi/9c1+ 98MRw6Gu1YmLpJPSIyNiKYlB+YMe5aKv+H3uxwr+rAi+3ikv6W+P1iJr9KDNpJQf8un+95fv4lAv /Ont6ar/HK/f0YQ/pr9SELQPLMT/m8OWTM6ozhCGO8oN3bO+is6G3Ms3rubXf6SyXykDkSPZ7yOo LcRY7MfhHxFUG7ArbMoMDRDxagisUdDgQYQJFS5k2NDhQ4gRJU6kWNGixDt3Lm7k2NHjR5AO5dUY WbDkSJQkDZYM2dLly4V/Cv6RKXMmzRo0a+qEeZDgQIHxhAYFWpCo0KJDB3Z8V+Nd055RKV6rQbWg ValZtW7lGhUnzq7yUKYUq7KsSZUkWXZly7XmzIQ230pFutRg0KN4lRo9WnTjU8BQ23K1es1wYayD FS9m7PVmTpuPpYpde5Zy2oNrEc6rwZlzY9AQI+skPRpyzqhIf/7ke9f1UqJ2WUuE/xr4qVPcoUFS LVwVcWLdwYUPR136tMHIL8miNXkW7cnLBudN71zQ82fiw+eeBstTa926QMOPX510NkTAuZ3ezr7x d1XfiYG3p18f5le5O+Ued0m58lizMmOJJc+q64w66+wT7ivkvOOKNYFua2o2vGCz8KLaJFyvKcEk Okw3w+DDKkSDQpxPQRRTnAi/BkvTL7+QoDsJM8vUCrAk6gqUDjvsQEMAgRp+1A45xvYSCrB4BEMS tqHOoyi9gjjc8KAOFeJtRN8aI1HEg3q7UkUww2zIuOQOIg2u/gZkLiH/bDRrHgJznG7OA4cDMkgE /tGTKz3/oS/Jd5KMksMjlSQovP/XJqpyUIMkDGwhxLLcUrErD9uSt6vgE3NTTolk0Dj+3iqzo7Iq a26lNgNUq8A5EayOzsH6lHXWGvrkc0+pbH3ynVlx5VDWQAPtEy9dCyq2ofSShRK3RSXN1NkTtfrt w0gztVTTTrNtD6zjGHxsJ5guK3XcGv0jcCRXEbwOtF57zRNXrY6lSN6E6HXoqXb1vC2eWQG1Falj 7aWSWds0XA9SZ0uU6Zrt2sLU2qswNfFLbStesDjIvG0QzYz5syg6tWZ0rtSQpVOpxx0NRFmxPn90 +V0/txIYopn/qrXPX3HGF9iBhl0qYHgTYo/ZKdU72CHeSGOYqv2k7ZLaLLEtMWr/i6tuDEZPWRT1 0zM9Irm5Nr8R+VR54NxRxzpzZKzlINuuuaW3G4r7IpyN4nXPJGcNdliAg545w0cLJtrK+CqtamGm OY4KuA+nvvZpqq2WvCtws3awaW4lu+i/gsSuwXNzxRUr3YPUNjm0Yl3OF6FeHWr3oGJbNyhf2euF l1aEoKr7qb7/aarXvPE21u+gGaotSvU0rJLExA/j6Q/nG4ap8Ygh53JSqSfXPivT5toatZsaHpWi kUP/pvPPRzrfxrJXbjVBOVfuytY7gaR99tcZWn34mPe/mXaB2cp/jbqb76ASFJ3hDFdAixn/jAcl DnVIScizUtIMU5PEeWt8PfnS/4iu1bhobU+ELmERd1z0osxpbCNlEZs8xPaNF7IQJeeDzmfahzJ1 1akxbMMTzPq3QOI10HW32xMD+SfEtwmQiFTKme8a5ZS6KVBfRsSfEHMnOEZFUEpGY153oLc0hqVQ KhOrXqWmVbhryCONmBlhGznyPNNoLnxzVGFFUnIqz4Ftfenj44zS9irrfEZ+bWnZnRx4SADKrXZK 3J+8kljE4gntf0ycJL/0dbNJ6i6IxpPkFh/1RIRI7HLF6R4HTQS5h1Uval9SkxtdSRGNZQ4hozkh +Gw5kbG48HM0RJUuW/g5N41FToFMCKxYtidDThKR91uI/xiZP0dGknWQlFUnC/8oQWUmkFaaRKI0 KdksAh4vJl2jSQaZ1rTpyUdEEjtjGt2ZRss455XzHKdkKocmcHmxRSskCS9NAsMZea6FX7MRnVo1 TB0e04rKzKY3FVJNhjJSf8V75A9xZzsDKimK+toZFQ+JLKMNbGgJsRT0kLM0OGJsjJrCngdNNJI1 XqV8mqFnTeGyn+Sg83v5yefmoiMWGobuLC8EHWV4hFD4DfJWC40dEBc60QY21U8zi+ZTYRdJXUHw fxrSWSYLuCdw0sZRBBspQy4IGYaBL4zzkZ5LJPYsLD0MhIkZmU3tyh3wcSun+sSrqPg50JLAEJjq 6yeA0kKgpCJUqTLDKhEt2s3/Zjo1qtSELEM/GtmpTraBx/vqbSBawEFVs6wc4WyVwnrBcqZ1YV/k 2gY9os5TqjJEaqyKWNwZz+fQ9K7zvGde9ek9W7aVfIRtIUApI1gXsjBA8TMZc3fYWM1WsXbTzF9D oUnRi1L3f7jz5BG36UBuxux3m0RP4Ah4NCtxC7VxDJ8sd0PGTCHAUvKlihqp9bVcrmm3r3TQHPE5 y76692NtmmHIACrQ5CI3QaU7qquey1THUrdmzgyiVDHqTV1ld2BRqm5H2QMsbl7VquXdItJwgtLV llLAIUGMkK4h337UoB+GI8lhYHrH5eh2vyKEUT5x2rE6Ku5j/8xjP9cnrhim/0SQrGLuYncMmu5q MVmDEifRRsuUKEtEJ9TSjwkJI18wU2XG1xjzj2C6RuicKmTyfDKP9bqx72Vsr3ndSFDN1bkXrlkt CN7MQQHZ5vpokcrsydCgc1PllkQwpA7xjmoBjLWo3Mkw/QDSi2dc6TK/uNJWqZGb9Atoyb1Iznx9 XlzQeRGApi9V6gNqYQdazLQ5GNTtkfIEDx1OJSlvSP/VKZEWV5Uxi/kwMb4SAoidpU7X5xY1uEWz C7LsWb+Rp6emc49XXJHzZbtzQt3lmv25ELRFmz6mPRihs4jecF4M0sHtck+ARN8Z+6YfwZbxi0Pk YsOmeTmNgfaz/e1sca+InP9l4qmZSh3kiWQ7qAjWpS53SbI9BnxTyhpad8+b7rBerVujvLZHhHSV Mge7UsH+kY3vaBaQ6Vgr/Xb2sl1+kH5L3CI9JaWp143qPbKafZdRcMRl3qlPQlBKnlR0fSrH3o5/ REiUjrF86z1jqNtb3lVxmbjYeHK2ALzZLVfIy3/O6O4El84b55hrE74+wRq4ZK1O+9c5hU3kFb3c cqePXz8lx5a4zCDzpveHYMz0+6q8l2zsitefrXWDbD3mbq9nCe2+05agHSEwjOEuJe/zhbQd84xv i9CHPjjAgdI+ovYvQn7wgxqgPiQxZn3ULUUi+hrGzAhIuZrYvHKXvxzgzGb/ObM5r+WNdexbtzS7 RDQ/eWBmviEKB+YeN//7rXhe1yKlMoqA27WFqD71p78IkObdth+J/NLrNDalaS8PM6McNLvXfcsN z37oewpjYvTvzTsiWPxTXv8G2f/zu61t9Om2+Os8RxmroKu+jNMO4UoI1eM+7puIl/E+veO77xs2 MmO68Js99PMjAck6xfM33+u9w/O9AfQ1UuuxfSq++0s+ARRA/zsIysMzbQPAEpSKKTs0Qvu8QUtA MEG90/NBg/jBB3yIZJIxGTO2gng31iu/IPk+Y6O9tgkSksmvtuC6EEw8EuQ93atB3zoTWsKcpPMI /Uu7GGzBhFA4MrS8ADRD/y7siaD7PDj8JIaIDfpwQO3bvoJ4wCFkiHcTkvIzP74ziKWTMaY7Qigk ifOrq8HYOpg7PGh7RBBcvBL0sVjqqQVcweZLvogrwzOEQf7DP/5rw+gTPR0kmHKbQ6VAlOFwwNQL wjzUw1Z0iI9zmaZjQib8PgqkNJXww/PbOayrQi10xCzkvSs0PC4UNQ26pahgvhjsv4TTRBp8QVH8 CIoTtLEqGoU4FFXci9AQwj0EwiHcQ4V4tyTcO1zEEwp8wkKkPV5Ev2T6xa3IvREEwSzkuvabRjkj vt7KCmZcw+VjPn+MRhrEx5dYlouzsoagQ6GgB6RgSCdhDG98xTzcPh+8w/9xfJm2CUS+e0IJPMJa 9DSQFDyYWLwtTDxG1DpGJEZRBEMAUww0lEY1xLP/W8P8g0mCrIhC2zBEWwjViAd6oIeB+MkmEQig BI0fxMOIdEUgXIhZNCTvK0R07MNzNL+ReDccYwyvk0fEUzz3K0mC9MJNaUZoTEOatMmbtIgSw7iI GMqgcEigZMifXAxYXEo9jEhxJMImVEfvK4h1fMooxBP0I7wqZDnEg7mstEdjPEtOcb4xbLtQdD7F dEN0W0uffMvKLAihjEugeEvFOMpYPAghlEg8HEc8SUJyREKOJERaNELT7MNy5DeVNMwPrEf2s8LI DEtQLEO0a0wXvM3g0Av/oixKofTJhQzOomQLi2xFz2RA5eTDciTHJgREJIwxQmQ90yxN6CSO3atH EkzJk/TNxUS+TERDFuSKBEiAg0BP8PQJgnBIvWBIvljIoDzOrrDI5DxKurzL14zAj6POjczLJWzN 69SN3ttKLNTC3JPHYVxPFNnE8ZRBmUQfs6wI9TzPgjhP9WRQvvjJohxKoFQN8eBQuaxIOyxR0EzO /WxNP8zIeeNI6kyI+ilCrCTJlDRJBA3BR5REDaUPxsxECVXD/esJ9MRQCx3SGjDS9fTJ+AzKoYBL CBFO+swKEmXFBlzKiUTR5/w4GM1II/xIvZNRAv03xLxReuzK7dzRFAHA/yCFULJ8iQpNzyON0wv1 TfgkTuKsgbf8UDoUUTxFzhKt0lisy89kSr0DPwE9zS3tw0JdP0d8v0Y9UO5EUxVx0N78UckLiSHN 1Dct0gvF0NtsUiXFUztdSLgsVczkzPoUzSD8Rv28SENF1KZM0UMF0xk1ye1EyX9bUElVkN2EzB4F 0gmFCE490gxVCCKl07bsU8zEUye9i8o8ziiNiuWcSKQk0YhoyhjlRRhNpi/VzitMiBoVxnvc1QYl z14NxU8UUmJ9UznVVDm9SYcMSqOAzw+F0s3UTGWtTypVSoqEwETNzh7Kzln8S+EgTO88UNukR3K1 j8ZsRjUtT5CoUE81CP+JJVILJdaz1NNRHUrxsAv6FNFolVJvqIGR9QZvsFbQhMAv5dZt5VZaDY2Y +04rFMHEXFgeDVKfc0Z/7AhPRVKMndiJjUzLbM/itFOjONWDQNWQ7YmTLVmnJdlAHVRZVFQBNVRB jEJYfdnFgMRxJUkbtdk0BdYfdcGB5NkM3dR3LVafLVYuBFk95dP57FN6ZVaDWFqXGFmS/QGTJVmT 1Vu+HVksbQin1NL95E+E0Nb2UNAEzdGY1VWw5dEW3E1NdAmLvVif7dR1ndN3FUURHY/NZMufUFqt 2Fu8PVm9NV299Vu+rYhsLVT+XFEVJdzELdBhDNfHDZNedcZgjYieNdb/OF3byv3UCtHYjgXZurXb kDBZ5S2IvlVOpyVd1nVNrI1V1zxNrYXZ2SxGG63Z260PMmzY3eVdtAXa9LTc381YhCDO4YzXpeDM PEXel1BevM3bv63fjRhYReVFRLVa+3C/RsTV7tWWMZSKis1cd2XboL3YNoxLkLVTBg5VhOBT+E1e hZhfCy7Z7utWrCVYWAUTAFZYHQ3gNBXLqBhW83XX3z3bzJ1G4ZRb95xPaK1bZm1hmMBgG2be5V3d 0uUI6ITdg8DI680Oxj3JMxVhzjvWoJ1TTTVhfPxYBubQPD3eU8XXfG0J6MVg5s3i0sXi1b1f8IvR 6dUWmjXi+KvYAjZS/069XHilW81sYbt936y44B3OYYPYYaidX9b94RUN4nniYzJ2pQM+X4ml2HVl W859Y7id4iid4IvA472F2ju+YfvFY6Wrnx2TXtn9Y5saZM0lZBRWW4JsYwme4ghOWrplWtK14CzG 4Tu2X1K5vezAxRd9iUXdX02mJ05G0rVN4Uzt5CaGY7ldVhd23yq24qeF5Ehe5Sum5OFSFfuQZesM CW11yh665U1mV/Ll5c3d5kPGV1EW3XxVWkaGCDueY4SQX1Z+ZGS2oxuBZdDQSP8EiT3eYOz0Y2vW HmzW3N49X6ENZjaOYigOaBkW5o3I4S1W5XN+2kdW54i4yvIZDlmuTv/W7AjYZdkvvudXUmAVbldD VuNQJmhlheKQ/uYnNuWOQOdI3uKFkF9mfoj8GheQZIwXjWeXsOTSxM4wxmg3slxDptiN7ml4fV+A /udhHmgptggulmQtfl6VpuOGZh+ohsfgmOlZ7r7XzOnnJFidHqEDPlZCRgig/uiEsFeRZuBldeJx Xuk6bmWExuEbdmqX5pySeQk/8IMasOuI8M9AXIiqlggt7dbB1eqtzmi0Besk1tBFJmbjRWt/Rmos RmeW7uJWZmuJILA1sbqPsGu8LojNdojWo8C940uKftUwDuzBBmSwTttODWuh/diRZuMZPusnjuKJ 4OJkTuXIbumWXoj/q3yOlWiJztZsiMjF7+PL4qZoMNbjq83k054cNEZjQT5sNBVnoS7rpKXtYo4I hlblVK5fOt7thrC9GxFMi6jru9Zs8+5shYDneKZpHpbeDbZp5m5u51Zbnmbtx6XiGRZlk65tg5bs 7z5mO67sw1qz3uYI8zaIuk5wzzbuLm1v5A7YapZV+s5oY2VXxgAAAMjwDReOFtbwNi7ls6aIhV5l LV7rOe5uds4t30ZwvBZuBmfwhiju1gttLy5t0rbeCn8lDe9xAMhQDedwh/BxlwhyHw/ygzhygzjy DkfygnDyJVfyGgjynwTxKd9wkR5pgZaI513ndNbhEpfspx6QfBPJ/4nY7AUXbs8G7Ro/7vs17Qm/ aXve8WxxcihvjDtXiDzvCCS38w6/8igH9ECH8jz3c0FH8irHcv6ubqRma3Vm6eWF6825bPK+iBc/ iPR+iPam8YnOYGytZwqn8xEi9CYvdSK/cj/v8Sf/cyOXclRX9SE3dVh/9T9viD6v9VbX81oPdF5P clbf8FanTytXZILWb+224UeHbEoG7xV35/LmbPRe8I2AcGkGYlHfL1JfdUEH9Fvf9lzXdlj/9m1n iFsv9XF/CEMf9F3X9oTIdoQwdCJH1SuXd6I2dnKG9HL+W2T3cvIx8KiIdjWnCDav9qyO8/m+dslx d3EXd3bn9l/3dv9gf/hYb3iGR3eJB/d1X/VTd3df33hE59OPt9ejbnToXWu3PmavgWqXkHH1voi9 Vjp61t+qRXgRUviI53WPV3edx/heJ3dz53mJSHegP/V3v/meb/god3LhpPJF72+Sf2xkLnFmH44X j3HiiNUsvWqa3x6bh/ii93p4f3ih93mKN/qIGHuG3/O0X/dCj3h5B3Fghm2OgGuGBvNNSXNpv/rl PtytdyWh/3ZV7/aw13iwN3Wk9/WyP3fFT3zGd3jEP3SJb3ttZ2BEN+q0fgimduQuF5P0TnP6kFGM 7Ps2YvLHJ/1XT/pUD/zIl3K1V32cz/mFKPdZ1/hwd/XTf/12f3j/oPz4cHbh5F32g5j6+pBxFKFm 0Q+4PZeK5IeJ5Q8NEbXygIbby+fycz5+67ea5n+J7Nf+jPdwuNfy6b9+8cd2onej7efwUSbl8V9/ 9h+hko7+8G//jUAhFZR/+5cIGr5/rUAcuUgrvAOIGgIHEixo8CDChAoXMmzo8CHEiBInUqxo8SLG jBor0hNIr+PGkCJHkixpkuC1Pyn//KlxLWVKgSxP0qxJ0Js3mzp38uyJcd8+n0KHEi3qs+VLlQJf umw5kKVTo1IV5hSI0+pUoQC2bhXYdWBXrlzBigVAtmyNsV7NllV7sO1asWfNxv3ali5DoAWB8kXI V2+Nv30PChYo/1jvYcAE/wZObHBwY8OMI0seCFhx1sw0W858mbTpwGs1OI/WbLpGVYOpT5v8mpYt 3tey19Ku7fosWYK3EboOi7f37+CzIR6mbNxy0Mp7ky9Hfrx5QszPFytGzNy6c+XSWXO3yFk0+NEr VTqFKrM7UZxVc6q/qh69yN21aQOfbzd23fnDE9avbxu/froB2Bhm1TGX3XPbTbegcn4dyCCByWFX 2WWDVQgfhhKRJppLoTUlGnlRnZehTuuldhWJI8m3n2+5DXefQXKxOGBB/Qn331s0rjhZg9sZCB2Q 1EX3YJAQTjZhZBVeCGGKTY4I3kxLuQSeZzKJ6CRJ66E2kJbuYf9Z0Yq3+Sbja2TeJVuLLioEV5lu zRYmmwtBZpyP1x2o4IKOIUjYg3gmGRSSFzL245eFiqfUlFNyCJN4MV1paEjsbYmal6tBChGcAqIZ W5oBvunmijUC2CmOMdIop4V2PqbqnkJGaCSRrrbq6qCsHgmZn5ey5hRTMYFIXpUygXjeo7pS1F6l N1FqqbE5OpsbjKXu95+Yp6rpYrWeTusQdoTK6u2qQvqZq3TjStgXobfm2ix3UHkGbGjfhcgUZ1Gy O9F7WG2Jonso3svbjdH6N/CowXFqraf+vShcqKH+See5PbLqoHPmKlRurBIDamuq4P57WlS/DruS Z4xy+PFF+Zr/eCK/zGYYZb0jPorWXNeSOqZcwB3MkHzZminjmdoWJxmudhadV2F6NrhqgRlDfO6c TcuKsmZQRSkyUuR1qNSwo5lHdUOS8vsvzOWVNyLYQq2bNtsfW90UUuIl2iiVpBFbbNtYveflTWOn aLbXVtqNNoZ3IdzT2nkrrmtUXL+7FEwsRU5azIsnlO+ylO5b6JWVew245aGLPnpFM6m06LtJ+fpu 41aSrqy/7MXu8q4G2Wue3Z6/vjvvpNvrdXglA0/vr6XhHfqJVvW7r78Yll1a4DGD3jv11eede70l 9xqTlI0fjzyXsuuLLIm/Q2/7+cZ/bz377WP59nfDg8ih6VZT/75+2/2K7XeTj3peb+vcJ8ABcg6A 8jsdlSZ3OwHyT2/9+5rtzva2z+GPgBZkiD/8UQMNXjAkAZQfyX5VP9xZrz2Tap6TzCYiAE6PIBXs IAwHkkEOZjCGGqFc4CCXtfPVj3DVa9mk3kesHMJPcCR8oQ0JWMOCLDGJFyFh+oYIPQki0XKYM1QP IXi2hJjPiTacoQbDuEGBcNCLEPGe9IqFw8GZ8W8UREjrsFfFNrKvhjMcYxPpuBDA2c+HH5SZHt1o OvRN0IWB9OISaVjGQ3JxkBTcoiFdB0FGgmyIg6xc2fpIyYS4QyDu+GTo7piQPG6yIIMDnRZXGMVS gsx+bPyd//9YaZBO0rIGoOxk3u4oRoKQUpYuhOLdjKe+FvrSKKoU5i+FecxienIgn6QlLnNJQxlS c5HMfIoaJwjLOV6zJN5TpjJZWMRi1vKZtmxmNKkWxkSCsZtwDKAjdZdDd0pFlSMk4jzZuMla2hKX /vRkOlE2zXVucJf0NKURb6fPgxYlnt/83FPQ1kVKQvOWoOxnQAWax2mSkaHYJKI4/+jRo2hyirHk ITeTWM508pNtBJUhO0caUVdKb5UyHUoRVYhQwfnSnBVt5jkvmraBctSaI5UnMm9KFAOO8540vWY0 o0qQlkIqAQkQyFUNUsZeKjWCXa1aJKP30EfatJQWdaYzM9r/HflkNatYRQgYDfrVudbujWjU3R8M p6m57IZmZ9KrqIBGszbxtS5uyo9bHCafTm7lmY1lLGzQ8tcbLWSwABNQtgpi1au2dSFGpStoq5a7 N0K0hZlSk8JIJSr+MIyyqYUNz+iS2AGRKa1dgaxjYSPUbUWrspQ11W8Nixer1sCtxTVuaJP7Mnye Enc97Nls5VEDefR2r8+6bqcIdl3W5mdb1xIQZG/rm4BCd1qn9S5heXvY4mLVrZtVLnzh40qezjN6 54FuV+RB3eBI97ym4i59XCtb2h7uPtVd7SwNbBZ3qFa95f2vttLEptoel7js7Wx8M1zJCD41qQGC 0X7l0l8C/1tWsX4t8YBzZFlswdbEB/lkY3M2YMnCZb1rCu6n7DNjgmz2vT5GroZ7B2TqYdK5l6xv X1P8mv1OV79bcfJYXHzZ1SY5wgVWMoWtC9wFiwWyEMbs4VBbMBqL2TWc5Sx7jxvk17WVuO9t3ytX yEIE89UsTN6vdJc83U0BeLvSyvGXAazgPm85Pwwu2H8dRmdF99ZG7bVwhdO8Zsv9uMdtHvLu7mfX SeonvwHWL5On6+kGf1fLOhYztK6s41OZ+LGCDfSfz3tgQC9sNj9W86RDh2FIo1nSA1zmlNeiX1HD Js94JraMUUzoTkfWYAper4xxs+WGLdiWjRVus6MsYIDN9v/LJyZTr8Oda8W598yaFbf7MslNYw+E 3XuWLryHPW6LhGrX85bIAWpwgH2TyLjlxnV7mWnsPAvE3fKG973pTSP3Jjwi/NZ3ijCcZjdf+M2B ROGeM37wJnO8yfJuOMh7sm9+j1wgD4dPrx8dcHubcXkFMXjBNR7vdoe85jsZ+cnznW9965w75e6s xSHt6w62DIgfB7XH2T1wd9u86SMpOc9LrnOS71wzaHYz0IV+YS8mz0TvfvfGOa50UBPc6e5M6VSq TnKTm6bNEx8Ixc8s8QvubTV763jMCYLwgh+87GaXZU27s3OcP1zqOD9N3OGu+KtHOoZi05zycrJx pIs943z/p/zffQnP0/Q86hA3+dQHb3ULW3zxllY50ZXHJci/B+Fkj7nrLZ/5azq3vpnpPNRzP/iq S4XhPdYsj29NdJWdMHmwH/bMxX702RdztKZZO+h5D/Gcf773p4f79QP+VhhaqksGmfneB5502TO/ +Y7MyuEHgnvpR539vZc06a/ueydKqiDu+fjXaS7zvZefkrB03fO1X/qp3/RVn/UJHcVtXenZUPMA 0bJg3tKBncb1HysBE2sQnu5NH9WBXmaYm7m9VQK6XRLJDgluztEtH/lhHgVuUjw9H/V9HuG1nwG+ X6WBoPBpneO5nOqNn97xX/6tYAWeH+dFX0FgoOeNXuKd/5viLWEOroyWtBv+9WDZRSEQ+p/taQbv SR0HaiDbdSCPnVvKbd8I6svmBNHlQSEaMl0VrmERnlz0QZ8Mssa/LeDWtVz3YdzxeRzssSEfHgT0 iV4BEqDPzSHpVdwh1Z9CgN8e9iEjqh8gSl/ozWB3YN3vVRimXRPBUWEjNmLhQR1BRCLKMSHjbSIp ZtgArl+/XRrAlSIr+gQOVs/UdWHnYUkltqItnsQHNh77jNwz1MAzPEMWut8tlt+bXWL1UGK4GSPp /CIwMmMv/uIwViECiqAAyV8xvuLrQCMw+uLOPWM0EmMyhqH7yF3pyV3vOKMv+qI3PmMvfuPsZd2j 8doxgv+gQWDj6DjjOgpEO7ZjOrqj0/kb9qlZ9u0O4/nbpSkj26AjOxoENPqj2WmdpZ2ePS6Oj62i GPKON/bjQOCjPvKjQzZc4rmdOdYh78jfF1Kj6DSkOurjSjJjQXjkR86bCBok9iFk3kBk8OGaTaaN S7IkQaikSsbkuDGcynng0BFk3NXg3IXOPrLjOjalT8JkyMWDQMSDVdbAVbJhRZpkGIqj6FRi/JEj HSrOPvrkSrbkWf4dVVblQFjlWq7gVkZaMdYkQZreKs7l4syDOs7DPGRkWaYlP0rlVLolVRbmVb4l 86li9gVdLpYkwCHgUVKNXvLlPvblM/RlP6JjOv6l2a3/ZWFiJVYiZv8l4UGOovUYJT1epGTWgF4K hF5eJkvCJmtupFP2JPN9Zltm5TvW4q7VYGSOjkSK4VJKZmtSpnHKpmxi5kaW32F+pmeKZuYBpHQa okXWZfwB304WCl8ixGQap2t6pzpypFo6p0FkJXT+YyF6oO+hZEnyplfey2TOZkH05WvyZX2yZkZ2 pEY23WGGZm7mJnTyg4AKaEEMKD8MhIEeaA0oKIIWKIMuKCXJo69dpw3O4/Zlp7FsZ3F+p2VeZn3a J2u2JlCOp3+SZ4kexIMyaIpCKEEc6IOyKIKuaISepPZJJIZ+pUCmjYaGaIhq6DMeJ35S5i92KHPq Zmji/2ZVGumLuiiKNmmLFiiMKqiBCoSKNuiCEqiVshl1ap8l/lv7VGTetOZAgCiZbic0did98qhg 2hxiNqd5ummWUimMPqlBLCmUVumKVqmc6umcaimNjuWN8mF8jumY2ieaGmqP2mZnOqdo6maA3ilC JKic0qmVSumcWiqTWmo1BmRwBuQ3biiZyqeP+qJ3pulP3iZbsqWJEuZb2qmKYimkUuqkQqiLSiqt 3iqVwir7hOCFwuMtbudsdud3Emqw+qh95ucKeqZ/HqmTNqid1mmfPuutvuie4qqsnqYhKqZqluKG 9ihBdKuhDumh7ufsuWVbnqijpqqMXmq0ziq1piiTZv8pn87rPOIlRAbqCorpt8YnqIarcnrosBap qjLrWxpmrg6ogyLslSrswTbrlR7susLrulJPUk7ce3KrmOprsG4shxKra3pruRYsaJYoklJg1g2n LQJrsRrqoO4robLsjjJnQRTscyJpgt4szuaszu4sz/bslI4jE7ojzOoriHosjw4qqMrssprrsoJm yQrlGmassPYov3brt85nuR6pyNJsqkJt1BaqhrbsQbSsygZs5nEtQRim2o6s1wJhcfZrmR4q3E6t xvKn05bsebbt14Isml5t2GbsfIqtWiZp2jatkWLIIRwCyiSukzBu2zguRUAudwBr2PLo0Q7t2wZs 3dr/rbJ2rZvqZuKGruIOhOQahOiWrkagbkGIbuqO7kmo7kScruvWAOwKhOPWru3Obu7ObuhGBO6S 7umSxO8uhOrKLvCGxC/UwC8kb/IeL+BCLuPyJePK7vRGL+0ewjxQ7/UG7+5CL+/qrvf2bil9bs22 6fHmrkNI7vBKxPCub/rqrvDCb+S6rvuurvwSBOqK7+6KBFMwrmjU70MAsOnCr/qOrgArxPImcPM2 r+MKq/Umrn1CcIhGr16G7nZCsL5W70F47/mWrvhyMCNBp9oabNNeL/4aMAqzLuxyLwcbb/e2bwrr L/cmRP6yrgmjrwtvb/XasA7Tr/6eMBDfsAvvMBH7//AA327vgjAPI/EPv4T//m8MozD6mnAOM3H4 XnENb7AK2zAL87DyCsQvdPEPZy/26nAFY29rSnD3TnEHEzD4+rAH//D52u8HL/EW3y/bsGrhLi3b srEQK24Ly28gH28d37Ah03AK4zAeD7BCaLAiS3EcQ7IRIzEjt7EhU/IhWzIdx/AlA7IUUzH8loz/ KjIhf/IOT7EjZzIozzErB3EgGzH6Mq/yLu8XJ27yUnB8Rq/onnEuj+4Z63IZs3EWB7EOA3HxurH9 trEne/LrPOfdqqpoFjApo3IXl7I1T7MqV/Igv28jMzM2p7Iwe/MqI7IrizMmH7MfPzIzb7Mxz+72 XP/DE8OzOUdxIVNzJzMyCG+yEk/y9wIvLX8x8y6vLd8wy14vGYOzQU8mBC80LL8wQkuzJq9xJc/x OX9yM0Mzq0InRKcyOrMzR88zQ2DyODdEDW/xNY90OPewFWtxOd/zHwMvFyOzSe8zO3dIh8gz5Hy0 Q4s0JdN0Ejc0Ob80Nqv0ISTwLIfx6Qp0Uf9C5cY0LpOxoWKwHRNzK18xTHtxOmfyPtsz6RBmHx8u Vfc0UJ+0Tnv0InM1ShPvG5M1SMfxSbN0MlvyVgs1XWuyTrc05AYPFFfJXVOvRYs1W7t0N6M1ODtu 84JxLRe18oq05Tr1G4spMDO2Kru1RMe1ZVc1LFf/tOg4M9Oa6ERv80+38zWH9jTXszbz80RT9R97 M2mntVnXdUqXtmavdlZrNhMLtSNXCZUkLnj4bz7zdGa3dSLf9mXPNkobNuMuMFLfsi0vtyxfsAUf dBmnseJC9wQjdDb/tkVHtHHHdncrTn/+J+EiRA6vdh3bsQwHr09L9hqvd1artEPHt3u7d2WfsBdb MXAvs2m3snmvNDWL76K4MBT/MHDbNXqftxzHN0z3cDontQLTsgsjtWJ/7CE/NRkHa+Jy0E+r9/3O MERT9FS/sIhz9QGDTd5iRImj+FnHUIrzRLCExqIkClOIzgIPhFE/eI3PsnyareVOLWtmEMty1OAu /+2Jq7hPtHj7ILlOnIyinIxu23ToHLZy27hBKHfyhmrV7jhM8VJBdXnWPu1GzHDCiTl6hAeUo86M R7kCg3FA5/iDH/Xl9ivfzsMM8aUiUZPe5nlJpLmHoISUjA4tGzVAfzGb/zNiF+u+Uu53+gOZihIZ fZaeRzpGaI+Zy3jvyPKNH/qaE/rVxjmH0rmhOjovQbqkl/pDxHiwMPnrHPZRB7SNC7qOG4SiX+6n t6Yd4ZEYkbotKvm9pDivk46qO26MqzZEYHVEC4Wh/3OyDzqnw27mjikpWdNWRWMVr/ji+Lq1CwV7 vxzB/fpCUIlL8PbcwHYAn/W27wSrUzlBuHoso//z2yJqQcWVHTk6KRU488019WA74t7vCcpD4iKf Scy4PAsPFL83SZv7diM7m786nCv7uXvWGHF5E8l7UK/gXHv4gV+1IAc3FsM1fqc0mcM3g498RSN4 FGv8yWvxKxfxHvr7HR+zyWs8yqMOUR/4xmM8WqO8zOM2J6t8c5c3A/u1T3fUHZ2uBiFxBlUzh4s8 09v3x4u4ycMxfptytlPNVufzaIO0ZTvyXeM1aj8yPIQ9HT8yiI/zK5O3cPP3bNt7x/27CetXSZd9 Mgu7uDM5cXd9S5O4G0ty1sv2Zxd16Co1piv1/r60SM9Qhm8Q4/qD6B79IVhTgRcy1jc4x28vKCf/ /OX7/etUu2C/deeD/Fq/d0yzNTwkLjzUgNgTc2Hzs3Zn8zdrPbEbN+TGm9u7/WT3c23Dft6PNDq7 NHu/ds0bfCwv90AjdZXbO3avU+Kbt+ND/l+nfe5vPdW/Pj5zfNVb/cYTtYI7doIPvfYf8fPfM+Se PuqDvuovs9O3tkMfwMoneDHbs8sH7+u5PNwfwrAN807L91gTtn67P/IDxKEaNQ4JHHiwIEKBBRkm JNiQoUKHBwdOTFjwV0WDNTJmdGjR4MeIA/3VKAkRpL+Th0pSFKnwIUyQFDXSnBkT58WNIhvizDmS ZlChQ4kWNXoU6dGJLhduhFmTqc+hN2U6nTpy/yZIeAXhdR0Ir0bXrE7HUn0K9eEBh2qbJv0JNaG8 gXJryLMrN25Buw/pnpWKVqffp2OVhtxpGO3ZwEFRLk0MuC1HjL8ycnzo8fDjpStNttRYUCVom4hr En789+bLmKZXZ37o2G1s2bNpjxa6uPXnt2bhLsYNG3LVsBG5fgV7nLXPwKpzw2R7iO2B58qtvv2J 95BceXG1a8S+V29fqaaJG65uvfnf3rrRK45MPbj6sZUxWrbM/KXqkqFZmgTtryf5SEvPN9gcS420 3yIrz72oansQwggF6w0olD47DKjRAgzwNeASg0giBr0CK0TmLkzQPOaks7DDgg5o8SqqGNqup/+9 6gJPLxDrcrDEElP0UMefMuSRRRPjC7I9DjVM6JfJYuqIMswqRHEiz2B8aKWVsMKQwB/P0zFI1XTi 0EIZyTpPwjTVPEg6il5cE87aPKSJRDq9oqirOuMUSro332TzRbZq+BPCvui6a0eKDKXpLhv3fBTS SI2KMsqBKlNTJZKEyrQzSOeU8NOkQpWUVKLaHOjUQQcltNQ9RxVKz7DylPXOUgNF1U0/E0o1Qu0Q vbHRRBO1sbtWjT02zY44omxPlawMaj9JX5UTTbemRdZWP/vElVts1Zx2xLC+GtfOVnllrCdWa9uL 3RvnGvbQYRX1lt4IL1323nrdctakg/j1VEn/V6sVdWB9Ib31zzYDVddgUo8L9+ER74w10oRV1bbP hSUMdi5HOxZKvINCbphkipQ9KN+Si4o205ZaflblmGWOEGFA/VSVzZkfJTFPisXlOVucaeI1Y6EL NfTXHX1191COdW6YWWZNxnfZpylq2d9+rd6a66JuHRpXVhVmuOvZYp1V3LRJTXXbXIsuet133VV0 UZERbVrusluVujK++bav65f1HpzwsMdGmNCvC4/tOLXrlPhYos81utvZ4n1XvO7YTbov7kq+FtJ8 oUy5aqkXPx11khW+eNU3dcx4cttuK/hB0IOCmESHaq3V3FxZdx26VQtjaka7QDS+IbogOlQv/6Ia O7FH6KU/DVkoLbWMUuyv3z717r039+aagR/UxbZjn7BU24fiWSyBJObdqGuuGWh+2cRuHdVTyyc7 xKdo5Os7IKHRXXgypNOwRkHwaRHtQlep0pnMgaT73gQpmKbVaQtnLxJJm8K0JQOOaUsUAkkBm1Ie DJHwEGCBSKw6aMIeTYkhK4KOBksYw+cYSXYA/F/zdiiQAB6GRg4ZmYCEU5rMlIWBj1KW6e7lQO1F TYIVlOIUvRY7Vr1EUDK0DpBKaEQvfhE/Y+rSa9rXPloBbTBjukZC1liQNrZlLMB7jgxp2LpPmSkm yPufHrkDwmItKYzwQWAN6RU1fPWtiZZa4v/JqNhIRw7lVObbFg0bosU6GghNCexQcDCZxi/mRoXu Kw7kHMRGU6JofgoSFPmggyD+oQsmPyRgZAYoxPBkCEmfTOAg2ROhHwzklz/4ZVEodam+KZKJ3GPk I5nJzLZ1i4Z9ctHzNkm9MVaTmmRyTX7K5L6tiNKbaCvSIVIpkDbWoI3lROcuZyio8qUlOpS7ikJw tEe+CNBMr2JnEa9ZTdoM8yDCBCZRkolMYyLyb4Zs5kKneC6NOcedwWMYDnWZImuuB6O4aZBP6jST dD5EfmIiZ5fimRs64uSVDcKOILODPJz875POe88+K8rP2gAUp0JpoiErdTLroYxqDBUqBRf/dr+a RNNFrNxiJmfqGpZidKlPrck3Z/eZcoaUnB91o1abusryBCqpu7qoAmuZHe/YsinKa2l6iNRUqfZT o24RKDBzGkyaQPGJ9jnmTgE3VL+mLnGGKxpKgGdDf74GlniM3mEZtNQQQqY641ynOd34lnNe6YbT lOhaHouuDdUoiOFpkVo9aMDFtnCEqfXSgwAalGHOdXvZ06vpHpgy2v4Vt12bZP4wmLPWhe+ZuRWK /OqHzuEat7jolJ+pDmc4/KX0KEkT1sj+2C49xkx9A62BMAWa04G29qezje0favCHX/wBvShbpnDZ O7Pgvk14wL1ge4eSXOQalyLzW+5+62ff/6CI7Wvns1ywOFaspi0NffrKLndhS1ft2rW2h5waZchb 4Y6k97b01XDJYLdbuPE2ccHd8H31S1zk8pd+J/ba7xy6Jl8ZOHMeu5wUg1nj124Xx9tlsHptuyzz 2ge9Gakweis8YiNz+JkYEx5vfQfdoZpYufpNsXLz21//MjeDIt4Y0+YGLHgtrW7dgy2Ec3zj7l5P odf7cZGFXF6OmNe8bT7ynJEVyYcCKmeIe+6Irxxl/OK3v/Rbrv0qBycEKw1zTvuVx8QcUB3ruLXc zXFP0RwlOJf3x+cdsmWC7Gby0hnUkppkgG+Wwf9qmb3F3S9NAp1c4g66z/Vq1Ky9rLnN/f/xeztm 8Fx5LWlhZs+JlgoynIkcZE0fO72hVnbFwpblPC/5bU5+8qsBbWVAT/m+M7sb0hiVN2HlGtJ23bGD HR1UNKf3x+WtDHmFfF5Np5vIy5b3msYGYrdhrGZHhnKJqXwQKf8b2097saMy1zFGN7rM3b3xg+fq U8BZ+t1EprCn3xxvN8+bJn7QuB9qoHGMr9jU+AN5qP896BRT29X1okcNVk6PlRcFzCKTOcGnuHBy O7jGj1YkMtXNLGN3ethDvlSxPy3vjR+E40n/OCR7e0E9BxbUJZe6iv1d4ljD6eUsz3p0vb1oXFcw 5w3G8Wt9/cvRvdnNmsZ0z9ULdHQXvej/ylb6QDjecbsvHZK+vVhRQy5PfaPYzycf7tXj5HKXD2Tr SSn4wSmo8JxDWrsBbTj2gH7eive86O6+eJHXbnSkb3zuda873p3LZGdj3MrUFrSUT/xq1kMq6y0/ PMtpj5RFDZGKvaaIuOlqc5PFmdiXLjaFLY/sgRT7+EZP+tHp3vG5k/7ZplfckqNuYmur2vpWh3Kk Xt7ygxze+x+PdKQhf1cKcx74QmYzhtWe/E8nG9RKP7roRY906Ps2kvkT+bKvT+LXs17VSCXxtM7w BpDOxM3GygwBBAoBEGAgHJAiiI7iMO3d+kbiLG/t4k7unM/u6o/+mu/+HirJ/K769i3b/2At0IxF 9ihC9gww1CSt3H5gAe2qARvwAX0s4oYt4iiQ3TAN7iwO/ozMA+XP/ihi9IIiHuIB4+YrYaRNw1QP 8Prv9QRwBWtP6xBP3nyNJmRQxxYQx2rQARtw3YBvyIiu0ziN8yJQA+ls/kJP/pivBpIwDuNQDpVw 3gLLCfkM1vLrz1Zv1Upl9q6wCsVP53YNBoUiDDFQ/YgtBy9vKNIw/j7P4+bv7u5OCS/RDufwIDLx /vDu/6gs9QLvWFqQAIUiEA+wC2tgBmuQIiBQFcPQBn/Q3dhP3eLt/X4w1CaRA3VxEolQ4+SQJjBR EzvRE69t9UTR5CTF8L6PBZfxCmnPBf81bNfGTgZh0QYh0BVtsQcVyueOr8i0ERJH7AhBsP6az+M0 8RIHIgk5cR05cU8IjxgHBwD9zNWScRQFEQsL0BnBb85q8JccsBof0BXB0AHTCwHeDvneTQ3RjeJs 8cjckAg7kO6ScOMw0Q7rECPdcU2mTtDicXFKLuDscRT3kSYKEBq/bxmjcajCUBVvEBYP4iWtEb0g kCHH8BvfbgKTbQ3bi/5Gryczjg7VMRiFUh2FEU6uz+Sm0CMLJwW3D1tMsvYC0fv4cfacsb1ssCVh EhtZESvL6yD/oCDXEByRTwLRjw0/UCh+sSL9YB2Fsh2Lkh03UvuMMeCWUh5Vz2D0MSr/q5IF89EK r9IVb/AVX5ElW/EVP40mNw35Nu/91LDzhJAXmW/5JjMe2JIigLEogzIzj5Lf/rAu7TIew48AU3IF SdEq2YsVBzMrs7IwZ5IlA/PiguImw3EnN2z57K8cLTMOPe4t2zId4fIoq47V9rAPQbMTwW8qsdAv +/IZcYsrCbMVsRIMVfMlI9AHvTEDsVM7l+35KhH0OPAi3ZIO3dEi1cT1rgwejdMjkxMqq/A0/eoa DbMwB5MgGxAs7fMrF/MxvbEMbzE2hRAEi/A7KzPpjLItibI8h/FBArDfSKw41dM4k7MUY285V3I1 L3QgBXMrwTL5vvIxzdDTcPE/ufPu/87RMr8THTdxPOcwLjUyNvir1fiw2iAUNJGz+0oRJU8RPguz K+kTJn1UIA8SK8uw8/yTJhiSRCFyIpmvHQ/0LYlSRSFEJLHPD5WSRu2SPamSL52TNaWzJVMTGwUz SI2UMTePP7+RRM3RO0EPM1kUHVt0MxdURv8w+x70SqGPNFVyKlWykawxPrXSJV/zS8E0RINQAs90 0z7uDenuHC3yN4OSHTOxTWfD6kARBZPSTu/042LvFEmxGbkUEVPzS6FzVPPzQo/UMYEQSZUPN9nU UVPUUetQRV00KZqS6qoOUzWVGPcU8fhSL/mUivw0KKZTIIt1TM00+RZSJ6/z/m7zF/+BcxN7M0WH cVJlAwBDsUGtTVfxlB+VUzl/FTC3MkPDlEev8SBTtT/RlCGDkBgfVTyR0F0VVELwMkZjdFvxtFfz VR8lFFj71FxXc1wFVSvnM1n5MzutszY70Teh9TLdFDNp9UVTMMqg0Ervdem67/DmYTk5Vbi81Eef 80d7FAw10CET1SGN00AhNRgn1SjlNPBSD+U+02LnrQrnweXmQWPpAWdLM1wJtVgJ9kfFFFVVFURp NDzF8yIlFSM1c0EBzlKrzClnNh5z1vBslmr7tU8BdlCpUzVHtWsNtlANNmGX8mGhNEqTNk4jpE5X rTOldld1diB2NutsNl/pC2QDlVz/xdRj3c8H2dViFxZtWVRaq9Vl67TKGtRt8Y5uq1ZndVZjNXbD YDNIB5VYEdEoDtVtfbNJV/RRIbY2mtL6bjVxZQMcShdOShccigJ1G8Zmb7YqrfZx02R1UWdcoxNv A/VrR7co0nFzgbFNCXde7Wvq0tNgUDd1KcJ4hWp21WR5haJ59eVxW/dmWQ5yg+J5jeJ69eY14/NP rTFoT1V3jyJlETRw4wTlOpN4S+Z5s9eR2Lc23LcG4LdVYrdxWzducdZ5Tdct5JdrwvR2BbU6JTd8 k+JAqdVNJaVStbVskncgGJih+Dc24BeCIwVy8Td+TdeCLThCJvhpYvJrufdnIcR//7e1cxnWWPgt U7lmeTl4glj4KCRYfw2meufheqsXQly4f7eSPrmyR2WDXHv4SltWcD0X1JIXh73niIkCho+3XmIX Z2k4huOWeaOYduezKwNWgGMjJkVVV8mTGFf3eo2XiRs4iiFYjJn4jMf4gs94f9OYJsT4jcs4hsHY gdc4jutYdfGYjqNYg9MYilPXiOc4jcd4feF4cGBzOq9YhGlCYAf4/gz5IAYZjeVYja13kMmYjSP5 krFXkjXZjTEZeQV5k+0YkzNZiUd5lKUYZ934kle4k0G5lCFZewfSZ0U4gAnSkR9Zj0XZk0O5ku84 lIfClfUXjy2ZkHkZlkk5mR14mP97uZTzeJKj+Zdr4Ikft3l3WZqdWZmHeZqtBpGzmDYCllRzGfoK WY1n95qpGJiTopm1OX/PmZipGJ0p2Z1JeZ7huZvNOZmHAn//mJr3eZnlOZ6PV5+NTGB1mJzLWaDx eZ+XmJMhOZ27WZlhuaAjup7vOZZN2ZjXmYNnV2PDGJmd+Z5TWcOAmIsTeukKWqTp+ZTzGZVZWpgX GqAxWpsreqBJ2pc5Wp2F4qNhuqZl2p4lWaJzK5HBF6U/TqUp2qc3+p2j2Z0dOqcnOqiP2amjmqbb mKGlGpqjmqttmqB3ms68FKGPGqmBeqWpeqvfuauXep3PWqfReqYHGqBfGKg7mq3/29mttVrZRBWc yTrUQLqq1/irwfqpAVmUA1uv1zqkufmZG3qxBTqtt5mwmXqu8VqyEfuC/VqzvwewNfqVW5qNhbqw h1q0MzqiTbm0L/uTY3q17TqQK5mbUfuwNRrUgHizC6+C2FeWPXm3Wfu0mZmtjZm2e1uwgXu4F7qY mzqr2fm1KZukzTm5b9ttt1S6LTaJqzuhpdJbsftKr5u7c1k0//K7QQ0qxZu1xxu98ZFX03vZKFQl vZu9pzsfyzu+2cu9c7Qk61u/exVjzXu/hwpcBfFG6/a/0ztPCxy3Dvwkv5XAEXy8SdPB/4q6RXPA kTPCv3vr3vPCCYfbhohXE08v//E7sTc8u/2bxCN4smeDfQsO0XCNwqNSX5uznrn6xGs8veG7rbuN 8WYt/FzQKrv1+9wXx22cyOubtj9GXu7mRqrSRk1yH210rme8yKecyI/cuhItWOhBLhScGX8cxulB yFOcysf8wpd3iNqFy1hOHjy1LwdRu10OdV1wyMmcrPsaxeE6lnO8maO7uEcatrGZuGUbz9XatIea stFcO2ZXLhQ9zmnvjC380R29dF/Osun8v0/6huW60BE7tsNcqI1b0D37pQf7oXmbuFva2xRlde3C eFuu0SWZ0gfZ1U0XzIPb0tPbe6eY1AOa0w8bKRjYkIH9sW/6pzVdfhlbsLG6Bv98QR58wdl9QV5Q l9XjvNbBYdatHc6pfXWzfdKrXarn/NYdOUMlhKa9WrGZe9D3+K2tuq41HdUd29B7+dmdXS6Y/axL Vx5ePYqrnd971c//PN7DXbN5NE4Efd2LHd1pXN3ZHa4/3dQN3bJdu96hXcbs+Izz/abTuNo3WYwH ENwF3m1p2c7vvNKv+rITfrS/3d2netT5N+LF3JOfXWmafdkxGeNfm9tbWbQ3Xp0/HuQtVlyN+n0h ut3xfIItupfNPa9BW8xfPuB9Qdrrgtmn/tnpItgNe0caPby3vT37nLJ/Hrvrszp1fdCn+tx/3acX funN/qHj3emTAupL196dfSD/KJ7ei3vRWx2UD5zrCTzOfR7sw1eHRx6rlxvZjRvl4Z3XUz6ufdnt Q3rEKQLaURfa6X7qDwLai7suOn7N+93wul3ryRiTuT3w61tyK5fcoVuWP/vo0z7jEb/YVzvZ6brX IX6Q7+bylz3uweFQqP3hhV3WvX3jpbz0/fqbCx6sA721YX6ikT7PFR65kzqynZ/pjffub4TuYXna rV3N17zPuf/ak5f0cz7Ki/+oTRr5A569AB/uK9/y58Lu551Y5kL2trxb+zu/MXbAzf/St5bsAaKG wIEECxo8iDChwoUMGzoEBxGcw4kNfdWw6MuXvIwWN17UeFFeDZEDRZKsQU8k/z2UK1G6dEkvpkCZ A2m+pIgzp86dPHv6/Ak0qNChRIsmRIA0aVKhEY06faqwKVSGGTd6/Pgxo0B5JrmilNcSbEywBVea bYmWJcybU9u6fQs3rty5dAUiqHEXaVGpdftO5BvX4kCtHT+a5Oi1q9ivI9nanGkzZkuYk/1avow5 s+bNDPUOXMo5tGidGKuK1Oi1NFevjVcv5iq5cs2aNCefHY07t+7dvBHexQu8t3DeiDkK5hhScNet Y2HLrI02re3nZodbv449+1C9efH+1g5+rtaSgwejbr219VmyN5+rjV2dbfj59OtrB/3dvn6jpYtj TazYSK4JmBJLt0mm1kyzyf+3X4MOPthXd8FBSOFOxyHXUUesrZYeZItFJpuB1SEYYoUmnojiT/ml yGJBGF20VVUYmVQQhySR6B5t8CX4WIs+/ghkkEIaZFxxNAJIkI0HGtgeZDiWOGSUUk5JJXZFVtVY h1om9t5LZyHIpIJVCulHmWWOiWaaup2UpWsD0khQdJSB6SWDakLoRw156knQnnf+CahfcL6Z5EGx OSZnj4E2aKaeZyZwpp+LTkopVKwJmGWmCX2ZVoKVOphnAgIlAGkNpJIa6UCSfspqqxSRdKSraUaa Z6ir0iprrrru6mqtkJp5KqTC+lGqqrwey2I8NSiLbLMFRfqrqXvi+qij0zr/iy14ysbDbbbe8ikq sajqGSyxxI5qLZ/qfssubtt2KxC8zLYrq7llRkuqtOE6Sm66/tILMGbzdvvusgbPG/Citfprr7Dk LhxtowlPbJm8A8drcMYU33mvtWZ+XK6v0p7Z56obn2wUtxYPBC/GGqM8pqh81mqutAKZW2q+En8M c89FEVzwtge77DOV0IK8r8w33zxsv30WDbVPzL47NcEGIRx1kKGauvTI99r7Mc0y85x12TgVjPHK VWM9sainovsjqsCODayjpdIM7q8km823QxdrTPWyVVOc79umFq70ideiene419rr8dZ9T86QvIIL jvbQbLPrC6mdW+T24YWz/wjtqNEeju6ed9/ccdgmU953y4MDrjLL9GrleQIZ6S4614kn/qC4rIvb sK206l2zx7Avr3m8mw/t/O35ci1YsFz7Djee4f7q8KN69+54x8PvzXzsgWNO9cDP8/RilZ1fpDTi oJsOfoXAuq6urSPbXSzrxpY/udplDGtCu1zLgjKeKHXObaEr3PzeNxAGGg5UJbtf2HS2NLxN61oA 5Nvg1AdCAQ7lOFMyDv2qhzjUWY+BoPqaqi4ILtZ9b2YvJF8HsybAAgLNaiIECnIEIpggKW2BMDLc 7t4ns+mxcD9725r3rMW9uUlOYjcsn8os9zehEKY0QBSi7jx3ONxlRVQLnP9gBINHsu3ZTGL7gpbD hldF8yFsjgY84E9+aJ4gxu1zvpPg7niXxN/1TnvHG5vjciYykr0ujjg82N+umDmf6PGHemzRHxmI RBWW8W0pNKN9Wve9u01LaQuLHNkYWTYCXm0qQTRhkEBHxk5uUXS/Ax6j8vawc3EvYjWjmaQWicqi YfGRrKwki6YXRvgpEZDYux4y7fc1uS1tWL4qJQeDGUC02dEp48Gjj0KHujAG6227c6YSmxm8w7nw XnSTW9iwacUsKiuQ4UQgjIBkSyLCb1Sg26QE4zdI/ZDvl3XT2bj4RUN4wm5qBBkdJ4/lQFN9jiO8 g+U4z/hPPDXRbb1koSL//wdMhVIOnOzKqApjOTp0JZF+9RRoDRvHtWr6aaCUuoVNa3BTkdIlpYG0 pazISVIJAnGJtPRpC/llK1L6MoN4q+ktBvLUp+oULsusKrZiKdFxnlOofVShRh/XxJniL6RoiipO bZrTqbplpfF75q5S2k3PVc90S3ymUQXKwZmu65RkpRJapYpTgqRVrU8x6Tnf2sAIgjGB13Nm9gKq 0YRmcHxUnFRUL4vWwGqWsIVd4RmRRVKvdjV7KS3IXRm11JmV8lOXPStgBZLT13J2KMhk4WkrZUa2 XrSnAIXsjz5qQ1ZJNbNnFexsneK2P4Dztq6ynm9rqdsUau1/rgLsTc0Ks9XrHtcof+guqbp71fo9 1q7Am2BotzuV16ZVu9ZFb1G8+4caxLdZyy2vUG3rXN+69ymtbS1s/wrV/QZlvvL9FlF7e5AG1lfA bsHsf/+rXtkyeCfxJbCB6UlPxTpWsQiecFEwm1niZnezHsZJd08skApnS7fNhK5jM1xiqPgXtsUd cYxNXOD5ntjC9KXrcj9b24beWMaaNStx2ztkE6MYvCW1r2gfymHmJlknAC7ykUnslIAAADs= ------=_NextPart_000_0005_01C71ED7.4D885250-- From sip-bounces@ietf.org Wed Dec 13 11:52:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXK7-0005Mj-27; Wed, 13 Dec 2006 11:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXK6-0005Me-8I for sip@ietf.org; Wed, 13 Dec 2006 11:51:14 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuXK2-0001Ne-3g for sip@ietf.org; Wed, 13 Dec 2006 11:51:14 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 509F03A02143; Wed, 13 Dec 2006 08:51:07 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 0D9793A0210C; Wed, 13 Dec 2006 08:51:03 -0800 (PST) Message-ID: <45802F76.8030803@acm.org> Date: Wed, 13 Dec 2006 08:51:02 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Fredrik Thulin Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> In-Reply-To: <45802084.20208@it.su.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, audet@nortel.com, 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 Fredrik Thulin wrote: > Marc Petit-Huguenin wrote: > ... >> So this is why I am switching my focus from performance to 1) do not >> prevent implementers to use UDP if they need it and 2) anyway RFC 3261 >> mandates UDP AND TCP on all elements. > > Not even RFC3261 manages to get you everything if using UDP though - > large messages for one, security (SIPS) for another. Let's exclude SIPS from the discussion, as DTLS can be used here. Yes, large messages must go through TCP, but the reality is that not all messages mandates to use TCP, and this is especially true for messages that are sent periodically, REGISTER and SUBSCRIBE for example. RFC 3261 already can mix UDP and TCP when there is no NAT[1]. The problem here is that it not longer works behind a NAT, even with Outbound. My proposal is to extend Outbound so it works the same way. > > As I see it, it is too complicated to try and make SIP over UDP work > across NATs to even try it. For those cases where the properties of > Outbound are desired, everyone will be better off using TCP. > > For the cases where you have small messages, don't require security and > don't have to worry about NATs or firewalls in your network paths, then > UDP is fine (if I don't think about the re-inveted reliability). I don't > mind anyone using it where it actually works. > > I'm genuinely worried though that Outbound with UDP won't actually work > in the field once finished, because of something we fail to think of at > this time. Outbound with UDP does not work. Because of this some people want to exclude UDP from Outbound, which is inconvenient for implementers who care about performance. What I am proposing is to make UDP working with Outbound instead of excluding it. Remember that this is not the endpoint that decide to use UDP or TCP, its the servers (i.e. NAPTR records as described by RFC 3263). If the server decides that the endpoint must use TCP, then everything is fine with Outbound. But if the server decides that the endpoint must use UDP (and switch to TCP if the message is too big), then things breaks for the cases described in my draft, i.e. incoming messages too big and outgoing responses too big. > > If anyone can tell me of some other UDP based network application that > actually attempts to work through NATs by using keepalives (that means: > not DNS), and without users configuring their NAT with port forwards or > similar then please tell me so that I don't have to worry that we're > spending all this energy chasing a solution that might not even exist in > the first place. There must be some kind of precedence in this area, I'm > sure. > > /Fredrik > > [1] Excepted for the fragmentation response problem. See: http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt -- 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 Wed Dec 13 11:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXOu-00077v-6B; Wed, 13 Dec 2006 11:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXOs-00077V-TX for sip@ietf.org; Wed, 13 Dec 2006 11:56:10 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuXOr-0002TC-II for sip@ietf.org; Wed, 13 Dec 2006 11:56:10 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 950FA6C01C; Wed, 13 Dec 2006 11:55:56 -0500 (EST) Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) From: Scott Lawrence To: Marc Petit-Huguenin In-Reply-To: <45801BBD.3060307@acm.org> References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 13 Dec 2006 11:56:07 -0500 Message-Id: <1166028967.2975.31.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, audet@nortel.com, 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 On Wed, 2006-12-13 at 07:26 -0800, Marc Petit-Huguenin wrote: > > b) The only reason for Outbound to support UDP would be its > > full compatibility to RFC 3261. > > This is a good enough reason. > > > > > If this is the case, I would ask WG to consider this reasoning > > very carefully and if it makes any sense or not. To me it sounds > > like: "UDP is actually not needed but because the WG decided to > > mandate it a few years ago, it just has to be there." > > > > According to your I-D the client has to anyway support TCP (or > > other congestion controlled transport) so it would not even allow > > to implement UDP-only clients (which might be desirable for > > some vendors that currently only support UDP). Thus what is > > the point with the UDP flows ? Why could they not be optional > > for an UA ? > > UDP-only clients are not SIP compliant. So how a UDP flow can be > optional if UDP in the endpoint is not? I think it is perfectly reasonable to say that a new enhancement to SIP (eg Outbound) is defined to work only over certain transports, if doing so is either required to make it work at all, to limit the complexity of the specification, or to make the resulting implementations more robust in the wild. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Wed Dec 13 18:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudP2-00016W-NM; Wed, 13 Dec 2006 18:20:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudP1-00016P-GH for sip@ietf.org; Wed, 13 Dec 2006 18:20:43 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GudOz-00034F-5t for sip@ietf.org; Wed, 13 Dec 2006 18:20:43 -0500 Received: by ug-out-1314.google.com with SMTP id 72so274819ugd for ; Wed, 13 Dec 2006 15:20:36 -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=P1SED1mSxx58bww8KOXwEQQZ4pwcaeY6mks/PPO33EFg+G8FYbkZmddEqLWjba9f8T1N4iLyNm/rusd+JLBDMFTkgFfM66MOqnSdkp0aqddeAPj2k/X26sUPaSYVASeq7RYAz3mMYeE8aRNSpq8gHZGVJs8OOKka2x7T7DS8I7Y= Received: by 10.78.201.10 with SMTP id y10mr234271huf.1166052035719; Wed, 13 Dec 2006 15:20:35 -0800 (PST) Received: by 10.78.200.9 with HTTP; Wed, 13 Dec 2006 15:20:35 -0800 (PST) Message-ID: <953beacc0612131520r5c554b12n26b761ffca98695c@mail.gmail.com> Date: Wed, 13 Dec 2006 15:20:35 -0800 From: "Rohan Mahy" To: "Juha Heinanen" Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) In-Reply-To: <17791.40622.256716.794463@rautu.test.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457EE9D3.1080001@acm.org> <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <17791.40622.256716.794463@rautu.test.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, petithug@acm.org, audet@nortel.com, 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 Juha, I proposed that since edge proxies and registrars have to support both UDP and TCP, UAs that want to implement outbound for TCP don't have to also implement outbound for UDP. My proposal does not prevent UDP-only devices from working. I would also like to point out that devices that don't support TCP are not compliant with RFC 3261. I suspect one of the reasons these devices have not implemented TCP is because the devices you mentioned are usually used in a residential setting and therefore need a standardized mechanism to get inbound requests when they are behind a NAT. This was the original intent of outbound and the title of the document reflects that: " Managing Client Initiated *Connections*". There are clearly people who want to implement this spec for TCP, so I don't see what the problem is with finally doing something that makes it so we can have interoperable implementations that use TCP behind NATs. thanks, -rohan On 12/12/06, Juha Heinanen wrote: > just a reality check. yesterday when i was going to make some sip tcp > tests, i tried to find a sip phone that supports tcp. the most popular > ones from linksys/sipura (cisco) and grandstream didn't. > > -- 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 Wed Dec 13 18:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gudkx-0004n9-FY; Wed, 13 Dec 2006 18:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gudkw-0004n2-Fi for sip@ietf.org; Wed, 13 Dec 2006 18:43:22 -0500 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gudku-0006CT-DK for sip@ietf.org; Wed, 13 Dec 2006 18:43:22 -0500 Received: by wr-out-0506.google.com with SMTP id i7so237699wra for ; Wed, 13 Dec 2006 15:43:20 -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=TiH0XXxHuu0Z5rulZ3k+uRUpKrG5NVoY7+vvJY2pmoAGRjeyMeaORXYg+r9jCvF+7aFqABElVVOgrdy9dBTuXTNVaIvFoKjsDDCKXjLGm5i+msnxTcvYHjbJdT4B1bhE69pbsQvYIwKfODdVr9MiKiyrUou18ot9JxNE0XcR9lI= Received: by 10.78.136.9 with SMTP id j9mr267202hud.1166053398949; Wed, 13 Dec 2006 15:43:18 -0800 (PST) Received: by 10.78.200.9 with HTTP; Wed, 13 Dec 2006 15:43:18 -0800 (PST) Message-ID: <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> Date: Wed, 13 Dec 2006 15:43:18 -0800 From: "Rohan Mahy" To: "Marc Petit-Huguenin" Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) In-Reply-To: <45802F76.8030803@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 Marc, To date, I think you are the only person who has spoken on the list who actually wants to use TCP for some requests and UDP for others. What I have heard from the UDP-apologist crowd is generally that they are using UDP for either historical reasons (with which I sympathize) or for performance reasons (of which I am skeptical). The historical argument basically boils down to having a large number of components that will all would need to be replaced or drastically reconfigured at once. I think the language I proposed explains and makes room for this. On the performance side, I consistently hear several UDP-apologists concerned with the maximum number of connections they can handle. Your approach does nothing to address this concern since it ends up in the same number of TCP connections as the pure-TCP approach. From the TCP-advocates I hear that in their implementations they can handle a very large number of TCP connections by getting rid of poll/select, and that they can handle about the same number of UAs using UDP as TCP. The performance bottleneck I usually hear about with these implementations is access to the registration/location server database. (I have also heard about the registration/location server database being a bottleneck in UDP-only implementations as well.) Your approach would effectively double the number of entries in the registration database and therefore seems to make things worse rather than better. Certainly it does not address the perceived performance problems of either the pro-UDP or the pro-TCP crowd. thanks, -rohan On 12/13/06, Marc Petit-Huguenin wrote: > Fredrik Thulin wrote: > > Marc Petit-Huguenin wrote: > > ... > >> So this is why I am switching my focus from performance to 1) do not > >> prevent implementers to use UDP if they need it and 2) anyway RFC 3261 > >> mandates UDP AND TCP on all elements. > > > > Not even RFC3261 manages to get you everything if using UDP though - > > large messages for one, security (SIPS) for another. > > Let's exclude SIPS from the discussion, as DTLS can be used here. > > Yes, large messages must go through TCP, but the reality is that not all > messages mandates to use TCP, and this is especially true for messages > that are sent periodically, REGISTER and SUBSCRIBE for example. > > RFC 3261 already can mix UDP and TCP when there is no NAT[1]. The > problem here is that it not longer works behind a NAT, even with > Outbound. My proposal is to extend Outbound so it works the same way. > > > > > As I see it, it is too complicated to try and make SIP over UDP work > > across NATs to even try it. For those cases where the properties of > > Outbound are desired, everyone will be better off using TCP. > > > > For the cases where you have small messages, don't require security and > > don't have to worry about NATs or firewalls in your network paths, then > > UDP is fine (if I don't think about the re-inveted reliability). I don't > > mind anyone using it where it actually works. > > > > I'm genuinely worried though that Outbound with UDP won't actually work > > in the field once finished, because of something we fail to think of at > > this time. > > Outbound with UDP does not work. Because of this some people want to > exclude UDP from Outbound, which is inconvenient for implementers who > care about performance. What I am proposing is to make UDP working > with Outbound instead of excluding it. > > Remember that this is not the endpoint that decide to use UDP or TCP, > its the servers (i.e. NAPTR records as described by RFC 3263). If the > server decides that the endpoint must use TCP, then everything is fine > with Outbound. But if the server decides that the endpoint must use UDP > (and switch to TCP if the message is too big), then things breaks for > the cases described in my draft, i.e. incoming messages too big and > outgoing responses too big. > > > > > If anyone can tell me of some other UDP based network application that > > actually attempts to work through NATs by using keepalives (that means: > > not DNS), and without users configuring their NAT with port forwards or > > similar then please tell me so that I don't have to worry that we're > > spending all this energy chasing a solution that might not even exist in > > the first place. There must be some kind of precedence in this area, I'm > > sure. > > > > /Fredrik > > > > > > [1] Excepted for the fragmentation response problem. See: > http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt > http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt > > -- > 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 Wed Dec 13 19:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guels-0005pW-1t; Wed, 13 Dec 2006 19:48:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guelq-0005pN-Ey for sip@ietf.org; Wed, 13 Dec 2006 19:48:22 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guelo-0000ou-UN for sip@ietf.org; Wed, 13 Dec 2006 19:48:22 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 4E6443A02143; Wed, 13 Dec 2006 16:48:18 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id EE6103A0210C; Wed, 13 Dec 2006 16:48:15 -0800 (PST) Message-ID: <45809F4F.3050309@acm.org> Date: Wed, 13 Dec 2006 16:48:15 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> In-Reply-To: <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 > On the performance side, I consistently hear several UDP-apologists > concerned with the maximum number of connections they can handle. > Your approach does nothing to address this concern since it ends up in > the same number of TCP connections as the pure-TCP approach. From the > TCP-advocates I hear that in their implementations they can handle a > very large number of TCP connections by getting rid of poll/select, > and that they can handle about the same number of UAs using UDP as > TCP. The performance bottleneck I usually hear about with these > implementations is access to the registration/location server > database. (I have also heard about the registration/location server > database being a bottleneck in UDP-only implementations as well.) Your > approach would effectively double the number of entries in the > registration database and therefore seems to make things worse rather > than better. Certainly it does not address the perceived performance > problems of either the pro-UDP or the pro-TCP crowd. No, this is not how it would work. 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. So there is 3 possible combinations of transports for SIP; UDP alone, permanent TCP and UDP + temporary TCP. I excluded UDP alone, because of the fragmentation problem. So we wrote two tests with the same kind of transactions an endpoints would do, the first test with a permanent TCP connection, and the second test with a mix of UDP and temporary TCP. The TCP/UDP mixed test, even if it have to create TCP connections and close them each time a SIP message bigger than the MTU have to be sent or received, was using half the resources of the test with the permanent TCP connection. And the UDP+TCP test was using the additional mechanism to request the opening of the TCP connection. So the idea is that at a specific time, a specific flow can use UDP or TCP but not both. The transport for the flow changes depending on what needs to be used for incoming request or outgoing response. After the end of the transaction that needed TCP, the TCP flows is replaced by an UDP flow and the TCP connection is closed. Obviously this works only if the transaction that create the flow, i.e. the REGISTER, does not need TCP. If it is the case, then the only transactions that need TCP are INVITE that carries a big SDP (thanks to ICE) and the NOTIFY that carries big XML documents. > > thanks, > -rohan > > On 12/13/06, Marc Petit-Huguenin wrote: >> Fredrik Thulin wrote: >> > Marc Petit-Huguenin wrote: >> > ... >> >> So this is why I am switching my focus from performance to 1) do not >> >> prevent implementers to use UDP if they need it and 2) anyway RFC 3261 >> >> mandates UDP AND TCP on all elements. >> > >> > Not even RFC3261 manages to get you everything if using UDP though - >> > large messages for one, security (SIPS) for another. >> >> Let's exclude SIPS from the discussion, as DTLS can be used here. >> >> Yes, large messages must go through TCP, but the reality is that not all >> messages mandates to use TCP, and this is especially true for messages >> that are sent periodically, REGISTER and SUBSCRIBE for example. >> >> RFC 3261 already can mix UDP and TCP when there is no NAT[1]. The >> problem here is that it not longer works behind a NAT, even with >> Outbound. My proposal is to extend Outbound so it works the same way. >> >> > >> > As I see it, it is too complicated to try and make SIP over UDP work >> > across NATs to even try it. For those cases where the properties of >> > Outbound are desired, everyone will be better off using TCP. >> > >> > For the cases where you have small messages, don't require security and >> > don't have to worry about NATs or firewalls in your network paths, then >> > UDP is fine (if I don't think about the re-inveted reliability). I >> don't >> > mind anyone using it where it actually works. >> > >> > I'm genuinely worried though that Outbound with UDP won't actually work >> > in the field once finished, because of something we fail to think of at >> > this time. >> >> Outbound with UDP does not work. Because of this some people want to >> exclude UDP from Outbound, which is inconvenient for implementers who >> care about performance. What I am proposing is to make UDP working >> with Outbound instead of excluding it. >> >> Remember that this is not the endpoint that decide to use UDP or TCP, >> its the servers (i.e. NAPTR records as described by RFC 3263). If the >> server decides that the endpoint must use TCP, then everything is fine >> with Outbound. But if the server decides that the endpoint must use UDP >> (and switch to TCP if the message is too big), then things breaks for >> the cases described in my draft, i.e. incoming messages too big and >> outgoing responses too big. >> >> > >> > If anyone can tell me of some other UDP based network application that >> > actually attempts to work through NATs by using keepalives (that means: >> > not DNS), and without users configuring their NAT with port forwards or >> > similar then please tell me so that I don't have to worry that we're >> > spending all this energy chasing a solution that might not even >> exist in >> > the first place. There must be some kind of precedence in this area, >> I'm >> > sure. >> > >> > /Fredrik >> > >> > >> >> [1] Excepted for the fragmentation response problem. See: >> http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt >> >> http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt -- 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 Wed Dec 13 20:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guf07-0004vG-N5; Wed, 13 Dec 2006 20:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guf06-0004v5-Ed for sip@ietf.org; Wed, 13 Dec 2006 20:03:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guf05-0002px-4L for sip@ietf.org; Wed, 13 Dec 2006 20:03:06 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2006 17:03:04 -0800 X-IronPort-AV: i="4.12,165,1165219200"; d="scan'208"; a="90419287:sNHT46132695" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kBE134Mp010691; Wed, 13 Dec 2006 17:03:04 -0800 Received: from [216.102.208.13] (sjc-vpn7-684.cisco.com [10.21.146.172]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBE12tin012906; Wed, 13 Dec 2006 17:02:55 -0800 (PST) Message-ID: <4580A2AA.2030104@cisco.com> Date: Wed, 13 Dec 2006 17:02:34 -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: Marc Petit-Huguenin Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> <45809F4F.3050309@acm.org> In-Reply-To: <45809F4F.3050309@acm.org> 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=2624; t=1166058184; x=1166922184; c=relaxed/simple; s=sjdkim3002; 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=20[Sip]=20I-D=3A=20Preventing=20Fragmentation=20forClie ntInitiated=20Connections=0A=20in=20the=20Session=20Initiation=20Protocol= 20(SIP) |Sender:=20; bh=3NaND25KVklwgZn6qWs3VcIMoJhUhRhcrDhyOnansO0=; b=G2cs6vSBkBDwfhUBOn2+7ygynF/AYALMDipsMp3BobCtFOYEumvEAuI8LZkl6HDJigz5rc3a FRNdRaW3eUjBo4RfdhInJtCFVUPlfg4IXKT5SuN6zBKitj138h9u0msa; Authentication-Results: sj-dkim-3; header.From=mat@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 Marc Petit-Huguenin wrote: >> On the performance side, I consistently hear several UDP-apologists >> concerned with the maximum number of connections they can handle. >> Your approach does nothing to address this concern since it ends up in >> the same number of TCP connections as the pure-TCP approach. From the >> TCP-advocates I hear that in their implementations they can handle a >> very large number of TCP connections by getting rid of poll/select, >> and that they can handle about the same number of UAs using UDP as >> TCP. The performance bottleneck I usually hear about with these >> implementations is access to the registration/location server >> database. (I have also heard about the registration/location server >> database being a bottleneck in UDP-only implementations as well.) Your >> approach would effectively double the number of entries in the >> registration database and therefore seems to make things worse rather >> than better. Certainly it does not address the perceived performance >> problems of either the pro-UDP or the pro-TCP crowd. >> > > No, this is not how it would work. 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. > > So there is 3 possible combinations of transports for SIP; UDP alone, > permanent TCP and UDP + temporary TCP. I excluded UDP alone, because of > the fragmentation problem. So we wrote two tests with the same kind of > transactions an endpoints would do, the first test with a permanent TCP > connection, and the second test with a mix of UDP and temporary TCP. > The TCP/UDP mixed test, even if it have to create TCP connections and > close them each time a SIP message bigger than the MTU have to be sent > or received, was using half the resources of the test with the permanent > TCP connection. And the UDP+TCP test was using the additional mechanism > to request the opening of the TCP connection. > Doesn't this all go down the drain when you add (D)TLS to the mix? The relative costs of establishment are orders of magnitude different right? (I wish I had that number off the top of my head, but I don't) That's really the thing that's swayed me with these debates since we shouldn't be counting on non-use of crypto going forward. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 13 22:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guh43-0003I4-LT; Wed, 13 Dec 2006 22:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guh41-0003HL-Ss for sip@ietf.org; Wed, 13 Dec 2006 22:15:17 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guh3z-0006ih-K5 for sip@ietf.org; Wed, 13 Dec 2006 22:15:17 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 25EFB3A02143; Wed, 13 Dec 2006 19:15:08 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 044CE3A0210C; Wed, 13 Dec 2006 19:15:03 -0800 (PST) Message-ID: <4580C1B7.30206@acm.org> Date: Wed, 13 Dec 2006 19:15:03 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> <45809F4F.3050309@acm.org> <4580A2AA.2030104@cisco.com> In-Reply-To: <4580A2AA.2030104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 Michael Thomas wrote: > Marc Petit-Huguenin wrote: >> >> So there is 3 possible combinations of transports for SIP; UDP alone, >> permanent TCP and UDP + temporary TCP. I excluded UDP alone, because of >> the fragmentation problem. So we wrote two tests with the same kind of >> transactions an endpoints would do, the first test with a permanent TCP >> connection, and the second test with a mix of UDP and temporary TCP. >> The TCP/UDP mixed test, even if it have to create TCP connections and >> close them each time a SIP message bigger than the MTU have to be sent >> or received, was using half the resources of the test with the permanent >> TCP connection. And the UDP+TCP test was using the additional mechanism >> to request the opening of the TCP connection. >> > > Doesn't this all go down the drain when you add (D)TLS to the mix? The > relative costs of establishment are orders of magnitude different right? > (I wish I had that number off the top of my head, but I don't) That's > really the thing that's swayed me with these debates since we shouldn't > be counting on non-use of crypto going forward. > This is a good point. I'll try to find an answer to this. 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 Dec 14 00:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GujB9-00005w-PC; Thu, 14 Dec 2006 00:30:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GujB8-00005p-HK for sip@ietf.org; Thu, 14 Dec 2006 00:30:46 -0500 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GujB6-0006i6-Qg for sip@ietf.org; Thu, 14 Dec 2006 00:30:46 -0500 Received: by tutpro.com (Postfix, from userid 1001) id 69C4C1EC039; Thu, 14 Dec 2006 07:30:37 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lohi.tutpro.com X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from rautu (dhcp9.tutpro.com [192.98.100.136]) by tutpro.com (Postfix) with ESMTP id DC6F61EC003; Thu, 14 Dec 2006 07:30:35 +0200 (EET) Received: by rautu (Postfix, from userid 1000) id 808ADF0168; Thu, 14 Dec 2006 07:30:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17792.57723.393233.978264@rautu.test.fi> Date: Thu, 14 Dec 2006 07:30:35 +0200 From: Juha Heinanen To: "Rohan Mahy" Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) In-Reply-To: <953beacc0612131520r5c554b12n26b761ffca98695c@mail.gmail.com> References: <457EE9D3.1080001@acm.org> <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <17791.40622.256716.794463@rautu.test.fi> <953beacc0612131520r5c554b12n26b761ffca98695c@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, petithug@acm.org, audet@nortel.com, 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 Rohan Mahy writes: > I proposed that since edge proxies and registrars have to support both > UDP and TCP, UAs that want to implement outbound for TCP don't have to > also implement outbound for UDP. My proposal does not prevent > UDP-only devices from working. yes, i didn't actually comment on your proposal, but just how far from rfc3261 requirements the real world is. > There are clearly people who want to implement this spec for TCP, so I > don't see what the problem is with finally doing something that makes > it so we can have interoperable implementations that use TCP behind > NATs. we already have that. after i finally found a sip tcp implementation (in nokia phone), i made the phone to register from behind symmetric NAT with my OpenSER based proxy. the proxy kept tcp connection persistently open and i didn't have any trouble of making both in and outbound calls from that phone. no non-rfc3261 compliant features were in use in the phone. thus i still fail to see what value add would outbound give now when its REAL value add has been removed, i.e., mandating the phone to register with more than one proxy. -- 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 Dec 14 02:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gukji-0008An-Gx; Thu, 14 Dec 2006 02:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gukjh-0008Ae-Nm for sip@ietf.org; Thu, 14 Dec 2006 02:10:33 -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 1Gukjg-0002R0-1b for sip@ietf.org; Thu, 14 Dec 2006 02:10:33 -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 kBE79jK0003974; Thu, 14 Dec 2006 09:10:00 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 09:10:24 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 14 Dec 2006 09:10:23 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBE79nlv013233; Thu, 14 Dec 2006 09:09:50 +0200 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id 23EB693B78; Thu, 14 Dec 2006 09:10:23 +0200 (EET) Message-ID: <4580F8DE.5020703@nokia.com> Date: Thu, 14 Dec 2006 09:10:22 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: "ext Dostal, Pavel" Subject: Re: [Sip] xcap-diff-event References: <3E4278088AD82C48B4663DDFE762CEF302407BE9@prga004a.ww300.siemens.net> In-Reply-To: <3E4278088AD82C48B4663DDFE762CEF302407BE9@prga004a.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2006 07:10:23.0689 (UTC) FILETIME=[EC5EBB90:01C71F4E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF 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 Thanks Pavel, ext Dostal, Pavel wrote: > Jari, > > In chapter 4.3.1 In my opinion the "path" parameter shall be stated as > mandatory. > > right, it should be clarified. > In chapter 4.6.3 the same handling is defined for selector locating > non-existing element and multiple elements. I'd rather distinguish these > cases as subscription to non-existing element may have real usage (as > stated in chapter 4.1), but subscription to multiple elements (in the > sense of one selector for multiple elements) shall not be possible at > all. > > Regards, > > Pavel > > right, the intention is to allow subscription to an non-existing element (as it is stated). However, do you propose something along the lines: exists = "single", "none" or "multiple" ? So none and multiple would be an "error" in XCAP sense where a unique node is always mandatory for a successful operation. Having these two separate states might be better, i.e. the client would probably know to change the request. Also it would be better in-line with XCAP where 404 and 409 error responses separate these cases. However, the initial subscription must then signal this multiple case, I suppose. So it would make the handling a bit more complex, but more deterministic. Comments ? --Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 14 03:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulx7-0002Rp-C2; Thu, 14 Dec 2006 03:28:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gulx5-0002RS-6X for sip@ietf.org; Thu, 14 Dec 2006 03:28:27 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gulx1-0005qw-IJ for sip@ietf.org; Thu, 14 Dec 2006 03:28:27 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9FEA91BF; Thu, 14 Dec 2006 09:28:18 +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, 14 Dec 2006 09:28:18 +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] outbound-06 submitted Date: Thu, 14 Dec 2006 09:28:17 +0100 Message-ID: <7374777208BDC7449D5620EF94232567F6B423@esealmw113.eemea.ericsson.se> In-Reply-To: <953beacc0612121550p2fb16322sc1f03c6b3223b86f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] outbound-06 submitted Thread-Index: AcceSJqEVVtZdkz/QZyT1fy6o3ma7AAazH6w From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" , "Byron Campen" X-OriginalArrivalTime: 14 Dec 2006 08:28:18.0213 (UTC) FILETIME=[CE9A7D50:01C71F59] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIP WG , Cullen Jennings , 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, I see no reason why the UA should need to send STUN BEFORE the REGISTER, but I agree it should do it very soon after it has received the REGISTER response - which may include information whether the edge proxy supports STUN in the first place. Regards, Christer =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: 13. joulukuuta 2006 1:51 > To: Byron Campen > Cc: SIP WG; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] outbound-06 submitted >=20 > Hi Byron, >=20 > We could add text recommending that the UA compare the=20 > rport/received with the XOR-MAPPED-ADDRESS. That would=20 > appear to solve the problem. > Can you think of any problem with this? >=20 > thanks, > -rohan >=20 > On 12/12/06, Byron Campen wrote: > > I have a question about the usage of STUN as a=20 > keepalive over UDP. > > Are clients supposed to start sending STUN before they try to=20 > > REGISTER? If not, I can see the scenario where a UA sends the=20 > > REGISTER, sets a timer (btw 24-29 seconds) for the first STUN=20 > > keepalive, but before that STUN request is sent, the pinhole closes. > > Both ends will think the flow is ok (the STUN keepalive will open a=20 > > new pinhole, but the UA won't know that), and the mess won't get=20 > > cleaned up until the UA re-registers. Sending the keepalive "soon" > > after the REGISTER would probably solve this problem also,=20 > if sending=20 > > before is not acceptable. > > > > Best regards, > > Byron Campen > > > > > Hi, > > > > > > I submitted -06 of outbound so folks can at least take a=20 > look to see=20 > > > that the many small changes we have agreed to have been=20 > incorporated. > > > I also included the proposed text for FASTEST, since the=20 > draft would=20 > > > need significant surgery anyway if we go with CLEANEST. > > > > > > Until it appears in the archive you can find it here: > > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > > > outbound-06.html > > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip- > > > outbound-06.txt > > > > > > thanks, > > > -rohan > > > > > > _______________________________________________ > > > 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 schedule@barnesmiller.com Thu Dec 14 15:10:03 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guwu3-0001GZ-3S for sip-archive@lists.ietf.org; Thu, 14 Dec 2006 15:10:03 -0500 Received: from 90.red-88-8-132.dynamicip.rima-tde.net ([88.8.132.90] helo=[81.33.121.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Guwty-0002He-Am for sip-archive@lists.ietf.org; Thu, 14 Dec 2006 15:10:02 -0500 Received: from [136.117.75.37] (port=13493 helo= by with psmtp id rzZfSw-F907F9-00 for ; Thu, 14 Dec 2006 21:09:51 +0100 Message-ID: <000901c71fbb$c49716d0$00000000@cafeneurotic> From: "TG" To: sip-archive@lists.ietf.org Subject: relevant remember Date: Thu, 14 Dec 2006 21:09:32 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C71FC4.265B7ED0" 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: 2.9 (++) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 ------=_NextPart_000_0005_01C71FC4.265B7ED0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C71FC4.265B7ED0" ------=_NextPart_001_0006_01C71FC4.265B7ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gamepro, gamesnet gamerhelp itworld. Locations details november, normans hallmark quaker nj creations long. Dark crusade dm terror? Keyload secondview newsgroup aardvark, hompage = homepage creator. Badger pikachu scampi moron beaver babes instant turket. Reallife = innercity ambulance reynolds, beginning versions laurens fridaels. = Democracy government governed but notion, consensual mad. Melbourne, = wide custom mock magazine covers. Klaus continuing supplicant family = moved. Cronies lad hatch forbade. Elder scrolls oblivion cheats xii gta = pokemon emerald? Uses optimizer variable scandepth recursive scan batchmode. Check apply guides pamphlets complaint processing. Figures units ways = deck, allies tracking, splinter, agent emudvd. Typed, andy gibbs one machines, also, device. Kidnapping changes teams prostitute coco meagan together spree. Hurricane suriname, sudden death jongwook eurasia. Result glossary evil = morally. Faced attack, infiltrate vicious, terrorist. Breeds mixes personally = createapet. Super ul lyric addon fin replace. Instant turket bored = again. Present puny mhz laptop meg whilst produces. Projects maldives, fighting = sponsor mosquito. Monitors system optimizes memory required regardless. = Catching merry small we convince everyone lockheed. Unfold espionage underwater sandstorm hiding smoke. Betcom affiliate oaslistpos tops oasadtopx, talking baig komando? Releasesu thousands games registered! Containing dogs, mention poodles equally kayaking biking. Reader = developer telecoms ispstelcos broadband operators devices wlan. Xpvista audits leaks networkthe gtb inspector appliance. Webs collection = pictures regularly road. Hot briefs newspaper posted musicians jitters, amapples itunes growth. = Bombgirl beatdown copsgenius birdguitar ping, pongthe. Enforced union worked hire. Novellr xen, roi moving unix discover migrating suse lower. Worse = unprovable, jerk argured lose! Woody harrelson reilly tommy lindsay actor. Facelift torture wanting bc. = Eras television simulation dmz north korea, person military swing? Spelling cached iterative consider delivering native? Amtrak start trains hume, precisely. ------=_NextPart_001_0006_01C71FC4.265B7ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"Nokia"
Gamepro, gamesnet gamerhelp = itworld.
Locations details november, normans = hallmark quaker=20 nj creations long.
Dark crusade dm terror? Keyload = secondview=20 newsgroup aardvark, hompage homepage creator.
Badger pikachu scampi moron beaver = babes instant=20 turket. Reallife innercity ambulance reynolds, beginning versions = laurens=20 fridaels. Democracy government governed but notion, consensual mad. = Melbourne,=20 wide custom mock magazine covers. Klaus continuing supplicant family = moved.=20 Cronies lad hatch forbade. Elder scrolls oblivion cheats xii gta pokemon = emerald?
Uses optimizer variable scandepth = recursive scan batchmode.
Check apply guides pamphlets complaint = processing.=20 Figures units ways deck, allies tracking, splinter, agent = emudvd.
Typed, andy gibbs one machines, also, = device.
Kidnapping changes teams prostitute = coco meagan=20 together spree.
Hurricane suriname, sudden death = jongwook eurasia.=20 Result glossary evil morally.
Faced attack, infiltrate vicious, = terrorist. Breeds=20 mixes personally createapet. Super ul lyric addon fin replace. Instant = turket=20 bored again.
Present puny mhz laptop meg whilst = produces.=20 Projects maldives, fighting sponsor mosquito. Monitors system optimizes = memory=20 required regardless. Catching merry small we convince everyone = lockheed.
Unfold espionage underwater sandstorm = hiding smoke.
Betcom affiliate oaslistpos tops = oasadtopx, talking=20 baig komando?
Releasesu thousands games = registered!
Containing dogs, mention poodles = equally kayaking=20 biking. Reader developer telecoms ispstelcos broadband operators devices = wlan.
Xpvista audits leaks networkthe gtb = inspector=20 appliance. Webs collection pictures regularly road.
Hot briefs newspaper posted musicians = jitters,=20 amapples itunes growth. Bombgirl beatdown copsgenius birdguitar ping, = pongthe.
Enforced union worked = hire.
Novellr xen, roi moving unix discover = migrating=20 suse lower. Worse unprovable, jerk argured lose!
Woody harrelson reilly tommy lindsay = actor.=20 Facelift torture wanting bc. Eras television simulation dmz north korea, = person=20 military swing?
Spelling cached iterative consider = delivering native?
Amtrak start trains hume,=20 precisely.
------=_NextPart_001_0006_01C71FC4.265B7ED0-- ------=_NextPart_000_0005_01C71FC4.265B7ED0 Content-Type: image/gif; name="integrated jukebox.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c71fbb$c49716d0$00000000@cafeneurotic> R0lGODlhVAJEAYewAA4ABYoAAA5+AH2GAAQAe38AgQWBg8XFxsrfyqfG9T4UAG4kAIgVAK4nBMgg BNsXAABAABtEBjs2AFQ1CI4/CpNJA7RHAO41AAtuABVgDDdjAGhnAIdZAKdVCcFiANhrBgCEAC2M BjWOC2uIAoWLDa6FAMpyANx1AAWcBBOuADWpBG2qAXakAJeXBr6RBOehCgC0AB21AEKxAl7MAIy3 B6q0CL25ANnCAgnoACDUCULXAFfoDYTuDJbXAL7eAN3ZCAkMMxgJOkoFTV0ATYsNN6EASLYFP90A PwAVOCMmQk0YTl8WTYgmNJQZSMwTTOsTMgA9PC1LNzdMTWhOTo4xO5tJNbg1QuE6RQtWPh1ZTDtb TVlbP4NbBp5kSrVoOuNlSQBxNi11Nj91N2RxO3h2RqeFTbp5NdGIOAClTBKZM0ORPWOTR46UQZ6U O8CTNtuaMwy9RyXDQTK+OmW7RIPIPKjOTbq6OdPDQQnbQiPjTk3pOFbePIfiRZvXMrXYM+flQgYA gCgKcUUAjmICinYAiKwAdb0AjOoOeQASjB0niUcgdlUjgHUSiJwhcsUdhuohjgRGjS00fDdDgGpL foQ8e5ZNeMc5eOAxfw5kiSpUgUFWdmZjiXNbhqxXhLVhdOVmhwCEfBWLjj5xc1iFgICCgZiIfraM ctSKhgCegCaggkWShWGYgH6VdZyRhceic+yogADEiSPOe03EcVvCiHzFf520h7izjNG5cQDmdxHW dzXqjWDpgH/ofZ/nesbefNftiAUAxS0AxU0AtFIAxHsMy6gAxcoDx94DsQAasRUduD4lvFIRv44h uZcju7MVuNMqugE5xhZEwE01zVk9t3w9yJYxyrI9x9Q/sgJZyC5iwD1TympkyodeyaldscBovNVa zQB7yCeNt0WGt11+vnuGvpt8vbKCtOqFswCayCulwE2ZzV+gyoentJGRurSnwuuZygC8wiXCv06y slG7uIW7sq28xf/64aytrox8g/8ACwv/AP/1BgEA9f8A/wD///P//CH5BAD//6kALAAAAABUAkQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKtPevpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06L+RSJMqXcq0qdOnUKNKnUr1odGrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDKKsqXsy4sePHkCNLniwQ seXLmDNr1ku5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLno16s+3buHPrNkq7t+/fwIO33k28uPHj yJMrX868ufPn0KNLn25SuPXr2LNr3869u/fv4KVS/x9Pvrz58+jTq1/Pvr3798fDy59Pvz5r+D4D 6MfPvz9d/QDu9xKALAVo4D8GCogggScF2OCBKiXIIIMzUZiShBKuZOFOG/rnoXsQATiQiAuReJCJ BJGoIor2BDiifgKxGCOMJ9IYoo0KoSjjjAFwtKN9QAYZmkwbKligkSh1uGAAJhEI4ZICWohkSUrm VGWSRl4ZlJYfdtkfl09miCWTFyropINUOshlk1OmyWSCbk4I55FkxonmklDemWebYj6555tS3gnn nHmySaacdXqpqFtanlnnlUpS6Oik+63ppoaVShrlponS+SCnl6KJ6KURZpnpo5PiiSeiqJoK6KGg qv+66KxdOfRjizau2CNCGPZooojA+irssLZiyCOuux5r0K0p4vgrjcEmG+2LyRb0rLTQZrvrtMfq 6Gyu2SqLo5DkcheTpo4aSmqpnZI66oHpwlRlvHYmammgrYZq5qnqstuvqqOuuu+rnxbsbq/t0qow bw2xGG2CytZYLbUuiqstssVOTC3GzRoYcY7fYrstjNdybLK14Ips8cjEdhtyxxsjS3LF5das3blI 0jump2UmHLDOLc3LL7uwJtyzwQAPLXC+/q77M6joyip11IX6ufDVY+ErNdJHd71z14E2fTSksbqk 9cEE68u011Q/nfbSXFMN5dxY101W2/uu6zXX/xr/LCqfbcLdb8Bmuzq40u8KbS/isSZeNN86y623 3ZTXFJGEHXsr446cj/sxxBLzOvPEoPPoOcwxc8ytyZiLruvLqqecMuqZkz477TbnPlvlWVnK+++5 6R7axcIXb3xjwG9pdfLMF3f889BHL2Tz1Fdv/fXYZ6/99tx3r5X04IcvfnY8CWB+9uYLQFP63rd/ V/rwx3++SuzPFL9N8qv/Uv3l588/TP6bH/4EGJP/scSA7ksgUCSSPoI08CAPhEgEJWi+gUwQIRfU SAYdssGKdDAhH3RgBcdHQnLV5H8I1EkKXWJAAnZlhftzoQplyEIapgSGCswhThg4QoH4z4IjlJ9C /yIoRAj2EIPwE6EA7PFDIMZvIRl8IhKXaEQqNjB/SnTiEZlYRC5eMIQlDGN3TkhA+JWkfuxDow3/ oUb9pRCHaRRgHOfXxjOu0Y76M8kcVwJD+eFRffyrYyDpSEhAlvGOOkxkUVAox0KyEZF6dGQN83jD RrrxfIM0ZB5x+EhKZpJ+AfyjJDuJR1KW8pOfLKUiV7nDiEyQiEGsYBen6EMpVlGLS4SlFWXZwyv2 cosGeeUvqViQECaxlsR8oC+TyUtm5nKYThSjNOdDRk9aUpX5O6AlzVhJSpIylXs85TVbwshN0hCO qTRlOL95zVCqkpXwXOQhzXlJb3ITlN7sZD5NGf9JTfZTnPTkJyfL+c9ukjOdgmynQvf5zng61CU8 JKYXoznRYgKTohaVaBajqUtkVnSiHR3iEUOaURBKMaTL5Cg0wTjNlhpPmM70qDIv6tGKfhClzVRp TEEKxi/m9JZTnOkud5pSmQoViBh1qVLJBVOKCvWmx5xlFY+JzJH+9KNYFKlGvUhTrgrxqFmtqVcz StVZsnSpaIUNejjpFbY+9K1gyV0st1qVs6b1rtAbjx/V4la4+nUreA2sYAdL2MIa9rAc+atiF/sV xDr2sZCNrGQn+zyefOCyPbnsB8SiWcwy9rP86axnNZtZzwqFtCxBrU5UWxLWinazJnmtaFPS2ZP/ kFa2tzWtanc729ia9h+u/S1ouQcRzQrEuMbNSHI/styDNLciz11ucp973MsqRLQDQa51nbtde0h3 u9PtbnPH213KmjcpMgkucIWLE9YCxb0oga9N3Iva4MLWtuzFL283K9/Wjva/sFWvf++7XgL3d7jX cwh1q/tagmDXwZ1lsHcXzGDxWvgDE34whCOc4QsvOLrWpS6IMZyQBmf4xAjRroolnOLykpfE540x VSjM4fBi+LskDrGOYWyQFaMYxRRm8YltzOOCjPjH2S0vknusYwkHWbsTBrKSN0zlJBdZxlhuCo0v /GMfb/jJXMaxkLmb4zBP+cuyXfKSgzzkHXfY/8RQdnOFr/ziKmf5zkzZMoy97GUrn9nKgBazmqss ZjYfWcRKNjR4byznFqt4yhpGcp3xTOmLxKS/+y3wawtM29qmVreYzTSnPx1gUPM3v74lMKfhS19U D3jAuVV1fGvbW5WI+tWpRrD3FPznQp8Z0Rwmc6C5PGhAd7nRwqYysI38ZyFjV9GPvrKxJe3iZlf6 2gtJ729DbepRz1rWsl1JpkV94FGP29XexrV9Oy1r/aaa2+1+t7z9625d25vdpT71fesLanXrW9Pi hre/AdySc+e74MIld37Lbd9/I3zf2yZ4rieO63tnLyJwJvabefxgIju62iZ+c7LnPO2RjznkzP+W dskjjFuQl3zjKbdzsbFNc4RY/OY4h2jNd87znvv850APutCHDpKcG/3oSE+60pfOdMUS/elQVwxP 8kH1olA9H03POnoccvWue53qIrn6RMSeELJH5OsE6XrawS4Qs9vD7VGPu2lqcvWT1J0od6dJ3lWy 95jcPe9eNwngqy54wmv98F/Ze9+BsniYNF4niid84EsyeKwX3vKIz3xOJOL2r7O97WpXCNpBn4+B eN30p/f8Qcg+eoPA/e1gH73ZO/95udt+NHQ3/D+6TnnJV/3xu8f8332P9eHrHvjBLz7x+a773itf +c6/vN2br/nq4/34hq975R2//O33Hfnap37/ShYf/ucnX/rot776Y8L52s8+9p9/PepPD/vSv9/+ ta+/6OEf+tXnX/+sh3+lR3prN4C3d4CgkXuYd37R53nix4DGl3xfx4Dpx3yW53kWOH6/R3zbV4Hr 94E9EXnCt4ELyBIdWH4ZOH0liBLf13jkR4KXl33Yt4IgWIMl0X4GqH8EKH+uF39sJ3byB3c8SIAF wYO0N4D3938IuIS/cYTzR4Sw539IGIBTaID8V4RK+IRUWHY/6IM52H9OyIRiuBphqIP1N4QOCIWy 93/0h4VVOISkV4Zn+IR0OIZ2eId4mId6uId82Id++IeAGIiCKBE2WIjWM4iIKHSGuIjMk4iO//iI kBiJYsSIlMg7kniJmJiJmriJnNiJnviJoBiKomgflViKpniKqJiKqmhvo9iKaLWKsBiLsjiLm+eK tjhNtJiL6XGLvBhGuviLwBiMwjiMxIgbvXiM4lOMyriMzKh0yPiM0dOM0jiN1FiN1niNNAGN2mg8 2NiNhLGN4Jg73jiOgBGO5niOjbEJmxAZ6oiOxaOO8NiO7XgQ8ygQ8WgP8ViPBZGP64iP/OiP//iP BJGPA6GPAHmP+iiPCWmQBXmPDQmPDwmR9kiQCaGQBCmQEjmR/XiQGzmQFFmP88iQ7igkDCmS/riP /QiSHdmQLGmSJ8mSEwmTL2mQJdmRFumRK/8Zkzqpkjo5kxtpkiGZkzyZkQDZkzXZkilpkzk5kuQD E+qYEk8JlfB4ElEZlf9glVS5CSbxlFiJElhplVWplVl5lWK5lWVplmMZjyWhll55lmiZlmUZlm8p lWvplmSJlmypll2pEmCplVzplntJjrixl4HJlnV5mIjZlnhpl3N5l4jZlX+pmJJ5mHk5lZM5lnD5 ln3Jl3Fpl5tZmZHpEp9pmZcpmIPhEPy4jkf5kj7pkAaBkQLZkxz5kyupkCh5kUp5kggplEtJk6pJ kbOJECqJmw5pkb/JmhX5kUC5lExpHTFBmJ4plpt5l4GZmI15maFpndQJmNGZmXrZnXTpnWf/WZ2Y 6ZjluZiRSZ7XSZaFyZim+ReoyZuvCZxBKZseOZ/JeZ+s6ZvI2Z/IaZs+iZ8CipRGyZz66Z+rWZ8u KZMEipLNSS6ryaD1uZ+9KZ/CmZsFCpP8KaATOqEOupO0maH+OaARqqFJKaIeaqIf+qBN+RLQ+Z1w mZ3muZ6peZ5f2ZmkyY/saZg8Cp5SSZo72pmZ6aLS6aM0iqPTCZ1zqZ7vyRdRt6CLAaUs6h2pWaVW eqVYmqVauqVc2qVe+qVgGqZiOqbAOaXCwVhMGhZp2qR7YaZuGhxsGqdy8aZ02htewg/8IKdZBwB8 yqcl4acm4ad92qeBOqgAUKiG+g+E+qeH/2qoi6oSjsqog4qohyqpgOqolfoSeIoSeNqpK9Gpm1oS oJqnnwqqojqqeYqqoXoSpqqqpMqqqxqqo3qqJhGrpLqqekoXD8GnA8GrvNqrAGAPvyqswUqswCoQ wwqsxWqsx7oQw+qry/qs0TqtzAoRqGoPeDoQ2VoQ24qt/OCt2vqtBtGt2dqt4yquCGGu4Jqu5Pqt 7bqu8Lqt6lqnwZGszYqswSqt+Nqs9kqsv5qs/WoQ+qqv+1qtBBGwBhuu5vquClGu6Dqv8wqv59qw 6CoQEWuxnYqx8equ4gqqGiux9LoaMQGoKEGyitqomXqpKVupJmupjHoSLQupK3uyhVqzNP+bEjH7 silhqrX6qriqEptqqzv7qrDKEj/LqUT7D0fbs7Kaqj7rtKfatLSaq3XhEAELsPlqqMrap1vLtdBq sAh7sFrrr1zLr8sqtmO7EBkbrmx7EB67sRN7rqNKEBf7sW3rthwLrgzrsA57tyErsjCRsyYrqCgL s4Vrs4brsojLEjFLuCXLspmauDXBs0LbEkH7tEMbtVBbqpabtEs7ta2KuUrrqaNbuVQ7F1Z7tvdq rP9KrdXar62LtQwBu8UquwlbsBHRtwybEH1rt37bu3hLsdxascOLscArr2v7tn+rHQTburjrvAVL u8oqtrOruq/rutd7u7g7scfbsd7Ltrv/S7cPm7fsKrziy7vjS77r+rbKW7fLi3sykaiUuriOW7OY erMnG7k5+7g4q78oS7Lye786i7Q8W7qmO6uam7SwGroIPLVAS7oOnLlRm8BF27MVfLpz2lLu+75y 9xeYGrlj8bkYHE8cXMKlMcIonMIqrBkm3MIu/MLhs8Iy/D0wXMM2fMNBMsM6vMM8XLU4/MNAHMTY 0cNEXMRGfMRInMRKfBhC3MRNscRQrHNOPMUjEcVWrBKiGLZUbB0fTL1dq7pji6lkO6gCG8ZpS8b4 WrZiXBBkXLbau71enL1iPMfYqxBpi7ZofMdavMWAG78gPMD4C8Azu7/427/2O7MDLMiF/7wSKovI j7u/ivyyjfvHKhu4jszIh3uzkXrFdhERtEuwzHq11ru6bEytoAy9pVy9aVy7owzHZuu80pvK9irK pJzKZUy2fAwen4y9qBzHt4wQA8vLrHwQexzKatzKbxy7wxzLePzLtvzGrsy6bpzL3DHLwzzGdfzF Zxu2jrrKtivKd2y20pwQ3Jy1X4vN5tzGxRzH5VzK0orM1JwaNNGylUyzgwu59SuzjEvJmayzgvvH hqzJjxrQMtvIkEvQ8zuyl8y/+qy4nGwY9BzABw3I+YzQDC259wzIi4vJ/jzQF92/Bq3Ri2zPAN3Q Iy3SiFvRDy0YGX3IKT3IJX3SIh3Jgf8M0y9Rz/m7z/sc0iM9yRQN0JHc0ols0ytNGEJN0pKbv4Qq wCg90/6r1JSKz5P6yJns0ZYKyU991YSbqDSN1Y9K01Gt1UW9xIQ81j1c1matFvG81paW1kvM1nA9 EW791nFd13Z91xkx13q91yOM137914CtEHx9xIEd2IN92IgtmIW92Ixt14n92JAd2ZJdg42N15N9 2Zid2Zp9b5V915vd151d15892qRd2qZNXKEd16e92qzd2q69KKkd27Jtw69tmhexzr6B285sPHus 22WMsL08Gr6Nh90czdcx3LWsGMHtrPAMErQMzcwd3dAdGcs93RmBysgNPgpts2iNGd3/zdFu8d0b jRX/3NQ3HdMdbRc4HRbiXTlBLdUr+9XybdU17dDyy9AGPdEkbdWbLNGLWs/+nd9RDd+YrMhcPdVU /b///N8Ift+bbLgfHN8L3uATPckUzuDpDdUFnd9AHeGIjOAJnuESrdSF++APDuECftU5TeISDt8V jt538d71zb+VDNZDLdAzjtFVveMrDtKS3NUlrt9bzdEGvtA4fuQ2nuE9DeSGnOQCfdBOjtMAzs9Q TtQ1rt8vveLlreVV7tTcjeH4DdNd7uVJ3cg5PeRLzuVH7sEOzuM0DsJJXuQXPeE3LufgjdRZTuEu TeREneZhfuMBHedZneZRLuRu/uci/87Pe/7kI67TPz7ea37lLfHe663k+Xzpil7mL/7oXk7pMB7j Hc7iLq64TJ3lGl7qCW3neG7SFV3k/nvgCc7jqG7fL37fOj7e9xzgmN7Qrg7iX/7rfr7fU/3BCT3n h37riT7h8o3rhl7fgm7siT7jkerputoQtMzM1jzdoLyvxZzHpvzt5Azu9wqt2769wXysug291W3L 5Q621nvu0YzdWavK2WvMznzO7hzOtwvv2ivvcMzMzbzv1zzO3J7NCdu814zvCj/v0TvNnbHdTW7l 9bvrYX64FE/Qdr7UMa3qzm7xff7kIP/sSN7sgW7kQj3xKB/qHQ/pU77p0M7k0p7pq/++5TJe6TFv 81Iu6/hs0TKO4xl/8YMLF6lLzKzsxsWNxmMMzGb8zu3ctV8MzUcPxt7e8Mec78p89Up/yuRezuk8 ytZs9Evv8E5P9cA9rVMv8K/8zdss9t78vK18xgnP9klv73P/zgRvzEiPx0WP8AWP9N2s9QcLWdkt 3M39w4Nv7YVP75J1+KLB+Bzs+Hac+JFvXpA/GfoexJe/EY5f+U5R257/+Z8122sN+t4o+vFM+t1o +tSM+tio+rnM+tfo+nwM+7Rf+7Z/+04q+1SM+7zf+8Cj+8Af/MI//H7o+8Z//AtD/EGM/Mzf/B6i /EDs/NI//dRf/dZ//dgvHdD/w9n/D4vbj8PdH/7ivxvff8M2YQDon/4GwBPq3/7r/w/uj/4oof7z n/4q4f71//7jXx4SEf/pDxD2BA4kWNCgQAMJFS5EuNDhQIYEI0J0OFHhQYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5YWL5qcebCmvZoPG97EmTMhRQMwhQ4lWtToUaRJlS5lWvTfU6hRpf5TOJWq AatZs1bdmlAqV4dQw4r1+hXrU65a1a5l29btW7hx5c6lW9fuXbx59e7l29fvX7wgea4cDLTgTJ09 bxaW+LPpY8iRJU+mXNny5Y+MDSbeqJkn4ocVDXd2jNn0adSpVa9mjVQzUNGkKzr+/0w7dFCfQWW3 5t3b92/gwSG/3jla42zQuosX/9m8NHHFwqVPp17dOvXFt5Uvz+gZeWPcDHNzhH7d/Hn06dVnfJv2 6sL3Zs9qdS9/LNmzYMvGX1sf8H8AAxRwQAILNPBABBNUEK39oqqqPv/ko6/BqfTLb78IJVxwQw47 9PBDEEMUccQKKYwPQhM1tCpDBi90Eb/5uoqRRBprtPFGHHPU0S3BSjOstu1s8vGwIYkMkrvoiFxv SSabdPK8uODDr8Up+0uRyglnxLJFDK/c8UswwxRzTDILRM7CithikUX+VOQyzS3LlHNOOuu0U8zZ SmTTQS/ZjPDP++K8c1BCCzX00KO1nlR0UUYbddQ3RCOVdFJKK7X0n0cz1XRTTjtt6VJQQxV1VFI5 9PRUVFNVdVVWW3X1VVhjlXVWWmtFtVRcc9V1V1579fVXYIMV1VZiizX2WJCEVXZZZpulEVloo5XW VmertfZabLPVdltuux1wWnDDFddTb8s191xhx1V3XXbbdfddeOOVd15667X3XnzzZRRdfvv1F1R9 AxZ4YIILNvhgjgICADs= ------=_NextPart_000_0005_01C71FC4.265B7ED0-- From yet@cii.de Fri Dec 15 01:41:50 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv6lS-0002VZ-8m for sip-archive@lists.ietf.org; Fri, 15 Dec 2006 01:41:50 -0500 Received: from s01060017ee6c1a17.ed.shawcable.net ([68.150.38.249]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gv6lM-0006R2-7F for sip-archive@lists.ietf.org; Fri, 15 Dec 2006 01:41:47 -0500 Received: from [168.136.41.18] (port=61282 helo= by with asmtp id NJafEE-8de3bF-00 for ; Thu, 14 Dec 2006 23:41:53 -0700 Message-ID: <001201c72014$13b1e990$00000000@spedex> From: "also" To: sip-archive@lists.ietf.org Subject: planned Date: Thu, 14 Dec 2006 23:41:40 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C71FD9.67531190" 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.7 (+) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 ------=_NextPart_000_000E_01C71FD9.67531190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C71FD9.67531190" ------=_NextPart_001_000F_01C71FD9.67531190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only, be, found an ofwhereall these. Your use aptget from malicious or exploited. This is production release. = Document language report problem with, email. Exploited mirrors soforth further planned back project page, also. Exploited, mirrors, soforth, further. Digitally signed ensure all files belong. It was on october th testing, = packages that. Nihongo romacircn russkij, suomi svenska default = document. Into yet but they. Advantage more recent versions software see. Been = accepted, into yet but they. And how, becomes, etch unstable where. Other contact pagelast, modified = thu nov utc copyright. States skip quicknav about news, getting support, = developers corner. ------=_NextPart_001_000F_01C71FD9.67531190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"recommend"
Only, be, found an ofwhereall = these.
Your use aptget from malicious or = exploited. This=20 is production release. Document language report problem with, = email.
Exploited mirrors soforth further = planned back=20 project page, also.
Exploited, mirrors, soforth, = further.
Digitally signed ensure all files = belong. It was on=20 october th testing, packages that. Nihongo romacircn russkij, suomi = svenska=20 default document.
Into yet but they. Advantage more = recent versions=20 software see. Been accepted, into yet but they.
And how, becomes, etch unstable where. = Other=20 contact pagelast, modified thu nov utc copyright. States skip quicknav = about=20 news, getting support, developers corner.
------=_NextPart_001_000F_01C71FD9.67531190-- ------=_NextPart_000_000E_01C71FD9.67531190 Content-Type: image/gif; name="Releases Select.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c72014$13b1e990$00000000@spedex> R0lGODlhPAGkAYewAAALAI4FBAJ4AISMAAAAdnIAfwh3g820ybPOxanR70MrAGAUAH4YAKUhAMsU DNMUBAdHACtDAUI9AFk7DIYzBp5BALhNC+M0BQBlACdTAEVuDmNoBXlhBZtlBsFYA+1XDAaDABRz BD+JAF1+AIaHAayHDrGCBOyBAAOUCCqZAEWsAF6nCYCqAJWsAMCmDNmkAAXEABe2ADfJAGS0AILI AJG+B8vKANrCAAzRACLoADzsAFbjC47cA6rtCbvUANHjBwAARyMIREQLNlsDPH4HQKAATccFQtkA NQAdSxwfNjUhOGEhOHgUNKISS84pMucYSQM4NBkzNUQ0NGFINYpBRqw0McZDNt87NQBlSitmMjNe OFVeNnNoB6JhRsZmPONqNQCMRxiHNUWNPFN+RoR8MZJ8P8SAROSLSACmTiKSSj6jN1qbPICTN6Wt ScWmMeGcNQCyRBS9RUi/MmPCP4bJSKO4M7qxROm0QgDsMx3uPUrYQ1viQoLhRKvfTLXaO9ffPAgM gycHfjgAjWcKgYoMg6oAh8gAhtoCgwAbixcuh0UTdVwajXEmgK0TjsgWh9MUewxAgyUziERHgVJF f4E4iKs/isZGdetEdAlkfBxRcjpUf2VljXlYiKtWfbNkcuJkigKBdSh5hzmKhVOFg4mNf59zcsR6 guGJjQCYeB+hiEGTdF6Ug3aojKGejr+dgNOYhwC8eynEdz6+fmOyinLKcqK/frq8ctHOdwDadCLc iEfTdVXod4fZeZnljMrtg+zWeAoAwS4DzkcAzV0Es4UAvacAxrIAxNsJyQAryBIZtzsStFomzXUq vpwhzsYUyOIUyQA4vR1CxD5KtGRCyHUxvakxzsxCvt00zgZtwxNRyDNcymhauHttv6RfwsNpu+Vf vQ1/vSyIzUiJwWR7woaFzaF8tbh0t+NxzACczBStwzWhtmigwY2buZGdx72cue6muADOzBmxwTbK vFW1ynS9vq7Gxf//6JScnIx2dP8AAQr+DP/0CAAA//IE9gH6////+iH5BAAZsPYALAAAAAA8AaQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXCnQnsuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnLllKnUq1qtWrWLNq3crVJNSvYMOK HUu2bNezaNOqXcu2rdu3G8vKnUu3rt27ePPq3csXL9y/gAMLHky4sOHDiBMrZti3sePHkCNLnky5 8tfFmDMjtsy5s2e/mkOLhvu5tOnTTkerXo0WtevXsH2ynk27tu3buHPr3n0xtu/fwKPyHk68uGoB yI2rVIq8OfKczWtGhzndnvPn1q9jp37dpvbp1XeG/4/5/TvN8UPRB5dbXT357TLHg8cevT38+QKk w+eev6f79/255N5/PxG4nk0cNVdQcgspiJCDAykI4T/JQWghgwJNSJCGGHF40IQeghQibkcZ2J2A 2sW3X337oRggfioGyN95z6WYnXMu4qifjOW9xKKNOapn3o33pahjkD52B+SJN7ro5F4E/pikjABW KSR926F3JZVTEtllk2DeFJ6OMJKJZX8DFpmffTVK2SR+L47ZJppnPqnXf2zaGWOVRPI4ZJhfAmij m3oG6p2aXxKqaIt25glmmVnOOWOg8z3JaFAbXSghhg6OqCGIzmXIKYMcehjipgJseJ2qqTIEaqsU kv9a4aipavogrRHK2mqns8KKKqvAirpreRhmVOKKcw56KaDMOinnmi1uSSO0VA5poJ6OLkqtoZOG CeOjkjqLKKVnJsvlXfKFu+e0fFqJqJaMprntTGaeu26jdebp6L3Z1vlmpPNiCzCSTEL57qV4Igvt jM8KbK+8zSa6bLfe5jvwvu32S+fGFQcM6L44HmlUR7bG6uuwsH6Iq8nCtuyyy54WC+yrMMt8a8ol /1pzracWqzPLQPPKM8rB5jp00Z/a/BBzQPbpp7wiL/nnlFEirG6QT0/csKXqsimyoBuP+22fhsKb bpzVTnzg2uypzfbbcIflb9x01y1W03YDpdzefPf/7fffgAcu+OCEb5b34Yi79sHiiVu2+Ac9PZ73 Ro9XbvniCD0ekeUTXf5BQ5pr5HnlEI2OOUWhP5S6Qqsrt3rrA8HOkOyzn/4P7QThbpHurNueEe8G AX+774QtJflLxx+V/E7L28P4XM0z/7xR0d9UvUzXe/bR657HfvrlvX8uEPgH8c6595+Pnjv5CcF+ fvnEoz8+5t3LP3/r9Q+Pf/zFcf/9/+kDYPsEqD/4iS9z9LOd5khXwAaaj3gL5F8DDRg60qWuggk8 IAbFF8EDTnBv/rNfBx2ywdp5sCAXFGAKA6hBCdrvfi9cn/r0V0IYFnCFExyhDT9YPKUsL3nHk9zl /6z3vCHSBIiVc970gsg4JELOiUSEHPKWOD2YZE+JVJQiFl0ixCxukYtN9CIYtYia7fkOhw5kX/AU qMYY3pCNHMyg/NA4QA/SUYbha6EeYYjDPs6Qh8YJoQ3350L3yY6QOVQhHBN5wjXacZGOzOMLS+jH PeJOeLgRZBobeUn+0S6EaNThG/cYPjzu0JQUJOAmGclKTPJNk5RUZSRXiUBSivKWinThKUdZyzrW MJRy5GMNh+fGQJ4RkhvsZDJ1SUP/HZOFk2zjLGVYSNOtMn+MhCD71OjKtTTuK1eUSzi/uZPCkTCO jbRKN/1GTh9arjHjbKc850nPopjznqOppz73yf/PfvYTnwANKD8GqpGB8oMqBiVoQPeWUIUatKAK /chDEzLRi1RUIBdt6EEHotGGGiShBHloR0Ua0Yqa1KMcjeg/MqrS1iDFoC6BKUyLMtOl1HQmNw1K Tms605zGdKA2aehLZApUnBbVHjwtak+PetOmHhUyHGHpSltakYt2xKoFwepErDpRlm40pFQF60kP qlWMOvSsG5WqWb86VbaWdStH8elPNQoTodY1oXNFqlznytS+8kOvdr0rXgHrV7nuFKg+Pexfa0JX wDqWJkSNbF4h+1SnLjYyGykrSNu6Vs52dqqcfStJ01pStCpkrJ7d7EG4SlCsspatH20tacka1s7/ yja1tfXsZ3eblrg+VbBDRaxfHyvYvRJXspM17mOT+lfljhS5wI0uZZsrXOqONK/CPe5gpUvc7j4m s7VFrXipilKEjPerXc0tbtErW9hmtaWjjS1s34rb0KrXo+VNqVfFyl9vGmWvzCWsUBO7XaNeFrpL vayBJ+tY5/4WusFVsHdjkmAIy2TABabwcCPM3e9C1L27ja985Sva0tKWvbM9rWlte1/4tnfE/TWv iV9MUZDm970ojrFue+tbBVeXw4b9rYCFzGAEK5XIHNaudYP64CP7WMgOPjBeoyzlvnY4NlFN74n1 G+IUg3a0ILavlzdL3/PyFsZc/qxWy6xSG6tX/7f73XGcz7wajXYZxV5dsWpx3OaO6jesec5xjefb 5z3rGM1tPbGf07zjRLvYrYVmiz8nTelKW3o9C830YS7N6U57+tOO0bSoR03qUjMG1Kj2dABW7ZRV ByDVoN6Iq2dN61WLxNUTwXVCdB2RWhNk1r+2tUB4/Q9im/oqxDZ2R5TdEGYPxNkK0TWvaf1sYRfb 2tcOwLEtshRXw8TbTQF3T8R9FHKDm9YvEbe5WQ1ryKy71t+e9U3g7RJ1y7ve6K71q2VybnTPhNz4 fjW97b3vgLfb3ewO+L77LfCE87vgDDc4wwtuD4DHxNsRfzjFJc5qdhM83hs/uFA+kmxr43ra2P/e tbBPbnJbGxva2Y75QpTNcm3XvNraxvm2s1LynMcc5T43iL6H7fKW2zzlMK85tGle9Jw3XedQ37lV eq5zfacc6tJuuq9ffvVgO93XQr/6zbMNdK9LHdnYLjvMo571owc96kR/e0G43nWmux3nRjf72atC 9bjLfOZ5/3ndkd51uPv9IH0HeuH3zm2lvDvdHk+4wyG/8Izbu+KTtzjIMV/5kFPe4KBX+OdHL/K+ PD709P63vlHvb4v7++KRv3dNUs95kEPc4Zovve53HxzG+54qvA8+VH9P/OUI//h8Kb7yl898wyD/ +dCPPjmbT/2PSP/6Zqm+9rfPfatg//vgD7//+MdP/vKb//zoT7/618/+9rv//fDPS/fnP5H42//+ +M9/++nP/6Xpf//9F4ACOIAR8X8ASIAImIAKuIAEaIAO+IAQGIGxxoAOsQmbgBUWmE9GYYEvwYH2 YIEgGBMg6IEj2IEh6BIjyIEpuAkmeIItyIIn6IEfWIIykYIv2IIoqIIkKIM0OIMsOIM1+IM8KIQl aIM3OBNGuIM5WGlDCIQ0oYRO6IQyGIVTuIQ1sYNEaIVP+IMwAYUxqINEmIVSCIVdKIZAWIVeaIZl uIQ6aIJrsxEZKBAZGIcHEYd2eIH/QId5iId7OBB62IcKcYdzeIF/WBCFqIeDuIJ7qIiISIgg/wiI fsiHdDiIhoiHlBiJBnGHi8iHcsiJi3EUTeiDXPiCXEiGVFiKNFiFQZiDbaiKayiCowiGNriCbeiG RTiKp+iGosiKpqiKSuiCuth7GjGJnviHmgiIjYiJnViJC6GJIwiJdeiJ0EiJ1OiIfZiMiViMkriN zOiMnHiIz7iImSiNiQGKqAiL6DiGWpiL6xiFW8iGIeiKwTiPrQiD9niG92iL9oiG59iOtViL7eiO u/iKwpgRxMiMBHGMBzmN3IiQCKGQx/iQ0giRCWmNykiR4liRygiN12iJHrmMIGmMFgmSmYEUSdiD pMiLRxiMK5iSZfiPQwiMLjmQ7giQpxiKMv95k1i4k7EIjKaojgL5GxTYEIVIFUVZjhtIi0q5lEzZ lE75lFAZlVI5lVRZlVY5lRKYlVq5lUzBeAAAAENZgEjxlWRpD1/5EmdJlmfpEmoJAGjZlma5lmkJ lzNBl3QZl2uJl3OpljiRl3pJE3ypl375lmXZlm5pmDHBl4gJE2UZl2zZmHLplo45mfQ0mHk5l4+Z mZNpmZH5ljbRmZ2pmZQpmn2pmJI5mJspmZ6ZmKpJmqspE36JmniZmaB5mrbpmqaxEV9pELspELvZ m8AJlv8QnAWhlsMpnMepEMRJnL4pnL1JEM85ENHZnM/JnNDpnMiZnMWZnc15ENMpndn5ncf/+Ztg uZzY2Z3aWRzfWZ3leZ7aGZxkSZ3tCZ7KeZ7WaZ3gGZ/oeZ3suZ/0mZ4A6p/yGZ7c+Z8CKp/JyZyG 2Z+bZhSoeZmHGZiC+Zq02ZijCZuBeZepiaE7kaG3yZqiKZt7GaF12ZqM2ZoiGqGYmZqLeaHk9KCq iZkQSpmc+Ze4eaIgGpsfiqMdWpg7upozyqEVWqKAiaImWqErGpktKpufwRHT2Z8K6p5Pip3IKZ4G ip4MGqDrWaAIGqVY6p7eaZ9caqXRKZ7w+Z5VCqZ/05YDup/kSZ+GiaZpWp/bCaf6OZ7kaZwBiqdp mqV6uqf8mad3aqaDOqZUiqD/WaZcGpYn/2GljHoQwbGgdMGkW/mo9MeV42epUuGot3EUSwqhFvqY PmqaEiqqSgqqMUqqofqXkHmkLrqhjomYsvqjJUqpNBqqtgprnJmqIWqiKUqksbqjQUqhQtqqGOqq obmixKqsRXqjswmrGto4HaGoaPqlvGmoYdqd96mmB3qdXYqt12qtU7qd1FqngPqndsqptpEUOgqt tDqhxKqZScqrLhqt8uqjwHqsdumhreqrRxqaOKqjtpmrdjOtBCqnUBqfhBqm+smmiVqgnGqeC8uw Djuu/NkQ+Dmg3Amfi6pp7Mmmb+qm8xmuJGun3rqnESumE3utcaqlG3unCZGxJzuz6Epqfv86sgwa sua6s9YqsjxLsmdaskA7pzOrrUR7shnrpYjKG+xKr8H6mnD5qfnaqzY6oS1qqiyqr816q6o6rzcq oTWKtfCKqddHsHWjqSyhrmi7tmzbtilBtnAbt3I7t3Rbt7Lhtnibt3q7tz1kt8jHt8Xnt4I7uMAB uIZ7uOtKuIq7uIzbuDOBuIznuJI7uZQrt5C7d5WbuZorF5d7dps7gZ0buhGhDR9BuidhuguBuhyh uh7BuhLhuqN7EkehDTBBu/agDbhruy6Ru7aru7XLuzjhuzEhvLt7uy9BvMYbFsgrE8v7E7rbvMNb E80LvTkhvNTLvGGxEapLurD7D6jbvQP/Ab4FIb4JQb7k2xHn673aG74OAb7uexHpqxDxmxXbq74H 8b32m7sEsb24G77967/1y7sCwb39a7r6a78DnL//673/e8AMbMAKTMALDMAP/L0NnMARvL8F7MAO PMAN/MEGfMEaHMIkzMAefMECfMIAPL8YMbu1u7u4O7y5W7zPe7w2TMPYi701TLs1/MK+G8PJa7w/ fMM2DMRDXLxEHMQ8XMRIvMQ5rMRQTMQ7PBNOjMRW7MS9C8VVvMVRXBlHnMRT3MNKDLzEC8Q+zMQ9 TMYvDMMzbMa827ttDMZgLMZcvMR2XMZSfLvAm8c4fLxxLMd9nMVhXMRqbMVQsb7su7+K/5zA3JvI CMy63TvBjczIj1zJ9YvB4zvJjqzJl4zA/mvJ7NvInNzJ+BvJm1zJlOzIoJy/oFzK46vKbNHJmNzK p4zJmmwQARzKq6y+pKzKnLzLvYzLwGzLr1zLvOzLp4y/qTzLrszKrtzMxzzLI4EUe7zHfmzEbLzG 2bzNemy9WgzDyVvIhjzD3XzN11zF5SzG5RzF5MzOZuzH7lzGcPy884zO60zOWSzE+BzP55y9onts n/tp/wzQAd1pK+G+t1wREyzM5gvJLGwYLPzQzkcWy6vOQHG99hy9Gn3R+3zD1tzPYwG93ky91+tP FZ3EFx28QUzFT+y8TPzSLD0XJY3SnP+Gz24cwx+dztucz9ZrxO98zyt9z+9s0/ksxCs9xTC90S/d 0fp80z1dx+38x4W8z1js1GvM01ZdGif9xVz9zeGszRl9xl2Nx1esxd5Mw2/MzYYMzl5t1H2s1Ejt 1m9tzzwsyEnt0Wsd1p3x1HXNx2U9yOgc17+L00d9111cx8zL1EF9xH/c1lCd2Hm8w3Fd1YSN1m2M x3bMxn19Gl0Nzuo82UYd2IY9yJH9xKBN1oCc2nJ92lIsz44Nz4jN2pCNxqsNz9mXEcG8zL2szMqc zMJMybv928PsupC8yLAMzciNytKs28p9zM+sy8x93Inc254MGAcswNeNzBjMwbD8wMv/XcHRTMHV 7ckcrL/EXcyM3MErTN4LjN3XvdDlvcEgvN3mfcK/7N34bdwWLN9SYbczXdDy9N8APuBJMdCmxhcC nn7//dM6keCJ88NDTRNRndUyTM8WrtQHItI0LeEbbhMOfjjiDMcxXdsWLdtBTU4WLb1B8eH+rBHZ Td8QnMvE/N3JTd3DjcwpPMKirMI83sGT/OIZDN6oHN+KnOMqnOPqXd/4/d4QXMtEHt5nUeOhXNz8 K8u+Hd1XHt4yTt5TTsxW7sFeDt1afuMMrd3DnOXjvcxn3uVqwdsRXMD3K8LNneX3TefNXedrTsCf jN5vnMp9XuPuXebMnMxGXso2jt2v/0zCIJzQHuHCTfzV2hy9XLzWfw3TZ03icvzZlt7atl3Wkp7X m468Ea7plT7i9FzYbx3IG63XCO7Xgi3Wfg3pmP7or63ppF7b4xzpdOzqta7ak+7puA7sct3WvP7q j9HOR43NFX7h3Mzs6/zszj7hI43S4izU8wzXEW7O8Xztzz7XMszPYA3tPl3Zuu7UrD4yWhHRCm0S Ej047R4Srd7gKw4VyL57LN6VBk5qBG5+DL7vTQoSsPvkS27kPJ7fPv7u+V4V583c0Czcv+zmCd8W TI4QDy/m8kvmEb8WDV/MgL7Qi9zxCJ/x7G7x+i3mVN7edm7jIk+/JD/oWL7cwf3yK//P8mouzVJu 83x+5r2t8jM/EkC+wiVc8OpdwUFv8Cg/42ne80q/9Ezf9Pzn75Tm9IQD9VRf9TQh9YNj9fyE9YKj 9V5f9VwfOF8/9mRf9mcb9mif9pBq9mzf9m7/9nAf93J/fGpf93U/9wVr98qB92ev98XhFPmQD28T +D1B+Ppk+DSB+DoR+II/E4Sv+HLB+IYP+cFB+Tdh+WLx+I2PE5ifFJCP+J3v+Jsv+vYQ+jexEYEv EKmf+qPB+g/h+lQB+woh+yAh+65P+7OfD7n/D7ifEqy/+rrP+4w/EJJP/MMv/LT/+8Ff/Mgf/ASh /Kp//NDP/MYv/dY//ct//dl/+8z/T/3PP/zAr/zJr/0G0f3H3/zVb/vgT/3eH/3AH/3CH/+xn/3x D/3fL//wj//5//7Gn//9DxD/8uUTSLDgwYMDDf5jiHBgQYMPEypkKPEhxYYVCVrcGHGhxowXF3LM iNDhR4ggTYIkGXKkx5MlJcYUWdLmTZw5dTZUSLInR4oYIQpVKfJlT5tIacKc6ZLly6dHg378uVQp z5k1NV5VGdPpVoxVW2IlO5GrSZ8dd65lu7bpRJkwt66M23WqTqVpn97UW7TjWLtMBe+8mxXlV69l 6fZ9a3gvTsdw37al3LaxWrgrtV7umnky2sGZ64rWuxnz0sefJUNdzJqzX9Sty5oe/41aNVt7uXXv 5t2790DewO311P1zuMLiyH8TJ567+fLdz40LD96c+nHh2fNh3348unXw150r1979+Xfzyr+j7849 vfrk27WPF+89PnD87X3v59/f/38AAxTwv/oGNPDAAwtEcEEGG3TwQQgjlNBBBSe00LfzLtRwQw47 9PBDEEMUcUQSSzTxRBRTVHFFFlscsEIXY5Rxxv8qs/FGHCFjTbEcdQStRyCDFHJIIos08kgkk9ox Sb4OY/JJKKOUci0JjaMvPe/K0+/KK7fkzr3xuKxuPvuYkw+5/NSzkj0xf9KyvfDIhJFGOhmc784z s/QyTD35TO7PPhWUkzz98vsTT/8/E0XUUDIPxbLROmksMi2k3DSqydRQiqwmorC6KrLHPMPsNdg4 HdWju066bUpWW82xL0+rmusr2hCDtdPPQCXt1MQ6K00txngdylVii301tJZILVUuxWCVTVVmd41N 2V9FnXbJVY3Vlthkheo217CinetXcLsFS1Vrhzosr3BX87ZSZpvKdlt6c4r03gnnfHFPAPXF91+A AxYzQn8x5FdghBNWeGGGG3b4YYjrrHdiiiu2+GKMM9Z4Y447ZihikEMWeWSSSzb5ZJRTJtljllt2 +eWdVJZ5ZpprtvlmnHPWeWeeezYZZqCDFnpooos2+mikk1Z6aaabdvppV32Wemr/qqu2+mqss74Q aq679vprsMMWe2yyyzb7bLTTVnttttt2+22441Zba7rrtvtuvPPWW2C5+/b7b8ADH9JSITudFSxc CdfxrMMFb1pDS+FLsEA1I2fPzTEtHXPvkJH81PDKQA9XXqpIL9300x1/2kLJE518T0IPpg892jeP j/OrW4dQ99j9g6/y+qQrGHd8jQS9yePjcnJ0wgxLHXlPVXc6X30jlx07g9+r0PLal4NzeOIjNX7e d510aXnnGbf+qMWjl55p6gudTjzdb/c+89+vA36//cN3ePzTTUVTqxLdbT43QFS1r3Hve1sB/6I8 vJQrguw73wLdlxIGKo11wUuT/+34RzkY9c9+GfrS7PwntdahiX4hlBx47mdC+2HPgyeMmOeIwjwL Kil9F8Rg4274w3ll0G3rQ5Wb2GK98ykOcbKKlRErKMS+KbGJoXOi8gwXuZxU8YlQNBoNvfg/LoZR jGMkYxnNeEY0ptFIX2RjG934RjjG8V5qpCPH5HhHGdVRjxjDYx9ZtEdAUsyPg0RRIA25LUImkkSH ZGQjHflISDpOkZMEUSQteUlMZlKTGqRkJz35yX9tUpSjJGUpTdkqUKYSQqdkZStd+UpYNkSVs6Rl LW15S1zmsnix5GUvfflLYAZTmMMkZjGJpktkJlOZy2RmM5VpTEs6M5fQjKQ0rSp5zUlSE5LY5GY3 5ahNcIZTnOMkZznNSUpvqvKce0xnKtepx3bGU56cCwgAOw== ------=_NextPart_000_000E_01C71FD9.67531190-- From sip-bounces@ietf.org Fri Dec 15 04:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9Wh-0003I6-DX; Fri, 15 Dec 2006 04:38:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9We-0003FI-N4 for sip@ietf.org; Fri, 15 Dec 2006 04:38:44 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv9Wb-0003zm-5i for sip@ietf.org; Fri, 15 Dec 2006 04:38:44 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kBF9cdmN004206 for ; Fri, 15 Dec 2006 10:38:39 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kBF9cbht025810 for ; Fri, 15 Dec 2006 10:38:38 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 10:38: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_01C7202C.CAD39695" Date: Fri, 15 Dec 2006 10:38:35 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-fries-sip-identity-usage-bcp-01.txt Thread-Index: AccdZrxrMUWtBG32S1m51VHkaCyePgCxLoNQ From: "Fries, Steffen" To: "IETF SIP List" X-OriginalArrivalTime: 15 Dec 2006 09:38:37.0342 (UTC) FILETIME=[CBD03BE0:01C7202C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Sip] FW: I-D ACTION:draft-fries-sip-identity-usage-bcp-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7202C.CAD39695 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, please find below the announcement for the updated draft on the SIP Identity BCP describing the use of SIP Identity for the protection of credential exchange between clients. We updated the draft and discussed the use cases more elaborately and also included the handling of the reverse direction using the connected identity approach. We would be interested if this work is seen as useful in the scope of the SIP WG at is is right now or if additions are needed. Regards Steffen -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, December 11, 2006 9:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-fries-sip-identity-usage-bcp-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Identity Usage BCP Author(s) : S. Fries, et al. Filename : draft-fries-sip-identity-usage-bcp-01.txt Pages : 11 Date : 2006-12-11 =09 This document describes a use case for RFC4474 (SIP Identity) for verifying a certificate that might not be publicly verifiable by traditional means. It provides a best current practice document for binding an identity to a certificate for the duration of a session. The certificate may then be used to bootstrap further security parameters, e.g., for securing media data. A discussion of possible enhancements is included in the appendix. Editors Note: The first version of this draft was discussed in the SIPPING WG. As the target of this draft is a BCP for current issues, the draft was updated and submitted to the SIP WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fries-sip-identity-usage-bcp-0 1.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. 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=20 "get draft-fries-sip-identity-usage-bcp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-fries-sip-identity-usage-bcp-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_01C7202C.CAD39695 Content-Type: application/octet-stream; name="draft-fries-sip-identity-usage-bcp-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-fries-sip-identity-usage-bcp-01.URL Content-Disposition: attachment; filename="draft-fries-sip-identity-usage-bcp-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mcmllcy1zaXAtaWRlbnRpdHktdXNhZ2UtYmNwLTAxLnR4dA0K ------_=_NextPart_001_01C7202C.CAD39695 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_01C7202C.CAD39695-- From sip-bounces@ietf.org Fri Dec 15 09:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvELW-0005K4-AX; Fri, 15 Dec 2006 09:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvELV-0005Jy-Cv for sip@ietf.org; Fri, 15 Dec 2006 09:47:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvELT-0005rL-QB for sip@ietf.org; Fri, 15 Dec 2006 09:47:33 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 15 Dec 2006 06:47:31 -0800 X-IronPort-AV: i="4.12,175,1165219200"; d="scan'208"; a="91238904:sNHT50613174" 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 kBFElVG9014148; Fri, 15 Dec 2006 06:47:31 -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 kBFElQSb024963; Fri, 15 Dec 2006 06:47:28 -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); Fri, 15 Dec 2006 09:46:59 -0500 Received: from [10.86.243.41] ([10.86.243.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 09:46:59 -0500 Message-ID: <4582B562.3050309@cisco.com> Date: Fri, 15 Dec 2006 09:46:58 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: zhang.lu2@zte.com.cn Subject: Re: [Sip] Help: "About multiple early-session sdp body in a request" References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Dec 2006 14:46:59.0229 (UTC) FILETIME=[DFCC24D0:01C72057] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4926; t=1166194051; x=1167058051; 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=20[Sip]=20Help=3A=20=22About=20multiple=20early-session =20sdp=20body=20in=20a=20request=22 |Sender:=20; bh=HXLltidHYpXXenjq4tnQbVI9heD7wp7rHV1/vmgjIfA=; b=aJ04jCQX3X7s5WRb1Cpe/UKnKoXwq51bfJ/ObJTOR0XMVXhDDQix5aUhNohOzOapVD6AXDf9 ODt2x91ApWno+DKqPs3xmobXh/1y4tO+XNL12hZq2ZcLLYA/5yHKFU/n; 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org, shen.chengnian@zte.com.cn, ling.wenjie@zte.com.cn, shi.hao2@zte.com.cn 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 zhang.lu2@zte.com.cn wrote: > > Dear Sip Group, > > There encounters some questions when I read RFC 3959 and RFC 3960 > which refer to the Early-Session , that is Note that you may be the first to consider implementing this. I've asked around and haven't heard of an implementation. So answers are somewhat speculative. > *1. "Is it available to include multiple early-session sdp body > in a request?"* I think this is not entirely clear, but its not clear what it would mean if you were to attempt it. Also, each offer must be matched to an answer. If there were multiple early-session offers, then there would need be multiple early session answers. In that case, there would need to be some convention to decide which early answer goes with which early offer. Getting early-session to work at all is enough of a challenge. Getting multiple early sessions to work seems like folly. > for example: > Content-Type: multipart/mixed; boundary="boundary1" > Content-Length: 401 > > --boundary1 > Content-Type: application/sdp > Content-Disposition: early-session > > v=0 > o=Bob 2890844725 2890844725 IN IP4 host1.example.org > s= > c=IN IP4 192.0.2.2 > t=0 0 > m=audio 30000 RTP/AVP 0 > > --boundary1 > Content-Type: application/sdp > Content-Disposition: early-session > > v=0 > o=Bob 2890844714 2890844714 IN IP4 host2.example.org > s= > c=IN IP4 192.0.2.3 > t=0 0 > m=audio 30002 RTP/AVP 0 > > --boundary1-- > > > *2. "How can a UAS decide to handle a early-session sdp ,and not to > handle other early-session sdps when UAS receive a request with > multiple early-session sdps?"* Well, that is an issue isn't it. It assumes that you don't want to handle them all. This problem exists with early media in forking situations without use of early-session, and in fact was one of the reasons early-session was proposed. If you introduce multiple early sessions, then in some sense the problem has been reintroduced. > This question arises from the following scene: > Before A and B establish communication£¬ > (1) AS-1 wants to send media to B > (2) AS-2 wants to send media to A Is this in the context of IMS? To be able to do this, the AS's must be UAs. For the call flow you show, both AS-1 and AS-2 must act as B2BUAs. To make sense of all this, and achieve the sessions you show, I think they must have a lot of understanding of what is going on in this particular case. In the abstract I don't see how they could know that, but in a particular case perhaps that is possible. In the case you show it appears to me that you might never have to include two early-session descriptions in the same message. Instead, wouldn't one be removed, because it is being handled, and another added to be handled on a different leg? But its hard to say for sure without a concrete example of exactly what you are trying to do. IMO you are on a dangerous course in uncharted waters. It would be better if you found a more mainstream way to do what you want. Since apparently you have a B2BUA at each step, I think you could probably achieve what you want in a more straightforward way by carefully managing the contents of standard offers and answers along the way. Paul > To reach the goal , some principles should obey: > (1)precondtion defined in RFC 3312 > (2)Early-Session defined in RFC 3959, RFC 3960 > > The red circles mark special processing. > > > > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Dec 15 13:53:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIA7-00036C-Vz; Fri, 15 Dec 2006 13:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIA5-0002zt-3J for sip@ietf.org; Fri, 15 Dec 2006 13:52:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvI8J-00007Q-3P for sip@ietf.org; Fri, 15 Dec 2006 13:50:13 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GvI89-0005KK-SA for sip@ietf.org; Fri, 15 Dec 2006 19:50:02 +0100 Received: from pro47.proekspert.ee ([217.159.142.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 19:50:01 +0100 Received: from leg0 by pro47.proekspert.ee with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 19:50:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: sip@ietf.org From: Ahti Legonkov Date: Fri, 15 Dec 2006 20:28:53 +0200 Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pro47.proekspert.ee User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en, et X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Keeping session data in SIP messages? 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! I am writing a load balancing SIP proxy and would like to keep it as simple as possible, ie. I would like to avoid using any databases. Currently I have come up with the following solution: When first INVITE arrives, calculate branch parameter, determine the server to forward the message to, store the relation between branch and server name in database. When another message in this session arrives (the same branch parameter of Via header) the server name is looked up from database and the message is forwarded to that server. Can I put some header or parameter for some header in the message that client would be required to include in the next request message it sends out during the session? Thanks! -- Ahti Legonkov _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 15 14:05:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIMr-0000BJ-S4; Fri, 15 Dec 2006 14:05:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIMp-0000Ag-Vd for sip@ietf.org; Fri, 15 Dec 2006 14:05:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvIMn-00029B-M6 for sip@ietf.org; Fri, 15 Dec 2006 14:05:11 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2006 11:05:07 -0800 X-IronPort-AV: i="4.12,176,1165219200"; d="scan'208"; a="48737283:sNHT46092364" 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 kBFJ57Ub013929; Fri, 15 Dec 2006 14:05:07 -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 kBFJ56vo023203; Fri, 15 Dec 2006 14:05:07 -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, 15 Dec 2006 14:05:06 -0500 Received: from [10.86.243.41] ([10.86.243.41]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 14:05:06 -0500 Message-ID: <4582F1E1.6060809@cisco.com> Date: Fri, 15 Dec 2006 14:05:05 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ahti Legonkov Subject: Re: [Sip] Keeping session data in SIP messages? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 19:05:06.0400 (UTC) FILETIME=[EEDEE600:01C7207B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1772; t=1166209507; x=1167073507; 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=20[Sip]=20Keeping=20session=20data=20in=20SIP=20message s? |Sender:=20 |To:=20Ahti=20Legonkov=20; bh=ceLzKQFeQIzQt48IZ5t1OCewN9xTTKOLr9KpL+Lfq9k=; b=jj//Vwc48RD3YJtoWcB6665iswXLo0QRxfRZ0uQbwStW1B+RM2/xnnoTSyNmzVwyB5+xABTt pAx+c0LmtXuKJl7QcLtLtrTYINr5picvt+EH/6C4PX/eOQodaG+QPfHu; 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: 4d87d2aa806f79fed918a62e834505ca 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 Ahti Legonkov wrote: > Hello! > > I am writing a load balancing SIP proxy and would like to keep it as > simple as possible, ie. I would like to avoid using any databases. > > Currently I have come up with the following solution: > > When first INVITE arrives, calculate branch parameter, determine the > server to forward the message to, store the relation between branch > and server name in database. When another message in this session > arrives (the same branch parameter of Via header) the server name is > looked up from database and the message is forwarded to that server. > > Can I put some header or parameter for some header in the message > that client would be required to include in the next request message > it sends out during the session? Its not clear to me why you need to do anything. If the server is the UAS, then it will return a Contact header with the uri to be used for additional requests in the session. If your proxy is even involved in the subsequent messages, then it will simply forward to that address, which will be in the R-URI. If the server you selected is a proxy, and if it wants to be involved in subsequent in-dialog requests, then it can Record-Route. And if *your* proxy wants to be in subsequent requests in the dialog, then it also should Record-Route. What more is required here? Paul > Thanks! > > -- > Ahti Legonkov > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 czeqbmlli@elite-line.net Fri Dec 15 14:07:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvIOr-0001GO-6n for sip-archive@lists.ietf.org; Fri, 15 Dec 2006 14:07:17 -0500 Received: from atlas.elite-line.net ([195.184.203.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvIOp-0002NX-KH for sip-archive@lists.ietf.org; Fri, 15 Dec 2006 14:07:17 -0500 From: "charts" To: sip-archive@lists.ietf.org Subject: Next Big Winner Date: Fri, 15 Dec 2006 21:07:13 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7208C.FE4FC760" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccgjP5PtNUvV6DYS32rYfFqzjwOHw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <4F27FFC92FCFCE1.864BFE4B61@elite-line.net> X-Spam-Score: 4.0 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0001_01C7208C.FE4FC760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.45 (50% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0001_01C7208C.FE4FC760-- From sip-bounces@ietf.org Fri Dec 15 16:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvKqQ-0002sB-NK; Fri, 15 Dec 2006 16:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvKqP-0002r4-4u for sip@ietf.org; Fri, 15 Dec 2006 16:43:53 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvKqM-0007gn-S7 for sip@ietf.org; Fri, 15 Dec 2006 16:43:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GvKq0-0008Dl-7f for sip@ietf.org; Fri, 15 Dec 2006 22:43:30 +0100 Received: from pro47.proekspert.ee ([217.159.142.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 22:43:28 +0100 Received: from leg0 by pro47.proekspert.ee with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Dec 2006 22:43:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: sip@ietf.org From: Ahti Legonkov Date: Fri, 15 Dec 2006 23:42:45 +0200 Lines: 11 Message-ID: References: <4582F1E1.6060809@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pro47.proekspert.ee User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en, et In-Reply-To: <4582F1E1.6060809@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] Re: Keeping session data in SIP messages? 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: > If the server you selected is a proxy, and if it wants to be involved in > subsequent in-dialog requests, then it can Record-Route. And if *your* > proxy wants to be in subsequent requests in the dialog, then it also > should Record-Route. There had to be a simple and elegant solutiond and this is it. Thanks! -- Ahti Legonkov _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 15 20:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOb7-0006Hq-Po; Fri, 15 Dec 2006 20:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOb6-0006Hk-Ts for sip@ietf.org; Fri, 15 Dec 2006 20:44:20 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvOb6-0001nU-BN for sip@ietf.org; Fri, 15 Dec 2006 20:44:20 -0500 Received: by ug-out-1314.google.com with SMTP id 72so839755ugd for ; Fri, 15 Dec 2006 17:44:19 -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=NxETmH0iO3atsbAf11ldufoSSczW9iN172B2wcgAMWMmsGouGcnjSPE9UuEtpuG8kv85agWFZrfyE+/B96DABsH5TNXvQt+qTSVcM8iEYoP80urR3JCzWMyGJmsBh1OfdAqA9/pP5xjvh5Sso+AcML+Wdpz5WQYSc+PVKfUxDnM= Received: by 10.78.185.16 with SMTP id i16mr667922huf.1166233458676; Fri, 15 Dec 2006 17:44:18 -0800 (PST) Received: by 10.78.200.9 with HTTP; Fri, 15 Dec 2006 17:44:17 -0800 (PST) Message-ID: <953beacc0612151744l422c87c5tf5d8f5c9f177b786@mail.gmail.com> Date: Fri, 15 Dec 2006 17:44:17 -0800 From: "Rohan Mahy" To: "Marc Petit-Huguenin" Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) In-Reply-To: <45809F4F.3050309@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> <45809F4F.3050309@acm.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 Marc, What is the edge proxy supposed to do when it wants to deliver a large INVITE request to the UA and the UA does not have a TCP-connection established at the moment? thanks, -rohan On 12/13/06, Marc Petit-Huguenin wrote: > > On the performance side, I consistently hear several UDP-apologists > > concerned with the maximum number of connections they can handle. > > Your approach does nothing to address this concern since it ends up in > > the same number of TCP connections as the pure-TCP approach. From the > > TCP-advocates I hear that in their implementations they can handle a > > very large number of TCP connections by getting rid of poll/select, > > and that they can handle about the same number of UAs using UDP as > > TCP. The performance bottleneck I usually hear about with these > > implementations is access to the registration/location server > > database. (I have also heard about the registration/location server > > database being a bottleneck in UDP-only implementations as well.) Your > > approach would effectively double the number of entries in the > > registration database and therefore seems to make things worse rather > > than better. Certainly it does not address the perceived performance > > problems of either the pro-UDP or the pro-TCP crowd. > > No, this is not how it would work. 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. > > So there is 3 possible combinations of transports for SIP; UDP alone, > permanent TCP and UDP + temporary TCP. I excluded UDP alone, because of > the fragmentation problem. So we wrote two tests with the same kind of > transactions an endpoints would do, the first test with a permanent TCP > connection, and the second test with a mix of UDP and temporary TCP. > The TCP/UDP mixed test, even if it have to create TCP connections and > close them each time a SIP message bigger than the MTU have to be sent > or received, was using half the resources of the test with the permanent > TCP connection. And the UDP+TCP test was using the additional mechanism > to request the opening of the TCP connection. > > So the idea is that at a specific time, a specific flow can use UDP or > TCP but not both. The transport for the flow changes depending on what > needs to be used for incoming request or outgoing response. After the > end of the transaction that needed TCP, the TCP flows is replaced by an > UDP flow and the TCP connection is closed. > > Obviously this works only if the transaction that create the flow, i.e. > the REGISTER, does not need TCP. If it is the case, then the only > transactions that need TCP are INVITE that carries a big SDP (thanks to > ICE) and the NOTIFY that carries big XML documents. > > > > > thanks, > > -rohan > > > > On 12/13/06, Marc Petit-Huguenin wrote: > >> Fredrik Thulin wrote: > >> > Marc Petit-Huguenin wrote: > >> > ... > >> >> So this is why I am switching my focus from performance to 1) do not > >> >> prevent implementers to use UDP if they need it and 2) anyway RFC 3261 > >> >> mandates UDP AND TCP on all elements. > >> > > >> > Not even RFC3261 manages to get you everything if using UDP though - > >> > large messages for one, security (SIPS) for another. > >> > >> Let's exclude SIPS from the discussion, as DTLS can be used here. > >> > >> Yes, large messages must go through TCP, but the reality is that not all > >> messages mandates to use TCP, and this is especially true for messages > >> that are sent periodically, REGISTER and SUBSCRIBE for example. > >> > >> RFC 3261 already can mix UDP and TCP when there is no NAT[1]. The > >> problem here is that it not longer works behind a NAT, even with > >> Outbound. My proposal is to extend Outbound so it works the same way. > >> > >> > > >> > As I see it, it is too complicated to try and make SIP over UDP work > >> > across NATs to even try it. For those cases where the properties of > >> > Outbound are desired, everyone will be better off using TCP. > >> > > >> > For the cases where you have small messages, don't require security and > >> > don't have to worry about NATs or firewalls in your network paths, then > >> > UDP is fine (if I don't think about the re-inveted reliability). I > >> don't > >> > mind anyone using it where it actually works. > >> > > >> > I'm genuinely worried though that Outbound with UDP won't actually work > >> > in the field once finished, because of something we fail to think of at > >> > this time. > >> > >> Outbound with UDP does not work. Because of this some people want to > >> exclude UDP from Outbound, which is inconvenient for implementers who > >> care about performance. What I am proposing is to make UDP working > >> with Outbound instead of excluding it. > >> > >> Remember that this is not the endpoint that decide to use UDP or TCP, > >> its the servers (i.e. NAPTR records as described by RFC 3263). If the > >> server decides that the endpoint must use TCP, then everything is fine > >> with Outbound. But if the server decides that the endpoint must use UDP > >> (and switch to TCP if the message is too big), then things breaks for > >> the cases described in my draft, i.e. incoming messages too big and > >> outgoing responses too big. > >> > >> > > >> > If anyone can tell me of some other UDP based network application that > >> > actually attempts to work through NATs by using keepalives (that means: > >> > not DNS), and without users configuring their NAT with port forwards or > >> > similar then please tell me so that I don't have to worry that we're > >> > spending all this energy chasing a solution that might not even > >> exist in > >> > the first place. There must be some kind of precedence in this area, > >> I'm > >> > sure. > >> > > >> > /Fredrik > >> > > >> > > >> > >> [1] Excepted for the fragmentation response problem. See: > >> http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt > >> > >> http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt > > -- > 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 Fri Dec 15 21:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOuO-0006cf-Sh; Fri, 15 Dec 2006 21:04:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvOuO-0006cZ-FJ for sip@ietf.org; Fri, 15 Dec 2006 21:04:16 -0500 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvOuN-0003pO-TB for sip@ietf.org; Fri, 15 Dec 2006 21:04:16 -0500 Received: by www.implementers.org (Postfix, from userid 1006) id 500803A02143; Fri, 15 Dec 2006 18:04:13 -0800 (PST) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id D36EA3A0210C; Fri, 15 Dec 2006 18:04:08 -0800 (PST) Message-ID: <45835417.8020307@acm.org> Date: Fri, 15 Dec 2006 18:04:07 -0800 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.8 (X11/20061129) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] I-D: Preventing Fragmentation forClientInitiated Connections in the Session Initiation Protocol (SIP) References: <8B1D53AEF7B03449A6D3771B3B7F850F031D3DC4@esebe103.NOE.Nokia.com> <45801BBD.3060307@acm.org> <45802084.20208@it.su.se> <45802F76.8030803@acm.org> <953beacc0612131543l2afce06cxbdfdd5c0253da458@mail.gmail.com> <45809F4F.3050309@acm.org> <953beacc0612151744l422c87c5tf5d8f5c9f177b786@mail.gmail.com> In-Reply-To: <953beacc0612151744l422c87c5tf5d8f5c9f177b786@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org, Fredrik Thulin , audet@nortel.com, 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 Rohan Mahy wrote: > Hi Marc, > > What is the edge proxy supposed to do when it wants to deliver a large > INVITE request to the UA and the UA does not have a TCP-connection > established at the moment? As I proposed in my draft[1], the edge proxy sends a STUN ForceCCP[2] request over UDP to the UA to replace the flow by a TCP flow. The edge proxy can then use the TCP connection to send the INVITE. The TCP flow is replaced by an UDP flow at the end of the SIP transaction, or after 5 seconds if there is no SIP transaction. The TCP connection is then closed. Note that the draft is missing lot of stuff, e.g. how an edge proxy knows that the endpoint supports this, etc... [1] http://tools.ietf.org/html/draft-petithuguenin-sip-outbound-fragmentation-00#section-6 [2] Force Congestion Controlled Transport Protocol > > thanks, > -rohan > > On 12/13/06, Marc Petit-Huguenin wrote: >> > On the performance side, I consistently hear several UDP-apologists >> > concerned with the maximum number of connections they can handle. >> > Your approach does nothing to address this concern since it ends up in >> > the same number of TCP connections as the pure-TCP approach. From the >> > TCP-advocates I hear that in their implementations they can handle a >> > very large number of TCP connections by getting rid of poll/select, >> > and that they can handle about the same number of UAs using UDP as >> > TCP. The performance bottleneck I usually hear about with these >> > implementations is access to the registration/location server >> > database. (I have also heard about the registration/location server >> > database being a bottleneck in UDP-only implementations as well.) Your >> > approach would effectively double the number of entries in the >> > registration database and therefore seems to make things worse rather >> > than better. Certainly it does not address the perceived performance >> > problems of either the pro-UDP or the pro-TCP crowd. >> >> No, this is not how it would work. 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. >> >> So there is 3 possible combinations of transports for SIP; UDP alone, >> permanent TCP and UDP + temporary TCP. I excluded UDP alone, because of >> the fragmentation problem. So we wrote two tests with the same kind of >> transactions an endpoints would do, the first test with a permanent TCP >> connection, and the second test with a mix of UDP and temporary TCP. >> The TCP/UDP mixed test, even if it have to create TCP connections and >> close them each time a SIP message bigger than the MTU have to be sent >> or received, was using half the resources of the test with the permanent >> TCP connection. And the UDP+TCP test was using the additional mechanism >> to request the opening of the TCP connection. >> >> So the idea is that at a specific time, a specific flow can use UDP or >> TCP but not both. The transport for the flow changes depending on what >> needs to be used for incoming request or outgoing response. After the >> end of the transaction that needed TCP, the TCP flows is replaced by an >> UDP flow and the TCP connection is closed. >> >> Obviously this works only if the transaction that create the flow, i.e. >> the REGISTER, does not need TCP. If it is the case, then the only >> transactions that need TCP are INVITE that carries a big SDP (thanks to >> ICE) and the NOTIFY that carries big XML documents. >> >> > >> > thanks, >> > -rohan >> > >> > On 12/13/06, Marc Petit-Huguenin wrote: >> >> Fredrik Thulin wrote: >> >> > Marc Petit-Huguenin wrote: >> >> > ... >> >> >> So this is why I am switching my focus from performance to 1) do >> not >> >> >> prevent implementers to use UDP if they need it and 2) anyway >> RFC 3261 >> >> >> mandates UDP AND TCP on all elements. >> >> > >> >> > Not even RFC3261 manages to get you everything if using UDP though - >> >> > large messages for one, security (SIPS) for another. >> >> >> >> Let's exclude SIPS from the discussion, as DTLS can be used here. >> >> >> >> Yes, large messages must go through TCP, but the reality is that >> not all >> >> messages mandates to use TCP, and this is especially true for messages >> >> that are sent periodically, REGISTER and SUBSCRIBE for example. >> >> >> >> RFC 3261 already can mix UDP and TCP when there is no NAT[1]. The >> >> problem here is that it not longer works behind a NAT, even with >> >> Outbound. My proposal is to extend Outbound so it works the same way. >> >> >> >> > >> >> > As I see it, it is too complicated to try and make SIP over UDP work >> >> > across NATs to even try it. For those cases where the properties of >> >> > Outbound are desired, everyone will be better off using TCP. >> >> > >> >> > For the cases where you have small messages, don't require >> security and >> >> > don't have to worry about NATs or firewalls in your network >> paths, then >> >> > UDP is fine (if I don't think about the re-inveted reliability). I >> >> don't >> >> > mind anyone using it where it actually works. >> >> > >> >> > I'm genuinely worried though that Outbound with UDP won't >> actually work >> >> > in the field once finished, because of something we fail to think >> of at >> >> > this time. >> >> >> >> Outbound with UDP does not work. Because of this some people want to >> >> exclude UDP from Outbound, which is inconvenient for implementers who >> >> care about performance. What I am proposing is to make UDP working >> >> with Outbound instead of excluding it. >> >> >> >> Remember that this is not the endpoint that decide to use UDP or TCP, >> >> its the servers (i.e. NAPTR records as described by RFC 3263). If the >> >> server decides that the endpoint must use TCP, then everything is fine >> >> with Outbound. But if the server decides that the endpoint must >> use UDP >> >> (and switch to TCP if the message is too big), then things breaks for >> >> the cases described in my draft, i.e. incoming messages too big and >> >> outgoing responses too big. >> >> >> >> > >> >> > If anyone can tell me of some other UDP based network application >> that >> >> > actually attempts to work through NATs by using keepalives (that >> means: >> >> > not DNS), and without users configuring their NAT with port >> forwards or >> >> > similar then please tell me so that I don't have to worry that we're >> >> > spending all this energy chasing a solution that might not even >> >> exist in >> >> > the first place. There must be some kind of precedence in this area, >> >> I'm >> >> > sure. >> >> > >> >> > /Fredrik >> >> > >> >> > >> >> >> >> [1] Excepted for the fragmentation response problem. See: >> >> >> http://www.ietf.org/internet-drafts/draft-petithuguenin-sip-fragmentation-responses-01.txt >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-gurbani-sip-large-udp-response-00.txt >> -- 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 Sat Dec 16 15:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvgE3-0005fL-7I; Sat, 16 Dec 2006 15:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvgE2-0005fE-1k for sip@ietf.org; Sat, 16 Dec 2006 15:33:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvgE0-0001Ln-Jo for sip@ietf.org; Sat, 16 Dec 2006 15:33:42 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 Dec 2006 12:33:38 -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 kBGKXbf0018493 for ; Sat, 16 Dec 2006 12:33:37 -0800 Received: from [192.168.1.3] (sjc-vpn-hwcore-390.cisco.com [10.21.153.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBGKXbST001834 for ; Sat, 16 Dec 2006 12:33:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sat, 16 Dec 2006 12:33:49 -0800 To: SIP X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4974; t=1166301217; x=1167165217; 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:=20Question=20about=20Poll=3A=20Proposal=20relating=20to=20keepa live,=20TCP,=20and=20UDP=20usage=20in=20draft-ietf-sip-outbound |Sender:=20; bh=uq+lfhUwje0aLtIBLP8yeCgHRlZBmbPJctw6DQOAdz8=; b=CtiB+Dc+LP7CY6y8GgZtcOQZq/gLkKSgfQr3QL45EnIp+cgolzJER35jMBPWgBMYTi8YCogQ S9YOB+f1APd9tVT1+rVWvbg6cmZyWxKjo2jysZP1+4307azxBASqU6Li; 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: 825e642946eda55cd9bc654a36dab8c2 Subject: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-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 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 (note it would be easy to meet the above goals using any type of keep alive so they do no impact if we use CRLF or something else) Now I know there are people on the list that only care about one of these three goals but I know there are some people that want each one. I think that if we had some agreement that we were trying to meet these goals, then it would be easier for Rohan and I to help make progress on a proposal that everyone found agreeable. Perhaps Rohan's proposal meets these. I understand Rohan is making the argument that 2 is not needed because 3261 does not allow 2 - some people disagree with this regardless it is is clear that the bulk of deployments today are in category 2 for a variety of good reasons. I just don't want to hold up outbound with figuring out the problems of TCP vs. UDP. Or figuring out how to do high reliability in SIP proxy farms. Or figuring out how to exactly build very scaleable proxy farms. Or figuring out how to deal with some security problems with changing IPs on UAs. All of these things are separable from outbound and though work is needed on them, I think we can finish this work without solving all o f them. I'd rather not spend endless time discussing if outbound should only work for IPv6 to help encourage people to move to v6 but instead try and find something that we could all live with and meant the needs of at least a bunch of deployments. So if we can agree on above sort of goals, I think it will help me understand how to come up with some proposal that take into account what people are saying on this poll. more inline... On Dec 8, 2006, at 6:12 PM, Dean Willis wrote: > Previously we had recorded consensus to use STUN for keepalive with > both TCP and UDP. This was not a perfect consensus (there were some > dissenters). There has been ongoing discussion notably instigated > by the current editor of the Outbound draft, that some people feel > may have resulted in a change of the consensus on this draft's > technical direction. > > So I'd like to ask people who care and think they understand the > differences to answer the following questions, on-list and on-the > record. > > > Proposal 1: Make CRLF the only keepalive mechanism for TCP and TLS > over TCP flow (retain STUN for UDP flows). > > Yes (accept the proposal and use CRLF for TCP) or No (reject the > proposal and keep STUN for TCP) > I think we have heard from the people that think STUN is a good idea why they think STUN is a good idea. I think we previously came to the idea that the double CRLF was better than the CRLF so I would rather compare to double CRLF in the poll. > > Proposal 2: Make outbound registrations over UDP flows optional for > UAs. > > Yes (Accept the proposal) or No (Reject the proposal). I don't understand the question. The problems around this seem to be around difference between use and implement and this questions does not help me figure out what to put in the draft. I think I am also confused on how this differs from what we have in the draft today. Anyway, color me confused. > > > 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. Further, include text that explain that for historical > purposes a lot of deployments still only use UDP, but that we > expect/hope those deployments to eventually migrate to TCP when > doing outbound. I think this needs some discussion before you take a poll on it. Perhaps people who have said yes to this can propose how a UA behind a firewall will be able to tell if can accept incoming TCP flows? How would the system doing the setting of the outbound-proxy-set know? > > Yes (Accept the proposal and add the text) or No (Reject the > proposal and keep the text as-is). > I think to get some facts on the table it would also be nice to understand: What percentage of commercially available proxies today support high reliability with over 100k connections? What percentage of commercially available proxies do switch over from UDP to TCP on large requests? Do we have the standards in place to build UAs that work with high reliability TCP systems on a large scale. 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 srtrxfaekcu@chello.pl Sat Dec 16 23:03:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvnEx-0003HK-IM for sip-archive@lists.ietf.org; Sat, 16 Dec 2006 23:03:07 -0500 Received: from chello084010098223.chello.pl ([84.10.98.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvnCh-0001CZ-R2 for sip-archive@lists.ietf.org; Sat, 16 Dec 2006 23:00:49 -0500 From: "himself Islamist" To: sip-archive@lists.ietf.org Subject: The Bull is Back Date: Sun, 17 Dec 2006 05:00:57 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C72198.569E50B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcchmFaeDvGStPoWRbS1ylcT9x637w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <2A35760DE069D84.CC232D60F8@chello.pl> X-Spam-Score: 4.9 (++++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0003_01C72198.569E50B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0003_01C72198.569E50B0-- From sip-bounces@ietf.org Sun Dec 17 04:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvs5g-0003Lf-60; Sun, 17 Dec 2006 04:13:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvs5e-0003LM-Gl for sip@ietf.org; Sun, 17 Dec 2006 04:13:50 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvs5d-0003Cp-5l for sip@ietf.org; Sun, 17 Dec 2006 04:13:50 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 7C7D1AC2B2; Sun, 17 Dec 2006 11:13:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17797.2629.447139.696419@harjus.tutpro.com> Date: Sun, 17 Dec 2006 11:13:41 +0200 To: sip@ietf.org From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] some tcp nat tests 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 mentioned in an earlier message, i finally found a SIP phone that supports SIP over TCP (Nokia N80). during the past days i have done some tests with it. the setup is this: N80 -- WLAN -- AP -- Linux with iptables NAT -- internet -- OpenSER proxy/reg OpenSER proxy is configured to use persistent TCP connections to the registrar if SIP UA is behind NAT. this means that it keeps the TCP connection open to the UA a few minutes longer than the registration interval advertised by the phone. it does not currently send any TCP keepalive messages, but could be made to do so. if SIP request comes in bound to the UA, it reuses the existing TCP connection. N80 registers every 3600 seconds and, in addition, it is sending a 4 byte TCP keepalive message after every 20 minutes if there has been no other activity. wireshark reports the TCP keepalive messages as Continuation messages. during the tests i have not seen any problems whatsoever. the same TCP connection stays up and both ways useable forever unless there is a equipment failure. i still fail to see what exactly is the problem is that outbound tries to solve which has warranted hundreds if not thousands of messages on this mailing list. i really would have liked to see that energy spend on solving real problems, such as how to build a resilient, load balancing SIP architecture. -- 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 mdgszjk@citywebsites.com Sun Dec 17 12:25:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvzlH-0001UV-GG for sip-archive@lists.ietf.org; Sun, 17 Dec 2006 12:25:19 -0500 Received: from [194.44.173.137] (helo=[194.44.173.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvzlF-0004C4-2d for sip-archive@lists.ietf.org; Sun, 17 Dec 2006 12:25:19 -0500 From: "men" To: sip-archive@lists.ietf.org Subject: Small Investments to Small Fortunes? Date: Sun, 17 Dec 2006 19:25:10 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0003_01C72211.1198E650" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcciERGYvFEf82DVRRaxHkArBAsHmg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <7BFFF751BB351ED.3E24C84A06@citywebsites.com> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ------=_NextPart_000_0003_01C72211.1198E650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
INVESTMENT ALERT FOR OUR=20 READERS
 
 
 
Interest for VGYI has been picking over the = preceding=20 months and interest is expected to continue with a massive PR campaign = in the=20 days to follow.  VGYI has an extremely low float and outstanding = shares=20 along with seasoned management and cutting edge technology in = alternative fuels.=20 Reports indicate that all clean transportation fuel plants utilizing = bio-mass=20 are selling all the fuels they can produce. VGYI looks like a winner to=20 us!
 
 
Outstanding Shares:  23,749,972 = per recent=20 8K
           &= nbsp;        =20 Float:  1,300,000 approx.
 

Recent News:
 
 
 
Vision Energy Group, Inc. Prepares to = Purchase=20 Biodiesel Production Unit
 
 

Company Name: Vision Energy Group = Inc.=20
Lookup: VGYI.PK
Current Price: $.50 (90% gains = expected=20 this week!!)
Expected: HEAVY PRICE = INCREASES TO=20 CONTINUE
 

About Vision Energy Corp.
 
Vision Energy Corp. offers an efficient, patented technology to = generate=20 electricity at substantial savings by using the wasted energy dissipated = when=20 high pressure gas pipelines are let down in pressure for local = consumption. Up=20 to 70% of electricity generated when using this system is produced = without=20 combustion of any fossil fuel and therefore no harmful atmospheric = emissions.=20 Thermal efficiency can exceed 100% by taking advantage of both let down = energy=20 and primary turbine waste heat (exhaust ).
 
 
 
WATCH THIS STOCK GO HIGHER AND HIGHER
 
 
 

Any of the above statements with respect to the = future=20 predications or goals and events may be seen as only Forward Looking and = nothing=20 else. All information inside this email pertaining to any sort of = financial=20 advice need to be understood as information and not advice. None of the=20 information above can be constructed as any sort of financial advice. = This is a=20 paid advertisement.
------=_NextPart_000_0003_01C72211.1198E650-- From sip-bounces@ietf.org Mon Dec 18 06:56:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwH5e-0001p3-I6; Mon, 18 Dec 2006 06:55:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwH5c-0001ob-RD for sip@ietf.org; Mon, 18 Dec 2006 06:55:28 -0500 Received: from pb94.dyndns.org ([213.239.207.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwH5b-00026F-Ed for sip@ietf.org; Mon, 18 Dec 2006 06:55:28 -0500 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 2C288210017; Mon, 18 Dec 2006 12:55:21 +0100 (CET) Message-ID: <458681A8.6090607@pernau.at> Date: Mon, 18 Dec 2006 12:55:20 +0100 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] some tcp nat tests References: <17797.2629.447139.696419@harjus.tutpro.com> In-Reply-To: <17797.2629.447139.696419@harjus.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Juha Heinanen wrote: > as i mentioned in an earlier message, i finally found a SIP phone that > supports SIP over TCP (Nokia N80). during the past days i have done eyebeam and SNOM support TCP too. > some tests with it. the setup is this: > > N80 -- WLAN -- AP -- Linux with iptables NAT -- internet -- OpenSER proxy/reg > > OpenSER proxy is configured to use persistent TCP connections to the > registrar if SIP UA is behind NAT. this means that it keeps the TCP > connection open to the UA a few minutes longer than the registration > interval advertised by the phone. it does not currently send any TCP > keepalive messages, but could be made to do so. if SIP request comes in > bound to the UA, it reuses the existing TCP connection. > > N80 registers every 3600 seconds and, in addition, it is sending a 4 > byte TCP keepalive message after every 20 minutes if there has been no > other activity. wireshark reports the TCP keepalive messages as > Continuation messages. > > during the tests i have not seen any problems whatsoever. the same TCP > connection stays up and both ways useable forever unless there is a > equipment failure. > > i still fail to see what exactly is the problem is that outbound tries > to solve which has warranted hundreds if not thousands of messages on > this mailing list. i really would have liked to see that energy spend me too. eyebeam work like a charm over TCP. regards klaus > on solving real problems, such as how to build a resilient, load > balancing SIP architecture. > > -- 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 -- 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 Mon Dec 18 12:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMfk-0006mb-Cg; Mon, 18 Dec 2006 12:53:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMfj-0006mW-Br for sip@ietf.org; Mon, 18 Dec 2006 12:53:07 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMfh-0001VU-3E for sip@ietf.org; Mon, 18 Dec 2006 12:53:07 -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 kBIHr1p19650; Mon, 18 Dec 2006 12:53:01 -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: Mon, 18 Dec 2006 11:53:00 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> 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: AcchUe1gIxwWbbqbQbWGtWYJehi37ABeMQHA From: "Francois Audet" To: "Cullen Jennings" , "SIP" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Saturday, December 16, 2006 12:34 > To: SIP > Subject: [Sip] Question about Poll: Proposal relating to=20 > keepalive, TCP, and UDP usage in draft-ietf-sip-outbound [ .... ] > 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=20 > send large requests Hi Cullen, I don't believe this is the core problem. The problem with UDP is more that the UA will not be able to RECEIVE large requests over UDP. You could always build your UA to no send large requests and avoid the fragmentation problem, but you can not force other people's products to not use large requests. Many PSTN gateways and Softswitches always send large INVITEs for example, and they will always fragment. And I might add that many very popular NAT/routers don't support UDP fragmentation. The consequence of this is that point 2 really doesn't exist in real life=20 except in closed environments where you control the other UAs as well. A UA has to have an opened TCP connection "just in case" the other side sends a large request, which is quite likely. So, what you are really saying is that one may want to support UDP for closed environments where fragmentation is known not to be possible. This could be for example an Enterprise Network where you control all the equipment that is allowed. I do not have a problem with having words to that effect in the text, and words explaining the problem with fragmentation and incoming=20 requests. (That being said, I believe that in practice, it means that using outbound for UDP will just prove to be essentially useless: too complicated, and too likely to fail). > 3) allowed deployments that wanted to use both UDP and TCP to=20 > do so and not have the size limitations by using switchover What does this really mean? You mean a UA will open two connections, one for UDP and another for TCP? Yes, that would be the consequence of the previous point. I fail to see why on earth anybody would do this instead of just using a single TCP connection. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 18 13:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNbe-0006Zz-Qx; Mon, 18 Dec 2006 13:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwNbc-0006Zq-SV for sip@ietf.org; Mon, 18 Dec 2006 13:52:56 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwNbb-00023o-Ev for sip@ietf.org; Mon, 18 Dec 2006 13:52:56 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2006 10:52:55 -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 kBIIqs90029994; Mon, 18 Dec 2006 10:52:54 -0800 Received: from [192.168.1.3] (sjc-vpn1-674.cisco.com [10.21.98.162]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBIIqrST014702; Mon, 18 Dec 2006 10:52:53 -0800 (PST) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) 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: Mon, 18 Dec 2006 10:53:04 -0800 To: Francois Audet X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4500; t=1166467974; x=1167331974; 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=7zs8MlQz2dWZ5SBPDZcPGaPnkLPL54llhCtuv4QKzwc=; b=R86e4Hu+EQdySlupLbnE6mEPP8zX6NMQ2erVDHzfXo1Oo4FZ4ibj1FqZwInByyCOkgivc3Is uuhsuqnn67gWsBHJyN0YKWnxhLUe8VZWtHUwIPNKWtj2JSD2tu2xL+kS; 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: 5d7a7e767f20255fce80fa0b77fb2433 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 Dec 18, 2006, at 9:53 AM, Francois Audet wrote: > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Saturday, December 16, 2006 12:34 >> To: SIP >> Subject: [Sip] Question about Poll: Proposal relating to >> keepalive, TCP, and UDP usage in draft-ietf-sip-outbound > > [ .... ] > >> 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 > > > Hi Cullen, I don't believe this is the core problem. > > The problem with UDP is more that the UA will not be able to RECEIVE > large requests over UDP. Ooops - my bad, you are right - I should have put I was thinking of this as someone trying to send to the UA that registered but realized I phrased this all wrong > > You could always build your UA to no send large requests and avoid the > fragmentation problem, but you can not force other people's > products to > not use large requests. Well, it's seems very reasonable for any network (even one that only uses TCP) to have a policy on maximum request (or response) size and reject requests larger than this. > > Many PSTN gateways and Softswitches always send large INVITEs for > example, > and they will always fragment. And I might add that many very 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. > > The consequence of this is that point 2 really doesn't exist in real > life > except in closed environments where you control the other UAs as well. Could you point me at a non enterprise deployment that is not in point 2? I suspect there are some but the bulk seem to be form 2. > > A UA has to have an opened TCP connection "just in case" the other > side > sends > a large request, which is quite likely. I think this is only true when the policy allows messages larger than what can be done over UDP. I'm not arguing that 2 is a better way to deploy than 1 or 3, just that there are a lot of people that do 2 and that I think more work is needed to make 1 or 3 feasible so that this draft should not take on trying to eliminate deployments like 2 > > So, what you are really saying is that one may want to support UDP > for closed environments where fragmentation is known not to be > possible. > This > could be for example an Enterprise Network where you control all the > equipment > that is allowed. I do not have a problem with having words to that > effect in > the text, and words explaining the problem with fragmentation and > incoming > requests. 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 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. > > (That being said, I believe that in practice, it means that using > outbound > for UDP will just prove to be essentially useless: too complicated, > and > too likely > to fail). > >> 3) allowed deployments that wanted to use both UDP and TCP to >> do so and not have the size limitations by using switchover > > What does this really mean? You mean a UA will open two > connections, one > for UDP and > another for TCP? > > Yes, that would be the consequence of the previous point. I fail to > see > why on earth > anybody would do this instead of just using a single TCP 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 with UDP yet still be able to do large messages. I'm not saying that I think these schemes are a good idea or not -- but my feeling is that we can finish outbound and leave it open such that three of these are possible and future drafts can suggest which ones are best and when they should be used. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 18 15:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRh-0002Ha-DB; Mon, 18 Dec 2006 15:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0001xY-BE; Mon, 18 Dec 2006 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0000Ua-0W; Mon, 18 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E686B2AD11; Mon, 18 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GwPQv-000728-KM; Mon, 18 Dec 2006 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: Mon, 18 Dec 2006 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-sips-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 : Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-00.txt Pages : 39 Date : 2006-12-4 This document providing clarifications and guidelines concerning the use of SIPS URI scheme in the Session Initiation Protocol (SIP). It does not make normative changes to SIP. This document also provides discussion of possible future steps in specification, and the pros and cons of making such changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-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-sips-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-sips-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: <2006-12-18144004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-18144004.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 Dec 18 17:05:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQb4-00075u-Qk; Mon, 18 Dec 2006 17:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQb3-00075Q-5M for sip@ietf.org; Mon, 18 Dec 2006 17:04:33 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQb1-00028o-By for sip@ietf.org; Mon, 18 Dec 2006 17:04:32 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kBILus525226; Mon, 18 Dec 2006 16:56: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: Mon, 18 Dec 2006 16:04:12 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0E7965B9@zrc2hxm0.corp.nortel.com> 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: Acci1b3co/G6zIjUQB6yYpUxRkfiEgAGRCZA From: "Francois Audet" To: "Cullen Jennings" 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 =20 > > The consequence of this is that point 2 really doesn't=20 > exist in real=20 > > life except in closed environments where you control the=20 > other UAs as=20 > > well. >=20 > Could you point me at a non enterprise deployment that is not=20 > in point 2? I suspect there are some but the bulk seem to be form 2. Well, Outbound is not deployed yet, neither for TCP nor for UDP. What I'm trying to say, is that I fail to see a case where outbound-UDP-only would work on the global internet (at least with our current wording in RFC 3261). You would ALWAYS need to open an outbound TCP connection "just-in-case". Unless, well, unless we start making "assumptions" like: - Switching to TCP will never happen, because: - Messages will never be too big for the path MTU - If they are, it is "ok" to fragment UDP (change from 3261) - If UDP does fragment, it is assumed that it will work - If there is a NAT, it will be good enough to support UDP fragmentation Again, I'm ok with having outbound support STUN-over-UDP, as long as we are honest about the implications regarding fragmentation. This could be as simple as explaining that if you don't keep a TCP channel opened, request that are bigger than MTU and would observe the rules of RFC 3261/18.1.1 would not be able to be received.=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 RooseveltValencia@adsl-81-7-126-129.takas.lt Mon Dec 18 19:30:40 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSsS-0006Vx-Ma for sip-archive@lists.ietf.org; Mon, 18 Dec 2006 19:30:40 -0500 Received: from 87-196-62-196.net.novis.pt ([87.196.62.196] helo=adsl-81-7-126-129.takas.lt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwSsP-0008GP-W6 for sip-archive@lists.ietf.org; Mon, 18 Dec 2006 19:30:40 -0500 Received: from [199.164.127.107] by with HTTP; Tue, 19 Dec 2006 00:31:08 -0000 From: "Roosevelt Valencia" To: Subject: url document Date: Tue, 19 Dec 2006 00:30:43 -0000 Message-ID: <000a01c72304$eb2154e0$00000000@ANDRE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AccjBOshzrMO2BybS4eeKOLe+S78lg== X-Spam-Score: 2.8 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Chapters permission reprint clearance rightslink rightsand select. Edonkey, system especially, europe networks. Webdining aaasave, business politics consumer health food pets cooler? Df policycopy inc part. Click send file detailed, user. Reserved st petersburg, avenue fl, accuracy conditions, linkslucy morganfrom. Get FPMC First Thing tomorrow. This Is Going To Explode! Check out for HOT NEWS!!! The alert is ON!! FLAIR PETROLEUM CORP (FPMC.PK) CURRENT_PRICE: $0.27 GET IT N0W! TARGET PRICE IN 1 WEEK: 0.73$ Please use your brokerage site to read the full news on this exciting company. Go FPMC! Four killed panhandle plane, crash charity. Tutorials lyrics revent popups fidelity technical favorite shows provide. Discovery questions, call letter. Terri schiavo excerpt unanimous, ruling confirmed dead correction line. Sale nap ordering discovery questions call letter status. Below freefront, matterix authoring board promotion? Guard air watersfrom wire hurricane jeanne. Before tape was upquot bob sanchez spokesman vehicle. Into future runs, linux macintosh? Rolls zwart need player view bypass. Bag items home toys gift cards podcasts posters sales. From sip-bounces@ietf.org Tue Dec 19 02:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZbP-0005tU-1S; Tue, 19 Dec 2006 02:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZbN-0005tJ-Ij for sip@ietf.org; Tue, 19 Dec 2006 02:41:29 -0500 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZbM-0004ag-8t for sip@ietf.org; Tue, 19 Dec 2006 02:41:29 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 56F4974281; Tue, 19 Dec 2006 08:41:21 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15356-01-93; Tue, 19 Dec 2006 08:41:20 +0100 (CET) Received: from [193.11.30.69] (dhcp-wavelan-vo-69.publik.su.se [193.11.30.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 745B274208; Tue, 19 Dec 2006 08:41:16 +0100 (CET) Message-ID: <45879778.9060105@it.su.se> Date: Tue, 19 Dec 2006 08:40:40 +0100 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: <1ECE0EB50388174790F9694F77522CCF0E7965B9@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E7965B9@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.648 tagged_above=-99 required=7 tests=[AWL=0.017, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Cullen Jennings , 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 Francois Audet wrote: ... > Again, > > I'm ok with having outbound support STUN-over-UDP, as long as we are > honest about > the implications regarding fragmentation. This could be as simple as > explaining that > if you don't keep a TCP channel opened, request that are bigger than MTU > and would > observe the rules of RFC 3261/18.1.1 would not be able to be received. If we have a user agent that has one TCP and one UDP flow open to each proxy in the outbound proxy set, and these happen to be edge proxies - what happens when a large request is being sent towards the UA? The authoritative proxy looks up all the bindings in the location database, and sends it to one of the edge proxys (edge-proxy1) with Route: If flow-xyz was a TCP flow, that would just work - the request would reach the UA. However, if it is a UDP flow, it won't work for this particular request. The flow is fine, so a '430 Flow Failed' is not applicable. In the lack of a proposed idea about how this should work technically, I don't think it is meaningful to discuss this variant of Outbound (TCP+UDP) any further, since we would all be discussing different things. I know this problem can be solved, but it won't come for free and I always want to know the price before considering whether to buy something. I hope the same applies to the SIP WG. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 19 03:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaWW-00043I-Nv; Tue, 19 Dec 2006 03:40:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwaWU-00042t-Uz for sip@ietf.org; Tue, 19 Dec 2006 03:40:30 -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 1GwaWS-0001sO-Ef for sip@ietf.org; Tue, 19 Dec 2006 03:40:30 -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 kBJ8ddh5020576; Tue, 19 Dec 2006 10:39:50 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 10:40:17 +0200 Received: from [172.21.39.124] ([172.21.39.124]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Dec 2006 10:40:17 +0200 Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound From: Aki Niemi To: ext Cullen Jennings In-Reply-To: References: Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Tue, 19 Dec 2006 10:41:06 +0200 Message-Id: <1166517666.31943.22.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2006 08:40:17.0419 (UTC) FILETIME=[4F595DB0:01C72349] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Cullen, On Sat, 2006-12-16 at 12:33 -0800, ext 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 There's a draft out that proposes how to handle 3), which I personally find incredibly complex. To accept such complexity, I think we'd need to have some pretty convincing reasons for it. So far, it seems, the most convincing I've heard are "because RFC3261 says so" and "because we don't implement TCP". There are plenty of people on this list who've said that the best way to deal with 2) and 3) is to *not* deal with them. I think the proposal on the table meets 2) in that it allows for deployments to be UDP-only, but also instructs people that this will likely only work in a tightly controlled environment, not in the Internet. > (note it would be easy to meet the above goals using any type of > keep alive so they do no impact if we use CRLF or something else) > > Now I know there are people on the list that only care about one of > these three goals but I know there are some people that want each > one. I think that if we had some agreement that we were trying to > meet these goals, then it would be easier for Rohan and I to help > make progress on a proposal that everyone found agreeable. Perhaps > Rohan's proposal meets these. I understand Rohan is making the > argument that 2 is not needed because 3261 does not allow 2 - some > people disagree with this regardless it is is clear that the bulk of > deployments today are in category 2 for a variety of good reasons. People keep bringing up this point about existing deployments. Clearly, these existing deployments must be working through NAT just dandy, since otherwise they wouldn't exist. Then what are these deployments expecting the SIP WG to deliver? A new keepalive mechanism, so that they need to upgrade all of their equipment, after which they will work exactly the same way as before, but with added complexity? Somehow I don't believe that people would go through all that trouble of implementing STUN and SIP+STUN muxing for no other benefit than being able to add one more RFC to their product sheets. > I just don't want to hold up outbound with figuring out the problems > of TCP vs. UDP. Or figuring out how to do high reliability in SIP > proxy farms. Or figuring out how to exactly build very scaleable > proxy farms. Or figuring out how to deal with some security problems > with changing IPs on UAs. All of these things are separable from > outbound and though work is needed on them, I think we can finish > this work without solving all o f them. Even if we made outbound TCP-only, people would be free to use UDP in their deployments, just like they are at the moment. > I'd rather not spend endless > time discussing if outbound should only work for IPv6 to help > encourage people to move to v6 but instead try and find something > that we could all live with and meant the needs of at least a bunch > of deployments. I want to point out you're the first person to mention IPv6 in this context. Let me also point out that drawing any parallels between discussion of using TCP with SIP to using SIP over IPv6-only is really uncalled for. There is ample existance proof that apps work well using TCP, and that TCP is well supported by practically all networking gear and OSs out there. It's in heavy use and has been for 15 years in the web. In other words, nothing in the Internet needs to change in order to use SIP over TCP. This is not the IPv6 vs. IPv4 religious war. We also have data to back up the claim that TCP scales as well as UDP with SIP. I have yet to hear any description of concrete problems with using TCP as transport, and in fact, it strikes me as odd that you're attempting to make this discussion into something it's not. > > 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. Further, include text that explain that for historical > > purposes a lot of deployments still only use UDP, but that we > > expect/hope those deployments to eventually migrate to TCP when > > doing outbound. > > I think this needs some discussion before you take a poll on it. > Perhaps people who have said yes to this can propose how a UA behind > a firewall will be able to tell if can accept incoming TCP flows? How > would the system doing the setting of the outbound-proxy-set know? I said yes, because I can live with this especially if it pleases the UDP-only crowd. The short answer here is, they won't ever just know. And because they won't ever know, they will be better off by simply using a persistent TCP connection to the outbound proxy. It's actually the UDP-only crowd's concern to figure out when and where they can use UDP-only. > > Yes (Accept the proposal and add the text) or No (Reject the > > proposal and keep the text as-is). > > > > I think to get some facts on the table it would also be nice to > understand: > > What percentage of commercially available proxies today support high > reliability with over 100k connections? > > What percentage of commercially available proxies do switch over from > UDP to TCP on large requests? > > Do we have the standards in place to build UAs that work with high > reliability TCP systems on a large scale. You seem to suggest we have not; that high reliability is not possible with TCP. Can you be more specific? What are the concrete problems? 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 Tue Dec 19 11:42:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwi1P-0000Wq-Ud; Tue, 19 Dec 2006 11:40:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwi1P-0000Wi-19 for sip@ietf.org; Tue, 19 Dec 2006 11:40:55 -0500 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwi1D-0003Mx-6Z for sip@ietf.org; Tue, 19 Dec 2006 11:40:55 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zrx.siemens.at with ESMTP id kBJGeH2D001324; Tue, 19 Dec 2006 17:40:17 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id kBJGeahv003001; Tue, 19 Dec 2006 17:40:37 +0100 Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 17:40:37 +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] xcap-diff-event Date: Tue, 19 Dec 2006 17:40:35 +0100 Message-ID: <3E4278088AD82C48B4663DDFE762CEF302490B54@prga004a.ww300.siemens.net> In-Reply-To: <4580F8DE.5020703@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] xcap-diff-event Thread-Index: AccfTvM/XPatwEUCTmml/5LFI1XAbwEPKbbQ From: "Dostal, Pavel" To: "Jari Urpalainen" X-OriginalArrivalTime: 19 Dec 2006 16:40:37.0039 (UTC) FILETIME=[692E63F0:01C7238C] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::061219174017-4CFD4BB0-5DF5CC4A/0-0/0-15 X-purgate-size: 896/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP IETF 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 Jari, =20 >right, the intention is to allow subscription to an non-existing element=20 >(as it is stated). However, do you propose something along the lines: >exists =3D "single", "none" or "multiple" ? So none and multiple would = be >an "error" in XCAP sense where a unique node is always mandatory for a=20 >successful operation. Having these two separate states might be better, >i.e. the client would probably know to change the request. Also it would=20 >be better in-line with XCAP where 404 and 409 error responses separate=20 >these cases. However, the initial subscription must then signal this=20 >multiple case, I suppose. So it would make the handling a bit more=20 >complex, but more deterministic. In my opinion "none" and "single" is ok and I would prefer that subscription is rejected or terminated in case of "multiple". Your opinion? Pavel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 NellieChristian@bodytechgym.com Tue Dec 19 18:22:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwoIO-0006pl-Am for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 18:22:52 -0500 Received: from cp538142-b.mill1.nb.home.nl ([84.29.212.247] helo=bodytechgym.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwoIM-0002MH-Hn for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 18:22:52 -0500 Received: from ([174.146.106.83] helo=) by ( sendmail 8.13.3/8.13.1) with esmtpa id 1JOhfs-000EQM-yq for sip-archive@lists.ietf.org; Wed, 20 Dec 2006 00:23:02 +0100 Message-ID: <000e01c723c4$98455030$00000000@CP538142b> From: "Nellie Christian" To: sip-archive@lists.ietf.org Subject: agreed million Date: Wed, 20 Dec 2006 00:22:47 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C723CC.FA09B830" 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: 2.3 (++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ------=_NextPart_000_000A_01C723CC.FA09B830 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C723CC.FA09B830" ------=_NextPart_001_000B_01C723CC.FA09B830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authorised illegally swap songs ruled six sharmans boss. Copyrights or else heavy fine responded? Decision, titled following = favor plaintiff. Songedit ppnet rules slyck, news becomes! Changing february out clients, when. Owner los angeles, major record labels motion, pictures. Been taken = court, publishing, bodies restrict use material. On kazaas website = throughout past few years developing. Because ip address similarity = greeted message important notice permitted. Guidekazaa faq together = updates chm supernode patch. Users morpheus program formerly musiccity. Last modified text gnu details registered trademark, wikimedia! Filed = suit civil several private who shared large. Tools appeared although name. Free kazaafrom to navigation release media desktop. Site stopped april completely leaves behind. Crazy world decide newswire, essay. Downloads after th deadline zealand because ip address! Unusable require = forces allow computer keep working? Songs ruled six sharmans. Publishing bodies restrict use material sued = body. Explorer provides links browser, plugin lets access, unofficial. Linksedit were created niklas. Uninstall, detection removal frequently, = delete without special pc. End first generation pp, networks napster had shut. As but now usually = left is peertopeer. Milestones brief covering period, kool kmy = vmerijnorg. Free kazaafrom to navigation. Thisthe best offers tracks = browsing display hijacker redirects, url! Failed pay license fees later = gnutella. Paying, millions dollars instigated actionon december. All sites visit microsoft explorer provides links browser. Riaa trade filed suit. Raided under order, gather evidence trialon september federal! Has early, installed onto computers are. ------=_NextPart_001_000B_01C723CC.FA09B830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Authorised illegally swap songs ruled = six sharmans boss.
Copyrights or else heavy fine = responded? Decision,=20 titled following favor plaintiff. Songedit ppnet rules slyck, news = becomes!
Changing february out clients, = when.
Owner los angeles, major record labels = motion,=20 pictures. Been taken court, publishing, bodies restrict use material. On = kazaas=20 website throughout past few years developing. Because ip address = similarity=20 greeted message important notice permitted. Guidekazaa faq together = updates chm=20 supernode patch.
Users morpheus program formerly = musiccity.
Last modified text gnu details = registered=20 trademark, wikimedia! Filed suit civil several private who shared = large.
Tools appeared although = name.
Free kazaafrom to navigation release = media desktop.
Site stopped april completely leaves = behind.
Crazy world decide newswire, = essay.
Downloads after th deadline zealand = because ip=20 address! Unusable require forces allow computer keep = working?
Songs ruled six sharmans. Publishing = bodies=20 restrict use material sued body. Explorer provides links browser, plugin = lets=20 access, unofficial.
Linksedit were created niklas. = Uninstall, detection=20 removal frequently, delete without special pc.
End first generation pp, networks = napster had shut.=20 As but now usually left is peertopeer. Milestones brief covering period, = kool=20 kmy vmerijnorg. Free kazaafrom to navigation. Thisthe best offers tracks = browsing display hijacker redirects, url! Failed pay license fees later=20 gnutella. Paying, millions dollars instigated actionon = december.
All sites visit microsoft explorer = provides links browser.
Riaa trade filed suit.
Raided under order, gather evidence = trialon=20 september federal!
Has early, installed onto computers=20 are.
------=_NextPart_001_000B_01C723CC.FA09B830-- ------=_NextPart_000_000A_01C723CC.FA09B830 Content-Type: image/gif; name="monetary.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c723c4$98455030$00000000@CP538142b> R0lGODlhTAEcAYfoAAoBAHcADACOAICHAAcHfHIDhwWBer+0zrHkzKbM60UsDWUaAHUYAJsRAc0t C9ghAQAzCB1GADZGCWszAI5OAKpBA7FEAN5CBQBqACRuAEtWAGtnC3poDpJdALxRC+lSCQeIABaG ADhxAGVxDHmHAK2FAMN6AOuKAAmdASmfBDyrDGyeCYCVAJ+TAMiVANGgAAvCABm4BDzKB128AICx AJ/FALfABuXLAADmACLlAEbYDlbmA3TbBqrmBcznAOzsAA4KRRwANEEENl8AMYgETpQAQrwAOt8A PgAgNxYaMTcZTmguR4AlSJcgSr4TTugfRgA+SR02P05KS1RCS3M/PqY1Mco2OOU/QwdUOBNSNzlc MmlYP3NtEpVsQLxoOtRrTgCNRB6FPUeFOV+HTHp5Pap8TMVyO+CNOgifNh2aOUWqTFqcPoudN5Wb TLqbQOykOge+RSy7TE29SmfFNIvLS5/INce7MtTKRw7ZPibSQUrdR1vfM37uOpvZSMTqO9/ePwAK jh8AdU4AjFYIdYUAgpkAjc0IdOIMcwsqdBogdTgti1UTfoYXfJIldbUdiOUcfQBLghxGhU09e1Y0 jIlBjp5Oc8JOgtI2jQBffRFYcUZriFJhgIVbjZVUhc1nc+xaiwWOhhNyfkx9gFmFdX5zjJOKiMKO fuSNdACWjiKldEWnhGKainqbgayggbSneNaUcQTEdinBiTnNcVvGjoLBga3DjM3Fg+e6jADTdB3U ej/tfGTcd33UhpzpgcrUdtXWiAcAxBYAxk4JwF8AvY0OzqgAzssEwOwAzgAVty0cwUgTvF0atHgc w60ut8kpttkfxwk6sSY9xEs8wFhFsYVKvZI0ubk9te1GwwBhzBpoy0hiuV9qt4NptJJmx71lsedT vgx4wxpzxzVzumJ7u3hzwJ92yc14xdF7wAGfwy6rwkGdy26Ttn2VtqGXubaRwuWYsgDKwxG1yzu2 wm7Dw3m3xaG9vv/97qOemnh8gfMAAAD8CP//DAIA9v0A/w7w//Pw/yH5BAAK9J0ALAAAAABMARwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDMetMexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0KUeNUKNKnUq1qtWrWLNq3cq1q9evYME6 HUu2rNmzH8OqXcu2rdu3A9HKnUu3rk64ePPq3cu3r9+/gAMLLhigcIB/hgcWRnxY8WHDkAVCXsx4 cuPKlDFn1nyZYL7PoAeCHv1v9OeFmzdzfjzZsWXJnQfLDks5MWzGBBerxu04d+zMtS8H923wtEDj xj3nE708YerfsXlLv018tvWLLgtzhLw9gD3tHbWD//c4PmT58t+9jwePPuTnju/txfc4X34+kdy7 f2y/3jt5/+EBaNeAR7FnmH7pIcifgCCdx6B4ABpo0nzx1cdRfRYG2N9+DCaIYIAcEiiiURJCqKB/ lqE4WYgg/pdeft3BSJ9p8Jl2H4b3NajihzFyZ5mOLI4oJFASvhjhgTziJ6CDIZo4Unvv4QiSlEB6 iN6CHgaZ5JBclkTRcJi5Jlx0Bj1XXW9gHrQbcs2V1iZzyqnZ2nR08rbbbtflWVF2O8boYot/8njl kR8WuSWFOWaIqHlLqvdghxsGumWXlM7k45GN/reikYPqiGSWVm76kZQ23kgjoy7+mCKoTEpa6auw xv8q66y01mrrrbjmquuuvPbq66/ABivssMQWayxLfIEDjp7/KMvss4G1pOy0096kLE3UXvuTtjJl 25G3JoFrj7jijlvtsUZxay042LLLkbo7wesSt9fS6+5I9pr7Lbv56osuUur2S+655lL7rsH+yvtR wO4OfK7D9Wqb7b3glhtSxPuqhPHB/uqr8L9CMZxxvhLzS/G9IzeM8sUob+zxygJHbHLBHJP88cIz c5ySyzybjDDIIbd8cscu69xxxgWvzLJHPR9NtMo6N23zSSUjTTXUNQ/dL9AqWeTsQF83u+zEy4r9 ddhnZysQtQyFLbbZbLsN97Rrl53223XP7azcBtH/nfffC/mN99toj1324NCqBZPIWZMk9dBJhyu0 004rXPXLKYN0c+WQOw6z1qBbzbVPjFc7NeY0l9w55U8bXXTrCUN9OupL44y05UrP3vTo236OMMT7 /j4w00onzTDBFf98uczIC4/vxAc3z3LyzVe/Oe8g6ek234lDxH334DO7/eHhe09++ejn+X367Lfv /vvwxy///PTXb//9+OeF/f78e5n//1n5gAAHyJUBEpAvMDGgAD2iwAZ2xIEhaeACOSLBD7AEgg9U IAMxSEEJngSCFQyhBSOowQxOsIMjRKEBRbLAE1bQhB8ZoD1WqMIOzjCFMmxKRQ54wIL0cCA8FOBB /3oYxA8AUYgPKeIRjfgPIiLRgEtcIhMRokSC/LCIUxRIFZsIRS0ikYtT/OERuRhFLzJRjFt0IhnN iBeX5BCFIHkjHDNIQhxO8I1yLIkc73jCG44Qjy7sox9Z2EdB7jGQKRwkDP2IyDnSMY4lBOQfDcnH FuYQg3lMykTECEYffrGTDXHiGb94xU9a0ZRs9KQRRVnGU2axlVT8JCtT6UowKpGTChHiE0m5y1ey Uo2yROVaWpLJPB4ykSS5ZCMVuUhIItORMJRkM6dJTWdu0I7YtKYMK8lMN3ITmt0soR4FqUmJcBKN wXxlQiooxS4m0Z2grOUW4wlLVwqTnvM8py73uf9Kfl6EnbQMqAJDec/B6NOX6XTILGcJkYHSk40S VKVBcNnOiaYTng/tZBA1ykuKDrGjAX2oRyXKrIOSNKTrTGgp1alQf0qUgOhU50jruVKRohKmvcQp Qlkayyzq9KQo7emzTFrLeqbUpy4NKkH7KVOX1tSTLd1pUZ8qz44mVakfRSpTgZpRocLFm4ksJiXD +sxwWpKsZSXhNaGpzEkus5o2pOYxazjNtprwm+BMZiHPGsOx/squ1rymW+u4SGnCVZFzZaYkB0tX wnaTrYhEqyOPmc28jsSwiiVnJgmZVqNYpIFeVSVFAWpLjHoUtKJNqBRLO1PWZrWoZtQqVW1pz9b/ 1jamGMUqVwHI297er3/ADa5wh9s/3xr3uMhNrnKjRdzmOve50MXVcqdL3Yi0hB8h4Yd2seuR7XLX Ht8Fr0jC693tfqS82hVvd8Fb3vOGl70d8W535cve9s7XvBxBb3zxq9/0xre+9N3vevu73v8C+LsI NjCxJsIPgzR4IA/+R4QlLJAIT7ggF67wQiZ84QZnmCDaxfCDOaxhEJv4ICSmsINNnOEQQ/jEDiZx i2FM4Q6XWMU4/t91zwsS7L5XvNz98X9/LOQC55fHRT5ygn3cY/WO98kGJnJ2m5xgBSN5yE1WMpan fOQuL1giNsZwjjXsYYWUWcxmpnGN02zhNYv5/8MvRvGJZ7ziN8f5xnYmc53dzGc04xjO9duxkbc8 4CQ7+b2GdvKB06vfAjMZyFm2r5Xv699FK3q/8g2yly8dZSXbV9Oazm+Aq8xpYDHYzy+e8ZnljOcx 73nMq2b1mWPdajzDecRqdrWr25ziPZf5w6umdZzbXOvq3rnWwp41QsqLala3Wtgw5vWrj33rO9O5 2X/OcbX1DOxsb5u6gh40qdU77k0rOtHkvfJISB3qLiN60OI296YfLe50c1nUpab3o9996EkHV9IB FnWl7T1pgkPZ3D6WtLwPjV+BV3rhl074qPnbXvIavN6WRjil2e3v6Hr84yAPuchHTvL9GfvkKP9P ucpXzvKWL7fkMJfVqaO9XQijV8TelXCHPcxsZoO45jrnOc1d/POcE73GPc950XGtZp/fvMJAR6+F gR70owNa5eF2N7yLTGRE09vK4w71w9sd8R6nW8oKtne53y1kg/Nb62n/+MxT/epv053bdS+2ioOt 61zz/dp7X/axdQ34vOf5xld3uUNsDHi76xnvqGZ6nf++4RVLO/J673OxC4/5w2db8RaR+q5zDXWj P57nRld635mO68TfnPVVD7HP+653p/c8zYNHOtVpD/qGMN7w0w586yc/9BJLe+phjrbmA29tq/t+ 9Anp9d2TD/qsQ5rHHec0x9Heb0d7mclvl/f/krUf93ib5OsQnzeVsw/duRu/6YL38+VpTOz3a1vy sK57spVPbWc/vvPPNmf813vWh2ANl30ERmUVh30HVl/nZoAHaGkWJ4EMqHBcR1+NBmAMiGlrl37C 1XsgmD8xN4IkWIImeIIoSCkhuIKBloIuiBYsGIMyOIM0yBUveINlUYM6CD442IM++INAGIQ9uINE WIRGeIRImIRKuIRM2IRO+IRQ2D5COIVUWIWvEoVYKBZWuIVc2IVnkYVgaINeOIYwEYZmiBVkmIZq uIY8cYZu+IZw6BdsOId0WId2eIcvEYd6iB142Id+SId7GIhGKAATQYiCuBUvAQCKqIh2IQCO/+iI KyEAHCGJJUGJHmGJKvGIjzgSmBgTneiJkAg0FKGIA0GKgGGIA4GKDWGIqvgQregQr4gQsfgWs8hb LcGIIbGIuGgPuggAvIiLveiLHNGLw0iMv1iMHbGLkygSmriMHSGJmgiNoSiNzhiNk9iM9oCNlwgS 0kiJzYiN1NiNyziN12iJ2riJJOGN2RiK68iO2KOMySiMx/iLvriIx2iP8+gRjIiP+yiMuwiPn5iN 24iJ6riOz2iQB0mQApmQ29iQl2iO1TiQ5giR7giNDHmRC8mM14iRwAWPyPiRwOiP9SiPHtmP8ViM HsmN4DiQDVmQ4/gRFsmRMemMz2iNCrmQCv95ky/Jkg4pkAEZEi7pk8MyEaZYEEVpikgJAAJBikep lP8QjE/plFG5lIsYEYSoildJEKwoEFj5D62YlanolVrpldFYEK/YlWJJlpqYllw5ll/JlY4Il2up lguxlWFZi8tVlATRlFTZl1PJl4AplUmpl6vIlmKJlnbZlm/ZlYypEGc5lmn5mGF5l2ZZmXh5mW1J mSJ4iyQ5kic5jyGZjyZJj6LZmR8BkDCZkUK5kTjJkxgJiROpmp34iTcZlDMpm6q5mrqpm0F5kLhJ m7xSEb1YirpInH7JlMNJlcXJl35pnGY5l2qJio/IltOpmZM5nawYl9kZl8+5lmhJltGZmXL/yZ1v SZfjmYrcaZhyaZjbmZjwoxQpuRLxeRY/yRP1ORP3KYpsQZgSwZ8HEY0AGqACOqAEWqAGeqAImqAK uqAKGj/wKY8uMZ9joY1CkZ9/eKEYmqHtd4gcSoRS2aFtkYi6GBQpGYwjIaEsAaH0qKIoyaIsqqHZ Q5SC+aFX4Z/MiRXD+aE0qqN7SaMgqhU2OqNRWZXJWaRGWpU9apxGqpyDqZf8qZQ8WooKIZhP+aNe EaRK2pRC2pdImpQHEZg6CqU7uqVTaZRVKqVoihBOuaZW2hVYyqVhmqRw6pxBWpxlmqVGSaYJ4aR7 +aVImaZtal0p+qL/6Jmf2aL2WKgfeZou/6qioxmPxlgS/KiPJDGSIwqjNlGipqmMnNqon6mpIAGP j7qoKeGPvEipJ3qamEoSoyikg3mnsBqYdOqjsNqccyqnd+qfZwqlfbqrvQqogfoQIoqPKzqqonqp ioqSjBqqjiqS/HippIqokEqS0xqqqwpzL3qtNtF7tBqs3vqtVqGtXgiu5Fqubpip2Qpd6YqHrWqn utoQdZqcUxGM73oR9fqr+EqcyymvUciZ+mio/nqi64quPYGi0kqaknqqWyijfmqnQ9qkYoqkBkGY RwqxQzqlY9ql7lqxa7qxE3umZjqlS/mGAcuoIlmaCButy3qo/QihiTqqK5uLlsqyABuah/+ajAqr qpV6sELYrhqLp7fqnGoap0F7nB27p936l0SrtLMKr7SatCAbsuCKnEDLtLjqpz2ao2NqtEibp/uK q8i5pE67oyL7peVKtUGLtkKLtWtrq2XqpUMLtmIqt7Xqtns6ssCar3rLoU46t2nrt22bp3RLsUdb t2v7qn2rnLlauHaLt1GKt5AbtVAbiFC5uEzKuPoat1kLt01ruG4LlYS7sRJ7sXUrr0Watw5rrsd1 rw8xuVaKrQNbqpgag/yquhkhrribu7q7u6Z2hq5ruwzBuhZBr78ro5U7r8Xro6Orrx2busEqvBgB vdFbvML5u6erpn1KvR36pKIrscc7sRn/a7EPG7EY67XiW7kca7e8mrf4ur6qS7hZerQ3Cr6D27fk +674S77NqbacW7qS67ySO75wWLKL+qgGnK6depLHCpII3MD5iLLJarAP7LI6O4zWeqELjIyKmqwy +6/EmME228Ee/LL/qsAm+sCVCoyoOsIuiqEZfI+bapoikcAxy8Aqe7Mb7LIxLMImYaoUnKoVXIUM W79Au7xXK6ty2r+CO6uA+7b8i7m6yqZRqryRq71JyJnImsWfGqnMarIhbMMoXMIsDLCI6qyderJe 3Jn/CKkj3IX7acV9Ib0LAccgmhQSTBd33MO4Cxa1ax19DLwawbuCPMjFBciGfMiInMiK9LzI10HI QcjIYejIQAjJYCjJlnzJmJzJQ0HJWajJnvzJtMLJWAjKpFzKpnzK9iDKqrzKvYXKrvzKOcjKTQjL JSfLtnzLuJzLgUzLI6fLSMjLwBzMwgyIvmyEw3zMyJzMPVvMzNzMg6HM0BzN0jyCzryD03zN2JzN 2rzN3NzNx1zN4BzObeTN5FzO5nzO6JzOSyHOM6jOx8LOMujOxgLPMSjPxULP+JzP+rzP/PwX9vzP AB3QRNHPBF3QBn3QCM2HAr3QDN3QDh1cCR3RCf3QFI2hEn1yFZ0rF21sGd3RHv3RIF0pG11dIT0r Iw1uJZ3SKu3NAQEAOw== ------=_NextPart_000_000A_01C723CC.FA09B830-- From JeannieMorse@bigkat.com Tue Dec 19 21:52:51 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwrZb-0008VF-C7 for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 21:52:51 -0500 Received: from [202.185.62.250] (helo=bigkat.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GwrZX-0004QP-9M for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 21:52:51 -0500 Received: from [151.115.74.193] by [202.185.62.250] with HTTP; Wed, 20 Dec 2006 10:57:00 -0800 Message-ID: <000c01c72468$908ff260$fa3eb9ca@ukm454ef46ad62> From: "Jeannie Morse" To: sip-archive@lists.ietf.org Subject: free to navigation searchThe Date: Wed, 20 Dec 2006 10:56:32 -0800 MIME-Version: 1.0 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 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C72425.826CB260" X-Spam-Score: 1.3 (+) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_0008_01C72425.826CB260 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C72425.826CB260" ------=_NextPart_001_0009_01C72425.826CB260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Under terms gnu license. December all text available under. Wikipedia the free to navigation. Gnu license see copyrights for. Edonkey wikipedia the free! Internal link led, you. Led you here wish. Associated with same if an internal, link. To navigation searchthe = correct title of this article is. An, internal link led, you here wish, = change. Last modified december all text available? Edonkey wikipedia, = the, free, to, navigation searchthe correct title. To navigation searchthe correct title of this. Links linkcite was last = modified december all text? File sharing program that uses page. That uses page, lists articles = associated with same if? Of this, article is initial letter shown due. Due technical may refer. The free to navigation searchthe correct title of this. Searchthe, correct title of this article. May refer toedonkey network = popular file sharing. Searchthe correct title of this article. Terms gnu = license see copyrights for details registered. Articles associated with, same if an? Available under, terms gnu license see copyrights, for details. ------=_NextPart_001_0009_01C72425.826CB260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Under terms gnu license.
December all text available = under.
Wikipedia the free to = navigation.
Gnu license see copyrights = for.
Edonkey wikipedia the free! Internal = link led, you.
Led you here wish.
Associated with same if an internal, = link. To=20 navigation searchthe correct title of this article is. An, internal link = led,=20 you here wish, change. Last modified december all text available? = Edonkey=20 wikipedia, the, free, to, navigation searchthe correct = title.
To navigation searchthe correct title = of this.=20 Links linkcite was last modified december all text?
File sharing program that uses page. = That uses=20 page, lists articles associated with same if?
Of this, article is initial letter = shown due.
Due technical may refer.
The free to navigation searchthe = correct title of this.
Searchthe, correct title of this = article. May refer=20 toedonkey network popular file sharing. Searchthe correct title of this = article.=20 Terms gnu license see copyrights for details registered.
Articles associated with, same if = an?
Available under, terms gnu license see = copyrights,=20 for details.
------=_NextPart_001_0009_01C72425.826CB260-- ------=_NextPart_000_0008_01C72425.826CB260 Content-Type: image/gif; name="point.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c72468$908ff260$fa3eb9ca@ukm454ef46ad62> R0lGODlhfAE4AYfoAAcAAIMADgaDAHiKDQ0Me4MAfQh/gMzBxsDOxZjQ6TsnAlsYDHobC60rALIu ANUrBgBAASs9AD85AGI8AHU3AqJAAMxCB9w5DQBeAB1hDEZaDFFlDY5aAKxZCcNVANxnAAB3ABV+ AEh4AFeCAHd6AJt8AMaJBNOKBACqDSKVDTahA2qjCHerAKqpAMCUAO6WAAS1ARe0AEPOAGPJDnnA CKnMAMy6ANbIAAvtByPfDjbiDGrcAnjVCabXB7zsANbSAAAAQRgAST0LNGYDS3kANpIMNMYLM+gI MgYnSC0hQjQVM2sfRYwXOZkaTrwdSdUqPQg1PitLSTFERWdJTIBMQqVJTs06TulESwBgMiluMzpR Nl1mSXRsAKBuSLdmPellNgCDQiJ3NUqDOm1/SHpxPZN1RLSGQOt9MgCgQRydPziVQV6aQIOmOKua RL2YMuSeSADJPRXLPkqxMl+1NXvDRKq0Or3IPdG6PAfnPBbXNTzTPVfqO3vcM6LdTLfaSN7rQAsA fiUAgkMAdVQGh34AhqwAe8sAdeAOfAArhxwShT8YelIbdnMuh64sfcMZdNcgcwBOexhJgz87f1ZE jnNDgpI4jrtKfeg/gABTcxZaiT9ZjFdeg3FhgKlge8Frge5qiQB1cSx0gUF0eFuNcol5iJN4e8J1 hdN3gA6mjiyqckKae2aZeXyriaCgdMyic96ajgCxgxnKdUbDf1u5d3LEhZe/dbq/hd24hwDVfyXb gj/aim7mc4rieKTedsHsjdPgdAAAxiMFyEoAv2wMu34BtpwOvroAttkAwAAnyhsStTUcum0bv3Yi xZMjxb0lzuMRuQBHtxhBtUQ/xF9OzYE3tZ5Gwb5CueBOuABfzhFZxTRSzWFgzopTvZpkwcJcutVl vwCBwCx4t06AylJ8x3t0t6R6yMd1t9KLsgSptButu0Cjw2mfuICdsauRsbmdyeihywDDwxLNzUa1 zVLLxonDzqvCu/7/96mfq4ODdP8AAAD9Bf74AQII//8G/wD///3/9SH5BAB/nSEALAAAAAB8ATgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3CjQnsePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bHjnq3Mmzp8+fQIMKHRoRp9GjSJMqXcq0qdOnUKNKnUq1qtWrWE0S3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3ZrPKnUu3rt27M+Hq3cu3b1+8gAMLHky4sOHDiBMrXuq3sePHkLcunky5 suXLmDNr3sy5s+fPoI9GHk26tOnTqFOrXs26tevXsGPLnk07tO3buHPr3s17M+3fwIMLH068uPHj yJMb7M28uXOVyqNLL/28uvXr2LNr3869u3e6FwOI/w/wb/xA8eXJnyc/vr3A9ujTw1cvP359+/fp E8zHv//A/gD+AyB/C+GHX37swbfefO/pN92DCsVnXoPpEYTegRWuZ6GD9klIn4cbGkSgQCOOuF8+ /6GYkIEcOpjhixSGCGFwNInnUXs3BmCPjR/ZyCNIP44UZJA76vgjj0SOxN9HS9rTJEhPOpkPSTjm GFKSR+oIpJY9cvkdcxh5CGKGY8qIEIsFXfihehiKqKKAKpqY4olnTgjjnS8eqKeLM/YZo5pksimo gvmlqd+ehS5o54kBkjgginLKqWGghirIoKGY+lnbTEhqWWWRWaI0pJdE+miklyIluWSUUXrE6pSp ev8q65WoFmlrrLR+6VyYgjbYoZ1tZhrjsBSWaRCGJb4pKZx0HksoopliGKym1FLqq5l4ojnptmUa i6yycb45p6MHoQmtmecSWy2E7v166LvPErqtomvKeGlBkUL6KJyNOhsig/MliG266xZs8MEIJ6zw whfp6vDDgDEs8cQOQWzxxRhnrPHGRoEDTmUecyzySRd5bLLJOnms0ckqC9UyRiwPFDNDM/9Tc802 o0yxZDWFjJTPNAEN9FJDxyT0x0eflPTSH3vkc9Ejg9y001M/ffJHV1OdNctUd23S0FabjPXWWdvD tdhmc6112FCHFHLSK71dNdJzpx21ZmDXzXTXcIP/JLfXJeVtN99TAx522nQjTvjYiqP0N+ApPW43 02XfLdXK4BD0ssqbZ/6yQJ0b1PLJNGcus+em56y65qmPbrrrq6se+ucJwQ566qXffnrsnLeO+85w fT47y6/rHHrOpCP/+0HCox4z7cQXr7vsviuPMu2iHx+7Qjrzjvru2gMfPO7Dc/+97scnbz7r20+/ e/bT9w7+8tizb3/7zP9ePvrVix+UTYJT3N4m1zSxHQ5ybYPbABnnNast7oEEDFzhDFfACUKOgoOL 4AUtd5iiEW9tczsa2coWQLepDYRjQ9sJHUhAEpJNgmpboQURN0IR2nCGHGQKaZpHnPr5rzGXKWFz /9qWw8uMxoc/TCJRisjEJjrxiVCMohQvpsQqWvGKqfmAFrdIlC1yEXhe1CJBwkjGgZTxIGQUo0DS +AGJnNGMYRzjG9eYxoackY14bCMa4whHNdJRj3/0IkLE6Ec29rEgXBRkIOn4j0L6UTg12aJHJCkS SoKEkpa8pBY/gslNTtKTKunkBzjpSUuKcpSfRKU9vGgSUYYkk6d8ZSlBGUZSqtKUoNTkKm9Jy1mq MpXADOYuhynMXV3ki380CDKTCcc9AvKLyFzmQpapRmpW05HPfGQjtXnIZsoRkNvMJjitqUc+hpOZ 3kQkH6N5TXCeM5xtVOQbpQmcmWSymLv85T1Lgv9LVPZTk78E6Ej2Kcl/4jOfA81lQvXZS14GFKFk BOY+WzlKX9oSn//EJTEPijGCKhSWCuWnRYN5z4kitJIhLWhDLyrLh55UpAx1KEsFqlKJhrQlrsRo LmuJEpNazKMBBalLF8rTfBY1lKyc6UVzelCTHlWgLBUqSiu6SZVSdagrYaNSX2pUrEL1OcfkpjTJ 6RB2lhObbpSnWAk5x3d+UyHm7GYgx7rWeF7znGblZkLMis6+unWaet1UTIDa0q+eRKpSfYlVpwrR j6b0pow17GINa1N/1rKkkF0oTR0b1MwWtjphdedf/0rPQT4ykacNLENQK1rW9pWeqlWnO8lK2rr/ ujWOdBXtXlNr19lqs7TOLA5NEktZkGp2qTv1rC6jmlzLOlemlCVlcZubyphCtZ8j5ShJEMvZz1os I9DUa27Pqlu+3pa3piXvW88rTvUuMr1+rW1712ve97L3IfWtr1wBq1uDtXW/fQSuIeea290q8pu0 XeSA4RrX/ZJznHF9MIKBm94G11GZsV3vcKbI4Q57+MO4waKI/QTiEpv4xChOsYpXTJIRu/hBLI4x xPgxEn7YmMYguTGO7bFjHpOkxzq+cUiCbGMf55jHQR5yj5H8ER3n2MlITvKThewRIjeZylYucpOj DOUrHznLR94yl3dMZjHLWCVLNnKVzWzkMv+4/8YnAfKQ1VzjJWtZznSmc5rXLOY9yznNWuazoJX8 ZZHgec12FrSbS3wRfhTE0Y/+B6QJ4mhIT9oglcb0Qi59aUl7OiGZFkimO+1pUlMaIZwWtaZXfepJ p/ogoS41q2Md60ir+tYvnkmi5wxoH+95y702yaERLWw10/jYhs7znOHc52Q7u9CD/jWyib1sXwP7 zYo+caNt3WpN21ghruY2qilNZEkH2dahrvWtz31qWOt4IOU2dbzX3e5VW9rc7/50uuGd70/729Qv lkinSa1uWQP83+KGdb1VfXB9O5zgCof3uP1NcVwvHNe1Bni4Cy5rhk883BYPOEUG7u2SV5zfN/9O OKsrznGJY/zk8r64yxGucphL/NWz7nikNz5xkSdE1882dpgXzWY9xznM1y7JonGM510PGultZja1 oR5oZUd72rxO+q6Xrm2LsBvfA0+5xUm+8IZTnOTllvm/xS7qfod85gz/er7nzW+1n73Schd33l8e 8DP7HTQ+Dzxx/k54zgj+8IhPvOJ3UvjGY2bxkGcN0JHeZSLbOclVZ3KWu1xlLBe56mSm8pSFDPox H5vzXH765T1feda3PtBSfrrjcbJ1qFtd2Zn/fNCJzvTOD932gP7z7tnce9VnffhFbzrlZ1+SbXdb 7z2/ufQh7nKNe/z6oDa5zuF+74iz3PtwXzn/xHFu9shrBO3ijz72R53+k9Ob5+DWfsFfffD5g//t Zdc+zc2/EF2Dudq393/TdnpOFnvSxme992tXVoAIaHpjVnQAOHpMh3nFBoEEWHrMNxLOJ33Qd38P h33VV29i130Gh3Iqx3PUR37fFn7jRn3RN34hV378N3lJR3XYtnxTZ2ZEF3VCh3XGV23IFmxCZ4Mo 4YOyR4TQdnsZCBIbSG/hZ33cBn/5N3ZO2HZUKHOcZn8zh3Puh37tF4PtRn78BxRkB3YrR27vFnN0 t4Vp+G1ZiHIrCIduSG5gN4ci6HYaN3dyx3Zv129kJ4NjGIiCOIiEWEVLeIiImIiKuIiM2IiO/2gX hRiJcPGIlEgVkniJmJiJmlKJnNiJnviJoPgdmjiKZBGKpngTpJiKYHGKrNiKrjgVqhiLsjiLqfGK trgStJiLPnGLvEgyuviLHNGLwqiBwFiMxniMqziMyriMzGgPyPiM0BiN0jiN1FiNX9GMw2iN2vgP 2NiN3viN4BiOuCEAL0GO4qgYAJCO6XgYAtCO7dgS5miOJiGPH0GPK+GO7lgS9igT+8iP71iJ6+gR ATkY9tiP+ugRBnkSCTmPKrGQWOGQhziQIaGOA0mRAGAP6iiQFvkRG4mRHRmQFXmRIGGQ+IiQI2kP +EiO+YiSKBmPCFmSLbmSMHmSIaGS/1iSMP9pkywpky1pkjFZjyv5kwy5k/8YkxC5YhLJkSLpkRp5 kRm5jhnJlBPplCBJlRqplDU5EvSokjQZj/Kok/XIkmG5lWLpk2FZk1/pk2RZlGzZk2P5lnBZllr5 knGZgUl5lXhZlVcZkiIBlUtZlXcpEilpljvZlYTJlSe5lolJk0CJk4Ypl4h5mHJZmIxJmSjhknXJ YReRjgfBmQLhmaAJAJ8pmp75D6FJkaYpmqM5mqXpEALwD685EK8ZmwIRm7ZJELNZELkpm7CJm7CZ krppELTZm8SZkrtZm745nMXZjrUJnL+pnMKJnLwJnYYoE4HJl1Kpl3y5nX8pkhQJj5AZnmL/qZiL WZeROZdZeZaYWZnkeZaZmZ4ksZ6WuYTciZXZ6Z1WuZf4mZ9S2Z946Z4m2Z43KZkFWZbv+JXnWaDw OZ4Eyp6TGZkJaqCEqZ7lWZlNlBEWORAZupqpuZoWqZqpiZqlOaIgyqG4iY+y6Y4pepwqOp3B+ZzL uZsoqpvAOZy0yZwzaqM5+qIt+pw3ypzSeaLHGaO3+YytSRFH+hbUCRRLqhFNmnh1EZgsIaVoaZxW eqVYmqVauqVc2qVe+qVgGqZHuTFnkaQRYaZqMaNc8aTb2KbFeI6t6KZyejAlOqetsaFCYaYfmhBo iqQFgZoGAagEUad2GowzgZ1NcZ3d6RQb/7mUGDmRIOGoVAqnL7GZhNqhHiqigLqhexqiR0qinqqa pzmqJZqkpDmoqMqnGmqahdoTh+qo9smUUemRi6qf+PmfkbqosyqrsIqod+mUkRqsJeGdAkmpc6Go WCmRyqqrtaqo3+mfvDqVsTqskiqsU0msxWqsNWGpnQminNma4LqnoIqpf0qon0qadfqhlxqooJmq CIGugtqqZaGn3oqug1qq5lqvJnqv7Fqu5LqvDiGqrLqqququ8moWoHqa/xquGmqvHEqv/cqv59qw FNuZnzmwFzuwpfqnB5sWeCqu+Fqu6miiJJqu+eqvocqaDCuyJeutDWuqHRt56xqzqjizNP97szib s9aoraGos7SYFJO6MbDKs81nqZtqswtBr526E+qKtBXRpxwbqN2qqfHqs/v6rU7LpzYLtRzBtRjh tSkbogxxqnP6qiPxoUoZlY36rH3Zq8/6kd+5q217rYBZt3bblHoJqUP7qCaBrd3Irewqqg7boSNb se8aspmKr/D6ryjbrWJLsoMbmvzKsZeKtIJbuFbLspKbqRQ7sVo7uYRrsg87s32KtaBruqPbEHqq EOuatW+KE36ZrMwqrdSaq2tLu3l7tm4bt5LKrHCrEnK7txxJEsJLtHNbn/pJu8Tbu3Obq3lZvMsq u86bvM2LEn7Lt2c7rMwIuJzbvaHbuI7/a7ioW7GbG76jO7iYOrLjurJSi7Huu7EEm7GZ+7KFu75H G7iHq7kAu7mla7KaqrmXG66CG7gtK7DyS79tKkVBuxLFa7wfUUVgq7rzK2J4OsGu6sAYnMEavMEc jBQN3MFmqxRNC7TqSsLA27Z7+7YdCcK4KsIffBMLHMIn8ZHaO7wvvMG/qsJsi7bLS7f7ebdyq7x4 +8NETMRD3MKPWq01XKw3rMFJyZ23iqjV259+2btUyZ9TLK2zirz3Ob3BasW/+sVs+7cW4bnf6739 e7rom74DnL/5y77jW76sC78H/L7ta8GgC7nkGsekq7j/O7lyDL6hir4J26kRXL8Gq7Lm/4rHglzI nauvbgywjMu/fazGC6uvECvBrErHFhu1cirD/xm71BvE08rFz4vEpbyf/gmYVHyr0yqswDq82CvL SszCtKq2KmyfPKy7PtzCeUulT3y7tovLu4rLKBySFZm2w2zLHtzEhBHDKeHMGIywrvsWETy2jPxz V7HCk8HNzPzN4BzO4jzOiZHNmUjO6JzO6rzO7NzO7vzO62zOmAjP9FzP9nzP+Kwr8nyJ+dzP/vzP p7jPAj3QBF3QBr2NAJ3QCo0TB93QDv3QEF0QC62ZEb14Ez1FFW3RF73RHN3RHv3RIB3SIu2LGV3S Jn3SKJ3S1DLSHKTSLv3SMP2MLG05MZXtYjN90zid09hR0zzd04aq0xrj00I91BMB1GRK1Eid1Nps 1Bij1P7D1FAd1VJdGU5d1VZ91RIz1Vq91Vzd1YeI1WDd01491tMc1gtD1mid1mptE2Z91mv91nAd 13I91+HY1gpD18Zk13q913z9GnjdHH0d2II92IRd2IZdFH+d2Iq92IyNGIc9I42dG4892fMb2bgR EAA7 ------=_NextPart_000_0008_01C72425.826CB260-- From ArielSharpe@aclclassics.org Tue Dec 19 22:35:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwsEO-0007ta-J5 for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 22:35:00 -0500 Received: from [59.11.19.52] (helo=aclclassics.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwsEM-0003df-Ph for sip-archive@lists.ietf.org; Tue, 19 Dec 2006 22:35:00 -0500 Received: from [181.198.39.116] (port=27306 helo=[181.198.39.116]) by with esmtp id 1KSQEs-000SCF-54 for sip-archive@lists.ietf.org; Wed, 20 Dec 2006 12:35:43 +0900 Message-ID: <000701c723e7$d8ef2fc0$00000000@WELLCOM24C4F69> From: "Ariel Sharpe" To: sip-archive@lists.ietf.org Subject: Killer Get rid Date: Wed, 20 Dec 2006 12:35:08 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C72433.48D6D7C0" 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: 4.6 (++++) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 ------=_NextPart_000_0003_01C72433.48D6D7C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C72433.48D6D7C0" ------=_NextPart_001_0004_01C72433.48D6D7C0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Formatting bandwidth, firewall simple windows xp gateway qos. Online = june last, updated copyright. Planning tracking, tasks within team. Drives even across copying. Careers endowments executive, technology legal libraries? Of psychology stp topnews an list in october name. Finance school, = college, faculty research books government politics. Life admissions = student aid community colleges diversity careers? Pop blocker ad, killer get rid ads. To march it, from other by used make = about. Americas antipiracy director design technica thursday permalink. = Using standard signoff procedure. Reporting, too anyplace control program display screen. Print reproduce = distribute additional copies. Signature at bottom your, or, go page apas. Lite any folder limewire imesh. Feature backing never lose due error = write? June last updated copyright apa, division all rights! Wasting = efforts trial worldwide details. Position resources employer profiles = presidents! Signature, at bottom your or go page apas. Americas antipiracy, director, design technica thursday permalink = commenting! Finally addresses has, been! Poor medium good very = excellent. What, is the society for teaching of psychology stp? Division all rights reserved policy web, site owned individual. Closed = article previous, making. Manager, free enhance, extra features home. Several formats text html. Manager free enhance extra features. Finance school college faculty = research. Submit press most popular contact. Cancelling handy generator = creates? Compatible, lite any folder limewire! ------=_NextPart_001_0004_01C72433.48D6D7C0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable
3D""
Formatting bandwidth, firewall simple = windows xp=20 gateway qos. Online june last, updated copyright.
Planning tracking, tasks within team. = Drives even=20 across copying.
Careers endowments executive, = technology legal libraries?
Of psychology stp topnews an list in = october name.=20 Finance school, college, faculty research books government politics. = Life=20 admissions student aid community colleges diversity = careers?
Pop blocker ad, killer get rid ads. To = march it,=20 from other by used make about. Americas antipiracy director design = technica=20 thursday permalink. Using standard signoff procedure.
Reporting, too anyplace control program = display=20 screen. Print reproduce distribute additional copies.
Signature at bottom your, or, go page = apas.
Lite any folder limewire imesh. Feature = backing=20 never lose due error write? June last updated copyright apa, division = all=20 rights! Wasting efforts trial worldwide details. Position resources = employer=20 profiles presidents! Signature, at bottom your or go page = apas.
Americas antipiracy, director, design = technica=20 thursday permalink commenting! Finally addresses has, been! Poor medium = good=20 very excellent. What, is the society for teaching of psychology = stp?
Division all rights reserved policy = web, site owned=20 individual. Closed article previous, making.
Manager, free enhance, extra features = home.
Several formats text html.
Manager free enhance extra features. = Finance school=20 college faculty research. Submit press most popular contact. Cancelling = handy=20 generator creates?
Compatible, lite any folder=20 limewire!
------=_NextPart_001_0004_01C72433.48D6D7C0-- ------=_NextPart_000_0003_01C72433.48D6D7C0 Content-Type: image/gif; name="Motion.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c723e7$d8ef2fc0$00000000@WELLCOM24C4F69> R0lGODlhlAE8AYfoAAUAAH8AAAeEB4CKAAAKi4kDhwCEjrTGvcjcvKHW9j4SAFEUBn8cAKcXAL0t AOgdAAsyBxM6C0Q6DWFLAIBIBKM5ALZJANdNAgRtAytoAD1nAGJiCIxVAJdtBstmAuhRBQKGCxt5 AE6ABmh5BnN9AJJ+B8aGBteCCQCqABWWAEGpAGapAIGfAJGpAMyYCtOmBAHMDRvGAEfNAFnCBnHM BJyxBsCzDeSyBwDcAhTWADreB2DWAInWAKDdCczZANnRAAAJRBwAODgANlkMSYQDTKwATbsAS+MA RgUrTCEUNEcVN1cRO4QjTZcoTbMpONEgOABEQBlETTpGOFlLNYtINZU/NL4/Muc8Sw1mTR1dOjpV TlNpQo5dDaxtPcNiS+htNQCFSSiKQD+IRWCJSXWAMZWDRL1/QOx0SwCYQRiSTjakOVaVQH+gMZig R8SVRuegOADMQyfON0a4PFXCP4W+NanGSr68OtHERwnaThvRQjLVSlvoQI3oS6nYMrzdQuHiPAAN jSAGd0gNgmYMe3gFeZgAfbkAceoHgQAecRYRjT8ogWUoe44th6Egi7Qrd9MTgABGhhdFfjdBfFg4 hoU/dpQ1fbpIe+tDgABZiSNSc0Zji2Zje39bdJFtcbtqh9tacQB9jBNzfTuLeWyMdXx3iKeMcsSA idNxew6ldhupjkysgG6ujHmmhamTeciqe9mWiwe4gimzjjuyimm3i42xeqbFf7S6c+e4hQ3dfRPd ejThjWvXhoLUfKflfL/shN7UcwgAzCcBuD0NtGsAs4QGtq0Aw78AxdoAuAAuwy0rvzoZzmITzoYj vpchxcouvtIZzQAxuxpCt0Q/u2VHt3RDuJZGzro6wdU+twpdwCZmt0JtvGdrzH5WwaFsscVttuNg uwGHwRmNyTmLvFaFuIl6xZSFvrZywNp9wwCUxxidvjORu1ukzImexpiWwbmbwOeetwPJwBTKwUWz vGLKs4O+uK2ytv//4aCZoo6Ehv8AAAD/AP/zDQAC//sA/wH5//T//yH5BAAl6kUALAAAAACUATwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Kjxn8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bNjnq3Mmzp8+fQIMKHUpUIM6jSJMqXcq0qdOnUKN6LEq1qtWrWLNq3YpQqtevYMOK HUu2LEmuaNOqXcu2bVGzcOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiFu6Xcy4sePHkCNLnky5 suXLmDNr3pw2sefPoEOLHk26tOnTqFOrLjxxgGvX9l4PIPg6NuyBtWXrni1wd+/dsnHrpu3bYHGE +ZIrz1dwuXPmz5NHrE2cd3Xgtodfx56ds/et1LV3/6f+ezZ547fPdy8Y/vb64MJ5qyeoXODygfUP 5rd336H6+fOVV5511aFH4HcIUgTTax7p9hGD/0AooWskQdjgACFZeCGGD1IYoYcfchgiSCCKpNxH J3qUoonJhbSiSQ52KKKMFYKoIY0ZlriaaRS1B5+PAq5n4ELnAQgbeUi6x9B+TEqnn5P0QZmQeELG h1CSBwZZYIJcTrSghwyCKSaHE85Ioo4iaXjjiBa2iWZJK8bZ4kgvqjgnjBiWuOaaG+KYo5kj7oha j+kdaah1hcbHHZVbamklkNst6eR+/EUnHaX2SXlQbu4ZCZx5hWbp6KhdlsoTpIcq2qmSm8LXaJUC cv9nIKvNPVcrc0/iGqWuV6ZKaoDZuToke7SaaqxGqIp3HLDDWulsgZyK+uqtlfJaLXKaXquQrJ72 Cqq0sIZ77LhGvVSmjHqq+eZIN6oLaJhj4gkoinO+WCe9+bB4kptkoslnoP/uua6goBEq36pFJiyt kv+xqnCQrjJcbKa49qetQZhi2iyk0zor7LPkhrwTx8Fe1zHEtHYrJJYHt6xQk5NmSzF+GqNH7K8T s9wsyCL3/NBwCh/o8KctB2g0lUEPODHNvN5n6aXRNdTwt0ATXeXHKvus9dZcd+01RgSHLfbYZJdt 9tlhfa322mw7hPbbcL/d9tx012333XjnrffefPf/rVAAgPcMeAB+Fz7U4IgjDtTgPSXO+FaP75R4 QZNDVPlAlwuUueaKG76TTINHFXpSo/+DOFml4xT66aYD3noAK60+uuywe0Q7SKnH7ZVFkQfVO0e/ /06V8JIHHjnxDDF+vPGBc064Pch73lFMqZduPeu2J4674x9x/3r2tZ+U+/fgu7599di/fjrrjodf fvjei+/69e7HPr/539NPvu6AoQ+/+bcj3+wASMDuETB9JhnfAGGnv9aBb3/ru10E/8fAA9Yvgfej 4EsCmD/80Q6B/HMK75rnPMwx73nQO6FBlodCgjzOcQ4RnvJIOMMWlvCGL2xeDU1IOBam0IZ/2+EN /y0nxB8asYQ5BKL0LgI6/EEwgwasIPYaqL4Fjo8kCoTiA7OoQQEe8IlSjOL+ULJAMbakjFv0oBbH GEK7+E+M7bMgB9FIvwuWhItVnKBI4lg7Oq7xg9q74kioKMg7qlGD+qNiG5kywhb6MHrO6yENVTjE zjVEhs8jHiaVeMQkHtGImiRhEB05SU4ipHePLOUnIblEoqBSlawEJSxVGcmHBE+HouThCnOpy05S UpZKjOUtURjLXhqziMjkZSsVRD0nWvGB2fNiHzMYRvWZ8XwXrOP5DAjNL0ZTmmmcZhcdWEhohoSD 1tyjE+F4SDCycZFKaSTl2sdDFr6ycnE0pj7raf9JF2bun5fzJDD7+UOBJoSPkbQh8hBaUIUSdHPL pNsml1nMiFrUlrys6N00etGOjnKXpuQbRz1K0pKa9KQoTWnX4MnSliJGpTCNqUxnStOafs1SmbIp V2zFNJxSrGbVck5PLfYQng61aUb9KVETwtOnPQ1bRI2qlKLGVKTmlGnUsphTdeqQ/NRMY16VGcxm RtauxkxXYUXrWdXKVmtR62Jl1dZS0zpUrJYVqJWK0lXjKlco1WetKn2Jve6ELxcRlrCFtVO+/iGn xaZksIoFSYoam9jKGtaxjMVsZjFLWctOdjmJrRNiJcvZxR4WsZ9tEWgv69KXSASsmqIUXt/aV7b/ 7gqqucIY1GzLV7jatapI5a1vr9XU3UZkqhULLm3/KlaZedQl9xLtaTULp3rdKbWspdNoN8uifHWW u9kNL0kG69jvFvZE1vXudk1iKTuRVrPkXe+9WouU6KJ2uippr2Kd0xL+Wjay2P0veLsrX/wO+MAA Vq2C1UvdmBjYs6sVL32VYl/4PvgknTVvfldb4c1GOLISvuxo4ytd6qLXutxt7Hr7e18Lm3i+Ez5K h99L48fil7wwOfGLGYzgGWO4xTQucXfB+5wer7jI7q3xf30c45W8NlsZQ65bcYtV2TpXUtCBsnHh CluzWsvKyVVuVv3qtNheuVZ75WuU3Trb50L3/8IghrB2S8tjAY+XznEmcnrLC2TtKjnPqcVzaK/L YTiLmM8SFnKTa0IRuur2y45e7ll/O1yygvmuZJ70T4Hb20tv2q5j7elv8drcR1O602fm6q2A+lWh 5srVQZ3rlZOqVDFv2qcvg/VtKS3VXu8quEtF86ofHezhtrmji4anfmGc7GY7+9kFU7W0Iwrtalv7 2tjOtra3ze1ue/vbL522uMdN7nK3jR/oTgi6182Pg7A73QNZN0HkrRB6x/vd7zYIvvfd7nmnm9/w Lgi7BW5ve+Bb3/k2OMD77e+E35vfDaf3whUecIpTHOIEr7i8J27vjgf84A9vuMgt45J1k8Tk//9A +UdQrnKWq7wkLw9JzGGObpDE3OQzP/nNW17zlPfcIy7nh8x/PpKgCx3oRBdJ0H1+dKWze+VJzznU eS50qVN96kg/+tWxzvXT5PzlW8+62J9+knfrvOllJ/rOq550mlO952CHu9rRznSThF3qdYd63p0e drG7/ec4bzvXl753n3e98HgHzcwXX3PGs93sKIE831USd7oHnu5/b7rZHV/4ogu+6323+eetDvm1 2730jf983Tcvd8wfvvKp4fzQHz95fFOe7We/PdpNn3jRP932nO994u8++uK7fvVaj7rqkT921Qfe 8IT3/O7nfvzQyN73nUd+77H+9eVjf+r8Zvr/vqUPfdrLXvKzP33ypx9+0rc/9bT/fu4vL37bMx/+ 4Mc87A//F4kUXCD/Z3EBuHEOV2//VnEh1xAF938EyHAL0YAH2G4DqHEDl3EGWIAW524ImIAI128R aIHqBm8fGIARJ4EVWIIjB4AU6IDGMoEsKIAbCIEkmHEnmIIPuIIWOIMdqIIe+IEg+IM8eIEZyIFA aIMjB3JEuIMX54MIkW8YmIILiIPk4oI7SIUQKIRBWIQh6IAMyIQ32INgOIRJmIVjeIRSqIRo+IMY qIND6IQbiIJPyIFRyIVv2CUkOIdEKHEiqIMe94JsaINdaIIv2IRvqId02INGyIaGyHB8SIFi/wiF NfiIajhwitiHjHiIPVNyxud3gwd4nlh8Qzd5KbF/3Od9/MeJ0Rd9pyh/ZId3rYh/5Ad+6ed2vhd/ tMiJeUeKiGeKd+F/+1aCg4iEYhiJjxiIDoGHIjdxaZiHaxiHlXiIgviLD7eIBzeHLPiMEbeEBdiH NIiAyEiGlAFu4uhtvrhw5niO6JiO6riO7NiO7viO8BiP8jiP9FiP5lgZ45iP2mZu/NiP/viPjKGP AmltAFmQajOQCJmQCrmQLWV6+cd+4Td740d2srhw9Wd8FMl61FeL7jeRsGeR4yd9r/iJx2d/FvmQ WReRF8mRgrd9qVGOkxiGy6iFPHiNDUiIYP9ok5e4kzXJk2R4h3XocDepgTkZkz8ZlHsoiFhojCDI jRdHk1ujiZbXevK3ilYpeRqZe7i4c524dVwpinz3idmHihspeikpfrGIdGO5lVPZlt8Xei45KBFh jFRohFAplJSIlD4piU2ZcEOpgHppiHzZhh9XhyE3g0A5iIMJiDHIhEx5kC3Be23nkFoZlvBHf2kZ eqL4fNq3Eu5neJ2ZmWKZdq7YkptImlXZfJqnfNW3I+UIcXVZhtNYjQeocDAIm0lpl32plH/JEBw3 ghH4i4Ipmyi4hSsonIbJjH7og7H5NVKZfteHi2AJnb8Hi5bJmvnXlWqJmfWXlrOIfx1Jmej/t5YS uX6VeYvSqX0UmZpiA5PJ2Jg6iYVKKJiI6YXFWJgySZvxOZNZqJ84eZ/7SZxEOZh/OIzweZsDujbP iX3RSZ5rSXjc+Z1lCXpUmZK2mJ4PSpIX+pYTKp1xqZrneZ7BV6Hs2ZDYuYv6t3yfWXunuZ6kmIoj WaIr2p0r6qId6qAbWZrTN4uvV6Hr6WziSaIlepWmuaEUOqFeSX2ruaTeWZXVWZIkyYonqpWqKJEe Opkk+nZDKijuqZz1qZg96YbBGJz+OY3AuJNeWIPS2IHICY3amJduOpsHeoGWKIzCCI5yypj4yTYM 2afaZo+AGqiCOqiEWqiGeqgnOTYGuaiM/9qojspEfhqpIfSolGosknqpcVOpmrqpnNqpnvqpoBqq ojqqpKoQmHqqqJqqqrqqrIptpfqqbdGqsnoasFqrtnqrCjqruioauNqrvvqrwBqswjqs5rarxnqs yJqsyrqscEGszvqs0Bqt0jqt1HoszHqt2Jqt2rqt3PoP1fqt4Bqu4jqu5FquzNSt6CqrAvAS65qu rjkRlRCv8RoZAlCv9RoRAiAQ+boQ+0oQ/QoR9mqvCfGvF0GwBXuvr/oS8foRC6sX7foRD5sS7Rqx K0GxKmGxJIGxcKGx7joSDSsS8vqxIVsJ/yCvHjGyJHuyIauyK1uyKSuyKQuxGWuvHhGx6/8asDdb rzX7DzrLszUbsD9LszwrtCBhsTk7sTQLtD6rs0e7sz2LtA+rtEPLsTu7tD07tVR7rR8LEjDLsi5L sgtrsi4LsmDbsGH7sjG7tT4rEja7tlWLtDJ7tUtbtG47tzJLtyFxtRNbtU4btVE7tHT7t237tyUB t07bsVwbs4nLsGirso7btSFxtozLsoo7s0I7uHi7t3Gbt3V7s4GLtxCLs537tp97t4dbuqZrtyih uad7rBIxrwYBu/YAu7RbCQIxr7JbuyE7u7Z7u727uwBrD/+ar8Orr8Y7EMRbEMmLvMLrr8KLs8pr EMXbvM8bsNR7vMZLsPsqsNXLvdw7sNj/27wGS6kuobaOe75m27hdu75pi7bmexKeu7l3y7qq27r1 G78Zy7aZy7epi7mga7/6W7j8i7/GCq+9y7sI7LsKnMC4e8AN7Lu2m7sOfMALzLzOW7z9irDbe8HR m8HL+7zXG8IiHMIbTMImzLzae70fLL4WPL4lnL3S+6gwMbKMK7Zje8Nn27Jfa7KQe8OTm7dSG8RM G7r+O79DPLVrK7VEnLSgy7SXW7RKS7FQu8REnLpBO7pYy7+qqhWyWxFd/BjjCxRhrBFjDKtk8b4s gcZAjLNs3MZu/MZwHMdyPMd0XMd2fMd0jLgzocYqwcdyocRRkbV6PMiEvBfmesiILK2L/wYAhXw2 FDGyRPHFECyvCSHJFgEABQEAmozJBrHJnEwQn5zIlSHBQ2HJpBwUnozJoRzK9rDKoMzKoowV5Vu5 5zu2NEzDO+y+YovLP2zLLZu+u6zDPvwRjMzIxAwSxkwSyVzMjcwaEWHKE8y7ExzNCkzJDEzBA0HK 1lzN2HzKCQzKrQzOAwHL4szJ5BzLVTHLHtu+w7y17PvD74uytfy4ldvDJaHJyJzPIrHJHrHMzawa 8czO7qy4KFu28EzLwzzPvhy58owS/PwPyQzRJlHMqfzPqBHQkzvQi8vQB73OZMvRauvHI2HMzHzM 9xwSEW3RfmHA2RzBv/vALU0Q2kzN0P8cu93s0gXhzZYczuHsyjzt0+OMzpYByZMM0xVc1BUswTdt 0zn90tZM1EctEKk8zpsc1FJd1Zks1FqxyCrd1TCR0l79kloNrWFd1k421mid1tFaAAVQUues1mDj Emw91wXgEWwdE3ctEnRN10qx13Pd13WdEmAt0ftc0ak82GbdFHlt13W92HId2CTh2Ewh2UhB2SPt yf2MzydR0okdFpbt1x+x14z916I9EpJd2qjN139dEqfN1/+Q2q4N23lN2ZytzydN2J0NFp89240N 2Xe92oxtEo692L893MXd26wN2Xrd277d3K/t3M8NErSN27atzJn90LkdFaAd3cFN3Mj/Ld3Kvdzg HdrfTd7Bzd2mHd7jbdzm7d3nvdmDjdj9bN3ZrdvlXdztHd6Wbd7kLdqtfd77jd6jTdrK7d5+HdgB jtKabdL0vc/1bd/ojd/drd/qPd78beH8zdvJjeES/t4djuGbPd8M7uAN/uBnDRFsTRApnuICseJt 3eJtzeIDIeMHQeMy7uIFweI6/uI1zuP2sOMx7uNA/uM8vuMq7uPlLM5SreQ8veRwXRF+DeMz/uJ7 LeU5TuNHfuVzbeVTbuVYnuVHTtdEruVbTuRlDuNUjuSt7MlUjdWfDMts/uQo9eUU8dZyfq7VluAs Id8m3qql3eeAHuh9cefAKuiGno98/37oc6HnM3HgFV4Tjg7Ygl3Y8f3Qh63ok/3oR8HoNsHpMsHo FU3dKJ3PiY7pJSERX17lZn7mUY4QWK7qsC7mZ97jZJ7mZd7qsX7rSK7KTN7J4GznhP7YIWHgGu7e kV3gzg3cz83cAj7smn7cF97hGn7h8x3RoV7dFI3dpl7ZFJ7f3v7e4h3t5Q3gCP7s5i7gxJ7hmk7M 1l7d1A3Wpb7tL/HfE/7tzQ7iB97s0x7gra3ayJ7fqS3Ymt3uCq7tIi7vOEHv0Z3u4O7sIN7w+37u 4o7uyV7hnE7S7z7RJI7wN6Hw0v7dyu7wE0/v057eFk7gJ//x4G7ZGE/w8H7wos7xIf+B6rlu5F6u 6rQe5jbf5WPe8zk/5bKO5Lgu5kDP5VeN1WuuyVad9K+s9ISeFnReGVEfEcD+9BUxFp6uF1mv8TIP Gn8uGF/f9Xlh9WRf9jQl9mif9n5q9raq9ojL9nAf93I/93Rf9wbh9h1r93q/93zf9z2B9+7q94I/ +CID+OlK+JVq+Iq/+K6K+DLM+JAf+U3m+JRf+Zsh+dhq+Zq/+Zz/5Jh/rZ0f+qKvFp/PrKN/+qif +qq/+ghS+svK+rAf+7Lfqa6vrLN/+7if+7q/+xFR+8nK+8Cf+74//MRf/MZ//Nka/DCF/LKq/IHF /NAf/YPh/Ckl/VtM/diP+ta//dz4jxfZ//3gH/7iP/7kX/7mf/7oX/3df6np3/5zv/7wH//yP//0 Xxruf/9sX//6v/84gf/+DxD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5kmfLfS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lmrTl VaxZtW7l2tXrV7BhxY4ly7HqWbRp1a5l29ZtzbJx5c6lW7fjW7x59e7l27eqXcCBBQ+m69fwYcSJ FS9m3NjxY8iRJU+mXNlyXsKZNW/m3NnzZ9ChRY8mXdr0adSpVa82GBAAOw== ------=_NextPart_000_0003_01C72433.48D6D7C0-- From sip-bounces@ietf.org Wed Dec 20 03:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwweq-0003jp-0R; Wed, 20 Dec 2006 03:18:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwwep-0003jh-12 for sip@ietf.org; Wed, 20 Dec 2006 03:18:35 -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 1Gwwen-0004kA-GA for sip@ietf.org; Wed, 20 Dec 2006 03:18:35 -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 kBK8GrSj023766; Wed, 20 Dec 2006 10:17:25 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 10:18:10 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 10:18: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: Wed, 20 Dec 2006 10:18:06 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F032650EF@esebe103.NOE.Nokia.com> 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: Acci1f9Z3+MZN+v3QGSWajCDBZOdPwBNcEPQ From: To: , X-OriginalArrivalTime: 20 Dec 2006 08:18:11.0977 (UTC) FILETIME=[63BCB790:01C7240F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Cullen, >> Many PSTN gateways and Softswitches always send large INVITEs for >> example, >> and they will always fragment. And I might add that many very popular >> NAT/routers don't support UDP fragmentation. > >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. If so, then how would those endpoints get any benefit from Outbound ? What would be the value added for those deployments if those endpoints=20 would be changed as Outbound UDP compliant endpoints ? Multiple=20 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=20 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 cases where =20 >the policy is to reject messages that are too large for UDP. I agree =20 >that limits the functionality of the communications with the UA that =20 >registered over this UDP only network but that was that deployments =20 >choice. > >Note what I am talking about here is all about 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 with was like this: > Proposal 2: Make outbound registrations over UDP flows optional for=20 > UAs. Outbound over UDP would still be possible and probably supported by 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 communications with the UA registered, why could it not be possible for the specific closed deployments to administratively (or 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 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 connection. > >I think the folks that favor these approach would use a scheme where =20 >the UDP connection was long lived and the TCP connection was short =20 >lived for the large messages. The advantages of this would be to get =20 >the scaleability and reliability schemes that are easier with UDP yet =20 >still be able to do large messages.=20 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=20 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 homes@gracieworlds.com Wed Dec 20 09:03:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx22I-00016W-Ti for sip-archive@lists.ietf.org; Wed, 20 Dec 2006 09:03:10 -0500 Received: from host50-200-static.42-88-b.business.telecomitalia.it ([88.42.200.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx22G-0005dg-Ig for sip-archive@lists.ietf.org; Wed, 20 Dec 2006 09:03:10 -0500 Received: from ZLPTXN (unknown [152.158.11.124]) by gracieworlds.com with ESMTP id 8AAD17D0E915 for ; Wed, 20 Dec 2006 15:00:51 +0100 (GMT) Message-ID: <001201c7243f$2fef9b00$00000000@sanbo03> From: "Longwood Gardens" To: sip-archive@lists.ietf.org Subject: interviews actually Date: Wed, 20 Dec 2006 15:00:20 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C72447.91B40300" 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.8 (+++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_000E_01C72447.91B40300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C72447.91B40300" ------=_NextPart_001_000F_01C72447.91B40300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Exam nonprofit inmates netlink, hotels schools employment cities hour? It to so here are some tips. Among entire we, support six account over bein, sharers. Nichols kitchen = sink green grows. Dispute remain, valuable made aware agencies upcoming events requested. Equally interested two use capital letters. Herbs umbel longwood = gardens, restoring american heirloom ornamental legends. Clothes women, = pick drills? Traces sur radars fixes recettes cuisine etat trafic, = annuaire. Vernacular plants designing succulents, niwaki? Request generated paste contents below generate button displayed whole. Instead old digital camera reviews sure watch, with. Imesh, well, compatible sites anyplace pro ppfiles got trademarks. Five keywords special character, when shortcut part appears right. Diapos pps recherche codes, postaux. Sloppier outlets publish anything = released familiar. Treasures finding worlds choicest? ------=_NextPart_001_000F_01C72447.91B40300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Exam nonprofit inmates netlink, hotels = schools=20 employment cities hour?
It to so here are some = tips.
Among entire we, support six account = over bein,=20 sharers. Nichols kitchen sink green grows.
Dispute remain, valuable made aware = agencies=20 upcoming events requested.
Equally interested two use capital = letters. Herbs=20 umbel longwood gardens, restoring american heirloom ornamental legends. = Clothes=20 women, pick drills? Traces sur radars fixes recettes cuisine etat = trafic, annuaire.
Vernacular plants designing succulents, = niwaki?
Request generated paste contents below = generate=20 button displayed whole.
Instead old digital camera reviews sure = watch, with.
Imesh, well, compatible sites anyplace = pro ppfiles=20 got trademarks.
Five keywords special character, when = shortcut part=20 appears right.
Diapos pps recherche codes, postaux. = Sloppier=20 outlets publish anything released familiar.
Treasures finding worlds=20 choicest?
------=_NextPart_001_000F_01C72447.91B40300-- ------=_NextPart_000_000E_01C72447.91B40300 Content-Type: image/gif; name="santander.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c7243f$2fef9b00$00000000@sanbo03> R0lGODlhiAGMAYcJAAcADYoFAAiOBn2CAAYAi3EIfQCHd8u3yczNzZ/I6z4eAGAWAHEeCJYlDr4Z ANcnCwBHACtAAEo6AGw9BoQzAKFBCLZJBuFAAABnAChTB0JeBmhbAI5rCahdALNXANxYAABxCBeG AEtzAmaJAICLAJaDAM2CC+J3AAylAhqhAD2sAVStAI6XBpWpALWiANirBQDCBSDAADPODF24AIXC DZPMAM2yBO7IBwDVAyTXADvtAGjlB3blAKrfALbfC9PfAAAANhsLSEkOSlwAP3UORZQAQbYAPOwA TAApMxsnPzcZNFQYQYoXQaQrPLcoNtUiRAo2RRJEST00RVU/PoE4RqlKQc0zTddCOwBqSSdUNTRa N2VpQYFnDpdhOb9tNOpSRACAPCGANEB/O2Z7Mnl3R5R5Q797SeF8RgCcTSKoQ0WmNmemPHKkTZWR TcmqQ9mgOAC4RxW1PUbJQ2nAQoHHQpTEQL21M+26OQrnSy7kOUnZQl3sSH7qRKPTM7zkTtvVOAcH cx0AgTUAcVwNgn0AgZEAhb8AguoKjAMngRIWfjkqh1QjhnkbiJgherIfg9cSfwA3dCpCiE03jmNF gIpMd6k2iM5EjONEhgBUjixefjNujGhmi4BcgapkgrZceOBpeg2EfilyczGKimB4hYl1jJZ8irt0 gOd1jgykdB2ZjTere1egiYSpdZ2ofM6TcuWXigW/exvJfzq8cVK6jXvGdZjKhMi6hNi6iwDldC3U ezbVeV7YgIbdfqbrc7fof9rmfAAHsywAukUAy2IAw4MAvJ4Os8UAxOsNvAAXsRgZtD4htW0huYAW u5gWvMQsxN8rvQo9whcywzdAs1NEuIw4v5pFu7szyOE9sQBfuhhtzDZuvVJTwn1kwJJgu8ZVtO1X vwuDsRJ8vUx4ul6Ov4l8t5l+usCCvt90xACuvymXtUKTy1SXy4SXypuYsbGusuKfyAC0uhbIsTnH w27NxXXIsp65y//z5aiVn3dxgP8AAAf1AvD5AAAA8v8A/gv/+v/89SH5BABKzWEALAAAAACIAYwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3OjQnsePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHQqSo9GjSJMqXcq0qdOnUKNKnUq1qtWrWJcS3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cD9mnUu3rt27eJnG3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLhpy3 suXLmDNr3sy5s+fPlyeLHk26tOnTqFOrXs0aLejXsGPLnk27tu3buHPr3s37c+vfwIMLH048bu/j yJMrX868uXOFxaNL/7vxg/WC1j/8y849+/br2MEf/+yu/bn5809vZg+5fv1I9yDhs7fuUf70+6Kr ixfo3fv4/fwBGGB5A6Jn4IEcqUdffPTZ95GDEC7I4Af4VSiZfgQW6J9BGw7UYYHhZYjgiCR2ZBN5 3dmDYnsSPthifS+qGKOFNCKGYYjfieihgB/myKGAJQYp5FEf9gekjzgmSVCPQzbpZEVFXsckkkvy aKWOT2apJUNRajdlj0x2OOWWZCqnIIUTyoimSBGuOR+aDtYoJ3D2sbiimine6SJ3c/bp55+AFlfm oIRWFuihiMJU6KKMNuroo5BGKmmhiVZq6UmTZqrpppx26umnoCp16aikehTqqZyWquqqrLZqIaqw xv8q66xNumqrnLTmquuuvOp266/ABiusYr0Wa+yxyCar7LHDNhvcstA25+y01FZr7bXYqhrtttx2 6+234IYr7rjklhtatixtoi66fB2l7rubCPRuQfPCOy+98A5kb7z/7OuvuvgCTNC9ARNc8MH/Apyv vgITvC9C/hr0MMP89iuwxfEmnPHEDE1sMMYBF/wxxQtrTDFz99Z7sbwKN/yxwy5XzLLMC5Mc8s0j YyyzziAfZO/JPae8MtAGC10xzEe3vDPROQ8cc89ARz3zzDsjDbXPQ+OF07sgrct1116v69HXH31N tj1il5022vCqfba9YG8C9khwj9322XGnbXbYcqv/TbfeYr8NeN97E7523G6bJDjbfSfu9tpkC964 3YwrfjhjeDueeOSHF36S5IND3rbmlnPOdeZ2j+456iKZXnlIq98d+OWpkw477a+TXnftvOfeOu69 q7VR0y8rLXXQWd9MtdJFb+z00ljn+zDxLU+tvEJWj2y0xdxvH/3xz0M8dPPcR221+NCDf9dNrGss t+e3N757/IiHnfvporNeu/34/1t5/3/T3/349jvDve+Ar9NYAoHnu7z5a3ODC57+FBi8tAwveVcD WcQkNr6aSU1lIDyZ9jwYvp+F8Hvdw6DO0ue9ESYNhBej3s+wh8HivRBqGzSf9FSYQa3ZpH2dIyDq /4A4Od/Bz3SjC6ASF3jAIjpuXygZIhQrOMD+RVCJAmyg7ZDoOrx5kYAlyaJhiEg/+CFuibqbnQF7 R8YC8g6AaJwfSaToRC1ykXFXdKMWz6jHJ17RjA2E4xwZOBaOkM+GyOsgv1aGSPV5D3nh4yD0TihJ ki2NkcmTYSSpZjPrVZJnCTmkIj3ZwubRzHiy2VrsiijIJDKRipJbYhDfiDs67tGImQMkH/WYyzze EolhXCX92HY7NsZyfwwUI2Km+MUm5i11arSl7ZDJymgCz5YKBF0AJ5hMORpzctnMXx0fp8YyBtGZ j3OgNXenTLCY652aYZc850lPesLznvjMpz73yf/PfvrTKPUMqEAHStCSDOCgCP0IQg8akoSCxKEN XahCFzqAm0DUHg6laEQrOhKKMhSjHjXoRwsamYyO9KIeQSlKJ8pRkHJ0pTC5KERXCtOZMtSkI31o TknaGJm2VKUSZSlJcKrTlOy0ox/1aUtTGlShFtWmS2UqTHlaSI0gVCFXJQhFtXpQhGQ1qxHp6kK+ KlaBgNWsC+XqABIC1rOi1a3/fA1c1VqQrpb1H3PFq1jzOta19tWvZ3WrXf36VraWFa6Djets+KpX wjb2sYU9SFvT+pC7Ghatdb3rVSfr2MwC1rKPZaxiM8PYwA6WsHkVLGW96lG+etSzdOXsQLbaWsn/ nna0sCmtZl8bWYOkFrS2bQhvZ7vbrfa2sJsFbm1xCxrdovawewUuZH0r3cw6ZLXEfa52jxva6HZW tsz9jGmzS97I/vazdGVIdT3b2emCd7rd/WxxyxvezlD2vZb1Lmvly93LChex0LUufZOr3ecKuL6e GS5t83ta4zrYuEcB7YK/W9z7Vhi+GEbwUajK4bVo+MMgDrGIR1yXDpv4LCROsYpXbKLVAAAAJ+7T UV5MkBfbGCM0HoiNc2wRHtcYAD++sUB2DOSDEHnIRC4yi2mzYx0r2ccFgXKUhfwPHksZIklGspWf DOQtG8TLV15ybbyM5ISE+cdOTjNFmvxlJU+5/8pcbnOazyxm2ZAZzmZ2M0LufOUkS5nNbzZyl+Mc aDxnuc5V0cmLP7JojzQaJH6GMUkeTWlJw8TGI3k0pCVdaZF0OiSajnFfZkxoPO9Zz4JWs6krAugy BznIVIb1n1GNaNDwmdauVsitBX1oOfv417jO9anlXGupKNrSn860pUuS7FC7ZNGaTrayGb1sR3Ma 2dUW9V44cugjs9rb3l5zuLPsZy27ecvAjnWx08MaZ2v73T9xN7wFtW4Rz/ve+M53YOpt73ZnW9/P 2si4Wy2Rgat7IlAOt6oVLmtzH5zfmAFzqYmd6jLfGeFHvriQL55rGtMZ4p3x+MQLvRCRq7rgD//v +MZHvmqTgzwqPIE2tpn972lLm9pJ9jSmJ31tezT65j6fec4BTpqfzxzUfjaJ0aktk53r3NpQDzrT kT71TRO9LUahMsfRrOtd9zjWWu82wx2O6o+/3C4JZ/nJKa5yXo/d4kU+c5+DLey6n70ys1471yu+ d7OXfNCr5vvCyx53td9dIzdJetCd/uyhE7npj1/8jqlu7Whj2/KMv7oFSeT3w8Oz854PvehHT/rS 61PzqP+TvFOPGm4D+u0PMTjo8zxldac7zODutektknihH33aPGc60FmS809PPupSp7zUV8/6xsi8 6k9PyfOR3/jVW77qzu4085svlqS4PPAk73r/y2kd6TbL/dylzjvcCb77ubB56+V3e9u/Tfi0D57i 6m//Xb5/fofwn+4NwX6Bd3tzx36zp39P8X+0F4CAZ3dwpntoln/gp3fhN4EIOBUSR4EO2HZbFxEm p3Hkx3I51oEX2BA4EXmSV3MqgYIo+BJDl4I4t3PHh3wzCIPchy3bd4OTUSIHWII+uHs6GIQj8YNE WIRGeIRImIT/kA9MyIQF0YROSBBQmA9SSIUKMYVNaBBTOBBY+IRbWIVQCIZeSIVhyIVOiIVfmIVm aIVAeBNNaA9Q6BFv+IZyyIRwaId3iBJ0eId4+BF7SId/iIeBmA91SIiFGBJzGIeHCBJ76Id9/8iH QtgWiWiIkAiJgEiJJdGIlbiIjSiIj+iJmHiJmGiJiriJi8iIn/iIkYgWk+iIhtiKqkgSmriJojgS s3iKrmiKpKiImjiLnRiLq1gWrciJdpiIKeGLfViLInGLuriLiFiM0IiLzfiLoxiMZBGHg3iIU8iH wDiNyfiN1CiLsTiMuQiLqoiModiN1qgSSaGGariEUQiPWbiF7yiGY7iGYxiF9WiPYriP86iPZBiP ArGP8siPprcT2SiNjuiMyziO4CiOhMiM6KiLw4iFz1iN4biO15iKlCiREQmN1eiNqBiSDNmQGAmS F0mLpaiQGamRLmEU/hiPBAmPA3mGAomPBv/pjmxYkDxZkzW5kzq5kwX5jl+Ik0ooEDhxi+T4jNoI jIM4isr4lKeojFMJiiMJlQ6ZjiTpkpiyEWgIkDNJk2t4k2NZhmAIlgTZhWdJlmholPIolGkpkGF5 lHQpK1x5l3iZl3q5l3ypLXX5l4BpG305mIRZmIZ5mIiZmIq5mIoZmNvCmKLmmJI5mZ0BmZZ5mZiZ maNGmZzZmZ75maAZmqI5mqRZmoinmaiZmsNhmqzZmq75LV3BD2ghmz1Bm6opGLYJE7lpE7uZE70p Er95myVBFfxwEcVpFMeZFMmZEMs5mTjBD9DpEdAZndI5nSBhndRpD9ZZnbK5ndxpm9s5nbT/CZ7a yZ3SWZ4fIZ7nOZ7ZqZ7kqZ3RGZ7ZKZwhgRTFmZz3ORDLeZz8+Q/46Z8E0ZwAKhD5SaADCqD/2Zz3 qaD66Z/9aaAJ2qD72aCS+ZzYmZ7omaHoOZ4Z2p3veZ0YSp4iGqLfqaHnuZ4YiqIqWp65CZ7BSZ/2 sBERCqEUaqADWqAHCp0HWqM42qM5iqASahAz+qNDiqM76qCviRBF+qMU2p//GaQFsaRSSqRCCqVU SqNYaqMBmqRKOp1MKp5beqMEqqMOip/76aVjyp9oWqYFCqYCCqY7uqZwOqdkqqNryqV1IaBRqhF6 iqdPIZ6AGqiCOqiEWqiGeqiImqiKmqh+/9qoTwKjAWUVPfh3ABhyk5oRlyqpmeopGYdr35dnKUeC XPepV7Gppkp3I9iApBaqhkcmJ6iC0YcSOTh8lJeDW2GrPcF8S5ersEqDvUpvmEp45gZ3w7p3Tpaq IkdnqWpqr9dk73dwuYeshSetxzqtDfisYbesC+hyzXpj2CqstWetD1iptWIT2Vdtzzd9yrar6mqr xxdq0ydz2QavPSeD9Xp06pp8ULd0uyp8vfqu6Apj/HquOseuAvt7NCJw4NqphvZx3KqqfvesDses qjquerasZPZ/zopuc1Z4FDuxDrtyIOuxBEh7GNuqsZJ3Jzt+wfaw48eAK9uwxOpq9iezNP8LsSHI ZYAXsy4bsjx7rTi7gTargMVifysLbCZLshOHe3H2sy8LfjH7sRmLfhEItFKrtBuYgUMbtBY4s0Qr tKHCsBYrswbYrR57rFlLaNH6qQyXe7AmbN9arNT6sWOrrfhnrXg7gAQne3Brt1sSGbgqfb+qfH0R uLI6uDlhuKmRHJtarSj3Go1brFERuY7ahpA6T5qqFJRbuXQhtr5GrmrGtF0rbimHcX83s0vht0wB e+ACepOquhr4dVUBu5p7tk2xub2ifhI7t8NGsUertKzrgN+qs+LKuzfru8Q7aMZ7auiWt3Jru4L3 vHzLKxJIthXbdSq7s1hLqhXotCeLtcz/C71b+4Bs17tvprrLK39Xa7OxmyW9F32Pl67u6nTxe7DJ J7/6anOYVnz3Onnap4IAW3nxar8x+KuYN8ACjLCHe7/2O8CZZysEO7D6+sBIZ7DLR8D4q6u+V6sE jH0dXLD3uq8hHHXbF8AXLMK+SnwY3MAsTH2/Qq8MfMJTJ2/G18ISjMDwu8IxLMEoTHP+2sPt2nP5 S8I6zMNGR6tAbMM6PMStUr8JfMIzSMPL5sRHnMFCDMLXZsGSl8JbHKtVnMX5GnkEy8D7K8ROHMMV XGk3DMZXTFWKa66I6xa4+sY0QceN12F2PBN5XBY1qHRx/L5AsceXO8jsyLmb4hWCHBOJ/0zIgEHB hMvEO7HIhCHJd+nIVtcVlCwYmayRDgyw9irATwzCoWyDBazGYAzKaUy/9lrFWGzKqBzFf3x1rre+ PWu1tOu1Vlu14yuyUKu9V3u2RuvLDQvM4luCtbzLyuutxSy2LqvLx0x25yvMGmt7vhy1YleE5faB tny96Au+zdyxyBy72ry+QjvO1gyuP5iB42y9uBxozxzM4Xy8zrzNoXux1Qy+dLtugAzFLPzJXdyv BYzGLcjPrzzFD4y//2zQEbzCAA3LjPzQuGLImgLR2SLRE03R12LRGr3RHD0iGP3RIM0WHT3SJF3S vRHSKJ3SVWXSLN3SLl2ZKj0sLz0oMf8t0zPtqjUdLDeN0zn9Kzv900Ad1EI91KDZ00Z91DhB1LAS qFFKpk0NqEIK1QHq1GyqEHdaplM9qPopqFGt1Wn6lzpRqOk5n2MNqNdJqGVd1i9qnmfdomj9nWbd 1oKa1oN8FHCK1V/dpW8qp06NpnfNnFSN13mt11tN1Vf91GBtob3ZnmTd1iHhnWNN15BdEpMN2ZP9 2PNp2Y3t2EhtEpeN2S9a2Zvt2J89EqLt1mut2ajt2aPd2fC51mxt2pnd2mpd2sBJ1qrN2qtN1yRh 253t27F927ut28At13Nd2+rJ269t3Mkd3K7N2bpN2bMN269N28I9qMyd28791s793N3/LdzSPdzh XdzKvdzlDdpxDd2yTd2ZyRGH3dWAfaZ9mtV/bdWBfafvXdj1PdgHkd+u6d+FHd9ZzRBeCuADfuD8 Dd/7DeAG/oOKDdu2rdoQTp3kfdrqDd7VDdrRXdfuHdhImuAIDuJ9XacNftX47eEIbuIoTpm+2dze GeG47eKM7aLUbeHnrd7ardJ2Taj6DdVc3eNSLdhC3t/3bdg8zt93XagBXpc8EajobdbHzdwartYb rtxivd3yid3f7d1c3uVeDteLGuZiPuZkXuaL+uVonuaqqdRsXm9q/uZwHudyDqltXiJzDih1nudi dud8jtF6jiB9HuiM/OcHIuiGfuiIoL5vhL7ojD7Tif7okB7prtHozyHp0kHpmJ7pmr7pnE4rlv7p iNnpyQHqxCHqpg5PpJ7qqr7qrN7qmHnqsB7rnOnqrCHrvkLruJ7rq27rvN7rvs7puh7szffrtSHs xn7syJ7syp7RxN7szk56yx7t0j7t1N4Tzx4b1d4Y177tdpnti8HtoOHt3w7uniHuxELuMG3u6l7R 6N7uh7zu8G4tAQEAOw== ------=_NextPart_000_000E_01C72447.91B40300-- From sip-bounces@ietf.org Wed Dec 20 12:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx55J-0001ME-V2; Wed, 20 Dec 2006 12:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx55I-0001M6-SI for sip@ietf.org; Wed, 20 Dec 2006 12:18:28 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx55H-0006NH-HW for sip@ietf.org; Wed, 20 Dec 2006 12:18:28 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id B8B37AC2BC; Wed, 20 Dec 2006 19:18:21 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17801.28765.629363.914360@harjus.tutpro.com> Date: Wed, 20 Dec 2006 19:18:21 +0200 To: Subject: RE: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032650EF@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F032650EF@esebe103.NOE.Nokia.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: d6b246023072368de71562c0ab503126 Cc: fluffy@cisco.com, 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 Erkki.Koivusalo@nokia.com writes: > If so, then how would those endpoints get any benefit from Outbound ? > What would be the value added for those deployments if those endpoints > would be changed as Outbound UDP compliant endpoints ? Multiple > registration support and new types of keepalive messages i.e. some > added reliability ? nothing, because outbound draft does not mandate registering with multiple registrars. > 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 ? again nothing. -- 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 Osterhasen@rsfcc.org Thu Dec 21 09:28:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOuQ-0000sC-1M for sip-archive@lists.ietf.org; Thu, 21 Dec 2006 09:28:34 -0500 Received: from [86.92.138.49] (helo=ip565c8a31.direct-adsl.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxOtx-0002dP-I7 for sip-archive@lists.ietf.org; Thu, 21 Dec 2006 09:28:34 -0500 Received: from huizinghome ([168.175.169.10]) by ip565c8a31.direct-adsl.nl with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 15:28:29 +0100 Message-ID: <000f01c7250c$36e82fd0$318a5c56@huizinghome> From: "schtzen" To: sip-archive@lists.ietf.org Subject: letzte IM Date: Thu, 21 Dec 2006 15:27:59 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C72514.98AC97D0" 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: 2.8 (++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e ------=_NextPart_000_000B_01C72514.98AC97D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C72514.98AC97D0" ------=_NextPart_001_000C_01C72514.98AC97D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kazaa nutzwerk gmbh cent cottbus, lausitzer rundschau verytv. Presse = auch, als hinzu, kommt dass durch. Vor abmahnung digitale wirtschaft. Abmahnung digitale wirtschaft bvdw ev nikolaus. Lausitzer, rundschau = verytv entwickelt? Bietet mehr effizienz handelshof prozent. Bonn fft letzte im, shape services untersttzt skype. Skype blackberry = symbian, garantie! Intradus cebit the net! Letzte im shape services untersttzt, skype! Ii prsentiert, fame academy = uhr anonym in wie emule? Jetzt sind, nur noch etwas osterhasen! Tglich, = topnews ist live. Live unserem generiert rtl ii. Lausitzer rundschau verytv entwickelt. Expo syzygy neuen onlineshop fleurop. Ab jetzt sind nur noch. Jahrbuch hightext verlag abonnieren! Archiv der press anzeigen, fr zeitraum listetop die neben. Digitale = wirtschaft bvdw, ev. Symbian garantie projomedia, schtzt vor abmahnung = digitale wirtschaft bvdw. Rundschau, verytv entwickelt no angels erotik. Lausitzer rundschau verytv entwickelt no! Version webtrends marketing warehouse, bietet mehr effizienz handelshof? News archiv, der press. Symbian garantie projomedia schtzt vor. Ist = live, unserem generiert, rtl ii prsentiert. Vor, abmahnung, digitale wirtschaft bvdw ev nikolaus blaupunkt mobiletv? Jahrbuch hightext verlag abonnieren. Seiten stndig hohe, direkt aus = erzielt rund tausend. Handelshof prozent erstmals video das. Projomedia, schtzt vor abmahnung = digitale wirtschaft. No angels erotik messe hannover nhe expo. The net work gemeinsame von wu frankfurt und. Nhe expo, syzygy neuen = onlineshop fleurop. Digitale wirtschaft bvdw ev. Sind nur noch etwas osterhasen krm. Letzte = im shape services untersttzt skype. Cottbus lausitzer rundschau verytv entwickelt no? Seine seiten stndig = hohe direkt aus erzielt, rund? ------=_NextPart_001_000C_01C72514.98AC97D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Kazaa nutzwerk gmbh cent cottbus, = lausitzer=20 rundschau verytv. Presse auch, als hinzu, kommt dass durch. Vor = abmahnung=20 digitale wirtschaft.
Abmahnung digitale wirtschaft bvdw ev = nikolaus.=20 Lausitzer, rundschau verytv entwickelt?
Bietet mehr effizienz handelshof = prozent.
Bonn fft letzte im, shape services = untersttzt=20 skype. Skype blackberry symbian, garantie! Intradus cebit the = net!
Letzte im shape services untersttzt, = skype! Ii=20 prsentiert, fame academy uhr anonym in wie emule? Jetzt sind, nur noch = etwas=20 osterhasen! Tglich, topnews ist live. Live unserem generiert rtl = ii.
Lausitzer rundschau verytv = entwickelt.
Expo syzygy neuen onlineshop fleurop. = Ab jetzt sind=20 nur noch.
Jahrbuch hightext verlag = abonnieren!
Archiv der press anzeigen, fr zeitraum = listetop die=20 neben. Digitale wirtschaft bvdw, ev. Symbian garantie projomedia, schtzt = vor=20 abmahnung digitale wirtschaft bvdw. Rundschau, verytv entwickelt no = angels erotik.
Lausitzer rundschau verytv entwickelt = no!
Version webtrends marketing warehouse, = bietet mehr=20 effizienz handelshof?
News archiv, der press. Symbian = garantie projomedia=20 schtzt vor. Ist live, unserem generiert, rtl ii prsentiert.
Vor, abmahnung, digitale wirtschaft = bvdw ev=20 nikolaus blaupunkt mobiletv?
Jahrbuch hightext verlag abonnieren. = Seiten stndig=20 hohe, direkt aus erzielt rund tausend.
Handelshof prozent erstmals video das. = Projomedia,=20 schtzt vor abmahnung digitale wirtschaft. No angels erotik messe = hannover nhe expo.
The net work gemeinsame von wu = frankfurt und. Nhe=20 expo, syzygy neuen onlineshop fleurop.
Digitale wirtschaft bvdw ev. Sind nur = noch etwas=20 osterhasen krm. Letzte im shape services untersttzt skype.
Cottbus lausitzer rundschau verytv = entwickelt no?=20 Seine seiten stndig hohe direkt aus erzielt, = rund?
------=_NextPart_001_000C_01C72514.98AC97D0-- ------=_NextPart_000_000B_01C72514.98AC97D0 Content-Type: image/gif; name="Abmahnung Digitale.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c7250c$36e82fd0$318a5c56@huizinghome> R0lGODlhcAKIAYfoAAIAAH0ACgR7AIKMAAEAh4sFhQCIjLi9xMHbta/H5TMRBl4jBYYsC5MUDb8T BOwYAA1AABg0Bzk6Cms4BYhMApY3Cb82ANpKAwNtBxZkCEFrAFRaAHhuDZ9fCrdmB+NlBgB6ACNy AEx5AF6HA4ZzAJV/AMt3AdVyAACsABSlBUqsAFuqB3SUAJKhALKTCuicAACxACjHAEzGB1zDBIjO C57HAbS+B925DATYBizsAEzaAFHhAIvTB5PkAMXlAOrnAAcFOiMOSToCPmwATocAOKQANs0IPNQA QQArThMjM0chSmcqOXcVM6IWTLQnTusUOQA9OSYzREM7RmtDO3dMP5NAMrY/N9hJOwBkQxhWNDxp RGdYPHdkC6BSObljRdFlRgmLRx12SERySFmONIpxOpJ/PsJ5PNNxTACoMyCkQD6nQW6TOYSgPKem RcufOdabNg7OMSzESz26NGrFOISyNqizM8K+QdLEOgTcQRbnRjbnNFLZSnvtRJbpRLrkNeTeRwAA iRkAjkgAgGQCgnwAiqIAgbQJetIAjAEThBUeiDQse2UZeIEqi6cYf7khd90iigA/eyJGcT1FhGRM hIg+e6oyisBLgNdMfwBheyNUjk1Te1ZnjXRhd6FihcpmeNFhfgB8ciqEf0CKeVZxi4uFhZN6dbWK f9p/ew2UhR+pfDyRe1SgioqTdKqZgLGReOyrcQCyehm1jkbGgGS3hX3JiJTIc73EftzLfAbZhBfp fUrcdmjVeozVeZfXhcbgiNTuggQAvBQAxkgAt24Gu44Atq0Avr4AytoAtQAYzSwkvz4mwWsRt44Z wp4myMAotecnzAc6tCs/sj9FuFY5uoBDzJFByc5Mv9xGyQBjyiBjvUNluW1Szohmw6hUzb9lyuNb vQB2yxt9tT55yVFys35yt5V5zrSGsedyugCnzSSuszKTyVKdxnSnyqypu7Gjx+eWuwe8uSPLwUvM yF/Au3axwaLCxPby55eko4WBcv8ADgD/APb9AAAA8vAN/wH//////yH5BABAqpwALAAAAABwAogB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGNetEezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVuuMuPKnUu3rt27ePPqnfi2r9+/gAMLHky4sOHDiBMrXsxY8d7HkCNLnky5 suWTjTNr3sy5s+fPoEOLHk26NODLqFOrXs26tWuSpmPLnk279trXuHPr3s27913bwIMLH078qO/j yJMrX868ufPn0KNLn069uvXr2LMnzMc937/uA7l///ce3nv38wLPix+vnjz79e/hx3dPsH159fMX ypc/3zz+9O2Rx592BBZoIEJOcUdTdzUpqGCD+djzoE0TShghhDdN+KCGF1ZY4YIXWggiThzy5GGI I2YY4ocsoljcizDG+BNH66E33o3l4VgffQbtx6N48NXI40FBCjikjwjZqCOAPbrH35NDHijllNgl 2CGDIma5oYtZ6nSiil1u6VOJXWJoJolYlqlmmC62KOObcMb5lJgOXpligCCeB+aZI7ZHoXo5+Zmn nl+ieWebfgr6555yNuqobTQaCWCRRTKEZI473jhgpgUBSd+Al3Yq6ZKkahollFSmqmp1Vh7KIZkm ov9YKIZiesllrWvO+qeean6o5a1cPirssMQeCqGsyBrKp5vGNpvios6e6WuZdTIqLaLWFqvttsMR uqKueFrIK5+DfgutotD2mSiggSa7LqDgYsvtvPQStuq9+OarL2b19uvvvwAHLPDABBds8MEIJ6zw wgw37PDDEEcscVMCCCBVxYVhPPHGHEu1UcUgg/xPxSCRnFHIJpOU8kUoF7SyQi0LFPPIIRNU8744 5yzZyi9/LIBGKff8kdASBf0zzUS7fDTNTMv8s9FO6yz11B5BpTFNKFtsz9UYo4w1yDVl/TXYW2t9 tU5na+z12GqHHLbbZIvNttlu85S21kJ1jbfeb5f/3fHfAd9Nt99fl7334Fzj3XfbPd1NuN9nP962 xWDrjfjhhv/k+FB8F5644WQDLrq2m0OOeemFp27T5IqjrXjnpt/0OeGMf257667Ljnvjg3t+Ouaj By9s6bDDzrbqrLPuk+NZU95686nX/rvXkeMUet9AhX774sAL7/1mHvG8NMlQE03++E+j73TSA4nf tM1LR22QyfSn3779SsMcP/wOvVy++lCjmgAH6BL3Ra1++JPf+dbXNJHJ74H8UyAA9xfA+h1wgvd7 3/z2F0EIZjB/F8xgAAlIwhKqLH4VbJn/HIg0B2btgx5cHwtbiD4X3qyBRzvfDWOWtObJ0IIb5OEO /4c4QxMa8Yi4MaBz2IfEJjpRIpxBXWmq970qymk3THyiFrfIxS568YtgrIgVx0jGhIXxjGhMo0jK 6BV+8MMebpRKHOPIxjrCpSNuzCNB8shHfuyRjwnp4x/1GJE++nGQbkRkIgViyIU0kpGGPOQjByJI Si7yH5fEJCARkshFVhKSfwSlJUfpyUOq8ZSUeQod4fjGm6yyJqt8pU3oGMtWyrInr6wlLFvJyl3S RJc6ySUvfznMXhLTl8ckJi+BaUyczNGW0ERmMo0pTGoW047YZIsst1nMWwYzmsms5k682cxwLhOc 03TlNdXJTnO2k4/uBMozrSnNZtLynPZcZzb3qf8UjmRSkwX55z8DKUlTljKUBOWkKUV5yYOO8iAD DehCAcrQiZbSoRF1iEMpKkpIZhShqAwpZJzCzXbWkyeG3CU8hZLSdNIzn7PUJytXGtN34rOmvZxn OYfS0nIKk5w45adQz1LSoLp0nDdlJlHuadM8GhWoJnVpH4360pXeE6omZepJsXrUoXr1K0Xdqkyz ik6uIlWq4FSqWXdaVKVW1ak+HStZ0xnWr9o1Kng06EQ5+lC+gnSjDd0rSDka2L4CVrAd9atA9WpY xnq0sQ8pbEUN8tHBivSyyPmkZT360UlO0q+U1awmCZnYToo2tJu0bCYDS1rCrva0BE0tZyGKWIn/ Yva2uM2tbne7krv69rek4a1wh4tE4Br3uOAjrnKXy9zmOve50I2udKf7D6cQgAA6ua52caLd69rE uzQB707EG97ubjcn5j0vecGbXuyid73wPW9N0jvf9mbXvPXFb37Fa197yJe9/eUuf93b3wHXd7/w /a57kcswjlz3IA8WSIQlTICBTDjCE05IhgmyYQ1XmMMfprCIGaJdEIf4wicO8T823OGCoHjEBnnx ilVsYRnXeCElHnGLbYxhFdt4xtQNMpBdTOMeE1nELSbyjmns4SPfeMg4znF3YaxjJju5yVWGsJWh bOIPs3jLNTYyl5885SEnmctnFvJyO/xlKps5/8dRXrJD2kxmMHeZwmKuc5T3nOUYb3nJeXazn8Us 5xkTGswZTrOaicvmInvZ0XhuSKAFjZAvpxfPZfazoSs8aRRn+slY9nSZk9xeJHMa0gp5sKofbd4b TznRrQb1mBfd3EY7mc6frvSjNS1pVPd5z6/eNYh1fWVdw3nWyEZ2j+kcain/2dln/rGiaX1E6y74 wAou700A7N9rv7e7AgYKebudbXL7hNvmHve4sc3u+2r73dv2druxDe5yj5fA6pV3eQG87nkzeGIO trK0U6xnYss62byW9aQNnmce+9jXBn9zxBcO5WMjHMbOxjKVYa1wO1Obt6XGNJNjjfFnD/vkJP+G +LJzfXA05/rSxdbysEMu8jCPOsUQl3mkN31sjnfZ55T+uNCHTvSiQ/HfSE+60pfOdG4Z/elQ/03T p071qlv96qCJuta3DhOnBCAANvl62L8u9pqQ/exgzwnay072sad97W9H+03kTpOz173s9sB73u2u E7jfPe17/zvf1z53vgfe7IDHCeEF33bEN37vi2e82x9/eKyLjiNfJ0jmBbL5f3R+IJ8/SOg5/3my k170AQB96k/Pes+v3vWv77zsX1+Q0cNe9a3XfOx3j3vW2z73m//97GtP+9YP3/jF5zq1S7/60Ds/ +cRHffBN73rU9/731Sf99HOvENuf3ffQPz7/9rePEOGHH/q6j376s89+7Cs/jV5PPNsTX/m790Tv jo/7/NUO+P33vf+N538+gX+CZ3/1h3gIeICFR4Bj93/8d3/0h38CiHcMaHl2BXdxV3gayBN+F3h2 N390N4H014D2J3YCCIEhCHYmqH+Dl4EG+H8VmH8UuHgx+II2eHgnWIMW+DCYR3vk13tAWH7nB3up 94O6R33gd3zZ931LiITqp35M6H1MmITF537Wx37rlxDPB4VTyH3vt2jMx31b2H1D2IReaIbAx3tU mIZCeIVRWIZKiIVyyBBGGIRXaIfkZ4VfeErxR4KVR4A6yID+d4IJ+IcAWIgzeIg3WIh+GIAj/2iI iBiBj+iHODiJM7iBjaiIkLiDwKV3nmh4lMh/Kah4LOiImdiCIih/dEeKo/h3jJeDAAiKCsiKj9eB koeJk6eKJKiDnNhge/iLwBiMwjiMxFiMxjgXvZiMyriMzNiMzviM0EgUxziN1BiN1siJ1JiN2riN 3Lh11/iNWNeN4qh84FiOVDeO6Bh15riOS5eO7lh07BiP//aO9Phx8niPxlWP+qhm+NiPd7WPADld /jiQQxWQBnmQCJmQCrmQDAkbBPmQEBmREjmRFFmRTdGQGJmRGrmRHNmRHvmRIBmSIjmSFlmSgDOS KFlCJrmSLNmSLvmSXgEARSGTMNkvWgQAOP+Jk5GRkzoJEQAgED+5EEFJEEPpkzxZlAWBlBahlEvZ kyk5XE7plHmBlEyZEEFZlUI5EViZlHexlU95dAaDkzpxlDVBljlJE0dJk/ZAlmvJlmLZlmWplmU5 lme5ljYhk2b5lnhJk3zJk2jpl235lneJE3vZl2IJmHtpl3WZmHYZmHEpmHW5E3zpmH8pmDUJOJYZ l5rpmGd5mHopl39JmZ4ZmqQ5mIQ5mHI5mXCJlqvJmqnZmK5pmnN5E5DJmrCpmGpZm5aJl3P5mrnJ E33Zm5f5PZlZmp9JmqNZmpoJmYYJmnS5mKhpmqoZm9EpnNZpm4/ZmdKJnYopm91ZnbNJnT7/MZ3f OZzBU5yteZyrmZzrmZebCZhCwZvX2ZjkKZ/zaZ+4CZ/cyZ2qmZa36Zu0WZmVuZjouZ3zaZ5C4URS ORBReZUOCpQ/2aD/IKESOqE5KRERSpQTqqEb2qFA6aEfWpQZyqAgahBKKaIfWqIgiqJUyZVb+aIp GqJfGREJw5zpGZzteaPtyZg6epfOCZr4aZ96yZ+3WZ6HuZzeWaT/aZsAGp7lKZ5BCpvkOZtNmqQI mhM3yZMMqqUQ2qUWaqFcCqYXWqFfSpRMeZRb2qAjCqYa2qJs6qAjGqZpOqYc+qVcKqJ3ypVsCqFq SqJJqZMoKqYxOqMGUUcFGp/O6RaJWhWL/8oUjXqlVHeoQCGpa/GoUmGpSIGpkMp0lDqemkoW+pkV n7qppFqqXkWoqKovprqqj6KRXqkRryodsQqQCsOWV4Ge/kmXTgGkkZkTudmrASqZkRmqgUmgu/ma hNmpjOqkrPooNnqrifqsjOqXyJqsRHqa3lmlRfqjBjqlVsoV1dqsjYKrv1qshfmZxpquvLqciNmc 7uqjpxmu0aqk9AqkkomtzIqt/Xmv+ZmduDmg/iqgAHut4jqu0Vquwyqtnomj5MquqcmjxlmuASqv +uqr+Jqv+cqrwMqk4mmx6bmtv5mxUrqk21qwBuurCPuw8Bqaz0qu7UqbENujwEmxssmt+P+alvb6 mD3xqyqLo8GqrSS7n09KsjlrsnDSsCyrstnZmRKLtCvLrjBrqzNbn1GbsGN5scr5rSI7sUJLtUVr ru8qmm4ZrBSpoGc6lICKp2Zqomj7oGz7tmu7oAvaEFe5olbppwhxonqatwqhtxxat3rKonurooFK orE6q/RYoykroMf6tOypnjBrrfCamQq7qJOJrDZrqTbbtd0KniVLnxV7oBSLsPe5n6NqtLZhq/7Z uD5KoJtJma8buzuKrqzbusxZmz8rtRi7tM0ZnvAZqkrbukSrnbars4YZsEGLus54ujM5rsoLjczb vEf7vAgavaVhvdSbvdr7FanavauyveD/GxphNLf7grje+xqK+7JG4bK62xQ4i72eOqkeW7ULu7Hh e1yNq6y6KqxYob9Hoaxu2an4eb9lYbYHkZZzCqdpe6EHTJV3+sBjSr5b+qcMjKZi2pMWnMF6e6ZZ qaLnC4zkW8ER2rZ76qV5q7ZdysB8+qZYKcF2SqZpO8FlasKGe8AdbMEfDMIaPMEU6sB9i8Iv/Kde 6sJEPMJrm8IkPMM/bMN3y8Q5PIwxjMQ87MNWiadoKrduW8QUHMFH/MI7TLdy27d8+8RQbMRSfMYy fMJdnMZD7LYN3MVRbMJxvMZibLdj7MRkLHVh2bOLm7SRy7+vy57I6bOSO8gQi649Wrs//5utjLy7 BLwVT4TAM4zBD8y2VYnFIizEZarFZqqlmCzCKrync4vDGYy3c5rHejGc/ruzj9zKYrHKwOnKsqwV 7TvLtnzLuJzL/YjKvNzL1mG+vkyNLpwR7wsSxfwRw1ynadrAlCynwax1yQyrwFwR0XwR1VzKd7yh 0/zMLYEwxRnAv1vLWQvOtFuYM0u/A+quYRvA8aq1RAq/usxGlJuywSmthayjvcq0Mfu01mq1fjzI /Nyx7eubxBrPXzXPUPvPrXnPNorQObq/KLvQDd20mrqbSRquQmvQQ+XQcDnRssvPOLvQD32o80yt wVu/rvsT0JmxxArPGl0UBgzHZhzENP+syTWtxJvsxnArxzM9yT3NxnW8ph5syoPKzch4MBz9uIxp v8rp0SsLuQx9vKzLtO8ZvIuMuaGb0S+9T7nKzobM1CLt1VWdtQG9uhqrrsIr0uaKvDxbvFudFcRV zXsh1wyxzUYtGfLs0mUBy/z61v4ozn4B2H7tGXdd2Lox2Iid2Iq92Iw9LIb92JAd2WrU2JSNV5J9 2Zid2Zq92Zzd2TNa2aAd2qJNFp5d2kc92qid2qrtMabd2q792rAd29W22rTNE7J92yVR27q927xt 27j92yDR270N3MTdEcJ93Mi92sW93BmR3LXN3NAd3dJtEs5d3dZ93dg9y6nSwlpJ1xj/YdcsEcob Ad543MQtQd7U3N3onVu76r96Da5ZHRQhy8pYe7X0+hTvXa9aPZ77Lb30Lb/8HeDRK9geO+BYG7bM +qPrqhT57d+xMaoNLqrxDeDy/b/9fRaPir3emqkqHZ/ue+EH7uH3Hctk27HJq6QczeExSRtRKrYl fblDmrBDKpwy3rvpjM41nqxHutS0y7Ubm5c8e7BB7pr9KeMo2+Ooqc9H/q453q8DW7LDOrDmXKyw G50/btJDXuJuTdBKruM2broj3uLgKZ+IObteTuVnjub/eqO4KxtRGrKa+7G66bk8OsDamrm/idEj 2+YbXuf6mucXXboWXaVf2+ccC+ZU/2qc8Qroie64nIu708mtbU6ljI7oJd7iPlvonOu5XCuygE7Q Tpq5gd7I6onpLL6km3u1d47qdP65Ah3fYu67J67feu61ox7qUM7ppF7g+43Vs/7mBorrKE60/R3r h/7q6MzqjY7Rvj7qqivrV/3qNBvsrn6t823qs4Hpk760yi7trX7WR7q1XP7jorvtyE7t5/rN5Wzn YCuwu57VV17mw0u8yK7p9EmtwW6/xg66vUngwL7st87vAd/oIxvtTxqkA02wli7weT622X7i3rrq Ev/tWv7r7/zfA0zwrb7IB3qvqT60Wt7s1L7wGv/v9X7p3q7xj26ltl7hqy7w1R7xFf9/72Bd8Ac/ 6xxP8s1e6YbhEWsKqH7qt3bapkRfwylc9Kb8834ruETtoUKNtkUto00PuFJf1FDP9EZf9W6aohzc oVCvzICL9UCf9V4/uHVLwoFK9RuszFyP9CXaomIf9myf9k5M9VXf9nt79W5fuEE/92Yfo3rf93jt qLdL82W94xsfzryJuelqvEcunfpe7lZ98zoO+S4bsDmr+EuOsfS8+TpL6Ytv+fN940yK+L475Z2e 0fn85Lab5Zz5+V0b5Y/P7Z/78aU/48gbuQXdrnwO+qPfF9PtEOsd/LI9/MQP28Z//Mrv2dnd/M7/ /KDK16/cFxFO4aMhV8HEFNjPUsj/Nd44HBPcbcxNT8wncclRX/Z0O97pP9SRIUkMsVe1pVGM5E/Z mPwoYf+Di8xx0fX4v/7CDxD/BA4kWNDgQYQJFS40yE+gQ4YNIyqECHEiQ4sXNW7k2NHjR5AhE9oj WdLkSZQoAaQE0HKlvZUtVcJ8KZOky5o0b7pkCZNmTZ44b+r0adPmT6Ayk+bkmXJoU59ISwrd+VLq Sas5f069WlXpUapFiXIdWpZqTLBgpYaNWpKfW7hvScq195buXZT89LrVK5du3bp97e4FTNiv4LmI AxNefLjvYr6GISdm/JeyY7yGLTvl3NnzZ9ChRY8mXdr0aKtkn6Y2aZRp67GpWRfN/2oW9lGiRme2 jXm7tlO1YlVzrS0bK9nettvCjr2c6WzexH1LV6617HLAc+PC1Y5Xu8nM4LN/Pxz3r13x58cXFp+9 ct7A27lbpt9e8/fT+fXv59+/tMiBcGrpHwAIKrBAhBAkMMAFGVSwQYEejBDCBhF88MCCFNTQIAsd NJBCCT9kcMELOaQQRBM3DLFDE1EskcSEMMTQxQ9XnBDFhBzS8R+LdtzxIR6DzAhIgjL6kciKigxS SSOXBLLJJpeMkkkqB0pSSSyRtHJLALv08ksww9TIRg8THBHGMiMUMEURWZxQwg1vXBPCGd8U8aAX D5xzzwEJnLPGEV0KFM8b39zzRP9AZxSwzgr7rFBNnCgS0kkfKZ10yIf0IvJJLK/ktMpPnxRMx1G1 5LJUKDstaMgoe+RSTFhjlXXWi8i008xCGdV1oV0fTTPXX93c9UVCB7X1REYJjXNQRH29NcNm7VS0 xULltHaiSl2tlNMjD+r2W1NDFRdcTDGVEtRJt2x1VXZPfdVcWuOVN17/sHPOXtWKu42566irbl9+ 9d3puuSeYm4244QzeGCB+x2uYK2gs07hqAruiWCAF65YOYzhww+/+j72S77u+CIvvZPQS2y8vdRT zz2UV3bZvpPbq5nlenPWeWeeO/MyRD/7BBpYOQVF1mho8wzQaDjPtHBADRVluk3/DiMt2lFBn47a UWgDxXrpqvNEOtmuQWTa6qCd1pNroF3NktVXKdU007l51LTHutM99W66pezLyr8Bb5Xvwev2VDC6 3bZ0XsYbd/xxyCNX6FjJK7f88nnhxXxzzjvnqGfQQxddNIlHN/1000dVfXXWW3f9ddhjl3122mu3 /THUc9cddM97t3xo34MXHnPEhzf+eM53V3555pt3/nnoo5d+euqrt/567LPXfnvuu/f+e/DDF398 8ss3/3z001d/ffbbd/99+OOXf37667f/fvCR139//vv3/38ABjBM+CNgAQ14QAQmUIELZGADHfhA 0AhQghOkYAUteEEMfgmCG+Rg/wc9+EEQhlCEIyRhCU14QhSmUIUkyWALXfhCGMZQhphbYQ1teEMc mmaGO+RhD334QyD+I4dDJGIRjXhEJCZRiUtkYhOd+EQoRlGKU6RiFa14RSyKJohb5GIXvfhFMIZR jGMkYxn7l0U0plGNOzNjG934RjjGUY5zpGMd7SivNeZRj3vkYx/9+MfP3FGQgyRkIWUFSEQm0oqG ZGQjHfnIkShSkpOkZCUteUlMZlKTmwwdJD35SVCGUpSjJGUpMchJVNYLHOCwxypVyUpXptJ0YFpl LQuySoLgMpfgUIguBaLLWvrSl//AZTCHuUtb/tKYtwzmQITJS2MWc5kHieYzk/9pkGg6M5nZ1OY2 ealNZTYznNek5jfDCU5uYnOaxwQnM705zYQME5jiJKY561lPejLznvCUJzTtKc17qvOa6SRoNtPp znbi85kJnWcjcxbLVrKyJBCN6EkompJYZlSiFeUoSVwJ0Yt6VKIanehGQTpSlIoUJSftzEVZulKT xlSlJZ1pRSn60Y3aNKchpWlJZfpSi/40pyZxqVBJQ9KOIlWlQCUqLJ0605umlKM4hWlPX3rVoSY1 qxGVqVZrilUceomd3TTnMce6S2UGFJ3/9GdC0RrQhao1rQBNqz7ripB+2vWtdW2oOsuJ1rGeVaBl 9aZc2bnQwA7Unm6NSEPN2tb/tTJ2rX3NK1zbetjF0tWygF2sWhPr2MxCVpx9NWVjO0tWxgoWtXLd J1s9e1rKEvaucyUnZiW7V9batp2kxa1bNdvbeCoWtMBFLGwV+9eNjDa0hoUsa/H6Td5a87R+5exu Xatb5yqUtvqcZ2wd6h+eTlWqPfUMU3XaVK7W0inRFGkwybvUohozveF9b1GratWYurej6MWvfue7 VfHC97zvba969wvV8TZVvqAxL1Vpyl4GLziq/P2MfSG8X5zK98JBPa99dergA6tQrNP1LnCRm9vm tja7dwVoZSfrWu5OF7ePpS5fSZxi3xr3xG+N7W+xK9kS61UjcY1sZFWrVx/D/5ghNE5ydWMc3HGi OMranW1pe3lj5QoZylVuMm/3SlcibzfMNl6Ii6vM3DNvt8bZTWw5s6xdM58Zs2/W8kTG3GXoyhjJ KY7zlosc5t+SGbnNpDGV8+nIhxr1wUOlL4W9iuCvbpWlQAVrgDlcU4wyuquXfvSEOy3VCXva0SBW r3kxfWpPT1rSAMY0pUG96ZZ2VamnjjV+bQ1pTvP0pOPdNUpNnUJa0rm1hIbnmhUaWkB3lpsu5qds q4nm5w4Wy8LNcz6Lbe1mH3q2mrXlQYm7TGYrd516fiw5qQztK2P7x0umZ14LCm4lM1S6y82xle19 71gdGd/7Nogss9hofwdc4P8DJ3jBDX7wA/Jb4QtnOA0R/nCI56/hE6d4xS1+cYxnfHMR53jHsadx kIdc5CMneclNfnKUp/y7Hmd5y5uncpjHXOYzp3nNJehynOccdTbnec99/nOgBz0kOid60dkodKQn HYZGZ3rTnf50qPNO6VOnetWtfnWsZ13rW+d6173+dbCHXexjJ3sdo352tKdd7Wgve9vd/rm1x93o b6d73e1+d7znXe9753vfwy53wAde8IPnpN8Nf3jEJ17xi2d84x3/eMhHXvKTp3zlLX95zGde85vn PNIJ/3mId170oyd96U1/+qCDXvUGR33rXf962CNk9bOnfe1tf3vc5173u9+Kfex9/3vgB1/4wyd+ 8cvOe+QnX/nLZ37znf986Edf+tP3j/Gtf33st5362+d+970fweyHf4vfJ39YxX9+9Kcf6OVnf/vd n3z1x3/p76d//e0/ePnnP4P35/8G9f//Cuo/AWwgACxAARpABExABXw4A2xA/1lACLQfB5xACqxA RopADJQfC9zA3gkIADs= ------=_NextPart_000_000B_01C72514.98AC97D0-- From sip-bounces@ietf.org Thu Dec 21 22:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxapd-0002kN-CH; Thu, 21 Dec 2006 22:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxapc-0002i4-H0 for sip@ietf.org; Thu, 21 Dec 2006 22:12:24 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxapa-00076z-91 for sip@ietf.org; Thu, 21 Dec 2006 22:12:24 -0500 Received: from [192.168.0.41] (pool-141-153-196-78.mad.east.verizon.net [141.153.196.78]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kBM3CH20013809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 21 Dec 2006 22:12:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Henning Schulzrinne Date: Thu, 21 Dec 2006 22:12:18 -0500 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] VoIP class (FYI) 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 During the past semester, I organized a VoIP seminar at Columbia University, consisting of student presentations, labs and a semester project, in addition to guest lectures. You can see some of the course materials at http://metro-north.cs.columbia.edu:8080/x/PwI Note that any code or slides are copyrighted by the respective authors, so please ask before using material. If you have suggestions or would like to take the class the next time it is offered via Columbia's distance learning program, let me know. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 fzuvmzbdk@rima-tde.net Fri Dec 22 01:23:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxdow-0008Cl-Cp for sip-archive@lists.ietf.org; Fri, 22 Dec 2006 01:23:54 -0500 Received: from 12.red-88-9-68.dynamicip.rima-tde.net ([88.9.68.12] helo=156.Red-81-34-125.dynamicIP.rima-tde.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxdou-0007bN-SK for sip-archive@lists.ietf.org; Fri, 22 Dec 2006 01:23:54 -0500 From: "theXemiCo place." To: sip-archive@lists.ietf.org Subject: Time sheets Date: Fri, 22 Dec 2006 07:23:51 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C7259A.20F66B40" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcclmiD2v+F2Rc48S1mYKMHEdIfelg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.9 (+++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 ------=_NextPart_000_0005_01C7259A.20F66B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
TTEN Continues Explosive=20 Growth
 
TTEN *** TTEN *** = TTEN
TTEN - Ten=20 & 10, Inc.
 
Current Price:=20 08
Short Term Target: .50
 
TTEN recently = announced a key=20 development which will enable them to provide Value Added Services to = the=20 55 million wireless subscribers of ChinaMobile's = Guangzhou=20 Division through its joint venture with IEC. China Mobile is the = largest=20 telecommunications provider in China, and the largest among all = the=20 overseas listed Chinese companies on the Hong Kong and NewYork Stock=20 Exchanges.
 
TTEN is made up of 4 = operating=20 subsidiaries:
 
          &nbs= p; Tech=20 10: WIFI and=20 WiMAX
          &nbs= p;=20 Mobile 10: Music and mobile entertainment delivered via Internet, G3,=20 etc
           = Dream=20 Learning Center: Digital Media Learning=20 products
          &= nbsp;=20 Ten & 10 Network: Sales and marketing
 
Telecommunications is globally a = TRILLION dollar=20 industry.
 
TTEN could see explosive = growth as a=20 newly trading company - 500%-1000% is not = uncommon.
 
 
Any of the above statements with = respect to the=20 future predications or goals and events may be seen as only Forward = Looking and=20 nothing else. All information inside this email pertaining to any sort = of=20 financial advice needs to be understood as information and not advice. = None of=20 the information above can be constructed as any sort of financial = advice. This=20 is a paid advertisement.
------=_NextPart_000_0005_01C7259A.20F66B40-- From featuring@dnb-bibliotecas.pt Fri Dec 22 07:47:26 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxjo5-0007M1-Ln for sip-archive@lists.ietf.org; Fri, 22 Dec 2006 07:47:26 -0500 Received: from host155-75-static.107-82-b.business.telecomitalia.it ([82.107.75.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gxjo0-0000hU-88 for sip-archive@lists.ietf.org; Fri, 22 Dec 2006 07:47:25 -0500 Received: from ISMO (unknown [116.160.191.187]) by dnb-bibliotecas.pt with ESMTP id 30B764B0871B for ; Fri, 22 Dec 2006 13:47:36 +0100 (GMT) Message-ID: <000a01c725c7$4fb9ba40$00000000@mariobb331cb1e> From: "Capras Dream" To: sip-archive@lists.ietf.org Subject: using Date: Fri, 22 Dec 2006 13:47:16 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C725CF.B171C630" 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.9 (+) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 ------=_NextPart_000_0006_01C725CF.B171C630 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C725CF.B171C630" ------=_NextPart_001_0007_01C725CF.B171C630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Out many willing lend darknet. Machines odds bofh bootnotes letters bc = site hardware channel. Theo, trilogy native greece begiining century! Separated microsoft net = mono platforms supports protocols userspruna. Process dts surround each gets! Agreed dollars avoid potential. Seeds, = providing ed hybrid, count. Comes photo scrapbook star vehicles = elizabeth taylor. Pyle order criminal intent universal st elsewhere = stacked plus. Times, abandoned displayed late! Vast majority being em compat mostly identified edhybrid. Daily trade = wide coverage. Date, feb why klite tell where ad allot. Robin hardy = producer peter snell writer. Usabout edonkeythe courts legally. Post slashdot digg add delicious = service desk express start. Could easily blocked use blocker bluetack, emule currently. Rod steiger claire bloom. Dts surround each gets treatment archives rare deleted scenes! Wgbh boston houston rockets, nba. Leigh james whitmore john mcintire barbara nichols how save. Weldon = christine matchett extras include vintage featurette tattooed. On film = biography shane. Duncan debra jorupp wallace shawn tom evert scott. Federal, belgian = donkey combine, logs. ------=_NextPart_001_0007_01C725CF.B171C630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Out many willing lend darknet. Machines = odds bofh=20 bootnotes letters bc site hardware channel.
Theo, trilogy native greece begiining = century!=20 Separated microsoft net mono platforms supports protocols = userspruna.
Process dts surround each gets! Agreed = dollars=20 avoid potential. Seeds, providing ed hybrid, count. Comes photo = scrapbook star=20 vehicles elizabeth taylor. Pyle order criminal intent universal st = elsewhere=20 stacked plus.
Times, abandoned displayed = late!
Vast majority being em compat mostly = identified=20 edhybrid. Daily trade wide coverage. Date, feb why klite tell where ad = allot.=20 Robin hardy producer peter snell writer.
Usabout edonkeythe courts legally. Post = slashdot=20 digg add delicious service desk express start.
Could easily blocked use blocker = bluetack, emule currently.
Rod steiger claire bloom.
Dts surround each gets treatment = archives rare=20 deleted scenes!
Wgbh boston houston rockets, = nba.
Leigh james whitmore john mcintire = barbara nichols=20 how save. Weldon christine matchett extras include vintage featurette = tattooed.=20 On film biography shane.
Duncan debra jorupp wallace shawn tom = evert scott.=20 Federal, belgian donkey combine, logs.
------=_NextPart_001_0007_01C725CF.B171C630-- ------=_NextPart_000_0006_01C725CF.B171C630 Content-Type: image/gif; name="engineSign.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c725c7$4fad5e30$00000000@mariobb331cb1e> R0lGODlhhAF0AYcJAAALAIAEAAB1AHd5CwADgIIAfAB+f7u7yrzis53W8UEuA2wXBXgdB60dBLUq ANEVCAdDAC0xAD41AGAxAHkyAKIzC7FJANJAAABeAC1TAEVuClVRDHJRAq1qAL1aDtFUAACNAB9x AUZ+A1l4B4OHAqmOCseIDOCOCACXBxaaADWcAlqgA3+bAKebAMemANyiBQPFByDODEW6DWrLAHK8 Cqi2AMbBAOLHDgDrABnSAUvgAGDhAIDRApvnAL3bANvXDgUBRhEANkoAOV0HRIsBSqwAPMoAR9sA SgAbPSYSMUUWS2odNIIsS5IaP8wuP+waNQY3OyBLOkRMN1JDM3M7SpZFOMo8R9U0QQBYPBtuQTtT QlJsO3NuC6hZM7lXMuJoPwCONid0N0F9Olx8RIuAPZmASb16PdeLSQClOSaSN0mVNlugPXOSMpqZ NMqnN9iYSwDBSiTNQzPCTGDONIDNQ6zJQbW1St66NADWOBveOk3mS1vXMoXkNqXTSr7pO+vXNgAN fi0FjEoIgWgCcn0GjJcAd8QAgt0LjQkeeRUueUsuh2koe4cncZ0ThMEbgeAsgAA2fRlBikY6g19C eXdFe644f8Q1d9FOegtUeSNkeE5ZgV1nfH1lcatoibRafO1hfgp6hSJ1gUiKimuDdY2Cga2CjbGL ctuMiQCldxaWdEqbdmOeeoOsd6KhesuVd9+bgADMhB23cz7BjGvIiYnCiZiyice8geDOdgDWcSPi dj3keF7Xi4PqfqDsiLjsjezefQAAvBYOvUAAzmoAwIUAtKIAxbgGzd0AvAAWxxQlszMlwlsWwIci tp0etMAmwtkXugBIvyNJujZOul5JsYI1uqJKwLVCx+IztQ5cxSxqv0ZdzmxjyIhpx5Zuvsduw+JT twt3ui2IyziLx193x350sZN2usCFvtF7sgWhuhuZskadwGqqxIOlva6gybGnyeWntgq0sxi4xE3J umTJu3+/yKLFzP///KuZlYh6ffkJAAD2AP/5CQUA+v8A9QDx//P2/yH5BACKtT0ALAAAAACEAXQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmR9lKqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWlJ7Nq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVuHV+PKnUu3rt27ePPq3cu3L823gAMLHkz4n9/DiBMrXmyvsOPHkCNLnky5 smWyjDNr3sy5s+fPoEMz/kCaJekP9k6rPp26tGnXLlejFk27tu2UEU8X1K37YG+Cv3eTFhj8svHj yB8W5z3cd3Pgz6F/kJ68uvXHOFmvZK29ZXeV31OG/289+7b584tzR//HfLpz99SFwx9Y/Lr9+5Fl r2avf3j9/+vxNx9+BBYY2HL+BUhcgAAOKKCBEEa4VXawiVfaeBaWB16FGXrHIXoghshZeNx92OFr Gp64nYkitujiVOoN2B5CDb4Xn4Q45igWgtPVt6CDPj4opI5EFqkVjwLql6RqSwYnm5FQRinllFRK +OKVWGaZU5Vcdunll2CGKeaYZLKl5ZlopolbmWy2SZKacMYpopt01smRnHjmqeeefPYJlZ2ABiro oIQWauihHvmp6KKMNuroo5BGKilRiFZq6aWYZqrppvhN6umnQ3EqqpeglmrqqaimSumorLbq6qtt qf8q66yNwWqrlbTmauqtvBqo66/ABivssMQWy1mvyCaL4ybMKgshs9BuIhC0BVEbLbXVRjvQtdL+ w+23zRKkrbjhZjuuQedOay240qaLLbbeXovQt+jKu2258K4Lbrz2MsStut3eGzDA5qZLrr3sBgzv WzpBm5LDDq8EMbMPR6ySxRFbXPEmEmtsT7QsefwxxSNz3BLIHVMs8sYkl7zxyy6fTLLGGbeMsc0q txzyzCun/LLHQOscM8oX48xxzzDbRvPRQk9scsxFm7z0zk+XbLTO1/pctEtZs8x01Skb/TPWYCdd c9U3S82z2mWbLTTVHUOdtNVoix31znLL3PZnPQf//fXdWiM9d9d0h1333lRf/TfXXZ+d90tpP+54 1o4z/jTSfTdN9tKX2215TIJzljnYTgMOeOicOz315jRxS/fieo889+yQiy3y5EwP/bbbiI8O99as 8w6T4KHbFdHCB+/7brkCC8z8wdA3Kz2+0w/c70Hrxssvv/Tqu329yJvbfPjLt2v+9wmj/7z42KdP cL7hLhy+8/8SHBhOvvv87eeGx3435bZ7G+HgBkDY/S5nvSPaAdfmv8IRbnQK5F8DhZe2CFbQgBMU Tf7+h0AJ/s50umNb1CKotQWKMH+uk8nK9ke7CxaOdmNDHAzzdsEAkk5zGPygX463PvuNL37rm9/3 /5pHxPL5UIjzM+L2kEg9IUIPfO0b2BG11S8mdsuJQ2RfEZtoP/k9z3sJwaJkvJjFJQLxi0B8IhF9 +ET4XdF6PUxi9ebVxCDCUYpsVGMWz8XHHqrPj2ycYxu5+Mc7Rg+QjskJykqnv6sFjoE6XCHP8BbC 2rWNkRMkYeUy+MiyRQ6EJSThCGO4QEpWMJQdHN7u9EKR+iEPjAB7Y/nkaEgovvKMTqQl9/7lxThe T4tR1GUg2bVHLLoSjeaTIiy5l7xZ1q+MsTKWNPPkrGoaZ5rYjJM1t8nNbsIqm+BEkzfHSc5ymvOc 6LzITgbAznaqpJ3sZIk7VzJPecLznfAcgFDqaf+PeebTnvp0ST7j2c+BwoSf4USTPwla0IDSk6Ep QSg+HbpQh/qEn/WUqEQbOlGONtSiHU1omjBKUYh+1KIb9ShJaWJSgRKUpCD950Njqs+MtlSmIg1N RNqpEJ4SJJ8/ZSdCfOrTnQ6AIUQV6kCKKhCgLlWpBykqU5sKz3ReZqoFmapQofoPrFL1qF3l6kPE GlWlMlWrR+WqV7/6VLAGNaxWjaZNUhpRiLrTpiAN6Ulv0lKX1hWgM/WoYFtSUcLGk645ZYxR3VpW xvJUqmRla1DX+tWBMjarTm3rZMPqVsg+dqCN5Wxc14ITxML0nnXNa2pfglh8shSnq50oagfL0bv/ 9tWyicWSaRmK19gaVrW0ZS1wf5vX3sYWobYNKHJ529fcomelvjVuShca2Jk0l7i/1atxV1tRlDJ3 uM5FjESqKlrJwvWt5TVIUsFKWcw6hLybpap7NctWz3b2spEdrVjWidN/LremuN3rScHbk5ve878z Re1padva8PJFvxCOsITt4+AK63TCGH6ThTfM4Q4bK8MgDomLAAAADwOLIiQmCIlXjJEUD2TFLrZI jFUMABqzWCAwrvFBcozjHOs4xITJCYxVQmIil/glRYbJkFOSZHs0WSc+ZvKKjUzlJj9ZylU+son9 ZGUtX3klX25Jl6m8kyWzJMxOLvGYz+xlNWt5/8t8WnOalfxmJLeZzGyOcp7rjGWXFFnOeP5zjuGM HhT/OMYz7rGPE4LoQ/94IjcuSKJ7TOlK0/jFj7Y0kAVT5jv32c98FrOn59wTM39aym/W856/jGZC f8bQmI41QiZtkEbLWtI+znSsZ8xrXV9aIZOm9aaPY2tN45ohxf6HsB+S4l7feseOrrWOkz1swAh5 0GmeMk/0jO1OmznKuUZ1qtv85G67+tx4RvepCrTsak9J3fCOi7vnPZF42/ve+AYRu31N7zrxWNHt RjaMMR3piiT6379W9sChfeNc99stOBkzoNlM5yyn+9pDBrS2J07qObc635mRcY2pfeyGNDvahv9e dqNdTHKF75rfD1dLqd18cTCHGtQdD3Ou+Wxqinv8yByXuLlBHnJYu9zYCl80o6eN8pTPmumVbrnU YR5zx0S65c9m+K0DLvBeO/rfSsf1whNedbRc2+cdF3VMrszxbA/d4mlHu81lwuqbE/0wEQl206W9 dL4jPe8jDzywdT11S3O97G9xeNIP/3Swjx3Sjke44Qu+8kdLHvFmGbHd7+6nfWNeSpwP/ao+j3jR mx4opE/9fRiveikh/PKAv/rjjU7wg1t+9rVnOuxb7xZbY/3vkz+68CE/8GKPvfCUZj3vTzLznNv9 43Nve016PvdAj9r6cT99YkQufJVT/dJY37n/tL2fcOS7POzLF8zCp45+G0Md+A4pOMBL3n3C7x3+ 6TdJ86WffTs73yfUl3bl9nZuV3faJ14GJ3jwx3gnl3UAh3vJZ39kN4F+R4H5pxa+d38WGHy/x2yC R220hnwdeIFn8XoQ6IGyJ3+xl4KVx3KU93W3p4IkyHwtAn0HCCeeN4M6uIOcdoM++INAiHo8GGJB WIRGeIQxMRH5sIRLWBBM2IQE8YT5EIVTqBBSyIQGIYUDcYVOqIVU+IRf2IVTCIZb2IRX6IVYWIZV OIQPkRNMaA9PmBJv+IZyuIRwaId3OBN0eId4qBJ7SId/iIeBmA91SIiFyBJzGIeHuBJ76Id9/8iH SHgUF4GFafgPaUiJUAiFVqiJAlGJlpiJnAiKa/iJnRiKoiiGn1iJnpiKWWiKo8iGI4GJa3iJZliL DbGKrFiKVYiLudiKr8iKqyiLtPiKuOiJvAiLHyGLaqiLwPiLB1GMmjiMz8iJYYiKwViLY7iL1AiN o3iMyGgQPRGHg3iIUsiHj8iI5wiJi2iOhriOiJiOidiO5GiH8fiO8uiOjRiJcQGIfTiI9CiO6aiO 6NiO+ViOAmmPLVGPA6mO/3iP+XiQD6mPP1ERqhiN1FiGzeiM3LiM05iNztiLy3iNHqmLIumL1fiN C7ETjTiOLtGQB+mI95iHMPkSCpmQ8OiSC//pjw55k/IYkRIJFQXZjwEpiDiJkAs5kzK5iCtpiEvJ lOdYkwaJlD/JFxFZk+84jzEpkIqIlPxIkF3JlY/Ikk25kzHZlFNJFWdIlD4Zlltpj1EJk2r5kFfo ljy5lWNplEfpjme5l3zpEij5l4AZmII5mIRZmIZ5mK3SlweImOakmI75mB7GmOUEmaInmZZ5mThC mZq5mSKFmd3EmUTnmaI5mqRZmgQBmiBnmsqCmqzZmq75mi2imrI5mz0Im+hGm7xim3zJD3bBm0jh m7oZFSHBDxdBnB1hnCCBnAmhnLiZFcwpEc+JEdG5EdNJENXZnBPBD9opENq5ndzZnda5nd7/+Q/g +Z3EWZ7miZzl2Z3GqZ7kaZ7c+Z4DwZ7x2Z7jSZ/uSZ7i6Z3o2Zw8wZvACaAqAZz24JsGWqADiqAJ yhIBqqAI2qAQyqAFSqAOCqAHmhICiqEV6qAbGpxCCBH4OZ/yOaLy2Z4jep75aZ0i6p4suqLpSaLx WZ8iKqM0+p7KqZ7XiZ0L0aI1eqMxep4zqp8weqJEyqM2WqQGYaRKiqRB+p06Cp0u2qMqWqJEGqVT eqRS2qJGGqRAGqNY+qVd6qVNips5wZ4daqYLeqHdiaHaOaAEiqYTaqBryqZtKqd12hJo+qZtSqd2 aqdsGqce6hOBkaM5+hCF+qRewZ6KuqiM/9qojvqokBqpkjqplDqpOhqohIaoiZkUNhhxneoX2hYV nzoXoborEsFjwtaAC7F79SdwETgWyleBkDd4r/oRrDqCY3J207d51bd21+d//VcVo2oUH5dkw6qr vlpzwGKAbodlxlqq2bdkGQetPido4mZkUyat1Ipt2vqs3kpuQJet4fqt4Hpqavdz1ypubvat52pz 7BqAucKsFmetdvaszvqr9RquFGev21pn/Gqv6Npn9Hpq9Fqw/kpzvgqwcCdoPNewADuwx8ongOd3 qPqBAaeqqjp8S+eCD3h0Gbt4mcaxxqeAIBt4X/dyteqCLHaxDad7GEuyINt3IquBmKJ3Hv9rsQQn s1CHq/N3fjv7s7Jme7V6s606fjn7skQ7s6vaskkLtFEHc0jLs2GCrPdatQNYcf+abmgmdFUbsKTG dvq6ZhCrr1pLc1kbsAYLrGiLsGNrrtEXttcXsZMyaOSKrtTXbdrqrm77aXVbgALYc9w6bgrbrISb t4VLtnRLtu3at4nrrmAbqoaLanu7KJURq7QKEZZLFpn7dFuxuUTyGXIrahEbuldBuo4rqryKqaq7 upo5Ep7rqpqaSBg3sPuautW3tQgbFATYaXQHt0sxuEqxuw42qnILvMoKgLZLrIr7u8vLqcl7Ypgr gYuXsjIYtC77qjPLqg44vTHbs8V3vb//9rItyL0n6H6117He+36cK3Yuy4KiYrPgh7Mmp4INGLXy u77hq4D267QMp77Um3Syir/xa2wq+33kC7Qfq7GXAr8V67MGzL0xW78IDLN8973fG4EXPLTj934N 7LPuZ8Beh7Tdq8C0qrTi+7psYrMmfLKDx7EebL8e3Hca3LT0l8DmG8Mw/LRL68I5LLUo+8Lyi8Ip HLL6e79EC23WC8TYW8RIjMNMrLQzXMNPzL88LL09zMQQ3G4wLME6nCkd3MAn93shHMQXLMIbDL5V 7MI3G4IoF3kf63gU275H/MX+i74H7MRMe05CPKuSwYAP3BF7DLvlFMgTCxnlS38nQciX/8smrNvI jowqptt8j5wl1Nquk0sUkQy6z7uZlSx3T5HJngHKU2mwgbtx43rKodatXQat4Zauqiy632bK7Lpq q3zK6RqsP3mqU+zEvKzGFey0QsvFDtzFKLu/xLzETcvBdZx+Z5e1acuw4uq2jbu2tUvNtQy2duu7 6nqw2dy1Bdi8e7mCK4uzK1xyQtvLdczFUEzCyLzO5CfMGQu/JOip82q2vnu22GzNzWutz+xp2MzP 2vy13AzQ3my8ilnIShzGaazMZzzHswfPedyzA1zAmoZ7EO3Lx/fHpTfJHN3RtBG7o+LRIj3SmwHS okLSiWXSnILSOaXSm8LSnenSmQLTCf8l0zZ90xFB0+GE0zzd0wih00Ad1Fbh00RN1EI9TUVdKEe9 1Ezd1E791FAtkUk91VRd1VZN1ItaEP05n1mt1Yrq1Te61WA91lzdqGX91WDNqGU91Y+61kna1ekJ 1+hJnwqx1f3Z1nFN12ct1+OJ1XN9n31N1uEJ2Dhqn4F9EHbd12I92GfN2Mt52Dgt1oT92Mwp2YUN nwyR2GF9nXet2JDt1mRapnsKE3PqEqVNpzKxpqcdE6t92qvNoKMNqG5KobBN2yMNnZ/t2Ijt2YWq 1g2h2bq925sd3G99qLG72IJd3MQt3MjN3L6d15093Hut1/pp3Jra3KCt3NmNEGjtEJD/OthwXd3b 7ajLfdPYjdnCXd5pndvand3YbdbJ3d49fd7izd28ndnhXdeBHd363d3qjd60Kdq2XdukHduvjad1 GtusreCureAEDqezveAD7tG4zd71nd6N3d8ATtnJ/d78CdwcXtSWvd3EPeKYTd32Xdn3HeIXvuEq rROKGuGo/RKtDaelfeMOjuAU2uATLtsz/uNQTRF4Xd1Z/dxEztfSzeIAPuTRXdjPTd8ynd/kbeR5 3eEeruKb/eT7vZ7k7eJX/eVgfpmVOuZkXuZmfuZnHuZqvuYzGNVu/uY1weZyPud0jh1wTit1PrV3 vud83ueykueAXph+PuhRHeiGHpiEi57oir7ojM66h/7o39jokj7plK5vkH7pPFjpmj7JmA56m94o nR7qF/jpoC7qpn7qqJ7qUELqjKLqrh5zrB7rwfnqtD5vst55tV4gt94nud7rvv7luy6xvz7sxN7T wb4nxZ7sym7Sx64ny44czU5Nz35N0V7t1n7tODHt1I7t4qTt3u4s3B7u4h7uAQEAOw== ------=_NextPart_000_0006_01C725CF.B171C630-- From islwnugffqt@compseg.com Sat Dec 23 01:34:05 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy0SL-0006xm-17 for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 01:34:05 -0500 Received: from [222.116.160.40] (helo=[222.116.160.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gy0SF-0002vX-Fp for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 01:34:00 -0500 From: "equally abide" To: sip-archive@lists.ietf.org Subject: Billing report changes Date: Sat, 23 Dec 2006 15:33:47 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C726A7.BCF168C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accmp7zx79VBeRtiRsCZn73Wts/41A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <8E71345827D901B.D72C1DC63B@compseg.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0001_01C726A7.BCF168C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0001_01C726A7.BCF168C0-- From alfredabell@mypersonalemail.com Sat Dec 23 05:14:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy3tM-000107-C5 for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 05:14:12 -0500 Received: from [89.137.41.171] (helo=mypersonalemail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gy3tK-0003v5-T0 for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 05:14:12 -0500 Message-ID: <5fcc01c72cfc$3b570d50$a78fc09b@alfredabell> Reply-To: "BECKY" From: "BECKY" To: "SHERRI" Subject: ANDREW Date: Sun, 31 Dec 2006 16:53:44 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 3.9 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 RAYMOND 0ur Attorneys discovered a loop-hole inside the bank laws, Applying what we have found, we're successfu1 by totally eliminating creditcarddebt with out them having to pay another cent, We know that our firm can help you with this too. You can contact us at : 1..561.282.9476 Exhaustive info or to discontinue getting or to observe our location I'll get you one! cried Dorothy, who was sorry for the poor man; so she ran back to the buggy and took from her suit-case a pretty blue ribbon. Mr From rdoaffbkgz@bsys311.pms.ford.com Sat Dec 23 18:04:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyFuh-0004xH-9m for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 18:04:23 -0500 Received: from [62.162.219.196] (helo=[62.162.219.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyFuf-0006Vg-Aw for sip-archive@lists.ietf.org; Sat, 23 Dec 2006 18:04:23 -0500 From: "Stores. Earn" To: sip-archive@lists.ietf.org Subject: Article Date: Sun, 24 Dec 2006 00:04:18 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C726EF.0E348270" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Accm7w40oZ2oMnZ2RnaNNg7n33pecg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <13B7EFB95F72CE9.C84A276540@bsys311.pms.ford.com> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0005_01C726EF.0E348270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0005_01C726EF.0E348270-- From stocknews@tracydowney.com Sun Dec 24 00:58:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyMNO-00038r-0x for sip-archive@lists.ietf.org; Sun, 24 Dec 2006 00:58:26 -0500 Received: from [222.123.122.63] (helo=smtp.e.telefonica.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyMMg-00071U-8C for sip-archive@lists.ietf.org; Sun, 24 Dec 2006 00:58:26 -0500 Received: from communes-de-france.com ([221.236.96.81]) by localhost.localdomain (8.13.1/8.13.1) with SMTP id k8J5EgHB006101 for ; Tue, 19 Sep 2006 13:14:48 +0800 Message-ID: <887A14B2.99979F1@communes-de-france.com> Date: Sun, 24 Dec 2006 05:57:42 -0420 From: "nikita phillips" User-Agent: Mozilla 4.79 (Macintosh; U; PPC) MIME-Version: 1.0 To: "Alexandra Otto" Subject: i need ur help Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Status: O X-UID: 396283 Content-Length: 1 X-Keywords: X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 From sip-bounces@ietf.org Sun Dec 24 18:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyd2H-00077G-44; Sun, 24 Dec 2006 18:45:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyd2G-00077A-4f for sip@ietf.org; Sun, 24 Dec 2006 18:45:44 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gyd2E-0005JZ-SZ for sip@ietf.org; Sun, 24 Dec 2006 18:45:44 -0500 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kBOMo0fb012445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Dec 2006 16:50:00 -0600 Message-ID: <458F1308.2070601@softarmor.com> Date: Sun, 24 Dec 2006 17:53:44 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Cullen Jennings wrote: > 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. ... > Could you point me at a non enterprise deployment that is not in point > 2? I suspect there are some but the bulk seem to be form 2. The problem is that none of those deployments are (yet) using the boatload of features like identity, e2m, complex route-header cookies, and other Very Important Stuff that we think might be likely to happen. But when that stuff starts to happen, UDP fragmentation will start to occur. We don't yet know how much will break as a result. But my guess is "a lot". How about we rip out UDP, fix the Outbound stuff, fix the route-construction stuff, fix the early-media stuff. and call it SIP 3.0? -- Dean -- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 attempts@xnsica.ptqide.r.12hs.com Sun Dec 24 23:26:39 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyhQ7-00058Q-Jm for sip-archive@lists.ietf.org; Sun, 24 Dec 2006 23:26:39 -0500 Received: from e177183092.adsl.alicedsl.de ([85.177.183.92] helo=xnsica.ptqide.r.12hs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GyhQ3-0002Qq-5f for sip-archive@lists.ietf.org; Sun, 24 Dec 2006 23:26:39 -0500 Received: from ([154.109.142.134]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Dec 2006 05:23:45 +0100 Message-ID: <001301c727dc$62ed8490$00000000@Hauptzentrale> From: "guard rail" To: sip-archive@lists.ietf.org Subject: Yahoo Google Commenting register Date: Mon, 25 Dec 2006 05:23:10 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C727E4.C4A876B0" 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: 4.7 (++++) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 ------=_NextPart_000_000F_01C727E4.C4A876B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C727E4.C4A876B0" ------=_NextPart_001_0010_01C727E4.C4A876B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Crotch until bleeds sounds, rustling haystacks, could! Earth ourselves, superevil, wheres drunken. Several small nations = waiting? Ho ok number, had bad attack. Early date relatively speaking = worthless bitches took. Has reduced following around total piece brat making! Copyright respective owners, credit unless otherwise noted. Syncs bitterly fake real. Owners credit, unless otherwise noted own = rights wish. Entries desperate attention forgets panties nicole kidman = might, pregnant. Story times as, always your summary far hysterical. Reading lives women = comes woman explaining linked. Packet valtrex ccdluna lol. Ourselves, superevil wheres drunken chauffeur multiple paparazzi tunnel. Oops third fourth enfilade slut brigade skank wagon th? Maybe week only = monday id. Posted by whod thought seventh seal would, packet valtrex. Vocally, since landed, pop scene faced? Cruel nothing sacred good luck = selling. Im saying this on tape. Roads la santa sayho. Play shared, material girl, also mimed, rivalry. Chauffeur multiple paparazzi tunnel when, hate god! Biggest, asswipe = pathetic chump life has, reduced following around. Lew insky wow theyre unstable. Theyre unstable, wouldnt guessed what = guy, front their? Celebrated live salsa merengue latin jazz. Trash whackjob york london munich everybody talking. Perfume soaked, = dressi somebody windexed seats after sat. Illegals richport, whoresmen = spindoc smells. Couple celebrated live, salsa merengue latin jazz. Reserved published = privacy policy. What guy front their faces. Jojo detailing wont funk smell bus, station tara. Zip code keyword city. ------=_NextPart_001_0010_01C727E4.C4A876B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Crotch until bleeds sounds, rustling = haystacks, could!
Earth ourselves, superevil, wheres = drunken. Several=20 small nations waiting? Ho ok number, had bad attack. Early date = relatively=20 speaking worthless bitches took.
Has reduced following around total = piece brat making!
Copyright respective owners, credit = unless=20 otherwise noted.
Syncs bitterly fake real. Owners = credit, unless=20 otherwise noted own rights wish. Entries desperate attention forgets = panties=20 nicole kidman might, pregnant.
Story times as, always your summary far = hysterical.=20 Reading lives women comes woman explaining linked. Packet valtrex = ccdluna lol.
Ourselves, superevil wheres drunken = chauffeur=20 multiple paparazzi tunnel.
Oops third fourth enfilade slut brigade = skank wagon=20 th? Maybe week only monday id.
Posted by whod thought seventh seal = would, packet valtrex.
Vocally, since landed, pop scene faced? = Cruel=20 nothing sacred good luck selling.
Im saying this on tape.
Roads la santa sayho.
Play shared, material girl, also mimed, = rivalry.
Chauffeur multiple paparazzi tunnel = when, hate god!=20 Biggest, asswipe pathetic chump life has, reduced following = around.
Lew insky wow theyre unstable. Theyre = unstable,=20 wouldnt guessed what guy, front their? Celebrated live salsa merengue = latin jazz.
Trash whackjob york london munich = everybody=20 talking. Perfume soaked, dressi somebody windexed seats after sat. = Illegals=20 richport, whoresmen spindoc smells.
Couple celebrated live, salsa merengue = latin jazz.=20 Reserved published privacy policy.
What guy front their = faces.
Jojo detailing wont funk smell bus, = station tara.=20 Zip code keyword city.
------=_NextPart_001_0010_01C727E4.C4A876B0-- ------=_NextPart_000_000F_01C727E4.C4A876B0 Content-Type: image/gif; name="Anticlown Media.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c727dc$62e40eb0$00000000@Hauptzentrale> R0lGODlhWAI0AYfoAAwFAIoAAAB9AIpyAAwEfH8AgQB7jrqxwb7Yzq7L+EIYCFEuA3EWAKgiALso ANITAAAzACUxAEQ5AGI2AH9DAK1NCrg1ANI9CQNXABNtAzZsAGxtAHxnAJdVALhRAOBWAAB3BxyK AEh7AGSBAHZ1AKh0CM6KAOyKAACbAC6UAEmaAFeZAIWcAKquALqdBeucCgLDABPCADy2AFHDAITH CJjBALPNDNjKAgnUARnbAEHYAFvXBY7aAJXXAMvXAOLhCgAKRRQASzwAQ14ANnwANpgFMbQATesI OAAeMhUkPjQZRVIVRIQSM5MqMsoVOeUdOwBHMRtERD83MWlJPoA8NqtHMco7M9k5SgRuSiRmOU5Y PGVXQHNdBZ5iTMlSMulVNgR3QS2GMzuIQG54Q4WJOqmDNr52TeV6NQmRQRyhPUytP1ecN4CiTKKg OcWdPd2fNgPASinJSzS0Omy8OIa4NZW9RM3GMuzERwDnSCvfQDTlOlTqSIzYQKvWTcTRPObSTQMA dhQHjj0AjWgOeYMMgqgDgb0AeukAhwAUfx0of0IlemcdjYgfd5sTfMYcjOcpdgA6iC1IgE1DcW5N hHpDeKxDc7xGdO43dgpVdxpkfj9qilRkhotSh5VngrJchd9Xfgl2dix8ikN2i1eEiH2IiKuGhbKK ju2FhwCmgiaqhzuXdFObjHSZjJmderKqcuuiggDJfyC2g069hmG7eXK9cp3Ii8e1gNvDdQDoexLm dD/gil7niHrXcq3pcczSh+vefQAHxiwByz4Asl8AvIYAw5wAwLMHsegAyQAfySAnxzkotm0svnIj t5oVzMkbxuEptA4ztRxFtkM2yVE/wnEzzZo/ybwywNFNvwBTuiljtz9rvVltxIBTw6xktrdlzNZe sQCIwyt3v0ZzzGR7tYRzx61/ust+vdJ5wgCUtyOtxT6SzFufsniVyJqlybqVttabzQC+xySyu0W/ u2LAxY3EuanFs/X/7ZKjloB6gPMNDAT/C/L/AAwA8f8A/wD/8Pn//yH5BAAR+SkALAAAAABYAjQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEhR4L+LGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MD9WnEmzps2bOHPqJBizp8+fQIMKHUq0qNGOO5MqXcq0qdOnEo9KnUq1qtWrWLNq3cq1q9evYMOK HXsRqtmzaNOqXcu2rdu3cOPmJEu3rt27ePPq3UtVrt+/gAMLHky4sGG2fBMrXlz0sOPHkM0ynky5 suXLmDNnjMy5s+fPoEOL9qu5tOnTqFOrXs26tevXsGNjHE27tu3buHPr3s27t+/fwIMLH05coezj yKcWXx4xufPn0KNLn069uvXr2L8y387dbWoC4MNn/x9Pvvzkh0DSqx8IoL3C9vABHAwffiCw+/jz O+THXyB/fgThV5CA9uRn4H0LqaeggvasR5CD9EVIAEPxsQffYBVaKN9CByKoYXwXFlRfQSFq6N9/ KP7XoIMrpjfQiN3FSNhI8F1U4z83cnRjjhep12N6NraXko8YEYmjkBnxGCQAKCnpJJJGmpTjjiDG t5GSR4IopZVZIpllSOJdFOY/Y37035VeLokmkxpNmWaUK8ko504i8YgklmKCl9GYdrJZJklYUskm RoGmCaihZ2aU6J+HCsklnhsxKuigdXqppZoguTkopElySah7BJVoIokXZiiQqHOmahiMBqF6Kqih gv/qqkAsQuRqiKzak6uu4E2Eaq0t0uoiRaXCSuB7pr66oT2zJlRilcpSCOuzsCa04IAe2pftqKTK h2qzqoZ7VkicMvplm3ca+imlja6J6bqR6nnSk+zeaC5JEXbKro6evsspv5s6yua/mPa5b7xkEoBu vepCeume8pon8UvSLttqtdxyC2K3VVqM0K2yYgyyxw5923GIJ2OMrKjgWsisx9SSvLKJxcrMcbIp W1xzrDCr3OzG3YortGDgzjryzRk/dPTLPZPcsrMiR73h0xXfDHS0LIdsM9TLouytyhd3PS3YPDNd 9tloh30Q1UO3fVbRYC+tttkSLW2y02QvdHfQdFf/tPfMWV+t9NhTC/5xtV5vrSzOUs+9dtx5ozWx a1UfLrPcfLP9uM6E85324E1nHnlDf3PN+NeKW65xsqqP2nLMSWPu+edtTR5dn+8urO+nu5/bZLqU 0uvuvIYK73tKxnekKbzHVxrw8+oOX3D0zPuefPXS2669VI8C75GgvS+vUpXS40mw8sWnPzD17faO /vPM90uupWnKD3D1/6bvvvns80+p2wBUSqM09bAlFapfOYtJx973O4Y50IDkax/20IQueC0OdBlj 3eYEl7Nopa1jrducCANIwhK6rYN982DgUrc4FprwhTCMoQxnSMMa2vCGOMyhDnfIQ9ts74dADKIQ /4dIxCIa8YhITKISl8jEJtqlh1AEjROnuJkoWvGKWMyiFrfIxS568YtgDKMYx0jGMv6FimhMoxq5 YsY2RmaN0XGjHOcoRzja8Tp0LMwd94iaPN6Gj2v0oyANAshCGvKQMhmkIgWDyEY68pGQXMwiJ3nG SFryksqhpCY3yclOevKTdcSkKEdJylKaUjWgTOVaTsnKVlpHlY5xpSyFAsta2jI4s8ylLnfJy176 8pfADKYwh/nKWxrzmMhMpjKXmUpiOvOZ0IwmUQIgzbswkzgLyGY2z6JNgTDgm+D8kAsHsoCMaLOc l/HUA9a5zowowJ0xcUA1pxOAelLTnQrIZ0YYcP+Zd2LEnzhq07q8BM6CXiSfCNWIPC8CAY40NCMP DQk/MRLRf1Q0I/f8CQQ2WlEHePSjC2UoRz8SvIuE9B8hTek/9bkRhLL0HxO9SEwPVkyGcHSjoKGA Tgey09tAgCA/FUhQhcpTg9izngT5ZkGUGqqC6PSpTWVP5ZA6kAAQFagCoYBTs7pVrBJEq0UNqz0Y cBCwSoSsV/WqPcw61ILclFhRVetA0OpNtdLVrXi1R1DbutaPRXWofLVqAEWCAQxgpLCKGalIB0pT j9z0oihAgVQuihEBbMSy/5CsRjR7Ec4iNiOfpahGMHsR0hr2IqcNCWkFQNp/YLa1rmWoRh7KWeX/ jTYjrSVtbQ+LkoqmlrelFe1GKtpQZr2MQq0qCAaUq5ChogAhzyVIdH/KV3ss9yDXFch192qQ6sqQ tQl5LEH0QV7y2qO84rQYa9c7kMcOFQc4EAh8GQKD+sJAIPV93OBc1l7vLkUA0DVIdO+b1/YSFbB6 Jchys2tcqcr3wQ55rz3iC2ECD4TAfOWuQhg8YYJQGMJ6FW8LHfJhe0RXukLlaIJVLFvh1ncklIWs Rn5L0o7Q+LQb5QgObAza4MIWI/ogD0PAexCcpngg6E2yPgSC3vMu2SCFFQh77UHkKFuXw0VWcYj1 K+X1AnjKVx6Ilddi4QIbuMMFeTKSpUzlgXy5/6kWY3B2FwyRob6ZzQ12MMwubN8yp1UgkQ00c7Xb ECyvzcMG+bCFIzuQ6YoYwCVLLqLjupATC9rEBZluggsCaYN4udNGPoia2xYS+HaEvEAOcmc1G9lV oza1ocUtZlvt6lfH2rENzXGOVx1ozpb3H79GdWZ7TWurrJa1F4HBRpQN7OHO1kbQHlhlp30R+Fob opQFSUSlHdB/7Dgj34btj6GdEWZj5Nvfzghnzf0RVYOktuxOtnCbDWR5OxvG9yaUQEWyW1ZvtsUX pWm8q+1t2wax2KM9dmVfy/BXHza1n8ZsaEPrZZEIu7yqnnhqac1xVu8WK/0O7m3/MfB4M9vf/v8W eWxRy3Lcrnwk68aIspmdW2rb/N/qHvnLyW1RHe0bJPEmbo9b3OKa/4PG7d6Iu+1d7+9B9OkkLzdG OFvbcRf83tlON3bo62c+ex3Q0WW0icNu6eiOTb4fnu8FbbpXLRMZzGKPO9kbfWIqdxoqd+90iT9c 3bpjus14BvzYL51ni1G4xAuxcNcabDhLn/nxpyJRXC8NrRFHmiBeLoji45p5QEOk7n7Ps4MjP/oU u73zIEazPcrs3INYuOvjBCAUoDCQ2R/59vawfe5pv3uBgAEMA/n9qzxIZLtj/u7I4pZ7v57f1Vv4 99DnNPKf0ucyw+H6cADqWzedVt7nvvaktwf/uUtK9Gz7nOgWNf9sd03Rm24ECBqBf0bkLxT1x1/m UvcI/UdS8WVzpP9BMXtQYHMHI3QYMYBEtCDzpyAL+CMO+A8Lsn8R94AQuH/sU0G5gz5BsoGloYBF whHyt38Q2CP39w9gkBEnCBLrdREpyIItqBkiqH/w94IvSB6NNR1rMSw2oYNJMSw+CATXJBdAmEVD 6Ee9YhOjE4RK6BQTUkJWcYElcR/zNIWHtIRWeIVYmIVauBtUKBVb+IVgaExdaBkRMxJlOIZoOEoR tBJQSEFNVEDE04YqEYaKhDixdzgRkYQ2dHZMkzX8dVwylIZ1IS14CIh9iDrpxTN2GCs7RDZ8/wiI i0iHWuiIhUMz7qE1w2eIj2iIOESJjHhcUYNLgjgda9glncKB6cI7R6KKq7hE1FM/69MwNziKrVQ3 YhOJIZOJkCg2fwhFWlOJ/GU0dyiJmkQ8A3WKrZiKqBgwrJhEsMiByyiLpkGM3DE/yAiNy5iN2tiK 3NiNQ0Q/2JiK+vND1BgYItEA6JiOGLhSB+VPLHVU9YRPCYUR2YRPSORSLPVSLxWP/8CP/WhPtNhL NbFNy5QPBnmQBGGQA6GQMhKQpUETeliOEpmF+TSRkOGQ5mGRtoSRHFlEGiknqiGL+dMvBRVTTvSR KOkrHtNTa2VWS0VXTMWSLJmSNFkbhXWThv+mfX8RcbgXaso1Z9e1iYLUkbbDdV9XEZ9WEGqHE9aG eMVXfG4FWEFlXkw2ajVElKUEjkeHk6z4adCYJsgWE+4HWrCGdNWWbqa2lQ+HlWyZGEaJXwRmbZqH YdUllElhX3N5lKTyh9XXdTX5l4wEEjgZWuqyawh3ERj3a0SBce3XmBzxYsk2cCQnmW0pFoC5EGOm k3npfImGeE9xiRvSfJzZZQOxlEvZi5eZmpX0EZCZcJeFWUDimqWVW1bHEtf3D7cJQdfYJZQylpX5 m5URmxrxe24onCgIfTVInDGBnMoJnM75GgxxhCLShA9ShBHSFtKpmtr5GyE5i8/5neAZnuL/2Rjb WZ7meZ64MZ7quZ6/iZ7uyUlBIYfkcYbsOZ4Vo0GFiBMn85nDuBNSg5/EWJ8aQYi2qDfASDr9ORMR qRSVt6A2JKCXQaAIaipXk4slgzcxQzgZeot2yaAm857aOT/2c43RQz/yiY1uiDvbqJXNKBTyU4oQ Wp/Ao4ze+JXns5spyjCqyKIn+hMjGaNsmYdb84iV14e2gqFes5eZCEK6uBYA6qAg+oVb8j3MyI3P WBLjmIw6uo3r+IRMUqLeCaRjKKF5g4m7yDlCqqRJ+olrqok98zZfo4tQShtiWkTwCBL4CFCl6I8j 8VIYAY/3xKcXAah/elQaAZDtaBSEihHp/4iOhRSlbUNVa1GRhiGpzFGn2+MWlLoW6HgYDMlDmOpL d3pKkFqqpnqqkhOqqmpHqKpFq/qqINGqslpLsFqr0jSruJqrulqMttqrvvqrY7GrwjqsTgise0Ss TmGsyrqszNqszpoZyBqt0jqt1Aqh1LpFz5qt2spE19qtUrSt4Aqr3jqu5Co04Zoa5Zqu6rqu7Nqu 7vqugHGu8jqv9EqF0lqvNQWv+rqvc4GvcMSvABuwArtI9TmwBkus9jmr/rqwDCuIawGVBxuxSTGY WEZs2ieVpUlhfSmaCSF2F7t97uWTTbF8DjGYCmayLeQx1UcQfbkbKkNsoGexQ5Z3oLZ9aP8Bsbjq sR67ZT0ZaqF2mpy4EEAbtErpmaaTIT5pZE0Jlyzrl57WacUnms0ntYtWdm4GtZ12MmcJbuEWlq41 a4EGQTfitV+bKXDojVeKcIfZER3HiixaoxtBbBkhbIipamRbsAb6iRBLZEs7YYrmZzubt9KnEIHb ECIbiTzrtxJBlUj2ZHz4uG9qfKQpfbI5m7OpcLWGba9puSqIuQbEtRp4EmEZlodJa605maWGbloH ma3ZozIaPGxyuqjrbddGux+RliJxt2VLpSeBu5z7u16ytiHBfouVfo7Jfrvmu7a7u8zrmAsna7Z2 WoS5L74Ldta7ED7bVsnCsU1LEX1Gd5n/ZnZoKrSHV2JWNmY4i54hcbqQSbzGW7bIpruaC2OUtbGV SxKyS7ZeS7zuJRLuu2vYh33t55vjyJw1GJldOqM26obxBycdgbwRxbrsFoGyBoC521rN6YLFK1IE ijE2O5pRqlq0qcHH+YAM6BEZDBLGSYEckcIikcIRKJwuXCQxyMBcSsP8goFAssI4DL3PW4FALMMH zMO/CxIG3IBA3BHyC7cdEZu+B3wEIXwrUp0MYcAGIcXBB8W7yoM/WBDDcoT0oRDZuRBjzCsKwYMX Op0EIZ1oHCDAwBDbUiBvPMUG0cZ0PBBf3IRlfMcCkZ1grMcw0sZ2zMc80cAdISEeQZ8s/6zC+7fC sVmGimzIi0zEviqcxhkxmKwweaLJoSsSUijJTVzDjKwR/KEo/NDD3SiHPHow1FPKF+HKVrovZ2ic j6zJ9IERnwwxoTwSsJwRufwPn/zLn9zLvWy2GpHJqJzEH5HLv4y2YRqjKXLKDRwlJkpSz8ybfoLI umwSZ3ilyozNA0Qpitw/CAS7XZon6JzOCcPJzczElGzDySycpXggWLovcCgvkbyOhnKG7byeJxS5 S6o5hwE51ZItBMIgbpyfBQHPeTGiAFMoDRvREj3RFB1EEvtGFV0WF31DGd3RHo0UGx3S3bGf4tSL EVmhHMSLRjqhc3oTRVrSJs05Au1FuP/40sLR0jNEpACtpJ+4iz2dfAH9hxbapEDNiYZztG3q002q 0z3doeJnHQXkJiJ6KVf6imf70LAY1Q69Jupjzs3oukC0yufcolaNozl81tmYpdbMuyhqzLtJo2+r pchY1p9ynxlS00cdNiPjM6cDoDzdOURd1Et9oD+dhEzNZUR7MUJ9OeMb2Fb0i4MNOTw92YZtM3iN Nwiq0Imt2TW92Go6vp6ImoJt1ISd2YMd0559pJ891IR0zlXNytf81euD1sgz27TtzU6kwKnMP2Mt tm1I19FI22wNzyeq1jOK23K9ozSF3Gv91rZ9KG67pePoutNNJdDt3L7d1tao3MJtjOD/LNtmTY6E WCGdPdmbjbhQs3aXrdgdnNSbjdgpm4uhyKagXTisvaDzHdSqLaeRO99Q6t9xit87zdqKqIeX7d5p yt+oLdpX5FIC4eBVJViWKhAT3qkHYakTfuGCReGCtan2QKkV6eHvTRAEKRAEOeEZnhAovuH2QFUW buECAeMx3gAcThAuTuMDYeGAmuIIseKA+uB5yhA/nuM4TuTiJ6j8uEAggeT3VI//cE4k4af/iFH3 5KghIeUc4afvmFFUXtuU4o/+6OQXYeV2dJD5cBFmnhFmbpAbIeaM2gBvfhFu7uYeoY/+BOYZlY8A 9Q9kvuQZxY9SjuV1vuf/oOXuCFB+/+pRGKHoi75QjD6ofx6oXC6oH/HoicqOhU7oIRGPTH6o9zSO gv4RbK7mZz7l/0jpw12okI7pIG0PHsUQMm7hYPPqEkHrBLGpIq4Qtq5FEA7h9vCpv54PBbHrC2nm A7HrxK7i8JiyTW3f4zTkwV7sECHjpA3kt64ABAFSDmBU9sTtRyUQwA7sCyHiHk6p65Tg1fLqGcHo dO7kqO7W3NhOF8FOJIHqhspYSMKn797lqy7n6MTAbWjvka7qcU6P/05FuG3plo4c2m4SC9/nfX4U +s7lIBHxCr9Qoe4Rj27pdp4RZE7mCz8Sa87vpx7lmo4SjRrxHaHtJ7XjVI6oZvswKf+fEfJuUif1 0Ywx5wePp4Q+8dkN79048hpxTgef8Th/9MEq0g+B9Feh9AvB9FAf9VKPg9s59VZ/9VjvrE5/S1nf 9bq09WAf9mI/9mTfFF4vSWWf9mq/9qNx9mSxr/7M9nKvFm6PrnNP93WP9Xe/9ySU94HE94BfG34/ +ITvloF/+Iif+Iq/+Iw/J4X/+Avb+I8B+eop+ZbvHZSf+XuBqprf+Rxx+aAf+qI/+nIP+aQP9p6f +qq/+qzf+lgh9q6v+eoa+7TfF6fvrrWf+7q/+6t/+4fP+01/ravq+4cB/JlE/MhfqnWa/Mzf/M7/ /IVs/D0B/dck/VZBk9avGdSv9qb/T/r+uv3gH/7iH7DZf/bjf/6nX/6GhP6B2fXPn63sH//yn/wR Pf8irf74X6v2n/8/Yf/+DxD2BA4kWNDgQYQJFS5k2NDhQ4gRJUb8V9HiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2VLjRJgxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaQzXS5l2tTpU6hRpU79mNTq VaxZhVLl2tXrV7ActY4lW9bsWbRp1a5lqzbsW7hx5c6lW9fu3ZZt9e7l29fvX8CBBa/FW9jwYcT/ Bi9mTDTxY8iRJU+mXNnyZcyZNW/+2tjzZ9ChRY8mXdr0adCcVa+Witr1a9ixZc+mp117IWvcuXXv tmjbN0PewYUPV/3b+HHkyZUvZ97c+XPo0aVPb0jc+nXs2bVHpd7d73bw4cWX9M58/HnK5dWvF4je /fvC7OXDhF/fvsn5+Y3et6/f//+d+BNwQAILZA1ABBNU8DgDG3SwrgUjlHDCox608EIMM9RwQw47 9FA8Ckv7cEQSS3QwRBRTVHFFFlu8yUQYY/TQRRprtPHGhGTUcUfNcPQRrYAAADs= ------=_NextPart_000_000F_01C727E4.C4A876B0-- From hjusdcye@blacktown.net Mon Dec 25 01:03:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyivP-00013d-1A for sip-archive@lists.ietf.org; Mon, 25 Dec 2006 01:03:03 -0500 Received: from [125.93.156.193] (helo=[125.93.156.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyivN-00037z-EA for sip-archive@lists.ietf.org; Mon, 25 Dec 2006 01:03:03 -0500 From: "Movies Compress" To: sip-archive@lists.ietf.org Subject: Billing report changes Date: Mon, 25 Dec 2006 14:00:54 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C7282D.184CE380" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccoLRhMx6EJCS0uSXyr5wUHYeGqBA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <88E3BA5EE177780.7DC522E1A6@blacktown.net> X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_NextPart_000_0004_01C7282D.184CE380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael says: GCME Huge News Release Expected Before Years = End!=20
 
Ring In The New Year With Cash!
 
GCME is fast becoming a major player in the = foreign film=20 market. With continuing mergers and joint ventures with the industries = most=20 influential corporations.
 
Company: Greater China Media & Entertainment=20 Corp.
Symbol: GCME
Price:=20 $0.70
Status: BUY ALERT
5 Day = Target:=20 $1.45
 
Right now it is at $0.70. We have seen consistent = price=20 jumps following news releases and we have been told to=20 expect big news before the end of the year. Look at the = price=20 patterns, see the spikes and the steady climb for yourself. Now is = the time,=20 grab GCME first thing Tuesday=20 Morning.
 ------=_NextPart_000_0004_01C7282D.184CE380-- From sip-bounces@ietf.org Mon Dec 25 04:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GymMM-0006yN-MZ; Mon, 25 Dec 2006 04:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GymME-0006vn-RD for sip@ietf.org; Mon, 25 Dec 2006 04:42:58 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GymIB-0001ub-ID for sip@ietf.org; Mon, 25 Dec 2006 04:38:50 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 764A4AC2BF; Mon, 25 Dec 2006 11:38:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17807.39967.360179.793067@harjus.tutpro.com> Date: Mon, 25 Dec 2006 11:38:39 +0200 To: Dean Willis Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound In-Reply-To: <458F1308.2070601@softarmor.com> References: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> <458F1308.2070601@softarmor.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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Cullen Jennings , 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 Willis writes: > How about we rip out UDP, fix the Outbound stuff, fix the > route-construction stuff, fix the early-media stuff. and call it SIP > 3.0? good idea, but you forgot to add SIPS to the rip out 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 Tue Dec 26 23:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzQTc-0003sc-00; Tue, 26 Dec 2006 23:33:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzQTa-0003sU-Fv for sip@ietf.org; Tue, 26 Dec 2006 23:33:14 -0500 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzQTY-0000tp-J5 for sip@ietf.org; Tue, 26 Dec 2006 23:33:13 -0500 Received: from sipx.cornfed.com (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 kBR4X2K17657 for ; Tue, 26 Dec 2006 22:33:05 -0600 From: "Frank W. Miller" To: IETF SIP List Content-Type: text/plain Date: Tue, 26 Dec 2006 21:32:57 -0700 Message-Id: <1167193977.4934.11.camel@sipx.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sip] Routing NOTIFY requests 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 Consider the following scenario: UA1 Proxy UA2/PUA | SUBSCRIBE | | |---------->| | | | SUBSCRIBE | | |----------->| | | 200 OK | | |<-----------| | 200 OK | | |<----------| | | | NOTIFY | | | ??<-------| | | | Further assume that the Proxy added a Record-Route header to the SUBSCRIBE request. Perhaps I just overlooked this but 3265 and 3856 do not explicity say how the NOTIFY is to be routed. Should 1) the NOTIFY request be routed through the proxy using the address in the Record-Route header or 2) sent directly to the UA1 per the Contact header in the SUBSCRIBE request? I guess if I read 3261 correctly about requests within a dialog, I would assume case 2 but presence of the Record-Route has me confused. 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 From sip-bounces@ietf.org Tue Dec 26 23:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzQl7-00083L-Hg; Tue, 26 Dec 2006 23:51:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzQl5-00083G-H1 for sip@ietf.org; Tue, 26 Dec 2006 23:51:19 -0500 Received: from [203.187.132.25] (helo=tapal.aricent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzQl3-0002Ua-Dn for sip@ietf.org; Tue, 26 Dec 2006 23:51:19 -0500 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id kBR4qRbt013442 for ; Wed, 27 Dec 2006 10:22:27 +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 kBR4qNgl013392;Wed, 27 Dec 2006 10:22:25 +0530 In-Reply-To: <1167193977.4934.11.camel@sipx.cornfed.com> To: "Frank W. Miller" Subject: Re: [Sip] Routing NOTIFY requests MIME-Version: 1.0 X-Mailer: Lotus Notes Build V655_10312005 October 31, 2005 Message-ID: From: Balaji Murlitharan Date: Wed, 27 Dec 2006 10:19:44 +0530 X-MIMETrack: Serialize by Router on Chemail01/CHE/HSS(Release 6.5.5|November 30, 2005) at12/27/2006 10:19:45 AM,Serialize complete at 12/27/2006 10:19:45 AM X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-22.8188 TC:03 TRN:75 TV:3.6.1039(14896.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: b22590c27682ace61775ee7b453b40d3 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: , Content-Type: multipart/mixed; boundary="===============0194936518==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0194936518== Content-Type: multipart/alternative; boundary="=_alternative 001AA7B465257251_=" This is a multipart message in MIME format. --=_alternative 001AA7B465257251_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgLA0KQXMgcGVyIHRoZSBSRkMgMzI2NSBzZWN0aW9uIDMuMi4zLElmIHRoZSBJbml0aWFsIFN1 YnNjcmliZSBjb250YWlucyB0aGUgDQpSZWNvcmQtUm91dGUgdGhlbiB0aGUgTm90aWZ5IHNob3Vs ZCBmb2xsb3cgdGhlIHJlY29yZC1yb3V0ZSBoZWFkZXIgdmFsdWUuDQpTbyB0aGUgTm90aWZ5IHdp bGwgZ28gdG8gdGhlIFByb3h5IHNlcnZlci4uLi4NCg0KVGhhbmtzDQpCYWxhamkgTXVybGl0aGFy YW4uQw0KDQoNCg0KDQoNCiJGcmFuayBXLiBNaWxsZXIiIDxmd21pbGxlckBjb3JuZmVkLmNvbT4g DQoxMi8yNy8yMDA2IDEwOjAyIEFNDQoNCg0KVG8NCklFVEYgU0lQIExpc3QgPHNpcEBpZXRmLm9y Zz4NCmNjDQoNClN1YmplY3QNCltTaXBdIFJvdXRpbmcgTk9USUZZIHJlcXVlc3RzDQoNCg0KDQoN Cg0KDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQoNCg0KVUExICAgICAgICBQ cm94eSAgICAgIFVBMi9QVUENCnwgU1VCU0NSSUJFIHwgICAgICAgICAgICB8DQp8LS0tLS0tLS0t LT58ICAgICAgICAgICAgfA0KfCAgICAgICAgICAgfCAgU1VCU0NSSUJFIHwNCnwgICAgICAgICAg IHwtLS0tLS0tLS0tLT58DQp8ICAgICAgICAgICB8ICAgMjAwIE9LICAgfA0KfCAgICAgICAgICAg fDwtLS0tLS0tLS0tLXwNCnwgIDIwMCBPSyAgIHwgICAgICAgICAgICB8DQp8PC0tLS0tLS0tLS18 ICAgICAgICAgICAgfA0KfCAgICAgICAgICAgfCAgICAgTk9USUZZIHwNCnwgICAgICAgICAgIHwg ID8/PC0tLS0tLS18DQp8ICAgICAgICAgICB8ICAgICAgICAgICAgfA0KDQpGdXJ0aGVyIGFzc3Vt ZSB0aGF0IHRoZSBQcm94eSBhZGRlZCBhIFJlY29yZC1Sb3V0ZSBoZWFkZXIgdG8gdGhlDQpTVUJT Q1JJQkUgcmVxdWVzdC4NCg0KUGVyaGFwcyBJIGp1c3Qgb3Zlcmxvb2tlZCB0aGlzIGJ1dCAzMjY1 IGFuZCAzODU2IGRvIG5vdCBleHBsaWNpdHkgc2F5DQpob3cgdGhlIE5PVElGWSBpcyB0byBiZSBy b3V0ZWQuICBTaG91bGQgMSkgdGhlIE5PVElGWSByZXF1ZXN0IGJlIHJvdXRlZA0KdGhyb3VnaCB0 aGUgcHJveHkgdXNpbmcgdGhlIGFkZHJlc3MgaW4gdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgb3Ig MikNCnNlbnQgZGlyZWN0bHkgdG8gdGhlIFVBMSBwZXIgdGhlIENvbnRhY3QgaGVhZGVyIGluIHRo ZSBTVUJTQ1JJQkUNCnJlcXVlc3Q/ICBJIGd1ZXNzIGlmIEkgcmVhZCAzMjYxIGNvcnJlY3RseSBh Ym91dCByZXF1ZXN0cyB3aXRoaW4gYQ0KZGlhbG9nLCBJIHdvdWxkIGFzc3VtZSBjYXNlIDIgYnV0 IHByZXNlbmNlIG9mIHRoZSBSZWNvcmQtUm91dGUgaGFzIG1lDQpjb25mdXNlZC4NCg0KVGhhbmtz LA0KRk0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwDQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAg UHJvdG9jb2wNClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rp b25zIG9uIGN1cnJlbnQgc2lwDQpVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3Bt ZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoNCg0KDQoqKioqKioqKioqKioqKioqKioq KioqKiAgQXJpY2VudC1Qcml2YXRlICAgKioqKioqKioqKioqKioqKioqKioqKioNCg0KKioqKioq KioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUHJpdmF0ZSAgICoqKioqKioqKioqKioqKioqKioq KioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQg YW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8g d2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQg Zm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQg ZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRz IG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAK bG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRy YW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 001AA7B465257251_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIHBlciB0aGUgUkZDIDMyNjUgc2VjdGlvbiAz LjIuMyxJZg0KdGhlIEluaXRpYWwgU3Vic2NyaWJlIGNvbnRhaW5zIHRoZSBSZWNvcmQtUm91dGUg dGhlbiB0aGUgTm90aWZ5IHNob3VsZA0KZm9sbG93IHRoZSByZWNvcmQtcm91dGUgaGVhZGVyIHZh bHVlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhlIE5v dGlmeSB3aWxsIGdvIHRvIHRoZSBQcm94eSBzZXJ2ZXIuLi4uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJhbGFqaSBNdXJsaXRoYXJhbi5DPC9mb250Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7RnJhbmsgVy4gTWlsbGVyJnF1b3Q7DQombHQ7 ZndtaWxsZXJAY29ybmZlZC5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MTIvMjcvMjAwNiAxMDowMiBBTTwvZm9udD4NCjxicj4NCjx0ZCB3aWR0 aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRkIHZhbGln bj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPklFVEYgU0lQIExpc3QgJmx0O3Np cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5jYzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9w Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5bU2lwXSBSb3V0aW5nIE5PVElGWSByZXF1ZXN0czwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KQ29u c2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYXJpbzo8YnI+DQo8YnI+DQo8YnI+DQpVQTEgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UHJveHkgJm5ic3A7ICZuYnNwOyAmbmJzcDtVQTIvUFVBPGJy Pg0KfCBTVUJTQ1JJQkUgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3w8YnI+DQp8LS0tLS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fDxicj4NCnwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwO1NVQlNDUklCRSB8PGJyPg0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwtLS0tLS0tLS0tLSZndDt8PGJyPg0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7IDIwMCBPSyAmbmJzcDsgfDxicj4NCnwgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tfDxicj4NCnwgJm5ic3A7MjAwIE9LICZuYnNw OyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCnwmbHQ7 LS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJy Pg0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyBO T1RJRlkgfDxicj4NCnwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw Oz8/Jmx0Oy0tLS0tLS18PGJyPg0KfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7fDxicj4NCjxicj4N CkZ1cnRoZXIgYXNzdW1lIHRoYXQgdGhlIFByb3h5IGFkZGVkIGEgUmVjb3JkLVJvdXRlIGhlYWRl ciB0byB0aGU8YnI+DQpTVUJTQ1JJQkUgcmVxdWVzdC48YnI+DQo8YnI+DQpQZXJoYXBzIEkganVz dCBvdmVybG9va2VkIHRoaXMgYnV0IDMyNjUgYW5kIDM4NTYgZG8gbm90IGV4cGxpY2l0eSBzYXk8 YnI+DQpob3cgdGhlIE5PVElGWSBpcyB0byBiZSByb3V0ZWQuICZuYnNwO1Nob3VsZCAxKSB0aGUg Tk9USUZZIHJlcXVlc3QgYmUgcm91dGVkPGJyPg0KdGhyb3VnaCB0aGUgcHJveHkgdXNpbmcgdGhl IGFkZHJlc3MgaW4gdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgb3IgMik8YnI+DQpzZW50IGRpcmVj dGx5IHRvIHRoZSBVQTEgcGVyIHRoZSBDb250YWN0IGhlYWRlciBpbiB0aGUgU1VCU0NSSUJFPGJy Pg0KcmVxdWVzdD8gJm5ic3A7SSBndWVzcyBpZiBJIHJlYWQgMzI2MSBjb3JyZWN0bHkgYWJvdXQg cmVxdWVzdHMgd2l0aGluIGE8YnI+DQpkaWFsb2csIEkgd291bGQgYXNzdW1lIGNhc2UgMiBidXQg cHJlc2VuY2Ugb2YgdGhlIFJlY29yZC1Sb3V0ZSBoYXMgbWU8YnI+DQpjb25mdXNlZC48YnI+DQo8 YnI+DQpUaGFua3MsPGJyPg0KRk08YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpcCBtYWlsaW5nIGxpc3QgJm5ic3A7 aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPGJyPg0KVGhpcyBsaXN0 IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPGJyPg0KVXNl IHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVu dCBzaXA8YnI+DQpVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0 aGUgYXBwbGljYXRpb24gb2Ygc2lwPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqICZu YnNwO0FyaWNlbnQtUHJpdmF0ZSAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8 YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVByaXZhdGUgJm5ic3A7 ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0j ZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdl IGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBj b250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQg bm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9y IHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBp biBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5 b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcs IG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2Nl cHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRo ZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVk aW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 001AA7B465257251_=-- --===============0194936518== 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 --===============0194936518==-- From Sort@uritukuiho.org.nz Wed Dec 27 03:12:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzTty-0004bw-W4 for sip-archive@lists.ietf.org; Wed, 27 Dec 2006 03:12:42 -0500 Received: from host198-221-dynamic.5-87-r.retail.telecomitalia.it ([87.5.221.198] helo=host95-19-dynamic.4-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzTtt-0007D4-Us for sip-archive@lists.ietf.org; Wed, 27 Dec 2006 03:12:42 -0500 Received: from baroni-6jycgw1f ([133.131.164.178]:16684 "EHLO baroni-6jycgw1f" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host95-19-dynamic.4-87-r.retail.telecomitalia.it with ESMTP id S22OGJSOUASHJTFY (ORCPT ); Wed, 27 Dec 2006 09:13:02 +0100 Message-ID: <000d01c7298e$c186cbc0$5f130457@baroni6jycgw1f> From: "Show" To: sip-archive@lists.ietf.org Subject: Sansa eR with Date: Wed, 27 Dec 2006 09:12:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C72997.234B33C0" 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.1 (+++) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 ------=_NextPart_000_0009_01C72997.234B33C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C72997.234B33C0" ------=_NextPart_001_000A_01C72997.234B33C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Listen free search sign up for unlimited. Top tracks playadd un ramito de. Olvido, tu amor marfiled under channel = hear. On rhapsody my, account help homemy videosmy playlists listen. = Account help homemy videosmy, playlists, listen free search. Account = help homemy videosmy playlists listen. Sansa er with you portable the helpvisit our musicburn? Music home gt rockpop latin pop. Violetas cambio dolor como! Helpvisit our musicburn cdrhapsody of, web, = content provided reg. Top tracks, playadd un ramito, de! Similar artists this feedssave your sansa er. Amor marfiled under channel hear and similar. Playadd un, ramito de violetas cambio dolor como. Your sansa er with you = portable the helpvisit our. Allyour browser, does not? Cambio dolor, como te olvido tu amor marfiled? Web content provided reg copyright. Tu amor marfiled under, channel hear and. Dolor como te olvido tu amor = marfiled. Oreiro, on rhapsody my account help homemy. Help homemy, videosmy playlists, listen free search sign. The helpvisit our musicburn cdrhapsody of web. De violetas cambio dolor? = Tracks playadd un ramito de violetas. Not appear to, support iframesx spotlight more. ------=_NextPart_001_000A_01C72997.234B33C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Listen free search sign up for = unlimited.
Top tracks playadd un ramito de. = Olvido, tu amor=20 marfiled under channel hear. On rhapsody my, account help homemy = videosmy=20 playlists listen. Account help homemy videosmy, playlists, listen free = search.=20 Account help homemy videosmy playlists listen.
Sansa er with you portable the = helpvisit our musicburn?
Music home gt rockpop latin = pop.
Violetas cambio dolor como! Helpvisit = our musicburn=20 cdrhapsody of, web, content provided reg.
Top tracks, playadd un ramito, = de!
Similar artists this feedssave your = sansa er.
Amor marfiled under channel hear and = similar.
Playadd un, ramito de violetas cambio = dolor como.=20 Your sansa er with you portable the helpvisit our. Allyour browser, does = not?
Cambio dolor, como te olvido tu amor = marfiled?
Web content provided reg = copyright.
Tu amor marfiled under, channel hear = and. Dolor=20 como te olvido tu amor marfiled.
Oreiro, on rhapsody my account help = homemy.
Help homemy, videosmy playlists, listen = free search sign.
The helpvisit our musicburn cdrhapsody = of web. De=20 violetas cambio dolor? Tracks playadd un ramito de = violetas.
Not appear to, support iframesx = spotlight=20 more.
------=_NextPart_001_000A_01C72997.234B33C0-- ------=_NextPart_000_0009_01C72997.234B33C0 Content-Type: image/gif; name="artists this.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c7298e$c186cbc0$5f130457@baroni6jycgw1f> R0lGODlh6AFgAIfoAAsAAHYAAAB3AIONBQAAe3sGigB5ccC0vs7WsrLO/DMcAFMgAIYRAJgmAMUl AN4pAANEABpIA0Q7C1JEAH0zAJU+A8ZIANU3AABpByJlBjVnAGNXAHtsAJJoAL9UCOxdBQyEAxh/ CkVyAFOHCnKEAKmGAMSBA9dyAACoAC2dADWjAl2cAYunDpuqAr6dB+SsAwDDABnLAEzACV7GAI3G CqazBcTCC+nEBgzrAiLVCzfnAGXlCo3WAJngALXuDuHTCwoHSBQAOEQARmIAMYMAM64ITrwHM+gA RwAgThESSzQVTF0iSXcgNacmOcYpO+guNQBKQRxNNUsySmQ+ToVBNaY0Tb83PttHMgFjRR5jQzlX P1NUTodeAKtYPMtoOdZVTA13QClyRzqIM1dySIF1NJxyMcWFMdKOQwCiQiaZNk6VQWKaS4SuMpqc SMyRO92fTADAPCDJQz64Mla0QHHFN5PKSs7HOOLARwXtQyvRNjXYN23rPYbRMZ7eNM3XSeLcPgAA eR4AfEIIf10Ae4QOiasAdsAAg98AfwwahhoshEgUg1cicokcfakcjMcqd9UrgwBDdCNNfU45jWg1 hYI4gZU9gsc9dO5CiQBVdBZkiEZYfVZUdoJijJ1Yf7FijORihAF/ehtzhkt+e2lzgoqGe6dxesN+ iuxydAaddSWTiUeufFqZgnGfgK2nh7mkhOKpeQjMdCjAhEC3gWK/jnW/g6KydLrDg92yeQ7lfhvr h0rUjl/rfonbhZbRjrPtddbjcQAAwy4AyjgOx1wAsnkAs6QAscMDvegAtwUmzRsStzISzGgRzngg uZkrxcsgwtosvQ5NxRo+zUIxuGk6vohBsaBLtctLstlFzgFcsixcuUNUx1ptv4BVyJJmurxquNNe vQB9tCpyvDiDzlmJyXyIuqKKw85xxNGEugCcwCCZuzKtvFOaynqYtZimubqUsu2syA7NyCG6ujrB zlO0yYTFvp3MuP//6qKqqn13h/UOBwD/Av/xBwAA9PIG/wP/9Pby9SH5BAAlsG0ALAAAAADoAWAA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eL9kKKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bKD/q3Mmzp8+fQIMKHUq0qNGjSJMSxMm0qdOnUJVKnUq1qlWKULNq3cq1q8irYMOK HavQq9mzaNOqPUm2rdu3B9fKnUu3JNy7ePPq3cu3L9G6gAML1uq3sOHDiBMnHcy4sePHkCNLnky5 suXLKhVr3jwQs+fPjzmLFg26tOnTqFOrJjm6tevXsGPLng10te3buHPrpky7t9S1BAjABAJkt/Hj yJPPZAiguXOM/PhFBAbMt/WCwbMPpM69+kDi34EI/yQOfqny808XRie4/l/58v+cN48/f7z4g9mD E6x/fSFy4iIBaE9wIhEYUnMHAjASgug1mNVC/BXUXnvugUdehQLJx59+AnFIH0Hw9edahARRV6J3 85FIoogsxpUSdSjJt6CC9jBo440hCWiPjgYm6OCPJK3YIQEEcUjeffsB0OKSFGmo5EDyJZnhk/V5 yCF//IXIpGEqMVhSdCOBWaOXYfID5Jk3RYTlc1BS6aZ94cEp54dbwlZflHROOeWKQtbpp0Ie5jnk oP9c+SSdaw4U6J+cRXjnoYgqSeKijPbXJY0+ikTmmJnimOmYzs0oKpp1GZVonqc6Cmmlll4q46gu Of/JEpmbkoqek3uyqeeueLLqa0J9/iqbrcSiWWuxyCar7LLMNuuYsLQ5K+1x0FZr7XXTZgvYtX5q 6+234ObWQAM2BRDASAukq+4CIZnrrrnSwmsrhBoupIAC3Pa3ogP88qvQu1IadG9F/nb0wAM69Vvw QPfiK9DABJmLbUry2lNxuNq+K++9InFM8bkiXRwyyDF5/JTIMCnc76depmuPyy6XdCyyB4tUsz0q jyxSzu2+SxK/GMMUVsMOD7TwwghBnCt/+TTt9ENKn0q00grVS5+uD0ls0MJN/9N11wYF2x/YXufz MNX/QIz2P0c7QNC4+fbE1bjjklR3SHejlHdJe4v/1DdKQONNruAhOV14PixVHDjODrx0M9+D29O0 5IafhDJ69Pa6ttYrpjuQ53HrZdLBD/zceEiLW05ySSaP1Drgp4dksseLp47S4xVfDrtJMdtMeumk l2R7gwtpXRADDAjs8NpTrx16QZ69as/sCqg0/M6xj6Q7Sa1THxLyIoG/EgQQYG9+Syi7CzvQts9M LAUUmAR/SfPbUz+sQSM3f/3331+r+CEhn0gEaA8MYEAkBpwVpuxBQAaWz37xC8n9UtK/CELQJQAM 4ANPIsAObjAkCTzTQgQggIMY0CDkEwgJUQiBgaRwICd8nl5QgIJ/0FAgN8RhDVVYwoHQ8Ic7/AcJ /4dIEAMa0SEvFMgLyddCIfbQiQ1ZoRKb+I8kLiSGPgwiQk7IRQwUBIuzUQkMYGASfeijJCF0IBNF MsY2kqSB+asJUoZIRBcykYpGsaIT6bi0VSmEiVMEpEOkOJA2GrIgSRTkQAgpw0aOxiRjpAwNVzLJ tZAwK3D8kSNDhwMckAWMCDEjYsTmmjiaMjWRTMklV7PKU7rylWtJJSwts8la2jJfs8ylXG7Jy14i RZfADKYwbeLLYhqzTsNUVuZ6Ra/DkHInJjqmNPNyKZl4SUMFEs6AtJkSJ7mvm9hMUKg0tcC06Cgk 0UmnmJLJTlpWzY8NiaaEpFMoItXzIc9MCHzKk/+qXslzJ7j6xz+nSdCqqORI5zSJrGSGKekpsCT5 4WY4e2Sga2KqRyHBaFYcus12etQzEHkUm051NV3lJ6TwbNOeAkaniHoonx05aZKYWdCaGuUl7rMo yxo6zpZ801PkDCqnFFrOs/SUqB9NKmRQCqxDPWqlKmVqQQKqIje9aVeCEgpNo2rTrlaFpGFzqliZ CVOuYvWpU7VaSSFV1Z+kCJ5l3YxS0cScrQYMa01V06pEitWD5FNXca3IW8+a0sLMNakLBWdMarXQ nxZ1MIkF1TcPS9mzICWwGVFrWDDr1c7upLI4fSxoR1sqz5r2tKj1FWlXy9rWuhY0qZ3Ka18b29qH umi2uC2WbY+ZW2XuNoy9Da5wh0vcwPz2uMhNrnKXy9zmOtcgxb3Nc6dLXehFV7jVzW5frsvd7noX mNpV7nfHS97ymve86E2vO8PL3va61y/qjcl750vf+nYrvnG0r37/hN/+vnK/sfGvgAdM4AIbuLwA 3u6BF5zMBMuVwYJxsIQnTOEK+yUgADs= ------=_NextPart_000_0009_01C72997.234B33C0-- From sip-bounces@ietf.org Wed Dec 27 10:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzalb-0002Pa-2R; Wed, 27 Dec 2006 10:32:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzala-0002PU-4v for sip@ietf.org; Wed, 27 Dec 2006 10:32:30 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzalX-0007rH-Sa for sip@ietf.org; Wed, 27 Dec 2006 10:32:30 -0500 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id kBREag90024731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Dec 2006 08:36:43 -0600 Message-ID: <459293E1.3090402@softarmor.com> Date: Wed, 27 Dec 2006 09:40:17 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> <458F1308.2070601@softarmor.com> <17807.39967.360179.793067@harjus.tutpro.com> In-Reply-To: <17807.39967.360179.793067@harjus.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , 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 Juha Heinanen wrote: > Dean Willis writes: > > > How about we rip out UDP, fix the Outbound stuff, fix the > > route-construction stuff, fix the early-media stuff. and call it SIP > > 3.0? > > good idea, but you forgot to add SIPS to the rip out list. Nah, I'd just make that end-to-end using Vijay's sipsec: draft. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 ddbdeg@captive-entertainment.com Wed Dec 27 23:09:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzmZl-000141-S2 for sip-archive@lists.ietf.org; Wed, 27 Dec 2006 23:09:06 -0500 Received: from [61.83.201.125] (helo=home-memeiw26kv) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzmZj-0005hn-C1 for sip-archive@lists.ietf.org; Wed, 27 Dec 2006 23:09:05 -0500 Date: Thu, 28 Dec 2006 20:20:01 +0480 From: Nasdaq.com Alert! X-Mailer: The Bat! (v2.10.01) Educational Reply-To: ddbdeg X-Priority: 3 (Normal) Message-ID: <61771131.20061228202001@captive-entertainment.com> To: sip-archive@lists.ietf.org Subject: Develop your success using our strategy that we provide for you MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.9 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
TAKE PLEASURE IN GREAT PROFIT= BY NORTHAMERICAN ENERGY GROUP CORP.(NNYG.PK)!
BUY NNYG AFTER CHRISTMAS DO NOT MISS Y= OUR POSSIBILITY. IT IS COMING TO BURT!
WE PROPOSE THE NEXT = PRICES:
CURRENT_PRICE: $0.024 RATIONAL IT USING! TARGET PRICE IN 1 WEEK: 0.09$
READMORE INFORMATION= ABOUT THIS INCREDIBLE COMPANY USE YOUR BROKERAGE SITE.
WE INSURE YOU THAT YOU CAN TRIPLE YOUR= INVESTMENTS WITH US.
From 9075stocknews@torfi.com Thu Dec 28 05:22:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzsPB-0003el-N6 for sip-archive@lists.ietf.org; Thu, 28 Dec 2006 05:22:33 -0500 Received: from [85.102.242.47] (helo=dsl85-102-61999.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzsPA-0003NR-6N for sip-archive@lists.ietf.org; Thu, 28 Dec 2006 05:22:33 -0500 Date: Thu, 28 Dec 2006 10:22:32 -0120 From: Pinksheets alert! <9075stocknews@torfi.com> X-Mailer: The Bat! (v2.11) UNREG / CD5BF9353B3B7091 Reply-To: Pinksheets alert! <9075stocknews@torfi.com> X-Priority: 3 (Normal) To: sip-archive@lists.ietf.org Subject: Develop your success using our strategy that we provide for you MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 3.6 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
TO INCREASE YOUR INVESTMENTS WE PROVIDE YOU NORTHAMERICAN ENERGY GROUP CORP. (NNYG).
JUST GET NNYG AFTER CHRISTMAS. HURRY THIS SHARE IS GOING TO BURT!!!
WE WANT TO PROPOSE YOU THE NEXT PRICES:
CURRENT_PRICE: $0.024 GETTING CLOSER IT RIGHT NOW! TARGET PRICE IN 1 WEEK: 0.09$
IF YOU WANT TO READ FULL INFORMATION ABOUT NNYG USE YOUR BROKERAGE SITE.
ONLY WITH US YOU CAN DOUBLE YOUR INVESTMENTS PER 1 WEEK.
From sip-bounces@ietf.org Fri Dec 29 00:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H09sz-0000fo-Hm; Fri, 29 Dec 2006 00:02:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H09sy-0000fi-SG for sip@ietf.org; Fri, 29 Dec 2006 00:02:28 -0500 Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H09sw-0007Hm-9V for sip@ietf.org; Fri, 29 Dec 2006 00:02:28 -0500 Received: (qmail 2506 invoked by uid 510); 28 Dec 2006 23:16:38 -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.5/1.7):. Processed in 1.246136 secs); 29 Dec 2006 05:16:38 -0000 X-Spam-Status: No, hits=-102.5 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.5/1.7):. Processed in 1.246136 secs Process 2484) Received: from unknown (HELO annasagaramv) (annasagaram.vamsi@aftek.com@59.95.41.72) by mail.aftek.com with SMTP; 28 Dec 2006 23:16:37 -0600 From: "vamsi" To: "'IETF SIP List'" Date: Fri, 29 Dec 2006 10:44:42 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccpdMt5o4JMtqaKRdqR6Y+Nu9MD6ABktICg X-Antivirus-MYDOMAIN-Message-ID: <11673693978352484@plain.ev1servers.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'Balaji Murlitharan' Subject: [Sip] SMS via 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="===============1523785135==" Errors-To: sip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1523785135== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C72B36.5BC7D640" This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C72B36.5BC7D640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Can any one give pointers where to start for SMS over VoIP. Any RFCs? Any pointer from where to start will be highly appreciable. Is the rfc 3761 appropriate for implmenting SMS via VoIP? thanks & regards, vamsi. ------=_NextPart_000_0058_01C72B36.5BC7D640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
     Can any one = give pointers=20 where to start for SMS over VoIP.  Any RFCs? Any pointer from where = to=20 start will be highly appreciable. Is the rfc=20 3761 appropriate for implmenting SMS via VoIP?
 
thanks & regards,
 vamsi.
<= /BODY> ------=_NextPart_000_0058_01C72B36.5BC7D640-- --===============1523785135== 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 --===============1523785135==-- From sip-bounces@ietf.org Fri Dec 29 00:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0A4H-0005db-Ec; Fri, 29 Dec 2006 00:14:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0A4G-0005dW-7J for sip@ietf.org; Fri, 29 Dec 2006 00:14:08 -0500 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0A4F-0001O1-04 for sip@ietf.org; Fri, 29 Dec 2006 00:14:08 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20061229051405m1400fekoqe>; Fri, 29 Dec 2006 05:14:06 +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 kBT5E45M019932 for ; Fri, 29 Dec 2006 00:14:04 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBT5E4Nv019928; Fri, 29 Dec 2006 00:14:04 -0500 Date: Fri, 29 Dec 2006 00:14:04 -0500 Message-Id: <200612290514.kBT5E4Nv019928@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (annasagaram.vamsi@aftek.com) Subject: Re: [Sip] SMS via VoIP References: 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: "vamsi" Can any one give pointers where to start for SMS over VoIP. Any RFCs? Any pointer from where to start will be highly appreciable. Is the rfc 3761 appropriate for implmenting SMS via VoIP? ENUM (RFC 3761) is probably a good basis for addressing SMS messages. The MESSAGE method seems to be the best way to send a stand-alone message to a SIP URI. But for message conversations, there is a "codec" type for SDP for IM-like communications that should usually be used. 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 Dec 29 01:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0BRE-0000ah-L2; Fri, 29 Dec 2006 01:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0BRD-0000aQ-C9 for sip@ietf.org; Fri, 29 Dec 2006 01:41:55 -0500 Received: from axesmail.axestechnologies.com ([202.144.91.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0BPA-0002Yy-JQ for sip@ietf.org; Fri, 29 Dec 2006 01:39:50 -0500 Received: from axesind ([192.168.5.3]) by axesmail.axestechnologies.com (8.12.10+Sun/8.12.10) with ESMTP id kBT6ct6j021230 for ; Fri, 29 Dec 2006 12:09:35 +0530 (IST) Received: from SINBNGBH001.TechMahindra.com (unknown [192.168.5.35])by axesind (Postfix) with ESMTP id 81451BA7CFfor ; Fri, 29 Dec 2006 11:45:06 +0530 (IST) Received: from SINBNGEX001.TechMahindra.com ([192.168.5.31]) by SINBNGBH001.TechMahindra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 12:05:24 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Dec 2006 12:05:17 +0530 Message-ID: <5C5A863D4858FC41818EF1C777DB6CFA01C79D8E@SINBNGEX001.TechMahindra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transport used by SIP UA Thread-Index: AccrE4DedXAmq4BjRcyzMrx33v/cXQ== From: "Adarsh Guler" To: X-OriginalArrivalTime: 29 Dec 2006 06:35:24.0342 (UTC) FILETIME=[85420D60:01C72B13] X-imss-version: 2.045 X-imss-result: Passed X-imss-approveListMatch: *@techmahindra.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Sip] Transport used by SIP 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: , Content-Type: multipart/mixed; boundary="===============1475157648==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1475157648== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72B13.84D976A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72B13.84D976A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI =20 If an UAC is configured to use the UDP port and a SIP Proxy is configured to use TCP port. The UAC is keep sending messages in UDP port, but Sip Proxy don't respond, since it is listening on TCP port. =20 In this scenario, how UAC should know that Proxy is listening on TCP Port....??? =20 Thanks Adarsh. =20 ------_=_NextPart_001_01C72B13.84D976A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI

 

If an UAC is configured to use the UDP port and a SIP = Proxy is configured to use TCP port.

The UAC is keep sending messages in UDP port, but Sip = Proxy don’t respond, since it is listening on TCP port.

 

In this scenario, how UAC should know that Proxy is listening on TCP Port….???=

 

Thanks

Adarsh.

 

------_=_NextPart_001_01C72B13.84D976A6-- --===============1475157648== 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 --===============1475157648==-- From sip-bounces@ietf.org Fri Dec 29 02:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0CRg-0006ko-Jh; Fri, 29 Dec 2006 02:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0CRe-0006ih-Tb for sip@ietf.org; Fri, 29 Dec 2006 02:46:26 -0500 Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0CRc-0008Bo-Uv for sip@ietf.org; Fri, 29 Dec 2006 02:46:26 -0500 Received: (qmail 19102 invoked by uid 510); 29 Dec 2006 02:00:37 -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.5/1.7):. Processed in 4.724231 secs); 29 Dec 2006 08:00:37 -0000 X-Spam-Status: No, hits=-102.5 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.5/1.7):. Processed in 4.724231 secs Process 19062) Received: from unknown (HELO annasagaramv) (annasagaram.vamsi@aftek.com@59.95.41.72) by mail.aftek.com with SMTP; 29 Dec 2006 02:00:32 -0600 From: "vamsi" To: Subject: RE: [Sip] SMS via VoIP Date: Fri, 29 Dec 2006 13:28:39 +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 In-Reply-To: <200612290514.kBT5E4Nv019928@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccrCk+w7z4SrcpiS9yCG29VZfHzoAAE9qRg X-Antivirus-MYDOMAIN-Message-ID: <116737923383519062@plain.ev1servers.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Message-Id: Hi Dale, 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. Thanks & regards, Annasagaram vamsi. -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Friday, December 29, 2006 10:44 AM To: sip@ietf.org Subject: Re: [Sip] SMS via VoIP From: "vamsi" Can any one give pointers where to start for SMS over VoIP. Any RFCs? Any pointer from where to start will be highly appreciable. Is the rfc 3761 appropriate for implmenting SMS via VoIP? ENUM (RFC 3761) is probably a good basis for addressing SMS messages. The MESSAGE method seems to be the best way to send a stand-alone message to a SIP URI. But for message conversations, there is a "codec" type for SDP for IM-like communications that should usually be used. 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 Fri Dec 29 02:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0CZu-000206-0a; Fri, 29 Dec 2006 02:54:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0CZs-0001yw-OB for sip@ietf.org; Fri, 29 Dec 2006 02:54:56 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0CZn-0000sI-MR for sip@ietf.org; Fri, 29 Dec 2006 02:54:56 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB00013FYVGC7@szxga03-in.huawei.com> for sip@ietf.org; Fri, 29 Dec 2006 15:45:16 +0800 (CST) Received: from huawei.com ([172.24.2.9]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB000FI6YVFT4@szxga04-in.huawei.com> for sip@ietf.org; Fri, 29 Dec 2006 15:45:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB0005NPYVFZQ@szxga03-in.huawei.com> for sip@ietf.org; Fri, 29 Dec 2006 15:45:15 +0800 (CST) Received: from x18916 ([10.85.204.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JB000EBDYVC4I@szxml04-in.huawei.com> for sip@ietf.org; Fri, 29 Dec 2006 15:45:15 +0800 (CST) Date: Fri, 29 Dec 2006 15:45:12 +0800 From: Peili Xu Subject: RE: [Sip] SMS via VoIP In-reply-to: To: 'vamsi' , 'IETF SIP List' Message-id: <00d301c72b1d$45a05590$9acc550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccpdMt5o4JMtqaKRdqR6Y+Nu9MD6ABktICgAAUWrCA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 'Balaji Murlitharan' 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="===============1643778392==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1643778392== Content-type: multipart/alternative; boundary="Boundary_(ID_xum2wmW5CQ4lTVq5l7IfSQ)" This is a multi-part message in MIME format. --Boundary_(ID_xum2wmW5CQ4lTVq5l7IfSQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Vamsi, If you are considering to transport traditional SMS service over SIP, 3GPP 23.204/24.341 is dealing with this topic. It is based on SIP MESSAGE request. You can get the specs from http://www.3gpp.org/specs/specs.htm. If you are considering implementing SMS-like service by SIP, the MESSAGE request is ready for you. Cheers. Peili _____ From: vamsi [mailto:annasagaram.vamsi@aftek.com] Sent: Friday, December 29, 2006 1:15 PM To: 'IETF SIP List' Cc: 'Balaji Murlitharan' Subject: [Sip] SMS via VoIP Hi, Can any one give pointers where to start for SMS over VoIP. Any RFCs? Any pointer from where to start will be highly appreciable. Is the rfc 3761 appropriate for implmenting SMS via VoIP? thanks & regards, vamsi. --Boundary_(ID_xum2wmW5CQ4lTVq5l7IfSQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Vamsi,
 
If you are considering to transport traditional SMS service over SIP, 3GPP 23.204/24.341 is dealing with this topic.
It is based on SIP MESSAGE request. You can get the specs from http://www.3gpp.org/specs/specs.htm.
 
If you are considering implementing SMS-like service by SIP, the MESSAGE request is ready for you.
 
Cheers.
Peili
 
From: vamsi [mailto:annasagaram.vamsi@aftek.com]
Sent: Friday, December 29, 2006 1:15 PM
To: 'IETF SIP List'
Cc: 'Balaji Murlitharan'
Subject: [Sip] SMS via VoIP

Hi,
     Can any one give pointers where to start for SMS over VoIP.  Any RFCs? Any pointer from where to start will be highly appreciable. Is the rfc 3761 appropriate for implmenting SMS via VoIP?
 
thanks & regards,
 vamsi.
--Boundary_(ID_xum2wmW5CQ4lTVq5l7IfSQ)-- --===============1643778392== 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 --===============1643778392==-- From sip-bounces@ietf.org Fri Dec 29 03:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Ckm-0004bB-LM; Fri, 29 Dec 2006 03:06:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Ckk-0004b4-Uw for sip@ietf.org; Fri, 29 Dec 2006 03:06:10 -0500 Received: from web52806.mail.yahoo.com ([206.190.48.249]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0Cki-00041B-KI for sip@ietf.org; Fri, 29 Dec 2006 03:06:10 -0500 Received: (qmail 37105 invoked by uid 60001); 29 Dec 2006 08:06:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D1LrWnaaY/72Icd9+s3CR2kWWNt0fPxkuOKaf7WNum7fJwqSmEh1az/PDtLlYhwejMmIZKHukWDfgjfI0Hxsg2TCChFctHLu7s8hJGiOD/eyd4T8rw+o1ps4BEQnqVX56cjK59dX+11EmSsU6MwhWBdUh/gvIR2oI1sd7mKO6Yc= ; Message-ID: <20061229080608.37103.qmail@web52806.mail.yahoo.com> Received: from [47.168.54.136] by web52806.mail.yahoo.com via HTTP; Fri, 29 Dec 2006 00:06:08 PST Date: Fri, 29 Dec 2006 00:06:08 -0800 (PST) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: [Sip] SMS via VoIP To: vamsi , Dale.Worley@comcast.net MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 The Message Session Relay Protocol (MSRP)=0A=0Ahttp://www.ietf.org/internet= -drafts/draft-ietf-simple-message-sessions-18.txt=0A=0A Message Session Rel= ay Protocol; a protocol for transmitting a series of related instant messa= ges in the context of a session. Message sessions are treated like any oth= er media stream when set up via a rendezvous or session creation protocol s= uch as the Session Initiation Protocol.=0A=0A m=3Dmessage 7654 TCP/MSRP *= =0A=0A=0A----- Original Message ----=0AFrom: vamsi =0ATo: Dale.Worley@comcast.net=0ACc: IETF SIP List =0ASe= nt: Friday, December 29, 2006 9:58:39 AM=0ASubject: RE: [Sip] SMS via VoIP= =0A=0A=0AHi Dale,=0A Thanks for the message. But for MESSAGE conversat= ion, what kind of=0Acodec is used, that is audio codec or any other specifi= ed codec? As per RFC=0A3551 Audio and video codecs are specified. =0A=0AT= hanks & regards,=0AAnnasagaram vamsi. =0A =0A=0A-----Original Mes= sage-----=0AFrom: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] = =0ASent: Friday, December 29, 2006 10:44 AM=0ATo: sip@ietf.org=0ASubject: R= e: [Sip] SMS via VoIP=0A=0A From: "vamsi" = =0A=0A Can any one give pointers where to start for SMS over VoIP. Any= =0A RFCs? Any pointer from where to start will be highly=0A appreciabl= e. Is the rfc 3761 appropriate for implmenting SMS via=0A VoIP?=0A=0AENUM= (RFC 3761) is probably a good basis for addressing SMS messages.=0AThe MES= SAGE method seems to be the best way to send a stand-alone message to=0Aa S= IP URI. But for message conversations, there is a "codec" type for SDP=0Af= or IM-like communications that should usually be used.=0A=0ADale=0A=0A_____= __________________________________________=0ASip mailing list https://www1= .ietf.org/mailman/listinfo/sip=0AThis list is for NEW development of the co= re SIP Protocol Use=0Asip-implementors@cs.columbia.edu for questions on cur= rent sip Use=0Asipping@ietf.org for new developments on the application of = sip=0A=0A=0A=0A=0A_______________________________________________=0ASip mai= ling list https://www1.ietf.org/mailman/listinfo/sip=0AThis list is for NE= W development of the core SIP Protocol=0AUse sip-implementors@cs.columbia.e= du 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 Fri Dec 29 04:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dh7-0000Vz-PP; Fri, 29 Dec 2006 04:06:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dh6-0000Vs-Oa for sip@ietf.org; Fri, 29 Dec 2006 04:06:28 -0500 Received: from web52806.mail.yahoo.com ([206.190.48.249]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0Dh5-0007QW-ER for sip@ietf.org; Fri, 29 Dec 2006 04:06:28 -0500 Received: (qmail 61192 invoked by uid 60001); 29 Dec 2006 09:06:27 -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=xYXNZuosj/bvTeJn24n/2OQ4rh/IYnrRWMukCgxKmWvN00CLrX1jZZGzeFY9YWPuIhyuCERZLUgQxwEMGcpHIvU2X31mbmAHPsB59cmsps05SbKariLS1kFFGrWtGjE8gCpMjDidJOWY+Tw1T7LlvlZXK5vE0mjWWinFVon0ZsM= ; Message-ID: <20061229090627.61190.qmail@web52806.mail.yahoo.com> Received: from [47.168.54.136] by web52806.mail.yahoo.com via HTTP; Fri, 29 Dec 2006 01:06:27 PST Date: Fri, 29 Dec 2006 01:06:27 -0800 (PST) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: [Sip] Transport used by SIP UA To: Adarsh Guler , sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============1975864528==" Errors-To: sip-bounces@ietf.org --===============1975864528== Content-Type: multipart/alternative; boundary="0-1617520466-1167383187=:60079" --0-1617520466-1167383187=:60079 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RFC3261 18.2.1:=0A-------------------------------=0A"A server SHOULD be pr= epared to receive requests on any IP address, port and transport combinatio= n that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is h= anded out for the purposes of communicating with that server. "=0A=0A=0A---= -- Original Message ----=0AFrom: Adarsh Guler =0A= To: sip@ietf.org=0ASent: Friday, December 29, 2006 8:35:17 AM=0ASubject: [S= ip] Transport used by SIP UA=0A=0A=0AHI=0A =0AIf an UAC is configured to us= e the UDP port and a SIP Proxy is configured to use TCP port.=0AThe UAC is = keep sending messages in UDP port, but Sip Proxy don=92t respond, since it = is listening on TCP port.=0A =0AIn this scenario, how UAC should know that = Proxy is listening on TCP Port =85.???=0A =0AThanks=0AAdarsh.=0A =0A_______= ________________________________________=0ASip mailing list https://www1.i= etf.org/mailman/listinfo/sip=0AThis list is for NEW development of the core= SIP Protocol=0AUse sip-implementors@cs.columbia.edu for questions on curre= nt sip=0AUse sipping@ietf.org for new developments on the application of si= p --0-1617520466-1167383187=:60079 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
RFC3261  18.2.1:
=0A
---------= ----------------------
=0A
"A server SHOULD be prepared to re= ceive requests on any IP address, port and transport combination that can b= e the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out fo= r the purposes of communicating with that server. "
=0A
=
 
=0A
----- Original Message ----
From: Adarsh Gu= ler <adarshg@TechMahindra.com>
To: sip@ietf.org
Sent: Friday, D= ecember 29, 2006 8:35:17 AM
Subject: [Sip] Transport used by SIP UA
<= BR>=0A=0A=0A=0A

HI

=0A

 

=0A

If an UAC is configured to use the UDP port and a SIP Proxy is configured = to use TCP port.

=0A

The UAC is k= eep sending messages in UDP port, but Sip Proxy don=92t respond, since it i= s listening on TCP port.

=0A

&nbs= p;

=0A

In this scenario, how UAC = should know that Proxy is listening on TCP Port =85.???

= =0A

 

=0A

Thanks

=0A

Adarsh.<= /FONT>

=0A

 

=0A<= DIV>_______________________________________________
Sip mailing list&nbs= p; https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW = development of the core SIP Protocol
Use sip-implementors@cs.columbia.ed= u for questions on current sip
Use sipping@ietf.org for new developments= on the application of sip
=0A

<= /html> --0-1617520466-1167383187=:60079-- --===============1975864528== 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 --===============1975864528==-- From sip-bounces@ietf.org Fri Dec 29 23:06:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VSv-0005is-Rm; Fri, 29 Dec 2006 23:05:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VSu-0005g4-Rx for sip@ietf.org; Fri, 29 Dec 2006 23:05:00 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0VSs-0003kC-Jm for sip@ietf.org; Fri, 29 Dec 2006 23:05:00 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20061230040448m1200sojdqe>; Sat, 30 Dec 2006 04:04:53 +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 kBU44l5M023374 for ; Fri, 29 Dec 2006 23:04:47 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBU44lid023370; Fri, 29 Dec 2006 23:04:47 -0500 Date: Fri, 29 Dec 2006 23:04:47 -0500 Message-Id: <200612300404.kBU44lid023370@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5C5A863D4858FC41818EF1C777DB6CFA01C79D8E@SINBNGEX001.TechMahindra.com> (adarshg@TechMahindra.com) Subject: Re: [Sip] Transport used by SIP UA References: <5C5A863D4858FC41818EF1C777DB6CFA01C79D8E@SINBNGEX001.TechMahindra.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: "Adarsh Guler" If an UAC is configured to use the UDP port and a SIP Proxy is configured to use TCP port. The UAC is keep sending messages in UDP port, but Sip Proxy don't respond, since it is listening on TCP port. In this scenario, how UAC should know that Proxy is listening on TCP Port....??? If the UAC decides to send a message to a SIP proxy, it must have learned, by some method, the SIP proxy's host address, port number, and protocol on which it is listening. This information is derived from the SIP URI which the UAC attempts to send to. The process is described in RFC 3263. 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 Dec 29 23:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VYF-0007Xj-5k; Fri, 29 Dec 2006 23:10:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VYD-0007Xe-8T for sip@ietf.org; Fri, 29 Dec 2006 23:10:29 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0VYC-00066T-2o for sip@ietf.org; Fri, 29 Dec 2006 23:10:29 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2006123004102701300odr1oe>; Sat, 30 Dec 2006 04:10:27 +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 kBU4AR5M023822 for ; Fri, 29 Dec 2006 23:10:27 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id kBU4ARqG023818; Fri, 29 Dec 2006 23:10:27 -0500 Date: Fri, 29 Dec 2006 23:10:27 -0500 Message-Id: <200612300410.kBU4ARqG023818@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200612290755.kBT7t45M031699@dragon.ariadne.com> (annasagaram.vamsi@aftek.com) Subject: Re: [Sip] SMS via VoIP References: <200612290755.kBT7t45M031699@dragon.ariadne.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: "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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Simpson@1st-bad-credit-home-loans.com Sat Dec 30 03:59:50 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0a4E-0002JZ-GQ for sip-archive@lists.ietf.org; Sat, 30 Dec 2006 03:59:50 -0500 Received: from p54877823.dip.t-dialin.net ([84.135.120.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0a42-0006g9-Ld for sip-archive@lists.ietf.org; Sat, 30 Dec 2006 03:59:44 -0500 Received: from [143.119.4.179] (port=7889 helo=[143.119.4.179]) by p54877823.dip.t-dialin.net with esmtp id 1BWHVZ-000CSC-45 for sip-archive@lists.ietf.org; Sat, 30 Dec 2006 09:59:43 +0100 Message-ID: <000d01c72bf0$cdefaad0$23788754@mrf7h0i9uemawr> From: "Anderson Carmen" To: sip-archive@lists.ietf.org Subject: Advanced Date: Sat, 30 Dec 2006 09:59:25 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C72BF9.2FB412D0" 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.4 (+++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc ------=_NextPart_000_0009_01C72BF9.2FB412D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C72BF9.2FB412D0" ------=_NextPart_001_000A_01C72BF9.2FB412D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Anna kournikova catherine zeta today advanced? Stephanie adriana lima, = britney! Beyonce knowles, pamela anderson carmen. Zeta today advanced naomi. Pamela anderson carmen electra anna, = kournikova. Rating actors musicians athletes groups all listmost popular = gwen. And biography at rating actors musicians? All listmost, popular gwen = stephanie. Today advanced naomi carter fa nicole wyle! Anna kournikova catherine = zeta today, advanced. Actors musicians athletes groups all listmost popular gwen, stephanie. Trivia and, biography at rating. At rating actors musicians! Stephanie adriana lima britney spears. Advanced naomi carter fa nicole wyle copyright. Pamela anderson carmen = electra anna kournikova catherine zeta. Photos quotes trivia and = biography at rating actors. Anderson carmen electra anna kournikova = catherine zeta, today advanced. Kournikova catherine zeta today. Catherine zeta today advanced. All, listmost popular gwen. Spears, paris hilton jessica simpson beyonce knowles. ------=_NextPart_001_000A_01C72BF9.2FB412D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Anna kournikova catherine zeta today = advanced?=20 Stephanie adriana lima, britney!
Beyonce knowles, pamela anderson = carmen.
Zeta today advanced naomi. Pamela = anderson carmen=20 electra anna, kournikova. Rating actors musicians athletes groups all = listmost=20 popular gwen.
And biography at rating actors = musicians? All=20 listmost, popular gwen stephanie.
Today advanced naomi carter fa nicole = wyle! Anna=20 kournikova catherine zeta today, advanced.
Actors musicians athletes groups all = listmost=20 popular gwen, stephanie.
Trivia and, biography at = rating.
At rating actors musicians! Stephanie = adriana lima=20 britney spears.
Advanced naomi carter fa nicole wyle = copyright.=20 Pamela anderson carmen electra anna kournikova catherine zeta. Photos = quotes=20 trivia and biography at rating actors. Anderson carmen electra anna = kournikova=20 catherine zeta, today advanced.
Kournikova catherine zeta = today.
Catherine zeta today = advanced.
All, listmost popular = gwen.
Spears, paris hilton jessica simpson = beyonce=20 knowles.
------=_NextPart_001_000A_01C72BF9.2FB412D0-- ------=_NextPart_000_0009_01C72BF9.2FB412D0 Content-Type: image/gif; name="Musicians Athletes.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c72bf0$cdefaad0$23788754@mrf7h0i9uemawr> R0lGODlhCAJsAIfoAAAAAHkAAACMBnR5BgwAi40FjQOHirXKwL/lzZjH8jkrClwaAHgUAJwWA80r CeMeBQYxAxgzCk40C2tCAok/AKlEALg1ANFHAApuACZkADFUA1FlCXFVAKNUDrtUAOVqDAx8ABSO ADp5B1uKAH9xAJZ3ALOMDtl+DgChBCqhAUemAGykAHKUAJaRC7+UAN2cAAbBABrBDj2+AFK7DXi3 Dpu9DM7MANfDBgTsCh/rCDfTDFLjAH/WBpzUAMbeAOfRBwQASikHMj0CSGgAM4EAM5cAOMkHS9gA PAAZOx4eTToeP20bS3EcQKghTMwjQu4aPwAyPyU1SEo3Pl05TIs/Q6hFOcM5NthAPgBqNituRD1Z M21bSYpnAq1pN85oPulnRgKEQiOGMkeNPVZ4QH+MM6VzTbR5TN9yRwCkNi6ROUSsMlWSTnugNKmq QsyWQ9qRPwDHOCK+QjSxTmSzPHqyPaq9PcjLNuS2SQDpOR3kNDfWSWDYSIzRSZzkN7vnRdPaQQII fBsAijcLgWYMiIUAhq4JcrwAjdIMhA0hiisadkcqi24ciYcocpgXdcYnf9smiQBGixJAektKe2gy f3dNdpg6f7Y0jOA2eAdVcShkgUFYgF5pfYlmh5Zad8RXcutbjQB5ciRye0d+e2h/eYKFh6OCibd3 fOJ4cwCXiSaaeDGrgmqXd3+RgaSZdbihetesjAvKjCbLfka3clazgHm1daTJfcaxit/OiAngiC3n fEnre1nnhXzYdpvphbzWjOHpggwFwCkAtDQAuFYOxYIAu60Au7oAtNgAwQAYshcSuDglvGwgxnkh xasqv7MuttIitgBLthJFsjQxy2JIznZIyqY2sb07y+lNyQ1sxxFmtkZfuFlptolgyZhbvcVtxeJU sgp9yyiDt06FzFFxy3Z9spp9wsB2xOyKywCiuByhzUWqvVWdwHycu52SvLykt9STzQC7wBO/yDzG zm28w4XNu628yv387puanIeFg/kAAQD5Df//AAwA+f8A/wD///7x/yH5BAAc4poALAAAAAAIAmwA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePGO2JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0KEqQSJMqXcq0qdOnUKNKnUq1qtWrWLNqnWi0q9evYMOK HUu2rNmyW9OqXcu2rdu3cCGenUu3rl2xcfPq3cu3r9+FdwMLHky4sOHDiBMrXsy4sePHkCNLnlz3 r+XLmDNr3sy5s2eQlEOLHk26tOnTqFPL/My69VLVsEm7nh0ytu3buHPrlky79+zdwG/7Ht45uPHj yJN7Jc68ufPn0KM3V069ek3p2LNr3869e3Tr4MOL/x9Pvrz58+jTq1/Pvr379/CDep9Pv779+/jz K4x/V7///wAGKOCABBboGn8I3gYAAAk2yJKB27W04IQM3rRgTBc6qOGGuGUokoc0NdBATAEE0B5n FAIwkIgsNkBQiQPB+E+JMkJoY0EKKIBQjgLxKJADQAL5T5Ax0lijQj7e6NeCAzH5j5NPqtijjv8k +U8++SgZIEsgkvTAAyJ9ORKW+dhDppll2hOkSECOtMCbb5LU5kglmrfZkQRBGaVAMOKpp5Y3fino Ay/SSJCQQzrwo6J7CuTkmwNBKhCWBH0J6FtWEmSljxQaJGlSHEYmUY1BMuqolE46maSPq1J5ZZaX 6v/150CU0gqroQZl+lSoh0lk6al6skolp1I22uqKLsaaFwMMCMQss3wGUOiiiBIkorL5sZQjSdvS aaKcDrAZrprjMjuSufbUKZK69nTJK14JVZvooocyymOmumLrXUsU9OtvSeiOBAEEIg1cMMH2DKww wgkzbPDBJLn7bln9jlSxPQEHfPHFInE8MXUYYYDBRiKXTNDAJ0OgL1sotOyyQALELHOexTq5cEIf s/dwzjz3LJxFs67Mmc9EpyT00UgVrfTSdiHt9NNQR00g0/JJbbVfVCN39dVZM+YRAQRsBQQQ/o0N IJcprgQMMF2bBdHaBq0tt0Jg101Q3WBDxA8/HwX/LVHeBpk9Ed5h01xzsQIBfiOUfm+NWYpSKq54 QXALVLnkhTPU+EVO1jT22CV9DoRLHoI9kukfMnihxBKzt/ZIr7dL4Ugeyh277BOW1HrbPs0ecYWy S1jh7berzbZPth9POEwSo75S3Sh5uLrqwP9+nuaHA0s5MKcahDlBgjv+lOgCwX68PcWnlKH01ae0 N0mgixQ/5C45bz8BL0n8/kq+m1Q727ZTX/vaQ7/UmQR17mIf78SSO+sZMCWiox3wdkeS4inQHp+T 3+hYsr/gPVB4J3EeSkwnQnvsrYMiWR70SoJC8WDvIJW7W+EmlzjCZU58VSFf93a4kPBBriF6YpyU /+AmkvSh5Hbxw+AGW5JE+C3xJPFrYgXPN8XXpY+C6GHdANe3xQEuMCwkxJ8Hx6gSLbZEhPf7IBbV OEEvRs+LFIScF0sYvOnpzo3VeaFBZpUqxPEwiH7EYURoYscxXtCQXSRd9S54yDK2UYL5g2P7zMhG /1GPjJgkoCQtKcEG4q5La/yihdImkihNiGaGA+Tm9pg9U/4xkAg5pSlX2aQU1bJTPETlLfl4OD/S UpDAtMovmaJKWf6QL8N0SDKDycynLFMpq3zmbKTZzGoyZ3PULE0olWPNzZxmm6IM52m6Sc5ymvOc wxGnOn+CTrh8qp0HWid/2CXPBcITJDnKZ74Osv9PAFHzngBVSj9zpU9XaQROCF0AU/DklGsdRF5I q6dk5qQtBYykWz6haFEw6pVBiSlMghJKQEdqkGc9a5dSgpazmkWtaiEKogpRaSqLVdCBmFSmRpJW tHBVJYN+xKQIgak3JcqeiMjUICgTSFIL4iSVHnUhTy2IShWmy0Ytdan9KkhWk2IkhIiMpGCFylKR qjKllrUgMRvIzR6S1oR89R9j/Udb5SoAgbz1H3ed61NMdhC9hvWvSLkrK7UHLFnOEiKCFYg+FsvY XML1rEldGFXtOjKpMFYfZAWsZuWykp3t7CQlK5lIFjsS0ooktDCBAQxKotqRtNYeIitJzEYyW3v/ tAwltQXLbW9LEhzggKjAPUtoMTCThymMJK99yWft8VrVrta2KCiJb0Xi2982TGAM4y1tBVAUgy03 uY/ZbDOPadaIzMplL/uHasm61n+gFwUF4WujkELeWf5TvPhdim+pEte03De/mi1LbsMy4LsUOLgI Vo0UiwKGBjc4NQCOsIT1kuAKW/jCRZvwXzGsEg17+MMgjhWHR0ziEoMlxPA08VFQLEgVz4TFMI6x jGfsHxcjOMY29hqNd8zjHvv4bDkOspCHTOQE/Xg6RU6ykpfM5CY7+clQtueRp0zlKiMkyu+xspa5 g+WxbPnLBepyWMBMGzFnmMxoxoqZB5Pm1qzZAysBAQA7 ------=_NextPart_000_0009_01C72BF9.2FB412D0-- From sip-bounces@ietf.org Sat Dec 30 16:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0lez-0004lW-Gs; Sat, 30 Dec 2006 16:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ley-0004lR-1o for sip@ietf.org; Sat, 30 Dec 2006 16:22:32 -0500 Received: from ms0.aircom.com ([66.194.150.35] helo=ams1.aircom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0lew-0000YI-QV for sip@ietf.org; Sat, 30 Dec 2006 16:22:32 -0500 Received: by ams1 with Internet Mail Service (5.5.2650.21) id ; Sat, 30 Dec 2006 16:22:26 -0500 Message-ID: <07BB842D3E28D411804900508BAC02BD06FDA8E4@ams1> From: Charles Kristofek To: "'sip@ietf.org'" Subject: RE: [Sip] SMS via VoIP Date: Sat, 30 Dec 2006 16:22:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 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 From acdedgfcdfceb@carolknutson.com Sat Dec 30 18:14:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nPd-0003kb-LN for sip-archive@lists.ietf.org; Sat, 30 Dec 2006 18:14:49 -0500 Received: from [201.15.162.89] (helo=c-rxswgi3rl4gej) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nPb-00026B-Na for sip-archive@lists.ietf.org; Sat, 30 Dec 2006 18:14:49 -0500 Date: Sat, 30 Dec 2006 23:14:46 +0180 From: Quotes.com Alert! X-Mailer: The Bat! (v3.6.07) Educational Reply-To: acdedgfcdfceb X-Priority: 3 (Normal) Message-ID: <75342099.20061230231446@carolknutson.com> To: sip-archive@lists.ietf.org Subject: Join AVPJ(ANDROS ISLE DEVELOPM.) and you won’t lose!!! MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.6 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
ANDROS ISLE DEVELOPM (AVPJ.PK= ) THE PERFECT METHOD TO INCREASE YOUR INVESTMENTS!
YOU CAN GET AVPJ RIG= HT AFTER NEW YEAR. HURRY UP THE ALARM IS ACTIVATED!!!
FULL INFO ABOUT AVPJ= JUST CHECK THEM!
TARGET PRICE IN 1 WEEK: 0.72$.BUY IT= RIGHT NOW!
USING YOUR BROKERAGE= YOU CAN FIND OUT ALL INFO THAT INTEREST YOU.
IT=92S GETTING GROWT= H ALMOST EVERY HOUR! MORE THAN 80% DAILY FRO= M INITIAL PRICE.
DO IT IMMEDIATELY DO= NOT MISS THIS PERFECT CHANCE!
From sip-bounces@ietf.org Sat Dec 30 19:48:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0orC-000581-6d; Sat, 30 Dec 2006 19:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0orA-00057w-Pp for sip@ietf.org; Sat, 30 Dec 2006 19:47:20 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0or9-0005PL-D8 for sip@ietf.org; Sat, 30 Dec 2006 19:47:20 -0500 Received: from mail.globalsuite.net (unknown [127.0.0.1]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id EEA4650002; Sat, 30 Dec 2006 17:47:18 -0700 (MST) X-AuditID: c0a8013c-adbbebb00000715a-b1-459708965e0b Received: from [172.17.136.198] (unknown [209.115.228.10]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 9F440DD8008; Sat, 30 Dec 2006 17:47:17 -0700 (MST) In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F032650EF@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F032650EF@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CDCB124-109D-40D8-9CDC-3B4A6914D5EF@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, 30 Dec 2006 16:47:36 -0800 To: X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 It took me some time to parse through this but sounds like you and I are in 100% agreement on what an acceptable solution would look like. On Dec 20, 2006, at 12:18 AM, 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 >>> 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 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 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 > 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 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 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 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 Sat Dec 30 19:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0otX-0005vl-Vl; Sat, 30 Dec 2006 19:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0otW-0005sx-0n for sip@ietf.org; Sat, 30 Dec 2006 19:49:46 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0otT-0005nu-Ox for sip@ietf.org; Sat, 30 Dec 2006 19:49:46 -0500 Received: from mail.globalsuite.net (unknown [127.0.0.1]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 537CC50002; Sat, 30 Dec 2006 17:49:43 -0700 (MST) X-AuditID: c0a8013c-ae3bfbb00000715a-33-45970926d340 Received: from [172.17.136.198] (unknown [209.115.228.10]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 506BFDD800D; Sat, 30 Dec 2006 17:49:41 -0700 (MST) In-Reply-To: <458F1308.2070601@softarmor.com> References: <1ECE0EB50388174790F9694F77522CCF0E726D00@zrc2hxm0.corp.nortel.com> <458F1308.2070601@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66249C99-45DD-4BFE-8E4C-81B8169B0BD9@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, 30 Dec 2006 16:50:00 -0800 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 On Dec 24, 2006, at 3:53 PM, Dean Willis wrote: > > How about we rip out UDP, fix the Outbound stuff, fix the route- > construction stuff, fix the early-media stuff. and call it SIP 3.0? While you are working on this, I think we should publish outbound? It solves a useful goal now and probably works towards the right direction of what you would propose as a replace for SIP 2.0. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 30 19:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ous-0006SP-13; Sat, 30 Dec 2006 19:51:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ouq-0006QD-7V for sip@ietf.org; Sat, 30 Dec 2006 19:51:08 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H0ouo-00064J-W5 for sip@ietf.org; Sat, 30 Dec 2006 19:51:08 -0500 Received: from mail.globalsuite.net (unknown [127.0.0.1]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 8842450002; Sat, 30 Dec 2006 17:51:06 -0700 (MST) X-AuditID: c0a8013c-abbbabb00000715a-0f-4597097a9153 Received: from [172.17.136.198] (unknown [209.115.228.10]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id B1B28DD8008; Sat, 30 Dec 2006 17:51:05 -0700 (MST) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0E7965B9@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0E7965B9@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) 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: Sat, 30 Dec 2006 16:51:25 -0800 To: Francois Audet X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Dec 18, 2006, at 2:04 PM, Francois Audet wrote: > > I'm ok with having outbound support STUN-over-UDP, as long as we are > honest about > the implications regarding fragmentation. This could be as simple as > explaining that > if you don't keep a TCP channel opened, request that are bigger > than MTU > and would > observe the rules of RFC 3261/18.1.1 would not be able to be received. > Yes 100% agree - we should explain the bad implications of not having a TCP channel open. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 30 20:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0p45-0001Ew-F3; Sat, 30 Dec 2006 20:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0p43-0001Eq-M2 for sip@ietf.org; Sat, 30 Dec 2006 20:00:39 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0p42-0000FQ-Dl for sip@ietf.org; Sat, 30 Dec 2006 20:00:39 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 30 Dec 2006 17:00:38 -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 kBV10boL001821; Sat, 30 Dec 2006 17:00:37 -0800 Received: from [172.17.136.198] (sjc-vpn1-110.cisco.com [10.21.96.110]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBV10aUH013021; Sat, 30 Dec 2006 17:00:37 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@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, 30 Dec 2006 17:00:52 -0800 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=755; t=1167526837; x=1168390837; 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:=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=rs893FimGUGGd81wH5kkAkgvARLiFowLgsa42cvcieA=; b=cz1kGvk+9pxSn1gp8GMNlL1yeVuVN6MwZk3ZPxmN6MMGX5XpWZjr+DUTYKbnEhHo6MRUpi9A 2dy+DjHPAi9bhhssuSINElUiA67vM3hsZz+ey9wWh+K1bL2STeFFtRYY; 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: d6b246023072368de71562c0ab503126 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 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 From sip-bounces@ietf.org Sat Dec 30 20:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0p9a-00034p-Vj; Sat, 30 Dec 2006 20:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0p9Z-00034k-L9 for sip@ietf.org; Sat, 30 Dec 2006 20:06:21 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0p9Y-00013K-Bn for sip@ietf.org; Sat, 30 Dec 2006 20:06:21 -0500 Received: from [192.168.0.115] (ppp-70-245-134-245.dsl.rcsntx.swbell.net [70.245.134.245]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kBV16FIM007962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Dec 2006 19:06:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45970D01.1090308@nostrum.com> Date: Sat, 30 Dec 2006 19:06:09 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound References: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> In-Reply-To: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.245.134.245 is authenticated by a trusted mechanism) 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 I agree 100% with #1 and #2. I find #3 to be of dubious value, although I see no harm in a solution that has that property as well (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 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 Sat Dec 30 20:42:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0phn-00052Z-B4; Sat, 30 Dec 2006 20:41:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0phl-00052R-MR for sip@ietf.org; Sat, 30 Dec 2006 20:41:41 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0phk-000699-C2 for sip@ietf.org; Sat, 30 Dec 2006 20:41:41 -0500 Received: from [10.0.1.3] (adsl-68-94-47-253.dsl.rcsntx.swbell.net [68.94.47.253]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kBV1fXC1009367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Dec 2006 19:41:33 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <45970D01.1090308@nostrum.com> References: <91E4CFBC-9DA7-40F5-B757-62E0352708C4@cisco.com> <45970D01.1090308@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1125AFAD-C978-40DC-8275-B0676AA5388D@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] Question about Poll: Proposal relating to keepalive, TCP, and UDP usage in draft-ietf-sip-outbound Date: Sat, 30 Dec 2006 19:41:29 -0600 To: Adam Roach X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.47.253 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Cullen Jennings , 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 concur with Adam, with the caveat that any unforseen complexities that might be introduced by the phrase "not have the size limitations by using switchover" not block the work. That is, if 3 is free, or 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, > although I see no harm in a solution that has that property as well > (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 >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 31 07:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zYl-0006lR-He; Sun, 31 Dec 2006 07:13:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zYk-0006lM-Gs for sip@ietf.org; Sun, 31 Dec 2006 07:13:02 -0500 Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0zYb-0001om-VR for sip@ietf.org; Sun, 31 Dec 2006 07:13:02 -0500 Received: (qmail 17673 invoked by uid 510); 31 Dec 2006 06:20:25 -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 3.248478 secs); 31 Dec 2006 12:20:25 -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 3.248478 secs Process 17652) Received: from unknown (HELO annasagaramv) (annasagaram.vamsi@aftek.com@59.95.41.72) by mail.aftek.com with SMTP; 31 Dec 2006 06:20:21 -0600 From: "vamsi" To: "'Charles Kristofek'" , Subject: RE: [Sip] SMS via VoIP Date: Sun, 31 Dec 2006 17:43:23 +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 Thread-Index: AccsWxY7Zg1m7sdJTyKMkSj6YSZscgAWkcVw In-Reply-To: <07BB842D3E28D411804900508BAC02BD06FDA8E4@ams1> X-Antivirus-MYDOMAIN-Message-ID: <116756762283517652@plain.ev1servers.net> X-Spam-Score: 0.4 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Dec 31 13:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H153p-0000LZ-E2; Sun, 31 Dec 2006 13:05:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H153n-0000LP-UP for sip@ietf.org; Sun, 31 Dec 2006 13:05:27 -0500 Received: from ms0.airnetcom.com ([66.194.150.35] helo=ams1.aircom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H153e-0001G8-LY for sip@ietf.org; Sun, 31 Dec 2006 13:05:27 -0500 Received: by ams1 with Internet Mail Service (5.5.2650.21) id ; Sun, 31 Dec 2006 13:05:12 -0500 Message-ID: <07BB842D3E28D411804900508BAC02BD06FDA8E5@ams1> From: Charles Kristofek To: 'vamsi' , sip@ietf.org Subject: RE: [Sip] SMS via VoIP Date: Sun, 31 Dec 2006 13:05:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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 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 Thomas@DALLASNEWS.COM Sun Dec 31 22:44:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1E6H-0003n6-Se for sip-archive@lists.ietf.org; Sun, 31 Dec 2006 22:44:37 -0500 Received: from s0106001731d67cdb.ed.shawcable.net ([68.148.11.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1E6F-0003Gu-VD for sip-archive@lists.ietf.org; Sun, 31 Dec 2006 22:44:37 -0500 Received: from [104.196.59.72] by S0106001731d67cdb.ed.shawcable.net with HTTP; Sun, 31 Dec 2006 20:44:52 -0700 Message-ID: <001201c72d57$28b51830$690b9444@zennie> From: "Sorvino Mischa" To: sip-archive@lists.ietf.org Subject: Kelli Kellie Pickler Date: Sun, 31 Dec 2006 20:44:37 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C72D1C.7C564030" 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.4 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_000E_01C72D1C.7C564030 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C72D1C.7C564030" ------=_NextPart_001_000F_01C72D1C.7C564030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harmon, faris friel, mouglalis nicole paquin anne curtis hathaway. = Keeley hazell keira knightley, kelli, kellie. Leader argentinan rock = band divididos, godmother soccer team. Branch hunziker kwan lombardo monaghan dfe, pfeiffer wie. Cornish abi = titmuss lima adrianne? Air feldman doutzen kroes drew barrymore elena dementieva, elin. Marcil minnillo paradis venus vera, zvonareva veronica. Here to, check, out anna kournikova profile! Jolene blalock jordana = brewster, josie maran joss, stone! Hayek samaire armstrong samantha, = morton. With first, album after sang theme song cambio. Alexandra neldel alexis, bledel ali, landry larter alicia keys. Aquino, krista allen kristanna loken kristen kristin. Olivia wilde, ophelie winter pamela paris patricia arquette. Clijsters = kimberly stewart kimora simmons. Forlani clara morgane claudia schiffer = collien fernandes courtnee draper. Julianne juliette lewis kaley. Sobieski leilani dowding leslie bibb lexa doig. Britney spears brittany daniel murphy brooke. Traci lords tricia helfer = trish stratus, tyra uma? Pink perabo priscilla taylor qi shu rachael = cook bilson. Pamela paris patricia, arquette velasquez patsy. Bax lacey chabert = laetitia casta laura linney? Griffith melissa george joan. Danica patrick, daniela hantuchova pestova danielle evans fishel! Sasha = alexander cohen, singleton saskia clarke scarlett johansson selita. Perry stevens weisz, rebecca gayheart loos romijn reese regine! Patrick = daniela, hantuchova pestova danielle evans fishel panabaker. Uruguay = name marisa iglesias poggio bouri height quot related. Minogue daria = werbowy debra! Jackson january jeanette, biedermann jeisa. Hanna verboom haylie duff heather graham. Morena baccarin morgan webb mya harrison myleene klass! Fairuza balk = hill famke. Birth date may place montevideo uruguay. Stratus, tyra uma, thurman vanessa ferlito marcil minnillo? Krupa, jodie, foster marsh. Stefani gwyneth, paltrow halle. Brisley hunter valance ilary blasi. Perry stevens weisz rebecca gayheart. ------=_NextPart_001_000F_01C72D1C.7C564030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Harmon, faris friel, mouglalis nicole = paquin anne=20 curtis hathaway. Keeley hazell keira knightley, kelli, kellie. Leader = argentinan=20 rock band divididos, godmother soccer team.
Branch hunziker kwan lombardo monaghan = dfe,=20 pfeiffer wie. Cornish abi titmuss lima adrianne?
Air feldman doutzen kroes drew = barrymore elena=20 dementieva, elin.
Marcil minnillo paradis venus vera, = zvonareva veronica.
Here to, check, out anna kournikova = profile! Jolene=20 blalock jordana brewster, josie maran joss, stone! Hayek samaire = armstrong=20 samantha, morton.
With first, album after sang theme song = cambio.
Alexandra neldel alexis, bledel ali, = landry larter=20 alicia keys.
Aquino, krista allen kristanna loken = kristen kristin.
Olivia wilde, ophelie winter pamela = paris patricia=20 arquette. Clijsters kimberly stewart kimora simmons. Forlani clara = morgane=20 claudia schiffer collien fernandes courtnee draper.
Julianne juliette lewis = kaley.
Sobieski leilani dowding leslie bibb = lexa doig.
Britney spears brittany daniel murphy = brooke. Traci=20 lords tricia helfer trish stratus, tyra uma? Pink perabo priscilla = taylor qi shu=20 rachael cook bilson.
Pamela paris patricia, arquette = velasquez patsy.=20 Bax lacey chabert laetitia casta laura linney?
Griffith melissa george = joan.
Danica patrick, daniela hantuchova = pestova danielle=20 evans fishel! Sasha alexander cohen, singleton saskia clarke scarlett = johansson selita.
Perry stevens weisz, rebecca gayheart = loos romijn=20 reese regine! Patrick daniela, hantuchova pestova danielle evans fishel=20 panabaker. Uruguay name marisa iglesias poggio bouri height quot = related.=20 Minogue daria werbowy debra!
Jackson january jeanette, biedermann = jeisa.
Hanna verboom haylie duff heather = graham.
Morena baccarin morgan webb mya = harrison myleene=20 klass! Fairuza balk hill famke.
Birth date may place montevideo = uruguay.
Stratus, tyra uma, thurman vanessa = ferlito marcil minnillo?
Krupa, jodie, foster = marsh.
Stefani gwyneth, paltrow = halle.
Brisley hunter valance ilary = blasi.
Perry stevens weisz rebecca=20 gayheart.
------=_NextPart_001_000F_01C72D1C.7C564030-- ------=_NextPart_000_000E_01C72D1C.7C564030 Content-Type: image/gif; name="Salazar Lucy.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c72d57$28b51830$690b9444@zennie> R0lGODlh9AFcAIfoAAUAAIoADgCFB352AAEAeHoAgwCLdMjOx8DOxrLO5EAUBmUnDn8mC5UoDM0s C+EUCwBNCxtNAEw+AFhIAIZEDKAyALFCANxHAABfDS5lADZpBVVcBoJqAKNqCsFsAORsAgCIBx99 AEmDAFh9A3ZxAKt7AMqAAOeHAACmASKmAEOUB1+rAn6RBpebAMShANmjAAbFCyPHADq9AGC+AIfN AJe7AbWyB+67AADbABTTAETlAGTmDXLuAK7RBrTlBuXaAQQASBcASDUIN1UHP4QAM5UARbYHRO4K TQAjPykfSDUWPmUnRYMVSZIYNLEcOOMfNwI9SR4xQEkzTF1EOX1MOaRJQMM1QOdAPgljTBpnRDlt Q2poQ4FjD5hRMctWO9laTQ54QyR7QEd/TmeCQIB3R6l0N8l0R9xzNgCaQRqmRkmfQWGjOXiZP6Sh P7arP+KVRQC0PCyxMkbCOmq2N33FNpW7P7O/QNPOPADjMhHRR0LsQGHhOYrrQZbXNb7SSdTlOgAA dScAjTEAjmgGd3QAjpsAhrECiNcIgAQedigtgkAoeGsjjHERg5UbfccgddUZeQE4dSA5gEw4jGw5 jnY3hqg7csxNiOE6iQBpjSNUdDdeiVNsiotZjKpufcpRgehacQR4cxGMik17hVJ4joB+fq53fc2E ddNyiAOodSqfgDWkelKqgIeYiK6ndMSkeu6hgADLgRXDgzLBfWPAeHG6jZnIgcGxgdfAiwDmfCDu dE7WiVvjiIvicp/ker7jhOTbcQUOtRsFujYAwF8HtIMJsZ8LtMUAwesAzQAVxBQewUsaslIZvoAV tqgrybgjxuUtvQpEzhc1ujo3wVZLwYtCzZUyx7dCvN08yw1tvxFaykleuWxazXxtx6FjvLJfs+5s zgB6yhSEyjF9zW52zHFyxZ5ztLWCyul/tgCduRSjv02ktl2mw4eaxJmrybilzOKdyADJxCK2sUG2 zmvHvYG9tKC0svH/4qaZoIF2h/oCAAn4AP//BAAJ/P8A9Qrx/v/9+iH5BAAx7ZkALAAAAAD0AVwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEjx4L+LGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmSY8WX MGPKnEmzps2bC1vq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evWnGK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPqdQu2r9+/gPcKHky4sOHDiBMrXsy4sePHagFLnky5 suXLmDNr3sy5s+fPoEOLHp0VsunTqFOrXs26tevXsGPLnk27tu3buHPr3o2btO/fQ3kLdwi8uPGO w5OfBgBAuXOE/KJHH0igunWC0wVmZ84c5/HiEblz/4+Z/WH154dZMse4/l979wAwVr84n3387/h3 QjxPnQDM7vv5h55jItW30XvwXbQeggnm5+BKEAFoEDDACEThQBRmaI+GAoknoT0eEvThgKzxN2GF GAJzERAsAnHgfQ/GKBSD8hFAn40KLqjjjTjW996PMDYoY2c05phRe9xxVOSQTG4UXogDiSdicyBS CaCEV1JZZZRabkkiallmOWWH4xU04pckrgQkgkje16Z9RsYpZJOfselmkG8yuCSddL6EZZlkBurl n4J6aSiaqxFqqKIfnonoowk12uWIYg6qZaWLdgkpmFB6OOmlVgK66agGeWqmppWGKSqUhR5K6quw wv/W05482cmnZ7Hmipajuvbq66a1BnnrsMQWa+yxGP2q7GrINuvss1MtK+1dtEJr7bWiCRRAAAbl 4623E7HakAIK4OSAA4lqmusCC0wr24jsDhQvQtvWO9C293Lb0Lli8coWvgM1ILDABZFbrkDkFnyw bCWd67AD2NL58LkXPfAARhZ3xC5GG/+TccUXi7QtRiNfVPLAA4uEcgMsfawRuSIleREDDGBEM8YX Z+xyRjuDBhHNAwFtD81E5+vuaw8XBAEEAy097sEJI3wwSBTDGafDF1UNUrUhEV1zRg+HZLACHWm9 9D9nn72R1jLePPPXHMStEQUU2CfzP15/jZHaEYP/tTTfF/ENuEftCQ5BzEG6jffXiiv+kdAC/e30 Q3QfNHlCTl+uNNORMy15QpAnhwEGA43eaueoFySAAAOtTpDpRwuGwuyqsy6Q6wnNTnvTknO+0O6p 2zP55ZonBHumDxUf/EGwHy/Q6M4L//nfBuGuXO++nzk5DjgYRLzvsRsGw/gwDKSPPuajz9D4BwGv kPPW486+QPMvpKirCjlav+XYH8S9/9zr3v8IYr3kKM8e7hPI7gp4u9U50HbhM0zmOHe/95Gudg7R 3PC21z2BDNB+WoofBBnCwAY6JIFcKlVzujOi/Q3ngMqDnQvtMcMIiq989RMX8L7XOgdGqEv9oyH5 /2qIkPFUEIQH8RcGgxdD0pkueihkTUmKRKPVBe5wGjFcRmbXt7480IohAeMV/9aSwXFEjCkRIxpB wsWNDG6NF2njGM04PoyQTyPnaxL3UhLAPebobnLq4lf8eBKcELF0F3zJFx3yRQj28YMHvMkhbUhJ 7/TEjE/BJEagAAUZgQEMvqmkKGcSMTgK8pSoTOVvRsnKmqhyM62MpSxt88qgsChbs8wlQ5S4KROd SpfANIyn1FVEYi6Gl2KxznUEosxgDqSWleGakoTVkmHCKEMUstt7sJlNHhloTuD8iXg6Ik1omvMy 5fyHMg3koZZ880V/PBKM3hSndgYSKMokJzXPyf9PzXjqI0CaZj33qU+A3kkjARVSQpUCSHn286Ff qYiqQpVCFQoKmRWdkpRcxShTnS4tGx2TriCqGYkaE3lkCmlIG0IpUJ2uo8V0CwtRdVJn2tSSKNlT Qhc6TpLo6U4HdSh8gqpQYaVTTfH5KUmXapmFwnOoA51nQ7dGzX+G06pDtZVQZ2TPP06VqWD1Slf1 2dOsatWnBD2JNL9KlKOG9a34catbCZdWqcw1WTfNa2owWhNx6fWvgOUrYGcDV6zUhV+DTaxiF8vY xsqksEt1bHog2xfJipKytbSsZjfLWYZhVpCdDa1oR2uaz5r2tKUhrWpXy9rWuva1p0HtaGC7GNlH Fou2uM2tbncbK9sei7fADa5wh7ss3xr3uMhNrnKFQty8LPe50E1Jc6cbu+ha97ogoe6AsNsU7daW u7D0rnjHS17EgPciAQEAOw== ------=_NextPart_000_000E_01C72D1C.7C564030--