From sip-admin@ietf.org Sun Jul 1 04:11:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04990; Sun, 1 Jul 2001 04:11:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01301; Sun, 1 Jul 2001 04:00:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01255 for ; Sun, 1 Jul 2001 04:00:07 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04165 for ; Sun, 1 Jul 2001 03:59:20 -0400 (EDT) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Sun, 1 Jul 2001 11:00:36 +0300 Message-ID: From: Itamar Gilad To: "'Jonathan Rosenberg'" , "'SIP list'" Subject: RE: [Sip] Consecutive REFERs Date: Sun, 1 Jul 2001 11:00:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, June 29, 2001 10:11 PM > To: 'Itamar Gilad'; 'SIP list' > Subject: RE: [Sip] Consecutive REFERs > > > -----Original Message----- > > From: Itamar Gilad [mailto:ItamarG@radvision.com] > > Sent: Tuesday, June 26, 2001 4:06 AM > > To: 'SIP list' > > Subject: [Sip] Consecutive REFERs > > > > > > Below are a couple of questions regarding REFER scenarios and > > appropriate > > response code usage. I'm sorry if this has been asked before. > > > > 1) A sends a REFER to B directing it to call C. B sets up a > > call with C > > successfully. Now A sends another (new) REFER to B directing > > it to contact > > D. B wants to reject this REFER on the grounds that it > > currently can't take > > additional calls. Is 486 the appropriate response? > > > > 2) Same as A, but this time the second REFER directs B to > > call C again. B > > wants to reject this on the grounds that it already has a > > call-leg setup > > with C. What's the response code B should use here? > > I'm actually curious why you ask. THe response code really > shouldn't matter > unless you were planning to define logic at A that did > something special > depending on the response code. Was that the case? > It's possible that the user and/or UA at A may have reasons to want to know what went wrong at B. Attaching logic or not sounds like an implementation decision. You say that the response code shouldn't matter. Should we then return a 400 + meaningful reason phrase for everything REFER-related? If response code isn't the right mechanism to relay REFER status, what is? > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From extest-admin@lists.bell-labs.com Sun Jul 1 05:18:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08917 for ; Sun, 1 Jul 2001 05:18:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D227444AB9 for ; Sun, 1 Jul 2001 05:08:41 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010701090841.D227444AB9@lists.bell-labs.com> Date: Sun, 1 Jul 2001 05:08:41 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Sun Jul 1 12:51:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12739 for ; Sun, 1 Jul 2001 12:51:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E558A44337; Sun, 1 Jul 2001 12:52:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sjc3-1.relay.mail.uu.net (sjc3-1.relay.mail.uu.net [199.171.54.122]) by lists.bell-labs.com (Postfix) with ESMTP id 7404D44336 for ; Sun, 1 Jul 2001 12:51:53 -0400 (EDT) Received: from overhill by sjc3sosrv11.alter.net with SMTP (peer crosschecked as: user2.sentito.com [65.202.222.2] (may be forged)) id QQkvux09613 for ; Sun, 1 Jul 2001 16:51:53 GMT From: "Frank W. Miller" To: Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [SIP] Calling Identity Delivery Blocking (CIDB) feature Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 1 Jul 2001 12:51:20 -0400 Content-Transfer-Encoding: 7bit Greetings, I have a question about supporting the CIDB CLASS feature. If an E164 number is used for addressing, i.e., the phone number is part of the address, how can CIDB be supported? The trouble is in this addressing scheme, once the number has left the originating party you cant really control whats done with the information? Perhaps theres something I'm overlooking here? FM -- Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. www.sentito.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 01:46:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21553; Mon, 2 Jul 2001 01:46:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27040; Mon, 2 Jul 2001 01:36:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27008 for ; Mon, 2 Jul 2001 01:36:09 -0400 (EDT) Received: from india.mercurykr.com ([165.133.13.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20956 for ; Mon, 2 Jul 2001 01:34:54 -0400 (EDT) Received: from ashwani (Param [165.133.13.33]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id KAA14188 for ; Mon, 2 Jul 2001 10:57:42 -0600 (GMT) Message-ID: <004501c102b8$f8f924c0$210d85a5@dti.daewoo.co.kr> From: "Ashwani Kumar Kesharwani" To: Date: Mon, 2 Jul 2001 11:06:37 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] Multicasting help Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi All Can anybody help me in understanding Multicasting in SIP. I am not able to get that who decides where multicasting has to occur, that is at the outgoing proxy or at the UAC itself. Suppose UAC 'a' has to multicast a request to a certain address then where it will put the maddr parameter in the request URI or in the via header. Now if it is in Via header then is outgoing proxy going to send the request to this multicast address. Thanks in Advance Ashwani _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 03:30:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04496; Mon, 2 Jul 2001 03:30:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00036; Mon, 2 Jul 2001 03:17:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00005 for ; Mon, 2 Jul 2001 03:17:08 -0400 (EDT) Received: from mailweb9.rediffmail.com (IDENT:qmailr@[203.199.83.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04424 for ; Mon, 2 Jul 2001 03:16:24 -0400 (EDT) Received: (qmail 27089 invoked by uid 510); 2 Jul 2001 07:21:42 -0000 Date: 2 Jul 2001 07:21:42 -0000 Message-ID: <20010702072142.27088.qmail@mailweb9.rediffmail.com> Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 02 Jul 2001 07:21:42 -0000 MIME-Version: 1.0 To: "sip@ietf.org" From: "Ashhar Farhan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Adhoc group messaging Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit While chatting with a peer, an IM user would typically like to add a third participant to the chat. This is currently not possible in SIP MESSAGE. MESSAGE rfc recommends that a group@host url should be used for multi-participant chatting. a group id is not available in peer chats that are one to one and have to include a third recepient (sort of CC of email UAs). although group@host is definitely the best thing for large chat groups, most of chat interactivity takes place within smaller groups of people who interact with each other and do often need to chat with about 3-4 participants at a time. this kind of chatting can be accomplished in principle by making each of the participants send a copy of MESSAGE to all the other participants. If the group grows too big, and the bandwidth gets constrained, then they ought to move to a scheduled group chat server. However, for most of the times it is enough to be able to chat with 3-4 pariticipants at a time. Do note that these groups are created without any schedule and grow out of a 1-1 chat. My recommendation would be that: 1. A sends B a MESSAGE, B sends a reply back with the same Call-ID. so that we have identified a sequence of MESSAGEs that can be displayed within a particular instance of User interface (like a window). 2. A wants C to join in the chat. A sends some reques(s) to C. At this point, what needs to be done is that: 2.1 C should get a list of all the participants from A. 2.2 C should get the group messaging ID (probably the shared Calli-ID) for all these messages so that this thread of messages to the other participants can be distinguished from any other threads that maybe concurrently engaged in by C. Alternatively, instead of the Call-ID, even Subject can be used (probably a combination of the two is going to be the only unique thing). 2.3 Others have to be informed of additon of C to the chat group. 2.4 All the future MESSAGEs and NOTIFYcations are send to the updated list of participants by all. one possible implementation for this is that we base this on SUBSCRIBE/NOTIFY. Step 1:A participant is added by sending a SUBSCRIBE to the new particpant. Step 2:The new pariticipant responds back by accepting the SUBSCRIPTION. The participant who has added the new participant also sends a NOTIFY to other participants who can update their chat lists with the userid of the new participant. - farhan@hotfoon.com ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 04:08:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04814 for ; Mon, 2 Jul 2001 04:08:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7796344341; Mon, 2 Jul 2001 04:09:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from noya.bupt.edu.cn (noya.bupt.edu.cn [202.112.96.2]) by lists.bell-labs.com (Postfix) with ESMTP id 0D99B44336 for ; Mon, 2 Jul 2001 04:08:58 -0400 (EDT) Received: from wuerlang ([202.112.103.163]) by noya.bupt.edu.cn (8.11.4/8.10.1) with SMTP id f62892h18920; Mon, 2 Jul 2001 16:09:02 +0800 (CST) Message-Id: <200107020809.f62892h18920@noya.bupt.edu.cn> From: wuerlang To: "'sip@lists.bell-labs.com'" , Jonathan Rosenberg X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Subject: [SIP] Some questions about the AppServer Whitepaper of dynamicsoft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Jul 2001 16:8:33 +0800 Content-Transfer-Encoding: 7bit Hi all, I have some questions about the AppServer Whitepaper of dynamicsoft "AN APPLICATION SERVER ARCHITECTURE FOR COMMUNICATIONS SERVICES". 1. What's the CPL APIs identified in AppServer Whitepaper of dynamicsoft. Are they based on servlet APIs or CGI APIs? 2. If there are a call forward application based on CGI and one based on servlets, and they both aim at the same enduser, which application will the event manager invoke? 3. If I want to provide Parlay APIs interface for the 3rd application provider, what should be added to the application server? wuerlang wuerlang77@263.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jul 2 09:18:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07927 for ; Mon, 2 Jul 2001 09:18:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 521F344345; Mon, 2 Jul 2001 09:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lists.bell-labs.com (Postfix) with ESMTP id 49DC044336 for ; Mon, 2 Jul 2001 09:18:08 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f62DHgx01929; Mon, 2 Jul 2001 06:17:42 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f62DHXW23177; Mon, 2 Jul 2001 06:17:33 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA05715; Mon, 2 Jul 2001 06:17:32 -0700 (PDT) Message-ID: <3B4074C7.240F0FA1@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Frank W. Miller" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Calling Identity Delivery Blocking (CIDB) feature References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 09:19:03 -0400 Content-Transfer-Encoding: 7bit "Frank W. Miller" wrote: > Greetings, > > I have a question about supporting the CIDB > CLASS feature. If an E164 number is used for > addressing, i.e., the phone number is part of > the address, how can CIDB be supported? The > trouble is in this addressing scheme, once the > number has left the originating party you cant > really control whats done with the information? > > Perhaps theres something I'm overlooking here? Take a look at ("SIP Extensions for Caller Identity and Privacy" ) -- Flemming > > > FM > > -- > Frank W. Miller, Ph.D. > Chief Technical Officer > sentitO Networks, Inc. > www.sentito.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 09:35:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08183; Mon, 2 Jul 2001 09:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11486; Mon, 2 Jul 2001 09:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04086 for ; Sat, 30 Jun 2001 12:54:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23860 for ; Sat, 30 Jun 2001 12:53:20 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5UGs1M20224 for ; Sat, 30 Jun 2001 11:54:01 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f5UGs1m12092 for ; Sat, 30 Jun 2001 11:54:01 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sat Jun 30 11:54:00 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 30 Jun 2001 11:54:00 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Zmolek, Andrew (Andrew)'" , William Marshall Cc: chogg@nortelnetworks.com, jdrosen@dynamicsoft.com, Marie-Noelle.Mathieu@compaq.com, duffy@bighorn.dr.avaya.com, ggf@bighorn.dr.avaya.com, sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Date: Sat, 30 Jun 2001 11:53:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10185.42290FF0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10185.42290FF0 Content-Type: text/plain; charset="ISO-8859-1" The current state draft is intended to establish a "cookie" that lasts at least for the duration of a call leg. The cookie is tied to a call leg based on To/From/Call-ID. Furthermore cookies are returned based on the host/port in the State: header. If the Request-URI matches or any of the Route: headers match this host/port, the State: header (cookie) is returned. There is the following text in the draft as well: 4. Additional rules MAY be defined by other extensions that specify when a State header is to be included in a request. An example of this would be extensions that handle call transfers and other features that would specify State header processing at the UAC. This leaves open the possibility to define an extension that uses the State: header in the manner you describe. However, I think what you want to do is a bit at odds with the original intention of the draft. Having a cookie that spans call legs would require a different set of rules defining when a UAC should return a cookie in subsequent requests or a UAS in the 1xx responses. I would like a more generic cookie mechanism, but I think the State: header mechanism is a reasonable compromise in terms of processing at the UA. The alternative would be to provide additional information in the State: header which indicated when the State: header should be returned; similar to the path that is included in HTTP cookies. e.g. State: host/port; call-id="...";from="..."; value /sean -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Friday, June 29, 2001 5:11 PM To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew) Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Would the re-use of a state header as a means of tying together multiple call legs cause problems with anything in the state draft as written? By persistence, I'm thinking more about using the token to re-establish some value-added context of a session terminated perhaps even days earlier, but even without that concept, I need any cookie replacement to not preclude token use across multiple call legs. --Andy -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, June 27, 2001 4:43 PM To: Zmolek, Andrew (Andrew); William Marshall; zmolek@avaya.ccom.avaya.com Cc: Sean Olson (EUS); chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id The State: header is a SIP extension. I believe it can be used independently of the other DCS extensions. The real issue is how widespread will the extension be -- can you depend on "most" clients to support it. I'm not sure what you mean by "token persistence". Do you mean a State: header that spans multiple call legs? /sean -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Wednesday, June 27, 2001 4:27 PM To: William Marshall; zmolek@avaya.ccom.avaya.com Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Sounds like the State header may accomplish what we are considering with cookies; there may be no need to re-invent this. How tightly coupled is the State header and the DCS call model? In other words, to support the State header will a device have to fully conform to DCS? Or is this required only to generate state? Moreover, how problematic would the introduction of token persistence be to the State header? Would this cause problems with DCS implementation? Another worry: If the State header and DCS are joined at the hip, then this might be too much for simple implementations to swallow even if our own products were to comply. How much support does this proposal have in the community right now? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: William Marshall [ mailto:wtm@research.att.com ] Sent: Wednesday, June 27, 2001 11:59 AM To: zmolek@avaya.ccom.avaya.com Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id State headers operate in both directions. A UAC that inserts a State header in the INVITE will see the contents returned in every provisional and final response, as well as any re-INVITE initiated by the UAS. A UAS that inserts a State header into a provisional or final response will see the contents returned in every re-INVITE from the UAC, as well as provisional and final responses to requests initiated by the UAS. The State header is documented in draft-ietf-sip-state-01. Rules for handling of State headers with future extensions will need to be specified in the draft defining that extension. In particular, a REFER that is attempting to replace an existing call leg may need the State headers from the previous call leg attached to the new INVITE, along with the From/To/Call-ID. This is all still to-be-defined. Bill Marshall wtm@research.att.com -----original messaage----- Subject: RE: [Sip] RE: [Sipping] Call and call-id Date: Wed, 27 Jun 2001 10:57:08 -0600 From: "Zmolek, Andrew (Andrew)" To: "Sean Olson (EUS)" , "Chris Hogg" , "Jonathan Rosenberg" , "Mathieu, Marie-Noelle" , Cc: "Boyle, Frank J (Duffy)" , "Freundlich, Glen G (Glen)" Does DCS state only operate in one direction (ie.only from the SIP transaction initiator)? If so, it would need to be extended to provide equivalent information when two endpoints have hundreds or thousands of individual call legs in hundreds of sessions and either end might initiate any given SIP transaction. Also, what are the rules for passing DCS state with respect in the REFER case? If DCS state is extensible to provide an equivalent session identifier at both ends of any given call, then I agree that there isn't any need for bi-directional cookies to be grantable and remittable by either end. But given the current draft's focus on proxies and what appears to be a unidirectional call state, I'm not sure that it's complete enough to solve the whole problem. Please correct me if I've missed something... --Andy -----Original Message----- From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] Sent: Wednesday, June 27, 2001 9:19 AM To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Have you considered the DCS State: draft for this mechanism? See http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt < http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt > IMHO, I don't see a need for such a use of a Cookie. Correlating messages to calls is not that difficult. The key thing to note, as you have, is that Call-ID is not necessarily useful for tying multiple call legs together. /sean -----Original Message----- From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com ] Sent: Wednesday, June 27, 2001 9:55 AM To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id I think it would be good to clarify our terminology, particularly since we sometimes forget SIP does not provide directly for a call with multiple active call legs (i.e. B2BUA is needed to rationalize each individual SIP call with the overall session). I propose we define "call" to mean the two participants in any given transaction and "session" to be some collection of calls associated within a given UA (note that "invited by a common source" is not a complete description since some or all of the invites could have originated outside the UA). This thread brings out several reasons why Call-ID should not be used to define a "session" of multiple "calls" as defined above. Mainly because of this, I'm preparing an I-D to address this need through the use of header extensions for cookies, which each UA can independently grant and accept in order to correlate call legs and potentially provide additional context for a given call. The alternative is vendor-specific headers and a walled garden approach to many features available in conventional PBXes today, and I don't think that's beneficial for SIP in the long run. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Chris Hogg [ mailto:chogg@nortelnetworks.com ] Sent: Wednesday, June 27, 2001 4:03 AM To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu, Marie-Noelle; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Hi Jonathan, Jonathan Rosenberg wrote: >Careful; I am not proposing that two call legs with the same Call-ID convey >any semantics. Specifically, receiving an INVITE from A, while in a call >with B, where the call-id in the INVITE from A equals the call-id in the leg >with B, does NOT imply that this is a consultative transfer. For that, we >have Replaces, which lists the replaced leg explicitly. >All I am saying is that a Call-ID may be reused for local convenience, if >desired, but that it has NO semantics outside of the entity that selected >that call-id. Given, what you are proposing will this not mean that the definition of a call needs to be altered? The reason I ask is that bis-03 defines a call as "identified by a globally unique callID" and "all participants invited by a common source". In the case you describe under the current definition of a call this would mean that we would have two calls (under the "all participants invited by a common source" rule) but with the same callID (hence contravening the "globally unique callID" part). Comments? Regards, Chris Hogg Nortel Networks. -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com < mailto:jdrosen@dynamicsoft.com > ] Sent: 26 June 2001 22:51 To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id -----Original Message----- From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com < mailto:zmolek@avaya.com > ] Sent: Tuesday, June 26, 2001 12:35 PM To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id >> >same call-id in the 2 INVITE requests, is this allowed ? >> >> Well, the current spec would indicate that you shouldn't do this: >> >> >The callid MUST be a globally unique identifier and MUST NOT be reused for >> >later calls. >> >> However, I recall some discussion at an IETF that people were using the same >> call-id across different call legs as a local identifier to correlate those >> call legs. With unique From tags and From fields, there really shouldn't be >> a problem, so I think its OK. However, if we are going to allow it, the spec >> should reflect it. Comments? > >If that's the proper way to solve this problem, then let's put that in the >spec. But I'm not convinced that this alone will solve all cases, especially >when this correlated information needs to be presented by a call leg attempting >to join (as in the consultative transfer case). Careful; I am not proposing that two call legs with the same Call-ID convey any semantics. Specifically, receiving an INVITE from A, while in a call with B, where the call-id in the INVITE from A equals the call-id in the leg with B, does NOT imply that this is a consultative transfer. For that, we have Replaces, which lists the replaced leg explicitly. All I am saying is that a Call-ID may be reused for local convenience, if desired, but that it has NO semantics outside of the entity that selected that call-id. > It only seems to work when the >correlating entity initiates all the calls. If there's a reliable way to >correlate an incoming call leg with an existing call, I'd love to hear about >it. http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt < http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt > needs updating and adoption though, if we plan to move forward with it. As you can see, its currently in the morgue. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net < http://www.jdrosen.net > PHONE: (973) 952-5000 http://www.dynamicsoft.com < http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip < http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C10185.42290FF0 Content-Type: text/html; charset="ISO-8859-1" RE: [Sip] RE: [Sipping] Call and call-id
The current state draft is intended to establish a "cookie" that lasts at
least for the duration of a call leg. The cookie is tied to a call leg based
on To/From/Call-ID. Furthermore cookies are returned based on the
host/port in the State: header. If the Request-URI matches or any
of the Route: headers match this host/port, the State: header (cookie)
is returned.
 
There is the following text in the draft as well:
 

  4.      Additional rules MAY be defined by other extensions that specify
     when a State header is to be included in a request. An example of
     this would be extensions that handle call transfers and other
     features that would specify State header processing at the UAC.
This leaves open the possibility to define an extension that uses the
State: header in the manner you describe. However, I think what you
want to do is a bit at odds with the original intention of the draft. Having
a cookie that spans call legs would require a different set of rules defining
when a UAC should return a cookie in subsequent requests or a UAS in
the 1xx responses.
 
I would like a more generic cookie mechanism, but I think the State: header
mechanism is a reasonable compromise in terms of processing at the UA.
The alternative would be to provide additional information in the State: header
which indicated when the State: header should be returned; similar to the
path that is included in HTTP cookies.
 
e.g.
State: host/port; call-id="...";from="..."; value
 
/sean
-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Friday, June 29, 2001 5:11 PM
To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew)
Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Would the re-use of a state header as a means of tying together multiple call legs cause problems with anything in the state draft as written? By persistence, I'm thinking more about using the token to re-establish some value-added context of a session terminated perhaps even days earlier, but even without that concept, I need any cookie replacement to not preclude token use across multiple call legs.
 
--Andy
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June 27, 2001 4:43 PM
To: Zmolek, Andrew (Andrew); William Marshall; zmolek@avaya.ccom.avaya.com
Cc: Sean Olson (EUS); chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id

The State: header is a SIP extension. I believe it can be used independently
of the other DCS extensions. The real issue is how widespread will the
extension be -- can you depend on "most" clients to support it.
 
I'm not sure what you mean by "token persistence". Do you mean
a State: header that spans multiple call legs?
 
/sean
-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Wednesday, June 27, 2001 4:27 PM
To: William Marshall; zmolek@avaya.ccom.avaya.com
Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Sounds like the State header may accomplish what we are considering with cookies; there may be no need to re-invent this. How tightly coupled is the State header and the DCS call model?  In other words, to support the State header will a device have to fully conform to DCS? Or is this required only to generate state?

Moreover, how problematic would the introduction of token persistence be to the State header? Would this cause problems with DCS implementation? Another worry: If the State header and DCS are joined at the hip, then this might be too much for simple implementations to swallow even if our own products were to comply. How much support does this proposal have in the community right now?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001



-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Wednesday, June 27, 2001 11:59 AM
To: zmolek@avaya.ccom.avaya.com
Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com;
jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com;
duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id


State headers operate in both directions.  A UAC that inserts a State header
in the INVITE will see the contents returned in every provisional and final
response, as well as any re-INVITE initiated by the UAS.  A UAS that
inserts a State header into a provisional or final response will see
the contents returned in every re-INVITE from the UAC, as well as
provisional and final responses to requests initiated by the UAS.
The State header is documented in draft-ietf-sip-state-01.

Rules for handling of State headers with future extensions will need
to be specified in the draft defining that extension. In particular,
a REFER that is attempting to replace an existing call leg may need
the State headers from the previous call leg attached to the new
INVITE, along with the From/To/Call-ID.  This is all still to-be-defined.

Bill Marshall
wtm@research.att.com

-----original messaage-----
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 10:57:08 -0600
From: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>
To: "Sean Olson (EUS)" <sean.olson@ericsson.com>,
        "Chris Hogg" <chogg@nortelnetworks.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Mathieu, Marie-Noelle" <Marie-Noelle.Mathieu@compaq.com>,
        <sip@ietf.org>
Cc: "Boyle, Frank J (Duffy)" <duffy@drmail.dr.avaya.com>,
        "Freundlich, Glen G (Glen)" <ggf@drmail.dr.avaya.com>

Does DCS state only operate in one direction (ie.only from the SIP
transaction initiator)? If so, it would need to be extended to provide
equivalent information when two endpoints have hundreds or thousands of
individual call legs in hundreds of sessions and either end might
initiate any given SIP transaction.

Also, what are the rules for passing DCS state with respect in the REFER
case?

If DCS state is extensible to provide an equivalent session identifier
at both ends of any given call, then I agree that there isn't any need
for bi-directional cookies to be grantable and remittable by either end.
But given the current draft's focus on proxies and what appears to be a
unidirectional call state, I'm not sure that it's complete enough to
solve the whole problem. Please correct me if I've missed something...

--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June 27, 2001 9:19 AM
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,
Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id


Have you considered the DCS State: draft for this mechanism?  See
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt>

IMHO, I don't see a need for such a use of a Cookie. Correlating
messages to calls is not that difficult. The key thing to note, as you
have, is that Call-ID is not necessarily useful for tying multiple call
legs together.

/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Wednesday, June 27, 2001 9:55 AM
To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id


I think it would be good to clarify our terminology, particularly since
we sometimes forget SIP does not provide directly for a call with
multiple active call legs (i.e. B2BUA is needed to rationalize each
individual SIP call with the overall session). I propose we define
"call" to mean the two participants in any given transaction and
"session" to be some collection of calls associated within a given UA
(note that "invited by a common source" is not a complete description
since some or all of the invites could have originated outside the UA).
 
This thread brings out several reasons why Call-ID should not be used to
define a "session" of multiple "calls" as defined above. Mainly because
of this, I'm preparing an I-D to address this need through the use of
header extensions for cookies, which each UA can independently grant and
accept in order to correlate call legs and potentially provide
additional context for a given call. The alternative is vendor-specific
headers and a walled garden approach to many features available in
conventional PBXes today, and I don't think that's beneficial for SIP in
the long run.
 
--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001



 
 -----Original Message-----
From: Chris Hogg [mailto:chogg@nortelnetworks.com]
Sent: Wednesday, June 27, 2001 4:03 AM
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,
Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id



Hi Jonathan,

Jonathan Rosenberg wrote:

>Careful; I am not proposing that two call legs with the same Call-ID convey
>any semantics. Specifically, receiving an INVITE from A, while in a call
>with B, where the call-id in the INVITE from A equals the call-id in the leg
>with B, does NOT imply that this is a consultative transfer. For that, we
>have Replaces, which lists the replaced leg explicitly.

>All I am saying is that a Call-ID may be reused for local convenience, if
>desired, but that it has NO semantics outside of the entity that selected
>that call-id.

Given, what you are proposing will this not mean that the definition of
a call needs to be altered?  The reason I ask is that bis-03 defines a
call as "identified by a globally unique callID" and "all participants
invited by a common source".  In the case you describe under the current
definition of a call this would mean that we would have two calls (under
the "all participants invited by a common source" rule) but with the
same callID (hence contravening the "globally unique callID" part).   

Comments?


Regards,

Chris Hogg
Nortel Networks.


-----Original Message-----
From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com
<mailto:jdrosen@dynamicsoft.com> ]
Sent: 26 June 2001 22:51
To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu,
Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id




 
-----Original Message-----
From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com
<mailto:zmolek@avaya.com> ]
Sent: Tuesday, June 26, 2001 12:35 PM
To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id


>> >same call-id in the 2 INVITE requests, is this allowed ?
>>
>> Well, the current spec would indicate that you shouldn't do this:
>>
>> >The callid MUST be a globally unique identifier and MUST NOT be reused for
>> >later calls.
>>
>> However, I recall some discussion at an IETF that people were using the same
>> call-id across different call legs as a local identifier to correlate those
>> call legs. With unique From tags and From fields, there really shouldn't be
>> a problem, so I think its OK. However, if we are going to allow it, the spec
>> should reflect it. Comments?
>
>If that's the proper way to solve this problem, then let's put that in the
>spec. But I'm not convinced that this alone will solve all cases, especially
>when this correlated information needs to be presented by a call leg attempting
>to join (as in the consultative transfer case).

Careful; I am not proposing that two call legs with the same Call-ID convey
any semantics. Specifically, receiving an INVITE from A, while in a call
with B, where the call-id in the INVITE from A equals the call-id in the leg
with B, does NOT imply that this is a consultative transfer. For that, we
have Replaces, which lists the replaced leg explicitly.

All I am saying is that a Call-ID may be reused for local convenience, if
desired, but that it has NO semantics outside of the entity that selected
that call-id.



> It only seems to work when the
>correlating entity initiates all the calls. If there's a reliable way to
>correlate an incoming call leg with an existing call, I'd love to hear about
>it.

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt
<http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt>

needs updating and adoption though, if we plan to move forward with it. As
you can see, its currently in the morgue.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net <http://www.jdrosen.net>
PHONE: (973) 952-5000
http://www.dynamicsoft.com <http://www.dynamicsoft.com> 

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
<http://www.ietf.org/mailman/listinfo/sip> 
This list is for NEW development of the core SIP 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  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C10185.42290FF0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 09:43:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11838; Mon, 2 Jul 2001 09:43:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11731; Mon, 2 Jul 2001 09:22:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11674 for ; Mon, 2 Jul 2001 09:22:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07957; Mon, 2 Jul 2001 09:21:36 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21241; Mon, 2 Jul 2001 09:21:47 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25462; Mon, 2 Jul 2001 09:21:45 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Jul 2001 09:21:46 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446568E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Mon, 2 Jul 2001 09:21:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Keep those posts ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, posts to IETF mail lists should be ASCII text only, not HTML or rich-text. There are members who use ASCII-only readers. It also keeps the mail size down considerably, a real issue with sip, which gets lots of email in a day. There is one other reason. When the size of your message gets over 40K, it is held for moderator approval. That delays the email, and creates work for yours truly. Brian _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 09:56:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13839; Mon, 2 Jul 2001 09:56:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12378; Mon, 2 Jul 2001 09:39:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11958 for ; Mon, 2 Jul 2001 09:31:16 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08115 for ; Mon, 2 Jul 2001 09:30:28 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09715 for ; Mon, 2 Jul 2001 09:21:39 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09687 for ; Mon, 2 Jul 2001 09:21:39 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C102FA.1019A922" Subject: RE: [Sip] RE: [Sipping] Call and call-id X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 2 Jul 2001 07:22:37 -0600 Message-ID: Thread-Topic: [Sip] RE: [Sipping] Call and call-id Thread-Index: AcEBhU8ouA1lEg+qSdCSx1DsIGczUgBdDAxA From: "Zmolek, Andrew (Andrew)" To: "Sean Olson (EUS)" , "William Marshall" Cc: , , , , , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C102FA.1019A922 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The state draft indicates that when both sides set cookies, the direction of a cookie must be deduced. Is there no explicit means for indicating whether a header is creating a cookie or returning one? =20 --Andy -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Saturday, June 30, 2001 10:54 AM To: Zmolek, Andrew (Andrew); William Marshall Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id The current state draft is intended to establish a "cookie" that lasts at least for the duration of a call leg. The cookie is tied to a call leg based on To/From/Call-ID. Furthermore cookies are returned based on the=20 host/port in the State: header. If the Request-URI matches or any of the Route: headers match this host/port, the State: header (cookie) is returned. =20 There is the following text in the draft as well: =20 4. Additional rules MAY be defined by other extensions that specify when a State header is to be included in a request. An example of this would be extensions that handle call transfers and other features that would specify State header processing at the UAC. This leaves open the possibility to define an extension that uses the State: header in the manner you describe. However, I think what you want to do is a bit at odds with the original intention of the draft. Having a cookie that spans call legs would require a different set of rules defining when a UAC should return a cookie in subsequent requests or a UAS in the 1xx responses.=20 =20 I would like a more generic cookie mechanism, but I think the State: header mechanism is a reasonable compromise in terms of processing at the UA. The alternative would be to provide additional information in the State: header which indicated when the State: header should be returned; similar to the path that is included in HTTP cookies. =20 e.g. State: host/port; call-id=3D"...";from=3D"..."; value =20 /sean -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Friday, June 29, 2001 5:11 PM To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew) Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Would the re-use of a state header as a means of tying together multiple call legs cause problems with anything in the state draft as written? By persistence, I'm thinking more about using the token to re-establish some value-added context of a session terminated perhaps even days earlier, but even without that concept, I need any cookie replacement to not preclude token use across multiple call legs. =20 --Andy -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, June 27, 2001 4:43 PM To: Zmolek, Andrew (Andrew); William Marshall; zmolek@avaya.ccom.avaya.com Cc: Sean Olson (EUS); chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id The State: header is a SIP extension. I believe it can be used independently of the other DCS extensions. The real issue is how widespread will the extension be -- can you depend on "most" clients to support it.=20 =20 I'm not sure what you mean by "token persistence". Do you mean a State: header that spans multiple call legs?=20 =20 /sean -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Wednesday, June 27, 2001 4:27 PM To: William Marshall; zmolek@avaya.ccom.avaya.com Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org Subject: RE: [Sip] RE: [Sipping] Call and call-id Sounds like the State header may accomplish what we are considering with cookies; there may be no need to re-invent this. How tightly coupled is the State header and the DCS call model? In other words, to support the State header will a device have to fully conform to DCS? Or is this required only to generate state?=20 Moreover, how problematic would the introduction of token persistence be to the State header? Would this cause problems with DCS implementation? Another worry: If the State header and DCS are joined at the hip, then this might be too much for simple implementations to swallow even if our own products were to comply. How much support does this proposal have in the community right now? --Andy Zmolek=20 Technology & Standards Engineer=20 CTO Standards=20 Avaya Inc.=20 zmolek@avaya.com=20 +1 720 444 4001=20 -----Original Message-----=20 From: William Marshall [ mailto:wtm@research.att.com ]=20 Sent: Wednesday, June 27, 2001 11:59 AM=20 To: zmolek@avaya.ccom.avaya.com=20 Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com;=20 jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com;=20 duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 State headers operate in both directions. A UAC that inserts a State header=20 in the INVITE will see the contents returned in every provisional and final=20 response, as well as any re-INVITE initiated by the UAS. A UAS that=20 inserts a State header into a provisional or final response will see=20 the contents returned in every re-INVITE from the UAC, as well as=20 provisional and final responses to requests initiated by the UAS.=20 The State header is documented in draft-ietf-sip-state-01.=20 Rules for handling of State headers with future extensions will need=20 to be specified in the draft defining that extension. In particular,=20 a REFER that is attempting to replace an existing call leg may need=20 the State headers from the previous call leg attached to the new=20 INVITE, along with the From/To/Call-ID. This is all still to-be-defined.=20 Bill Marshall=20 wtm@research.att.com=20 -----original messaage-----=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 Date: Wed, 27 Jun 2001 10:57:08 -0600=20 From: "Zmolek, Andrew (Andrew)" =20 To: "Sean Olson (EUS)" ,=20 "Chris Hogg" ,=20 "Jonathan Rosenberg" ,=20 "Mathieu, Marie-Noelle" ,=20 =20 Cc: "Boyle, Frank J (Duffy)" ,=20 "Freundlich, Glen G (Glen)" =20 Does DCS state only operate in one direction (ie.only from the SIP=20 transaction initiator)? If so, it would need to be extended to provide=20 equivalent information when two endpoints have hundreds or thousands of=20 individual call legs in hundreds of sessions and either end might=20 initiate any given SIP transaction.=20 Also, what are the rules for passing DCS state with respect in the REFER case?=20 If DCS state is extensible to provide an equivalent session identifier=20 at both ends of any given call, then I agree that there isn't any need=20 for bi-directional cookies to be grantable and remittable by either end. But given the current draft's focus on proxies and what appears to be a=20 unidirectional call state, I'm not sure that it's complete enough to=20 solve the whole problem. Please correct me if I've missed something...=20 --Andy=20 -----Original Message-----=20 From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ]=20 Sent: Wednesday, June 27, 2001 9:19 AM=20 To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,=20 Marie-Noelle; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 Have you considered the DCS State: draft for this mechanism? See=20 http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt =20 < http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt >=20 IMHO, I don't see a need for such a use of a Cookie. Correlating=20 messages to calls is not that difficult. The key thing to note, as you=20 have, is that Call-ID is not necessarily useful for tying multiple call=20 legs together.=20 /sean=20 -----Original Message-----=20 From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com ]=20 Sent: Wednesday, June 27, 2001 9:55 AM=20 To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 I think it would be good to clarify our terminology, particularly since=20 we sometimes forget SIP does not provide directly for a call with=20 multiple active call legs (i.e. B2BUA is needed to rationalize each=20 individual SIP call with the overall session). I propose we define=20 "call" to mean the two participants in any given transaction and=20 "session" to be some collection of calls associated within a given UA=20 (note that "invited by a common source" is not a complete description=20 since some or all of the invites could have originated outside the UA).=20 =20 This thread brings out several reasons why Call-ID should not be used to define a "session" of multiple "calls" as defined above. Mainly because=20 of this, I'm preparing an I-D to address this need through the use of=20 header extensions for cookies, which each UA can independently grant and accept in order to correlate call legs and potentially provide=20 additional context for a given call. The alternative is vendor-specific=20 headers and a walled garden approach to many features available in=20 conventional PBXes today, and I don't think that's beneficial for SIP in the long run.=20 =20 --Andy Zmolek=20 Technology & Standards Engineer=20 CTO Standards=20 Avaya Inc.=20 zmolek@avaya.com=20 +1 720 444 4001=20 =20 -----Original Message-----=20 From: Chris Hogg [ mailto:chogg@nortelnetworks.com ]=20 Sent: Wednesday, June 27, 2001 4:03 AM=20 To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,=20 Marie-Noelle; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 Hi Jonathan,=20 Jonathan Rosenberg wrote:=20 >Careful; I am not proposing that two call legs with the same Call-ID convey=20 >any semantics. Specifically, receiving an INVITE from A, while in a call=20 >with B, where the call-id in the INVITE from A equals the call-id in the leg=20 >with B, does NOT imply that this is a consultative transfer. For that, we=20 >have Replaces, which lists the replaced leg explicitly.=20 >All I am saying is that a Call-ID may be reused for local convenience, if=20 >desired, but that it has NO semantics outside of the entity that selected=20 >that call-id.=20 Given, what you are proposing will this not mean that the definition of=20 a call needs to be altered? The reason I ask is that bis-03 defines a=20 call as "identified by a globally unique callID" and "all participants=20 invited by a common source". In the case you describe under the current definition of a call this would mean that we would have two calls (under the "all participants invited by a common source" rule) but with the=20 same callID (hence contravening the "globally unique callID" part). =20 Comments?=20 Regards,=20 Chris Hogg=20 Nortel Networks.=20 -----Original Message-----=20 From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com =20 < mailto:jdrosen@dynamicsoft.com > ]=20 Sent: 26 June 2001 22:51=20 To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu,=20 Marie-Noelle; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 =20 -----Original Message-----=20 From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com =20 < mailto:zmolek@avaya.com > ]=20 Sent: Tuesday, June 26, 2001 12:35 PM=20 To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org=20 Subject: RE: [Sip] RE: [Sipping] Call and call-id=20 >> >same call-id in the 2 INVITE requests, is this allowed ?=20 >>=20 >> Well, the current spec would indicate that you shouldn't do this:=20 >>=20 >> >The callid MUST be a globally unique identifier and MUST NOT be reused for=20 >> >later calls.=20 >>=20 >> However, I recall some discussion at an IETF that people were using the same=20 >> call-id across different call legs as a local identifier to correlate those=20 >> call legs. With unique From tags and From fields, there really shouldn't be=20 >> a problem, so I think its OK. However, if we are going to allow it, the spec=20 >> should reflect it. Comments?=20 >=20 >If that's the proper way to solve this problem, then let's put that in the=20 >spec. But I'm not convinced that this alone will solve all cases, especially=20 >when this correlated information needs to be presented by a call leg attempting=20 >to join (as in the consultative transfer case).=20 Careful; I am not proposing that two call legs with the same Call-ID convey=20 any semantics. Specifically, receiving an INVITE from A, while in a call with B, where the call-id in the INVITE from A equals the call-id in the leg=20 with B, does NOT imply that this is a consultative transfer. For that, we=20 have Replaces, which lists the replaced leg explicitly.=20 All I am saying is that a Call-ID may be reused for local convenience, if=20 desired, but that it has NO semantics outside of the entity that selected=20 that call-id.=20 > It only seems to work when the=20 >correlating entity initiates all the calls. If there's a reliable way to=20 >correlate an incoming call leg with an existing call, I'd love to hear about=20 >it.=20 http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00 .txt =20 < http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00 .txt >=20 needs updating and adoption though, if we plan to move forward with it. As=20 you can see, its currently in the morgue.=20 -Jonathan R.=20 ---=20 Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.=20 Chief Scientist First Floor=20 dynamicsoft East Hanover, NJ 07936=20 jdrosen@dynamicsoft.com FAX: (973) 952-5050=20 http://www.jdrosen.net < http://www.jdrosen.net >=20 PHONE: (973) 952-5000=20 http://www.dynamicsoft.com < http://www.dynamicsoft.com > =20 _______________________________________________=20 Sip mailing list http://www.ietf.org/mailman/listinfo/sip =20 < http://www.ietf.org/mailman/listinfo/sip > =20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 _______________________________________________=20 Sip mailing list http://www.ietf.org/mailman/listinfo/sip =20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 ------_=_NextPart_001_01C102FA.1019A922 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: [Sipping] Call and call-id
The=20 state draft indicates that when both sides set cookies, the direction of = a=20 cookie must be deduced. Is there no explicit means for indicating = whether a=20 header is creating a cookie or returning one?
 
--Andy
-----Original Message-----
From: Sean Olson (EUS)=20 [mailto:sean.olson@ericsson.com]
Sent: Saturday, June 30, = 2001 10:54=20 AM
To: Zmolek, Andrew (Andrew); William = Marshall
Cc:=20 chogg@nortelnetworks.com; jdrosen@dynamicsoft.com;=20 Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20 ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] = RE:=20 [Sipping] Call and call-id

The=20 current state draft is intended to establish a "cookie" that lasts=20 at
least for the duration of a call leg. The cookie is tied to a = call leg=20 based
on=20 To/From/Call-ID. Furthermore cookies are returned based on the=20
host/port in the State: header. If the Request-URI matches or = any
of=20 the Route: headers match this host/port, the State: header=20 (cookie)
is=20 returned.
 
There is the following text in the draft as = well:
 

 =20 4.      Additional rules MAY be defined by = other=20 extensions that specify
     when a State = header is to=20 be included in a request. An example of
     = this would=20 be extensions that handle call transfers and = other
    =20 features that would specify State header processing at the=20 UAC.
This=20 leaves open the possibility to define an extension that uses=20 the
State: header in the manner you describe. However, I think = what=20 you
want=20 to do is a bit at odds with the original intention of the draft.=20 Having
a=20 cookie that spans call legs would require a different set of rules=20 defining
when=20 a UAC should return a cookie in subsequent requests or a UAS=20 in
the=20 1xx responses.
 
I=20 would like a more generic cookie mechanism, but I think the State:=20 header
mechanism is a reasonable compromise in terms of processing = at the=20 UA.
The=20 alternative would be to provide additional information in the State:=20 header
which indicated when the State: header should be returned; = similar to=20 the
path=20 that is included in HTTP cookies.
 
e.g.
State: host/port; call-id=3D"...";from=3D"..."; = value
 
/sean
-----Original Message-----
From: Zmolek, Andrew = (Andrew)=20 [mailto:zmolek@avaya.com]
Sent: Friday, June 29, 2001 5:11 = PM
To: Sean Olson (EUS); William Marshall; Zmolek, Andrew=20 (Andrew)
Cc: chogg@nortelnetworks.com; = jdrosen@dynamicsoft.com;=20 Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20 ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] = RE:=20 [Sipping] Call and call-id

Would the re-use of a state header as a = means=20 of tying together multiple call legs cause problems with = anything in=20 the state draft as written? By persistence, I'm thinking more about = using=20 the token to re-establish some value-added context of a session = terminated=20 perhaps even days earlier, but even without that concept, I need any = cookie=20 replacement to not preclude token use across multiple call=20 legs.
 
--Andy
-----Original Message-----
From: Sean Olson = (EUS)=20 [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June = 27, 2001=20 4:43 PM
To: Zmolek, Andrew (Andrew); William Marshall;=20 zmolek@avaya.ccom.avaya.com
Cc: Sean Olson (EUS);=20 chogg@nortelnetworks.com; jdrosen@dynamicsoft.com;=20 Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20 ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: = [Sip] RE:=20 [Sipping] Call and call-id

The State: header is a SIP extension. I believe it can be = used=20 independently
of the other DCS extensions. The real issue is how = widespread will=20 the
extension be -- can you depend on "most" clients to = support it.=20
 
I'm not sure what you mean by "token persistence". Do you = mean
a State: header that spans multiple call legs? =
 
/sean
-----Original Message-----
From: Zmolek, = Andrew=20 (Andrew) [mailto:zmolek@avaya.com]
Sent: Wednesday, = June 27,=20 2001 4:27 PM
To: William Marshall;=20 zmolek@avaya.ccom.avaya.com
Cc: = sean.olson@ericsson.com;=20 chogg@nortelnetworks.com; jdrosen@dynamicsoft.com;=20 Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20 ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: = [Sip] RE:=20 [Sipping] Call and call-id

Sounds like the State header may accomplish = what we are=20 considering with cookies; there may be no need to re-invent = this. How=20 tightly coupled is the State header and the DCS call = model?  In=20 other words, to support the State header will a device have to = fully=20 conform to DCS? Or is this required only to generate state? =

Moreover, how problematic would the = introduction of=20 token persistence be to the State header? Would this cause = problems with=20 DCS implementation? Another worry: If the State header and DCS = are=20 joined at the hip, then this might be too much for simple=20 implementations to swallow even if our own products were to = comply. How=20 much support does this proposal have in the community right=20 now?

--Andy Zmolek
   =20 Technology & Standards Engineer
      CTO Standards =
        Avaya = Inc.

          &nbs= p;=20 zmolek@avaya.com
          &nbs= p;  =20 +1 720 444 4001



-----Original Message-----
From:=20 William Marshall [mailto:wtm@research.att.com]=20
Sent: Wednesday, June 27, 2001 11:59 = AM=20
To: zmolek@avaya.ccom.avaya.com =
Cc: sean.olson@ericsson.com; = chogg@nortelnetworks.com;=20
jdrosen@dynamicsoft.com;=20 Marie-Noelle.Mathieu@compaq.com;
duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com;=20 sip@ietf.org
Subject: RE: [Sip] RE: = [Sipping]=20 Call and call-id


State headers operate in both = directions.  A UAC=20 that inserts a State header
in the = INVITE will=20 see the contents returned in every provisional and final=20
response, as well as any re-INVITE initiated = by the=20 UAS.  A UAS that
inserts a State = header=20 into a provisional or final response will see
the contents returned in every re-INVITE from the UAC, = as well=20 as
provisional and final responses to = requests=20 initiated by the UAS.
The State header = is=20 documented in draft-ietf-sip-state-01.

Rules for handling of State headers with = future=20 extensions will need
to be specified = in the=20 draft defining that extension. In particular,
a=20 REFER that is attempting to replace an existing call leg may = need=20
the State headers from the previous call leg = attached=20 to the new
INVITE, along with the=20 From/To/Call-ID.  This is all still to-be-defined. =

Bill Marshall
wtm@research.att.com

-----original messaage-----
Subject: RE: [Sip] RE: [Sipping] Call and = call-id=20
Date: Wed, 27 Jun 2001 10:57:08 -0600 =
From: "Zmolek, Andrew (Andrew)" = <zmolek@avaya.com>=20
To: "Sean Olson (EUS)"=20 <sean.olson@ericsson.com>,
        "Chris Hogg" = <chogg@nortelnetworks.com>,
        "Jonathan = Rosenberg"=20 <jdrosen@dynamicsoft.com>,
        "Mathieu,=20 Marie-Noelle" <Marie-Noelle.Mathieu@compaq.com>, =
       =20 <sip@ietf.org>
Cc: "Boyle, Frank = J=20 (Duffy)" <duffy@drmail.dr.avaya.com>,
        "Freundlich, = Glen G=20 (Glen)" <ggf@drmail.dr.avaya.com>

Does DCS state only operate in one direction = (ie.only=20 from the SIP
transaction initiator)? = If so, it=20 would need to be extended to provide
equivalent=20 information when two endpoints have hundreds or thousands = of=20
individual call legs in hundreds of sessions = and either=20 end might
initiate any given SIP=20 transaction.

Also, what are the rules for passing DCS state = with=20 respect in the REFER
case?

If DCS state is extensible to provide an = equivalent=20 session identifier
at both ends of any = given=20 call, then I agree that there isn't any need
for=20 bi-directional cookies to be grantable and remittable by either=20 end.
But given the current draft's = focus on=20 proxies and what appears to be a
unidirectional=20 call state, I'm not sure that it's complete enough to =
solve the whole problem. Please correct me if I've = missed=20 something...

--Andy

-----Original Message-----
From:=20 Sean Olson (EUS) [mailto:sean.olson@ericsson.com]=20
Sent: Wednesday, June 27, 2001 9:19 AM =
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan = Rosenberg;=20 Mathieu,
Marie-Noelle; = sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and=20 call-id


Have you considered the DCS State: draft for = this=20 mechanism?  See
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt=20
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt&g= t;=20

IMHO, I don't see a need for such a use of a = Cookie.=20 Correlating
messages to calls is not = that=20 difficult. The key thing to note, as you
have,=20 is that Call-ID is not necessarily useful for tying multiple = call=20
legs together.

/sean

-----Original Message-----
From:=20 Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]=20
Sent: Wednesday, June 27, 2001 9:55 AM =
To: Chris Hogg; Jonathan Rosenberg; Mathieu, = Marie-Noelle;=20 sip@ietf.org
Subject: RE: [Sip] RE: = [Sipping]=20 Call and call-id


I think it would be good to clarify our = terminology,=20 particularly since
we sometimes forget = SIP does=20 not provide directly for a call with
multiple=20 active call legs (i.e. B2BUA is needed to rationalize = each=20
individual SIP call with the overall = session). I=20 propose we define
"call" to mean the = two=20 participants in any given transaction and
"session" to be some collection of calls associated = within a=20 given UA
(note that "invited by a = common source"=20 is not a complete description
since = some or all=20 of the invites could have originated outside the UA). =
 
This thread brings out = several=20 reasons why Call-ID should not be used to
define=20 a "session" of multiple "calls" as defined above. Mainly = because=20
of this, I'm preparing an I-D to address this = need=20 through the use of
header extensions = for=20 cookies, which each UA can independently grant and =
accept in order to correlate call legs and potentially=20 provide
additional context for a given = call. The=20 alternative is vendor-specific
headers = and a=20 walled garden approach to many features available in =
conventional PBXes today, and I don't think that's = beneficial for=20 SIP in
the long run.
 
--Andy Zmolek =
    Technology & Standards = Engineer=20
      CTO = Standards=20
        = Avaya=20 Inc.

          &nbs= p;=20 zmolek@avaya.com
          &nbs= p;  =20 +1 720 444 4001



  =
 -----Original Message-----
From:=20 Chris Hogg [mailto:chogg@nortelnetworks.com<= /A>]=20
Sent: Wednesday, June 27, 2001 4:03 AM =
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew);=20 Mathieu,
Marie-Noelle; = sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and=20 call-id



Hi Jonathan,

Jonathan Rosenberg wrote:

>Careful; I am not proposing that two call = legs with=20 the same Call-ID convey
>any = semantics.=20 Specifically, receiving an INVITE from A, while in a call=20
>with B, where the call-id in the = INVITE from=20 A equals the call-id in the leg
>with B, does=20 NOT imply that this is a consultative transfer. For that, we=20
>have Replaces, which lists the = replaced leg=20 explicitly.

>All I am saying is that a Call-ID may be = reused for=20 local convenience, if
>desired, but = that it=20 has NO semantics outside of the entity that selected =
>that call-id.

Given, what you are proposing will this not = mean that=20 the definition of
a call needs to be=20 altered?  The reason I ask is that bis-03 defines a=20
call as "identified by a globally unique = callID" and=20 "all participants
invited by a common=20 source".  In the case you describe under the current =
definition of a call this would mean that we = would have=20 two calls (under
the "all participants = invited=20 by a common source" rule) but with the
same=20 callID (hence contravening the "globally unique callID"=20 part).   

Comments?


Regards,

Chris Hogg
Nortel = Networks.=20


-----Original Message-----
From:=20 Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com=20
<mailto:jdrosen@dynamicsoft.com>=20 ]
Sent: 26 June 2001 22:51 =
To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; = Mathieu,=20
Marie-Noelle; sip@ietf.org =
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20




 
-----Original = Message-----
From: Zmolek, Andrew = (Andrew) [ mailto:zmolek@avaya.com=20
<mailto:zmolek@avaya.com> = ]=20
Sent: Tuesday, June 26, 2001 12:35 PM=20
To: Jonathan Rosenberg; Mathieu, = Marie-Noelle;=20 sip@ietf.org
Subject: RE: [Sip] RE: = [Sipping]=20 Call and call-id


>> >same call-id in the 2 INVITE = requests, is=20 this allowed ?
>> =
>> Well, the current spec would indicate that you = shouldn't=20 do this:
>>
>> >The callid MUST be a globally unique = identifier and=20 MUST NOT be reused for
>> = >later calls.=20
>>
>>=20 However, I recall some discussion at an IETF that people were = using the=20 same
>> call-id across different = call legs=20 as a local identifier to correlate those
>> call legs. With unique From tags and From = fields, there=20 really shouldn't be
>> a = problem, so I=20 think its OK. However, if we are going to allow it, the = spec=20
>> should reflect it. Comments? =
>
>If that's the proper = way to=20 solve this problem, then let's put that in the
>spec. But I'm not convinced that this alone will = solve all=20 cases, especially
>when this = correlated=20 information needs to be presented by a call leg attempting=20
>to join (as in the consultative = transfer=20 case).

Careful; I am not proposing that two call legs = with the=20 same Call-ID convey
any semantics. = Specifically,=20 receiving an INVITE from A, while in a call
with=20 B, where the call-id in the INVITE from A equals the call-id in = the leg=20
with B, does NOT imply that this is a=20 consultative transfer. For that, we
have=20 Replaces, which lists the replaced leg explicitly.

All I am saying is that a Call-ID may be = reused for=20 local convenience, if
desired, but = that it has=20 NO semantics outside of the entity that selected =
that call-id.



> It only seems to work when the =
>correlating entity initiates all the calls. If = there's a=20 reliable way to
>correlate an = incoming call=20 leg with an existing call, I'd love to hear about =
>it.

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip= -replaces-00.txt=20
<http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip= -replaces-00.txt>=20

needs updating and adoption though, if we plan = to move=20 forward with it. As
you can see, its = currently=20 in the morgue.

-Jonathan R.
---=20
Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;   =20 72 Eagle Rock Ave.
Chief=20 = Scientist          &nbs= p;            = ;     =20 First Floor
dynamicsoft         = ;            =            =20 East Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =  =20 FAX:   (973) 952-5050
http://www.jdrosen.net = <http://www.jdrosen.net>=20
PHONE: (973) 952-5000
http://www.dynamicsoft.com = <http://www.dynamicsoft.com>&nb= sp;=20

_______________________________________________=20
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip=20
<http://www.ietf.org/mai= lman/listinfo/sip> =20
This list is for NEW development of = the core SIP=20 Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of sip=20



_______________________________________________=20
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip=20
This list is for NEW development of the core = SIP=20 Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of = sip=20 =

------_=_NextPart_001_01C102FA.1019A922-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 11:11:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21905 for ; Mon, 2 Jul 2001 11:11:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D3984434A; Mon, 2 Jul 2001 11:12:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mr1.ash.ops.us.uu.net (mr1.ash.ops.us.uu.net [198.5.241.86]) by lists.bell-labs.com (Postfix) with ESMTP id ADC2844336 for ; Mon, 2 Jul 2001 11:11:46 -0400 (EDT) Received: from overhill by mr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: user2.sentito.com [65.202.222.2] (may be forged)) id QQkvyi00063 for ; Mon, 2 Jul 2001 15:11:47 GMT From: "Frank W. Miller" To: Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [SIP] Call Fowarding feature support Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Jul 2001 11:11:13 -0400 Content-Transfer-Encoding: 7bit Hi again, First, thanks for the help with the CIDB feature, I'll look at the privacy draft. Second, I have an additional question having to do with call forwarding. Lets say we have a call that arrives at a SIP user agent and call forwarding is active at that user agent. Further, lets assume that part of the call is carried over the PSTN. There are two possibilities, 1) the call is forwarded to another SIP location, and 2) the call is forwarded to another phone that is on the PSTN. It seems to me that in the first case, only SIP redirection is necessary and that this may be transparent to the PSTN leg of the call? In the second case, there may be some SS7 interaction required. Has anyone looked at this and if so is there any documentation on preferred approaches? If not, does anyone have any thoughts on how it should be done? Thanks, FM -- Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. www.sentito.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 11:26:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02956; Mon, 2 Jul 2001 11:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15722; Mon, 2 Jul 2001 11:08:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15695 for ; Mon, 2 Jul 2001 11:08:32 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19176 for ; Mon, 2 Jul 2001 11:07:49 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f62F4wH16445; Mon, 2 Jul 2001 08:05:00 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f62F6gS04289; Mon, 2 Jul 2001 08:06:42 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA28841; Mon, 2 Jul 2001 08:06:31 -0700 (PDT) Message-ID: <3B408E52.81BB1CF9@cisco.com> Date: Mon, 02 Jul 2001 11:08:02 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Jonathan Rosenberg , "'Dean Willis'" , Romel Khan , sip@ietf.org Subject: Re: [Sip] II digit & Calling Name References: <3B2B6ABD.8B02BB2F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > The privacy draft, to some degree, is inconsistent with the caller > > preferences spec in this regard. For example, one of the rpi-id-types is > > "return", which is more like the Contact, in that its a "device" address, > > not a user identity. > > My interpretation was that this was more of a logical address rather > than a device address, similar to the 'reply-to' header in email. For > example, you could imagine that you want all future calls (not > transactions within the call) to sales critter S to always go to > sales@example.com. (Or the example given in the spec, of providing an > 800# for return calls in outgoing calls.) > > If this difference is indeed correct, I believe it would be helpful if > the authors could clarify the call vs. transactions-within-call > distinction. > You are correct. I've changed the description as follows: "Return session identity (rpi-id-type="return") This provides the URL to which the party wishes return session initiations (as opposed to new transactions within this call leg) to be addressed. For example a business may wish to provide a 'freephone' identity to encourage future return calls. If absent, the return session identity is assumed to be the same as the subscriber identity. " -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 11:38:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11212 for ; Mon, 2 Jul 2001 11:38:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D779344352; Mon, 2 Jul 2001 11:39:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paris.packetizer.org (rdu26-248-199.nc.rr.com [66.26.248.199]) by lists.bell-labs.com (Postfix) with ESMTP id D71F444336 for ; Sun, 1 Jul 2001 21:26:36 -0400 (EDT) Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id f621SrH18340; Sun, 1 Jul 2001 21:28:54 -0400 Message-ID: <00fa01c10296$5e0e25e0$0401a8c0@berlin> From: "Paul E. Jones" To: , References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> Subject: Re: [SIP] SIP Message segmentation problem over TCP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 1 Jul 2001 21:28:58 -0400 Content-Transfer-Encoding: 7bit Chandra, TPKT (RFC 1006) would have been the logical thing to do. However, as SIP is an ASCII-based protocol, which requires the parsers to look though long strings like "Content-Length" for information (then perform expensive arithmetic in order to actually calculate the length in this case), using TPKT would look like a "kludge" in the protocol. While the IETF has a history of engineering more efficient protocols, SIP was not engineered with processing efficiency in mind. Paul ----- Original Message ----- From: "Chandra Ravipati" To: Sent: Friday, June 29, 2001 3:01 PM Subject: [SIP] SIP Message segmentation problem over TCP > > Hi, > > I want to know how others are dealing with message segmentation for TCP. > > Do people use TPKT? or use Content-length: ? > > Using "content-length" is very inefficient and very protocol specific. > Why can't we use TPKT? > > > Thanks in advance for your participation in this discussion. > Chandra Ravipati. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 11:42:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13613; Mon, 2 Jul 2001 11:42:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15495; Mon, 2 Jul 2001 11:04:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15464 for ; Mon, 2 Jul 2001 11:04:48 -0400 (EDT) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16395 for ; Mon, 2 Jul 2001 11:04:04 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08672; Mon, 2 Jul 2001 11:04:16 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AJS00814; Mon, 2 Jul 2001 11:04:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010702105216.00b103c0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jul 2001 11:06:24 -0400 To: "Zmolek, Andrew (Andrew)" From: Michael Hammer Subject: RE: [Sip] RE: [Sipping] Call and call-id Cc: "Sean Olson (EUS)" , "William Marshall" , , , , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Andy, I had the impression that the nature of the cookie was such that only the creator new what was encoded. The suggestion about setting direction was to enable that node to determine whether the cookie was being returned by whichever side. Also, in response to the previous email, While the description was targeted to a simple 2-way communication, I was not under the impression that there was any guidance concerning multi-way calls. I would presume that it would be an implementation detail, unless explicitly defined. Mike At 07:22 AM 7/2/2001 -0600, Zmolek, Andrew (Andrew) wrote: >The state draft indicates that when both sides set cookies, the direction >of a cookie must be deduced. Is there no explicit means for indicating >whether a header is creating a cookie or returning one? > >--Andy >-----Original Message----- >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >Sent: Saturday, June 30, 2001 10:54 AM >To: Zmolek, Andrew (Andrew); William Marshall >Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; >Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; >ggf@bighorn.dr.avaya.com; sip@ietf.org >Subject: RE: [Sip] RE: [Sipping] Call and call-id > >The current state draft is intended to establish a "cookie" that lasts at >least for the duration of a call leg. The cookie is tied to a call leg based >on To/From/Call-ID. Furthermore cookies are returned based on the >host/port in the State: header. If the Request-URI matches or any >of the Route: headers match this host/port, the State: header (cookie) >is returned. > >There is the following text in the draft as well: > > > 4. Additional rules MAY be defined by other extensions that specify > when a State header is to be included in a request. An example of > this would be extensions that handle call transfers and other > features that would specify State header processing at the UAC. >This leaves open the possibility to define an extension that uses the >State: header in the manner you describe. However, I think what you >want to do is a bit at odds with the original intention of the draft. Having >a cookie that spans call legs would require a different set of rules defining >when a UAC should return a cookie in subsequent requests or a UAS in >the 1xx responses. > >I would like a more generic cookie mechanism, but I think the State: header >mechanism is a reasonable compromise in terms of processing at the UA. >The alternative would be to provide additional information in the State: >header >which indicated when the State: header should be returned; similar to the >path that is included in HTTP cookies. > >e.g. >State: host/port; call-id="...";from="..."; value > >/sean >>-----Original Message----- >>From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] >>Sent: Friday, June 29, 2001 5:11 PM >>To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew) >>Cc: chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; >>Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; >>ggf@bighorn.dr.avaya.com; sip@ietf.org >>Subject: RE: [Sip] RE: [Sipping] Call and call-id >> >>Would the re-use of a state header as a means of tying together multiple >>call legs cause problems with anything in the state draft as written? By >>persistence, I'm thinking more about using the token to re-establish some >>value-added context of a session terminated perhaps even days earlier, >>but even without that concept, I need any cookie replacement to not >>preclude token use across multiple call legs. >> >>--Andy >>-----Original Message----- >>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >>Sent: Wednesday, June 27, 2001 4:43 PM >>To: Zmolek, Andrew (Andrew); William Marshall; zmolek@avaya.ccom.avaya.com >>Cc: Sean Olson (EUS); chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; >>Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com; >>ggf@bighorn.dr.avaya.com; sip@ietf.org >>Subject: RE: [Sip] RE: [Sipping] Call and call-id >> >>The State: header is a SIP extension. I believe it can be used independently >>of the other DCS extensions. The real issue is how widespread will the >>extension be -- can you depend on "most" clients to support it. >> >>I'm not sure what you mean by "token persistence". Do you mean >>a State: header that spans multiple call legs? >> >>/sean >>>-----Original Message----- >>>From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] >>>Sent: Wednesday, June 27, 2001 4:27 PM >>>To: William Marshall; zmolek@avaya.ccom.avaya.com >>>Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; >>>jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; >>>duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>>Sounds like the State header may accomplish what we are considering with >>>cookies; there may be no need to re-invent this. How tightly coupled is >>>the State header and the DCS call model? In other words, to support the >>>State header will a device have to fully conform to DCS? Or is this >>>required only to generate state? >>>Moreover, how problematic would the introduction of token persistence be >>>to the State header? Would this cause problems with DCS implementation? >>>Another worry: If the State header and DCS are joined at the hip, then >>>this might be too much for simple implementations to swallow even if our >>>own products were to comply. How much support does this proposal have in >>>the community right now? >>>--Andy Zmolek >>> Technology & Standards Engineer >>> CTO Standards >>> Avaya Inc. >>> >>> zmolek@avaya.com >>> +1 720 444 4001 >>> >>> >>> >>>-----Original Message----- >>>From: William Marshall >>>[mailto:wtm@research.att.com] >>>Sent: Wednesday, June 27, 2001 11:59 AM >>>To: zmolek@avaya.ccom.avaya.com >>>Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com; >>>jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com; >>>duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>>State headers operate in both directions. A UAC that inserts a State >>>header >>>in the INVITE will see the contents returned in every provisional and >>>final >>>response, as well as any re-INVITE initiated by the UAS. A UAS that >>>inserts a State header into a provisional or final response will see >>>the contents returned in every re-INVITE from the UAC, as well as >>>provisional and final responses to requests initiated by the UAS. >>>The State header is documented in draft-ietf-sip-state-01. >>> >>>Rules for handling of State headers with future extensions will need >>>to be specified in the draft defining that extension. In particular, >>>a REFER that is attempting to replace an existing call leg may need >>>the State headers from the previous call leg attached to the new >>>INVITE, along with the From/To/Call-ID. This is all still to-be-defined. >>> >>>Bill Marshall >>>wtm@research.att.com >>> >>>-----original messaage----- >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>>Date: Wed, 27 Jun 2001 10:57:08 -0600 >>>From: "Zmolek, Andrew (Andrew)" >>>To: "Sean Olson (EUS)" , >>> "Chris Hogg" , >>> "Jonathan Rosenberg" , >>> "Mathieu, Marie-Noelle" , >>> >>>Cc: "Boyle, Frank J (Duffy)" , >>> "Freundlich, Glen G (Glen)" >>> >>>Does DCS state only operate in one direction (ie.only from the SIP >>>transaction initiator)? If so, it would need to be extended to provide >>>equivalent information when two endpoints have hundreds or thousands of >>>individual call legs in hundreds of sessions and either end might >>>initiate any given SIP transaction. >>> >>>Also, what are the rules for passing DCS state with respect in the REFER >>>case? >>> >>>If DCS state is extensible to provide an equivalent session identifier >>>at both ends of any given call, then I agree that there isn't any need >>>for bi-directional cookies to be grantable and remittable by either end. >>>But given the current draft's focus on proxies and what appears to be a >>>unidirectional call state, I'm not sure that it's complete enough to >>>solve the whole problem. Please correct me if I've missed something... >>> >>>--Andy >>> >>>-----Original Message----- >>>From: Sean Olson (EUS) >>>[mailto:sean.olson@ericsson.com] >>>Sent: Wednesday, June 27, 2001 9:19 AM >>>To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu, >>>Marie-Noelle; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>>Have you considered the DCS State: draft for this mechanism? See >>>http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt >>> >>> >>> >>>IMHO, I don't see a need for such a use of a Cookie. Correlating >>>messages to calls is not that difficult. The key thing to note, as you >>>have, is that Call-ID is not necessarily useful for tying multiple call >>>legs together. >>> >>>/sean >>> >>>-----Original Message----- >>>From: Zmolek, Andrew (Andrew) >>>[mailto:zmolek@avaya.com] >>>Sent: Wednesday, June 27, 2001 9:55 AM >>>To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>>I think it would be good to clarify our terminology, particularly since >>>we sometimes forget SIP does not provide directly for a call with >>>multiple active call legs (i.e. B2BUA is needed to rationalize each >>>individual SIP call with the overall session). I propose we define >>>"call" to mean the two participants in any given transaction and >>>"session" to be some collection of calls associated within a given UA >>>(note that "invited by a common source" is not a complete description >>>since some or all of the invites could have originated outside the UA). >>> >>>This thread brings out several reasons why Call-ID should not be used to >>>define a "session" of multiple "calls" as defined above. Mainly because >>>of this, I'm preparing an I-D to address this need through the use of >>>header extensions for cookies, which each UA can independently grant and >>>accept in order to correlate call legs and potentially provide >>>additional context for a given call. The alternative is vendor-specific >>>headers and a walled garden approach to many features available in >>>conventional PBXes today, and I don't think that's beneficial for SIP in >>>the long run. >>> >>>--Andy Zmolek >>> Technology & Standards Engineer >>> CTO Standards >>> Avaya Inc. >>> >>> zmolek@avaya.com >>> +1 720 444 4001 >>> >>> >>> >>> >>> -----Original Message----- >>>From: Chris Hogg >>>[mailto:chogg@nortelnetworks.com] >>>Sent: Wednesday, June 27, 2001 4:03 AM >>>To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu, >>>Marie-Noelle; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>> >>> >>>Hi Jonathan, >>>Jonathan Rosenberg wrote: >>> >Careful; I am not proposing that two call legs with the same Call-ID >>> convey >>> >any semantics. Specifically, receiving an INVITE from A, while in a call >>> >with B, where the call-id in the INVITE from A equals the call-id in >>> the leg >>> >with B, does NOT imply that this is a consultative transfer. For that, >>> we >>> >have Replaces, which lists the replaced leg explicitly. >>> >All I am saying is that a Call-ID may be reused for local convenience, >>> if >>> >desired, but that it has NO semantics outside of the entity that >>> selected >>> >that call-id. >>>Given, what you are proposing will this not mean that the definition of >>>a call needs to be altered? The reason I ask is that bis-03 defines a >>>call as "identified by a globally unique callID" and "all participants >>>invited by a common source". In the case you describe under the current >>>definition of a call this would mean that we would have two calls (under >>>the "all participants invited by a common source" rule) but with the >>>same callID (hence contravening the "globally unique callID" part). >>>Comments? >>>Regards, >>>Chris Hogg >>>Nortel Networks. >>>-----Original Message----- >>>From: Jonathan Rosenberg [ >>>mailto:jdrosen@dynamicsoft.com >>> ] >>>Sent: 26 June 2001 22:51 >>>To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, >>>Marie-Noelle; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >>> >>> >>> >>>-----Original Message----- >>>From: Zmolek, Andrew (Andrew) [ >>>mailto:zmolek@avaya.com >>> ] >>>Sent: Tuesday, June 26, 2001 12:35 PM >>>To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org >>>Subject: RE: [Sip] RE: [Sipping] Call and call-id >>> >> >same call-id in the 2 INVITE requests, is this allowed ? >>> >> >>> >> Well, the current spec would indicate that you shouldn't do this: >>> >> >>> >> >The callid MUST be a globally unique identifier and MUST NOT be >>> reused for >>> >> >later calls. >>> >> >>> >> However, I recall some discussion at an IETF that people were using >>> the same >>> >> call-id across different call legs as a local identifier to >>> correlate those >>> >> call legs. With unique From tags and From fields, there really >>> shouldn't be >>> >> a problem, so I think its OK. However, if we are going to allow it, >>> the spec >>> >> should reflect it. Comments? >>> > >>> >If that's the proper way to solve this problem, then let's put that in >>> the >>> >spec. But I'm not convinced that this alone will solve all cases, >>> especially >>> >when this correlated information needs to be presented by a call leg >>> attempting >>> >to join (as in the consultative transfer case). >>>Careful; I am not proposing that two call legs with the same Call-ID >>>convey >>>any semantics. Specifically, receiving an INVITE from A, while in a call >>>with B, where the call-id in the INVITE from A equals the call-id in the >>>leg >>>with B, does NOT imply that this is a consultative transfer. For that, we >>>have Replaces, which lists the replaced leg explicitly. >>>All I am saying is that a Call-ID may be reused for local convenience, if >>>desired, but that it has NO semantics outside of the entity that selected >>>that call-id. >>> >>> > It only seems to work when the >>> >correlating entity initiates all the calls. If there's a reliable way to >>> >correlate an incoming call leg with an existing call, I'd love to hear >>> about >>> >it. >>>http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt >>> >>> >>> >>> >>>needs updating and adoption though, if we plan to move forward with it. As >>>you can see, its currently in the morgue. >>>-Jonathan R. >>>--- >>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>>Chief Scientist First Floor >>>dynamicsoft East Hanover, NJ 07936 >>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>http://www.jdrosen.net >>>PHONE: (973) 952-5000 >>>http://www.dynamicsoft.com >>> >>>_______________________________________________ >>>Sip mailing >>>list >>>http://www.ietf.org/mailman/listinfo/sip >>> >>> >>>This list is for NEW development of the core SIP 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 >>>http://www.ietf.org/mailman/listinfo/sip >>> >>>This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 11:47:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16934 for ; Mon, 2 Jul 2001 11:47:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 162AB4435A; Mon, 2 Jul 2001 11:48:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1622144359 for ; Mon, 2 Jul 2001 11:47:36 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03531; Mon, 2 Jul 2001 11:51:37 -0400 (EDT) Message-ID: <3B409793.175A635C@dynamicsoft.com> From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul E. Jones" Cc: ravipati@avaya.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 11:47:31 -0400 Content-Transfer-Encoding: 7bit SIP is based on HTTP and you can blame HTTP for this particular aspect of SIP. Using a Content-Length header is perfectly logical, BTW. Cheers, Anders "Paul E. Jones" wrote: > > Chandra, > > TPKT (RFC 1006) would have been the logical thing to do. However, as SIP is > an ASCII-based protocol, which requires the parsers to look though long > strings like "Content-Length" for information (then perform expensive > arithmetic in order to actually calculate the length in this case), using > TPKT would look like a "kludge" in the protocol. > > While the IETF has a history of engineering more efficient protocols, SIP > was not engineered with processing efficiency in mind. > > Paul _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jul 2 12:01:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25863 for ; Mon, 2 Jul 2001 12:01:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6FC044371; Mon, 2 Jul 2001 12:01:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8ED844336 for ; Mon, 2 Jul 2001 12:00:49 -0400 (EDT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GFU00IIFSGZ81@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 2 Jul 2001 16:00:35 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GFU00001SGPHM@pmismtp03.wcomnet.com>; Mon, 02 Jul 2001 16:00:35 +0000 (GMT) Received: from hsinnreich ([166.35.248.227]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GFU00KN9SGB34@pmismtp03.wcomnet.com>; Mon, 02 Jul 2001 16:00:12 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] SIP Message segmentation problem over TCP In-reply-to: <3B409793.175A635C@dynamicsoft.com> To: "Paul E. Jones" Cc: ravipati@avaya.com, Anders Kristensen , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 11:00:11 -0500 Content-Transfer-Encoding: 7bit > While the IETF has a history of engineering more efficient protocols, SIP > was not engineered with processing efficiency in mind. Cheap shot. The issue of text based vs. ASN.1 has been amply debated and been shown to not make any significant difference. Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Anders Kristensen Sent: Monday, July 02, 2001 10:48 AM To: Paul E. Jones Cc: ravipati@avaya.com; sip@lists.bell-labs.com Subject: Re: [SIP] SIP Message segmentation problem over TCP SIP is based on HTTP and you can blame HTTP for this particular aspect of SIP. Using a Content-Length header is perfectly logical, BTW. Cheers, Anders "Paul E. Jones" wrote: > > Chandra, > > TPKT (RFC 1006) would have been the logical thing to do. However, as SIP is > an ASCII-based protocol, which requires the parsers to look though long > strings like "Content-Length" for information (then perform expensive > arithmetic in order to actually calculate the length in this case), using > TPKT would look like a "kludge" in the protocol. > > While the IETF has a history of engineering more efficient protocols, SIP > was not engineered with processing efficiency in mind. > > Paul _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 12:56:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01837; Mon, 2 Jul 2001 12:56:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19083; Mon, 2 Jul 2001 12:44:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19052 for ; Mon, 2 Jul 2001 12:44:55 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24040 for ; Mon, 2 Jul 2001 12:44:12 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f62Gisp29115 for ; Mon, 2 Jul 2001 11:44:54 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f62GirK11229 for ; Mon, 2 Jul 2001 11:44:53 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA14872 for ; Mon, 2 Jul 2001 11:44:53 -0500 (CDT) Reply-To: To: Date: Mon, 2 Jul 2001 11:44:51 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985022518EA@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Forking: a modest proposal. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm putting together the SUB/NOT draft (we should go into nits on Monday), and am currently wrestling with the issue of forking. I have what I think is an elegant solution, given the immediate NOTIFY mechanism that we have agreed on. Certain camps have objections to this mechanism, and thinks that all but the first SUBSCRIBE should be made to fail (by sending a 400 class response). I don't see this difference of opinion as intractable, but it is something that will take a considerable amount of time (discussion, work, etc) to reach consensus. On reflection, I realize that this entire situation just highlights a thorn we've had in our paw the entire time. Given that all transactions complete (basically) immediately (with the exception of INVITEs), forking *any* non-INVITE request is just a race waiting to happen. It usually just leads to heartburn when you attempt to analyze how it's going to work with non-INVITE methods (as in the SUBSCRIBE example). Since there seems to be a general feeling that all but the first received request should "fail" in some general sense (usually by the request initiator not finding out about the response), I'd like to float a proposal: Deprecate forking of non-INVITEs. Despite my tongue-in-cheek subject line, I'm serious. SIP is not going to Draft Standard this time around, so maintaining absolute compatibility with RFC 2543 isn't strictly required. No one has come up with a useful application of forking non-INVITEs (except, arguably, my proposal that a forked SUBSCRIBE can install several subscriptions, with the subsequent NOTIFY messages establishing the legs, routes, and contacts as necessary). Forking non-INVITEs adds complexity to the protocol, extra work to all extensions, and headaches all around. And as long as people insist that nothing useful can come from forking anything but an INVITE, there is no gain to be had by leaving this "feature" in the protocol. As long as it is understood at a general protocol level that forking of non-INVITEs is disallowed, I have no problem rejecting the additional NOTIFY legs we find out about. If we continue to pretend that forking of non-INVITEs is a useful concept, I can't see the logic behind refusing to allow successful forking of SUBSCRIBEs. Comments, etc, encouraged -- even if just to voice assent. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 13:15:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13947 for ; Mon, 2 Jul 2001 13:15:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 579BF4434D; Mon, 2 Jul 2001 13:16:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 29A7D44336 for ; Mon, 2 Jul 2001 13:15:53 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04544; Mon, 2 Jul 2001 13:19:40 -0400 (EDT) Message-ID: <3B40AC31.901404E0@dynamicsoft.com> From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul E. Jones" Cc: ravipati@avaya.com, sip@lists.bell-labs.com Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 13:15:29 -0400 Content-Transfer-Encoding: 7bit You said "TPKT (RFC 1006) would have been the logical thing to do". This implies SIP is doing something less logical wouldn't you say? SIP clearly puts cleanliness and simplicity above efficiency. I believe it's fair to say that this has proven to be a winning strategy for protocol design. Anders "Paul E. Jones" wrote: > > Anders, > > I didn't say it was illogical: it's just inefficient. > > Paul > > ----- Original Message ----- > From: "Anders Kristensen" > To: "Paul E. Jones" > Cc: ; > Sent: Monday, July 02, 2001 11:47 AM > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > Cheers, > > Anders > > > > > > "Paul E. Jones" wrote: > > > > > > Chandra, > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > SIP is > > > an ASCII-based protocol, which requires the parsers to look though long > > > strings like "Content-Length" for information (then perform expensive > > > arithmetic in order to actually calculate the length in this case), > using > > > TPKT would look like a "kludge" in the protocol. > > > > > > While the IETF has a history of engineering more efficient protocols, > SIP > > > was not engineered with processing efficiency in mind. > > > > > > Paul > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jul 2 14:00:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12939 for ; Mon, 2 Jul 2001 14:00:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0867344358; Mon, 2 Jul 2001 14:01:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id BD78B44336 for ; Mon, 2 Jul 2001 14:00:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22086 for ; Mon, 2 Jul 2001 14:00:00 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08226 for ; Mon, 2 Jul 2001 13:59:59 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Jul 2001 13:49:20 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044656A8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Unsubscribe from sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Jul 2001 13:49:12 -0400 I now request that you unsubscribe from sip@lists.bell-labs.com. To do so, send a message to sip-request@lists.bell-labs.com and specify "unsubscribe" as the BODY of the message, or vist http://lists.bell-labs.com/mailman/listinfo/sip Further discussion on sip should be held on the sip@ietf.org (for core SIP development) or sipping@ietf.org (for applications of sip). To subscribe, send a message to sip-request@ietf.org (or sipping-request@ietf.org) and specify "subscribe" as the body of the message. Responders, PLEASE double check the reply address and change the list entry to sip@ietf.org if the original message was to sip@lists.bell-labs.com Thanks Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 14:07:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17295 for ; Mon, 2 Jul 2001 14:07:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21309; Mon, 2 Jul 2001 13:40:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21278 for ; Mon, 2 Jul 2001 13:40:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29889 for ; Mon, 2 Jul 2001 13:39:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20379; Mon, 2 Jul 2001 13:40:03 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28507; Mon, 2 Jul 2001 13:40:02 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Jul 2001 13:40:03 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044656A7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Anders Kristensen'" , "Paul E. Jones" Cc: ravipati@avaya.com, "'sip@ietf.org'" Subject: RE: [SIP] SIP Message segmentation problem over TCP Date: Mon, 2 Jul 2001 13:39:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Okay, let's rein this one in folks. SIP is what it is, and we are not likely to change the way it works (and it DOES work). Unless there is anything much more substantive, let's leave this thread die. Brian > -----Original Message----- > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > Sent: Monday, July 02, 2001 1:15 PM > To: Paul E. Jones > Cc: ravipati@avaya.com; sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > You said "TPKT (RFC 1006) would have been the logical thing > to do". This > implies SIP is doing something less logical wouldn't you say? > > SIP clearly puts cleanliness and simplicity above efficiency. > I believe > it's fair to say that this has proven to be a winning strategy for > protocol design. > > Anders > > > "Paul E. Jones" wrote: > > > > Anders, > > > > I didn't say it was illogical: it's just inefficient. > > > > Paul > > > > ----- Original Message ----- > > From: "Anders Kristensen" > > To: "Paul E. Jones" > > Cc: ; > > Sent: Monday, July 02, 2001 11:47 AM > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > SIP is based on HTTP and you can blame HTTP for this > particular aspect > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > Cheers, > > > Anders > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > Chandra, > > > > > > > > TPKT (RFC 1006) would have been the logical thing to > do. However, as > > SIP is > > > > an ASCII-based protocol, which requires the parsers to > look though long > > > > strings like "Content-Length" for information (then > perform expensive > > > > arithmetic in order to actually calculate the length in > this case), > > using > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > While the IETF has a history of engineering more > efficient protocols, > > SIP > > > > was not engineered with processing efficiency in mind. > > > > > > > > Paul > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" > in the body. > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Mon Jul 2 14:08:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17862 for ; Mon, 2 Jul 2001 14:08:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B703044366; Mon, 2 Jul 2001 14:09:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by lists.bell-labs.com (Postfix) with ESMTP id 55D1B4435E for ; Mon, 2 Jul 2001 14:08:02 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16794 for ; Mon, 2 Jul 2001 14:07:12 -0400 (EDT) Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with SMTP id OAA16768; Mon, 2 Jul 2001 14:07:11 -0400 (EDT) Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2) id MAA07499; Mon, 2 Jul 2001 12:08:01 -0600 Message-ID: <3B40B886.BCC66ED6@avaya.com> From: Chandra Ravipati Reply-To: ravipati@avaya.com Organization: Avaya X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.bell-labs.com, sip@ietf.org Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> <3B40AC31.901404E0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 12:08:06 -0600 Content-Transfer-Encoding: 7bit Guys, I did not want to start a debate over whether SIP is good or bad. I wanted to understand why SIP can not use TPKT. TPKT is defined at(/immediately over) transport layer. IMHO, using TPKT is more efficient than SIP/HTTP solution. (Don't anybody get emotional(defensive). I am not criticizing any protocol) If there is any possibility of influencing the implementation standard to use TPKT, let's work on it. Let's talk about pros/cons without getting emotional. Thanks, Chandra. Anders Kristensen wrote: > > You said "TPKT (RFC 1006) would have been the logical thing to do". This > implies SIP is doing something less logical wouldn't you say? > > SIP clearly puts cleanliness and simplicity above efficiency. I believe > it's fair to say that this has proven to be a winning strategy for > protocol design. > > Anders > > "Paul E. Jones" wrote: > > > > Anders, > > > > I didn't say it was illogical: it's just inefficient. > > > > Paul > > > > ----- Original Message ----- > > From: "Anders Kristensen" > > To: "Paul E. Jones" > > Cc: ; > > Sent: Monday, July 02, 2001 11:47 AM > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > Cheers, > > > Anders > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > Chandra, > > > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > > SIP is > > > > an ASCII-based protocol, which requires the parsers to look though long > > > > strings like "Content-Length" for information (then perform expensive > > > > arithmetic in order to actually calculate the length in this case), > > using > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > While the IETF has a history of engineering more efficient protocols, > > SIP > > > > was not engineered with processing efficiency in mind. > > > > > > > > Paul > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jul 2 14:19:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25090 for ; Mon, 2 Jul 2001 14:19:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D09594436A; Mon, 2 Jul 2001 14:20:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 69B7444336 for ; Mon, 2 Jul 2001 14:19:43 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA05233; Mon, 2 Jul 2001 14:23:51 -0400 (EDT) Message-ID: <3B40BB3D.E2BF4F6E@dynamicsoft.com> From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ravipati@avaya.com Cc: sip@lists.bell-labs.com, sip@ietf.org Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> <3B40AC31.901404E0@dynamicsoft.com> <3B40B886.BCC66ED6@avaya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 02 Jul 2001 14:19:41 -0400 Content-Transfer-Encoding: 7bit I don't see how my response was emotional or defensive. I assure you it wasn't meant to be. The point is that SIP is not designed to squeeze every last bit of efficiency out of the network, and that this is a good thing. Noone is arguing that TPKT wouldn't save a bit of network traffic but it would be at the cost of making the protocol more ugly by special casing TCP from UDP and breaking with how HTTP and MIME generally works. For these reasons, and probably many more like it, what you're proposing is a non-starter. I'll shut up now. Anders Chandra Ravipati wrote: > > Guys, > > I did not want to start a debate over whether SIP is good or bad. > I wanted to understand why SIP can not use TPKT. TPKT is defined > at(/immediately over) transport layer. > > IMHO, using TPKT is more efficient than SIP/HTTP solution. > (Don't anybody get emotional(defensive). I am not criticizing any > protocol) > > If there is any possibility of influencing the implementation > standard to use TPKT, let's work on it. > > Let's talk about pros/cons without getting emotional. > > Thanks, > Chandra. > > Anders Kristensen wrote: > > > > You said "TPKT (RFC 1006) would have been the logical thing to do". This > > implies SIP is doing something less logical wouldn't you say? > > > > SIP clearly puts cleanliness and simplicity above efficiency. I believe > > it's fair to say that this has proven to be a winning strategy for > > protocol design. > > > > Anders > > > > "Paul E. Jones" wrote: > > > > > > Anders, > > > > > > I didn't say it was illogical: it's just inefficient. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Anders Kristensen" > > > To: "Paul E. Jones" > > > Cc: ; > > > Sent: Monday, July 02, 2001 11:47 AM > > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > > > Cheers, > > > > Anders > > > > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > > > Chandra, > > > > > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > > > SIP is > > > > > an ASCII-based protocol, which requires the parsers to look though long > > > > > strings like "Content-Length" for information (then perform expensive > > > > > arithmetic in order to actually calculate the length in this case), > > > using > > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > > > While the IETF has a history of engineering more efficient protocols, > > > SIP > > > > > was not engineered with processing efficiency in mind. > > > > > > > > > > Paul > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementor's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to > > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Mon Jul 2 14:27:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00236 for ; Mon, 2 Jul 2001 14:27:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22510; Mon, 2 Jul 2001 14:09:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22212 for ; Mon, 2 Jul 2001 14:04:22 -0400 (EDT) Received: from dns2.ulticomdal.com (IDENT:root@dns2.ulticomdal.com [204.130.158.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14869 for ; Mon, 2 Jul 2001 14:03:33 -0400 (EDT) Received: from pc015 (dhcp209.ulticomdal.com [204.130.158.209]) by dns2.ulticomdal.com (8.9.3/8.9.3) with SMTP id NAA19740 for ; Mon, 2 Jul 2001 13:04:07 -0500 From: "Hussam Jarada" To: Date: Mon, 2 Jul 2001 13:04:07 -0500 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] subscribe Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit subscribe _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 14:27:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00414 for ; Mon, 2 Jul 2001 14:27:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22427; Mon, 2 Jul 2001 14:08:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22398 for ; Mon, 2 Jul 2001 14:08:08 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17193 for ; Mon, 2 Jul 2001 14:07:22 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16781 for ; Mon, 2 Jul 2001 14:07:11 -0400 (EDT) Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with SMTP id OAA16768; Mon, 2 Jul 2001 14:07:11 -0400 (EDT) Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2) id MAA07499; Mon, 2 Jul 2001 12:08:01 -0600 Message-ID: <3B40B886.BCC66ED6@avaya.com> Date: Mon, 02 Jul 2001 12:08:06 -0600 From: Chandra Ravipati Reply-To: ravipati@avaya.com Organization: Avaya X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: sip@lists.bell-labs.com, sip@ietf.org Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> <3B40AC31.901404E0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Guys, I did not want to start a debate over whether SIP is good or bad. I wanted to understand why SIP can not use TPKT. TPKT is defined at(/immediately over) transport layer. IMHO, using TPKT is more efficient than SIP/HTTP solution. (Don't anybody get emotional(defensive). I am not criticizing any protocol) If there is any possibility of influencing the implementation standard to use TPKT, let's work on it. Let's talk about pros/cons without getting emotional. Thanks, Chandra. Anders Kristensen wrote: > > You said "TPKT (RFC 1006) would have been the logical thing to do". This > implies SIP is doing something less logical wouldn't you say? > > SIP clearly puts cleanliness and simplicity above efficiency. I believe > it's fair to say that this has proven to be a winning strategy for > protocol design. > > Anders > > "Paul E. Jones" wrote: > > > > Anders, > > > > I didn't say it was illogical: it's just inefficient. > > > > Paul > > > > ----- Original Message ----- > > From: "Anders Kristensen" > > To: "Paul E. Jones" > > Cc: ; > > Sent: Monday, July 02, 2001 11:47 AM > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > Cheers, > > > Anders > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > Chandra, > > > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > > SIP is > > > > an ASCII-based protocol, which requires the parsers to look though long > > > > strings like "Content-Length" for information (then perform expensive > > > > arithmetic in order to actually calculate the length in this case), > > using > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > While the IETF has a history of engineering more efficient protocols, > > SIP > > > > was not engineered with processing efficiency in mind. > > > > > > > > Paul > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 14:39:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08003 for ; Mon, 2 Jul 2001 14:39:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22979; Mon, 2 Jul 2001 14:19:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22952 for ; Mon, 2 Jul 2001 14:19:47 -0400 (EDT) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24869 for ; Mon, 2 Jul 2001 14:19:02 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA05233; Mon, 2 Jul 2001 14:23:51 -0400 (EDT) Message-ID: <3B40BB3D.E2BF4F6E@dynamicsoft.com> Date: Mon, 02 Jul 2001 14:19:41 -0400 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ravipati@avaya.com CC: sip@lists.bell-labs.com, sip@ietf.org Subject: Re: [SIP] SIP Message segmentation problem over TCP References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> <3B40AC31.901404E0@dynamicsoft.com> <3B40B886.BCC66ED6@avaya.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't see how my response was emotional or defensive. I assure you it wasn't meant to be. The point is that SIP is not designed to squeeze every last bit of efficiency out of the network, and that this is a good thing. Noone is arguing that TPKT wouldn't save a bit of network traffic but it would be at the cost of making the protocol more ugly by special casing TCP from UDP and breaking with how HTTP and MIME generally works. For these reasons, and probably many more like it, what you're proposing is a non-starter. I'll shut up now. Anders Chandra Ravipati wrote: > > Guys, > > I did not want to start a debate over whether SIP is good or bad. > I wanted to understand why SIP can not use TPKT. TPKT is defined > at(/immediately over) transport layer. > > IMHO, using TPKT is more efficient than SIP/HTTP solution. > (Don't anybody get emotional(defensive). I am not criticizing any > protocol) > > If there is any possibility of influencing the implementation > standard to use TPKT, let's work on it. > > Let's talk about pros/cons without getting emotional. > > Thanks, > Chandra. > > Anders Kristensen wrote: > > > > You said "TPKT (RFC 1006) would have been the logical thing to do". This > > implies SIP is doing something less logical wouldn't you say? > > > > SIP clearly puts cleanliness and simplicity above efficiency. I believe > > it's fair to say that this has proven to be a winning strategy for > > protocol design. > > > > Anders > > > > "Paul E. Jones" wrote: > > > > > > Anders, > > > > > > I didn't say it was illogical: it's just inefficient. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Anders Kristensen" > > > To: "Paul E. Jones" > > > Cc: ; > > > Sent: Monday, July 02, 2001 11:47 AM > > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > > > Cheers, > > > > Anders > > > > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > > > Chandra, > > > > > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > > > SIP is > > > > > an ASCII-based protocol, which requires the parsers to look though long > > > > > strings like "Content-Length" for information (then perform expensive > > > > > arithmetic in order to actually calculate the length in this case), > > > using > > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > > > While the IETF has a history of engineering more efficient protocols, > > > SIP > > > > > was not engineered with processing efficiency in mind. > > > > > > > > > > Paul > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementor's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to > > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 14:45:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12643 for ; Mon, 2 Jul 2001 14:45:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23192; Mon, 2 Jul 2001 14:26:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23165 for ; Mon, 2 Jul 2001 14:26:03 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28944 for ; Mon, 2 Jul 2001 14:25:19 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f62IPxp22055; Mon, 2 Jul 2001 13:25:59 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f62IPxu05515; Mon, 2 Jul 2001 13:25:59 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA19290; Mon, 2 Jul 2001 13:25:59 -0500 (CDT) Reply-To: To: "'Henning G. Schulzrinne'" , Subject: RE: [Sip] REFER failures Date: Mon, 2 Jul 2001 13:25:58 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985022518EB@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <3B3C915A.CD367B8C@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] [Problem to be solved: how to distinguish if the referred party or the referred-to party rejected a REFER.] > One solution is that the NOTIFY always includes the full SIP response, > so that it's clear what this refers to. For late failures of the REFER > (rather than the request triggered by it), it would be the final > response that would have been sent, e.g., > > SIP/2.0 603 Refused > From: sender of REFER > To: recipient of REFER > Call-ID: of original REFER > CSeq: something REFER I see a couple of problems with this proposal. The first is that the URI to which the remote party has been referred may be something other than a SIP URL. So, while synthesizing a response like you describe above may make some sense, creating a whole new message for the remote service may be bizarre. For example, I believe it reasonable for a implementation which can accept REFERs to "ftp:" URLs to map "550 Requested action not taken" to "404 Not Found," I think it's a bit ludicrous to expect this implementation to then go and invent a variety of headers to tack onto this 404 for the purposes of determining where the error occurred. The second problem, I believe, stems from the fact that several parties at the interim meeting expressed some strong privacy concerns about being "required" to include response header information in NOTIFY requests related to REFER. I admire the problem, but think the proposed solution is a hack based on a hack. I suspect we can do better. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 15:03:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25625 for ; Mon, 2 Jul 2001 15:03:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24250; Mon, 2 Jul 2001 14:48:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24225 for ; Mon, 2 Jul 2001 14:48:03 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13812 for ; Mon, 2 Jul 2001 14:47:18 -0400 (EDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 11:22:29 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 11:21:45 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 11:21:43 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 11:20:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Forking: a modest proposal. Date: Mon, 2 Jul 2001 11:20:57 -0700 Message-ID: Thread-Topic: [Sip] Forking: a modest proposal. thread-index: AcEDFmmEKESPnJRoR4asIicOWrRTcgADGBrA From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 02 Jul 2001 18:20:57.0573 (UTC) FILETIME=[BD2DF950:01C10323] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA24226 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The problem is not so much INVITE vs. SUBSCRIBE than a classic case of state management. The reason INVITE supports forking is the three ways handshake in the INVITE/200/ACK sequence, which allows for cancellation of branches that are not selected. We can only subscribe forking in methods that either have no side effect (e.g. Notify) or that include a three ways handshake. There are quite a few reasons to support forking -- think for example of doing discovery through a multicast channel. But we must make sure that if a SUBSCRIBE request is multicast or forked, a three ways handshake is requested before any notification is sent. We could possibly achieve that by having a specific acceptation code, e.g. "I received a forked subscribe, I am ready to serve you, but please confirm first." -- Christian Huitema > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, July 02, 2001 9:45 AM > To: sip@ietf.org > Subject: [Sip] Forking: a modest proposal. > > I'm putting together the SUB/NOT draft (we should go into nits > on Monday), and am currently wrestling with the issue of forking. > > I have what I think is an elegant solution, given the immediate > NOTIFY mechanism that we have agreed on. Certain camps have objections > to this mechanism, and thinks that all but the first SUBSCRIBE should > be made to fail (by sending a 400 class response). I don't see this > difference of opinion as intractable, but it is something that will > take a considerable amount of time (discussion, work, etc) to reach > consensus. > > On reflection, I realize that this entire situation just highlights > a thorn we've had in our paw the entire time. > > Given that all transactions complete (basically) immediately (with > the exception of INVITEs), forking *any* non-INVITE request is just > a race waiting to happen. It usually just leads to heartburn when > you attempt to analyze how it's going to work with non-INVITE methods > (as in the SUBSCRIBE example). > > Since there seems to be a general feeling that all but the first > received request should "fail" in some general sense (usually by > the request initiator not finding out about the response), I'd > like to float a proposal: > > Deprecate forking of non-INVITEs. > > Despite my tongue-in-cheek subject line, I'm serious. > > SIP is not going to Draft Standard this time around, so maintaining > absolute compatibility with RFC 2543 isn't strictly required. No one > has come up with a useful application of forking non-INVITEs (except, > arguably, my proposal that a forked SUBSCRIBE can install several > subscriptions, with the subsequent NOTIFY messages establishing the > legs, routes, and contacts as necessary). Forking non-INVITEs adds > complexity to the protocol, extra work to all extensions, and > headaches all around. And as long as people insist that nothing useful > can come from forking anything but an INVITE, there is no gain to be > had by leaving this "feature" in the protocol. > > As long as it is understood at a general protocol level that forking > of non-INVITEs is disallowed, I have no problem rejecting the additional > NOTIFY legs we find out about. If we continue to pretend that forking > of non-INVITEs is a useful concept, I can't see the logic behind refusing > to allow successful forking of SUBSCRIBEs. > > Comments, etc, encouraged -- even if just to voice assent. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 15:19:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05206 for ; Mon, 2 Jul 2001 15:19:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24573; Mon, 2 Jul 2001 14:58:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24545 for ; Mon, 2 Jul 2001 14:58:41 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21694 for ; Mon, 2 Jul 2001 14:57:55 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f62Iw6506921; Mon, 2 Jul 2001 13:58:06 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f62Iw5b16702; Mon, 2 Jul 2001 13:58:05 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA20636; Mon, 2 Jul 2001 13:58:04 -0500 (CDT) Reply-To: To: "'Christian Huitema'" , Cc: Subject: RE: [Sip] Forking: a modest proposal. Date: Mon, 2 Jul 2001 13:58:02 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985022518EC@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > The problem is not so much INVITE vs. SUBSCRIBE than a classic case of > state management. The reason INVITE supports forking is the three ways > handshake in the INVITE/200/ACK sequence, which allows for > cancellation > of branches that are not selected. We can only subscribe forking in > methods that either have no side effect (e.g. Notify) or that > include a > three ways handshake. The problem, of course, with requiring a three-way handshake involving the response to the method is that forking proxies drop all but the first response (except for INVITEs), so sending a forward indication to complete the handshake is impossible. Any non-INVITE three-way handshake which will survive forking must be something like a request in the forward direction, a request in the backwards direction, and a response to the second request. > There are quite a few reasons to support forking -- think for > example of > doing discovery through a multicast channel. But we must make > sure that > if a SUBSCRIBE request is multicast or forked, a three ways > handshake is > requested before any notification is sent. I don't think it's the notification you're worried about; as you just stated, NOTIFY is one of a class of "methods that... have no side effect." Your concern is installation of long running state at the notifier node; my proposal to the forked SUBSCRIBE issue can be implemented in such a way that such state is not created. > We could possibly achieve > that by having a specific acceptation code, e.g. "I received a forked > subscribe, I am ready to serve you, but please confirm first." As I pointed out above, using a response code for this isn't possible, since only the first response survives the forking proxy. However, if I take the intention of your statement instead of the implied implementation, this is fundamentally what I have been proposing all along: I send a SUBSCRIBE; the response is merely for reliability. I then receive multiple NOTIFYs. If I am willing to have these subscriptions outstanding, I send a 200 class response; it's then my responsibility to make sure they each get updated as appropriate. If I want them not to exist, I send a 400 class response (nominally a 481). There's your three way handshake: SUBSCRIBE/NOTIFY/200. It works very elegantly. But there are people who counterargue that, even though this is a technically feasible solution (and, in fact, one we will have to outlaw by fiat if we don't want it to happen, since we basically get it for free), there are some philosophical problems yet to be solved about having multiple subscriptions outstanding. I'll admit that, in certain circumstances, this might not make sense; those packages can dictate that all but one NOTIFY be answered with a 481. I argue that this mechanism can be useful in other circumstances, and disallowing it merely makes the protocol less flexible. My intention in this thread wasn't to fight this battle; in fact, my intention was explicitly to avoid it. I believed that all parties involved had an understanding of the current situation and viewpoints, and that we could remove the problem instead of solving it. If that isn't the case, we can take the philosophical discussion of whether forked subscriptions are legal on the SIP events list. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 16:10:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06586 for ; Mon, 2 Jul 2001 16:10:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26111; Mon, 2 Jul 2001 15:33:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26080 for ; Mon, 2 Jul 2001 15:33:53 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13395 for ; Mon, 2 Jul 2001 15:33:07 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f62JXgO01806; Mon, 2 Jul 2001 21:33:42 +0200 (MEST) Received: from lmf.ericsson.se (racom-sd-9.sd.us.am.ericsson.se [142.133.141.10]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA06073; Mon, 2 Jul 2001 21:33:38 +0200 (MET DST) Message-ID: <3B40CEAA.4A2228F6@lmf.ericsson.se> Date: Mon, 02 Jul 2001 22:42:34 +0300 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Paul Kyzivat'" , Christer Holmberg , sip@ietf.org, mmusic Subject: Re: [Sip] Two SDP issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Jonathan, > Ugly, and not my preference, but I see no other viable > alternative without sacrificing backwards compatibility. In this situation, I believe we should have a clear idea of what we understand by backwards compatibility. When a new feature is added, it usually means that the addition of the new feature does not break all the implementations that already work properly (but do not provide the new feature). However, in this scenario, there cannot be any implementation that works properly right now. They just cannot send RTCP properly. Therefore, in this situation, an elegant brand new mechanism might be acceptable. I do not think that it would be a big deal to "break" current implementations that do not work properly anyway. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 16:10:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06628 for ; Mon, 2 Jul 2001 16:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26448; Mon, 2 Jul 2001 15:44:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26366 for ; Mon, 2 Jul 2001 15:44:37 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20119 for ; Mon, 2 Jul 2001 15:43:51 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f62J1m508501 for ; Mon, 2 Jul 2001 14:01:48 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f62J1mu24292 for ; Mon, 2 Jul 2001 14:01:48 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jul 02 14:01:47 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2HG63>; Mon, 2 Jul 2001 14:01:47 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Christian Huitema'" , adam.roach@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Forking: a modest proposal. Date: Mon, 2 Jul 2001 14:01:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10329.70D62770" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10329.70D62770 Content-Type: text/plain; charset="iso-8859-1" Hmmm. It would sound like we have a few options for forking of a non-INVITE: 1) Disallow it This seems to be easiest, even if there are potential benefits to forking non-INVITEs. It certainly makes things easier for forking proxies. 2) Wrap it in a INVITE "signalling session" ala MESSAGE. This allows us to find a path to a "single best" destination (first come, first serve) By wrapping it in INVITE, we allow multiple destinations to actually answer. There is a small issue here with overhead in signalling. 3) Describe the semantics of forking of a non-INVITE for each possible extension We hack a solution together specific to each extension. Highly undesireable. 4) Create a PROBE method that allows us to find a single threaded path through. Similar to (2) above, but only one party could answer. PROBE == OPTIONS provided we allow forking of OPTIONS. This is ugly. Just listed for completeness. I prefer (1) or (2), leaning towards (1). I don't think adding three-way handshakes to other extensions is the way to go. Unless people want to allow ACK for non-INVITEs (no flames please, just a bit of humor) /sean >-----Original Message----- >From: Christian Huitema [mailto:huitema@windows.microsoft.com] >Sent: Monday, July 02, 2001 1:21 PM >To: adam.roach@ericsson.com >Cc: sip@ietf.org >Subject: RE: [Sip] Forking: a modest proposal. > > >The problem is not so much INVITE vs. SUBSCRIBE than a classic case of >state management. The reason INVITE supports forking is the three ways >handshake in the INVITE/200/ACK sequence, which allows for cancellation >of branches that are not selected. We can only subscribe forking in >methods that either have no side effect (e.g. Notify) or that include a >three ways handshake. > >There are quite a few reasons to support forking -- think for >example of >doing discovery through a multicast channel. But we must make sure that >if a SUBSCRIBE request is multicast or forked, a three ways >handshake is >requested before any notification is sent. We could possibly achieve >that by having a specific acceptation code, e.g. "I received a forked >subscribe, I am ready to serve you, but please confirm first." > >-- Christian Huitema > >> -----Original Message----- >> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] >> Sent: Monday, July 02, 2001 9:45 AM >> To: sip@ietf.org >> Subject: [Sip] Forking: a modest proposal. >> >> I'm putting together the SUB/NOT draft (we should go into nits >> on Monday), and am currently wrestling with the issue of forking. >> >> I have what I think is an elegant solution, given the immediate >> NOTIFY mechanism that we have agreed on. Certain camps have >objections >> to this mechanism, and thinks that all but the first SUBSCRIBE should >> be made to fail (by sending a 400 class response). I don't see this >> difference of opinion as intractable, but it is something that will >> take a considerable amount of time (discussion, work, etc) to reach >> consensus. >> >> On reflection, I realize that this entire situation just highlights >> a thorn we've had in our paw the entire time. >> >> Given that all transactions complete (basically) immediately (with >> the exception of INVITEs), forking *any* non-INVITE request is just >> a race waiting to happen. It usually just leads to heartburn when >> you attempt to analyze how it's going to work with non-INVITE methods >> (as in the SUBSCRIBE example). >> >> Since there seems to be a general feeling that all but the first >> received request should "fail" in some general sense (usually by >> the request initiator not finding out about the response), I'd >> like to float a proposal: >> >> Deprecate forking of non-INVITEs. >> >> Despite my tongue-in-cheek subject line, I'm serious. >> >> SIP is not going to Draft Standard this time around, so maintaining >> absolute compatibility with RFC 2543 isn't strictly required. No one >> has come up with a useful application of forking non-INVITEs (except, >> arguably, my proposal that a forked SUBSCRIBE can install several >> subscriptions, with the subsequent NOTIFY messages establishing the >> legs, routes, and contacts as necessary). Forking non-INVITEs adds >> complexity to the protocol, extra work to all extensions, and >> headaches all around. And as long as people insist that >nothing useful >> can come from forking anything but an INVITE, there is no gain to be >> had by leaving this "feature" in the protocol. >> >> As long as it is understood at a general protocol level that forking >> of non-INVITEs is disallowed, I have no problem rejecting the >additional >> NOTIFY legs we find out about. If we continue to pretend that forking >> of non-INVITEs is a useful concept, I can't see the logic behind >refusing >> to allow successful forking of SUBSCRIBEs. >> >> Comments, etc, encouraged -- even if just to voice assent. >> >> /a >> >> >> _______________________________________________ >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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_01C10329.70D62770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Forking: a modest proposal.

Hmmm. It would sound like we have a few = options
for forking of a non-INVITE:

1) Disallow it

This seems to be easiest, even if there are = potential
benefits to forking non-INVITEs. It certainly = makes
things easier for forking proxies.

2) Wrap it in a INVITE "signalling = session"

ala MESSAGE. This allows us to find a path to = a
"single best" destination (first come, = first serve)
By wrapping it in INVITE, we allow multiple = destinations
to actually answer. There is a small issue here = with
overhead in signalling.

3) Describe the semantics of forking of a = non-INVITE
   for each possible extension

We hack a solution together specific to each = extension.
Highly undesireable.

4) Create a PROBE method that allows us to = find
   a single threaded path through. Similar = to (2) above,
   but only one party could answer. PROBE = =3D=3D OPTIONS provided
   we allow forking of OPTIONS.

This is ugly. Just listed for completeness.

I prefer (1) or (2), leaning towards (1). I don't = think
adding three-way handshakes to other extensions is = the
way to go. Unless people want to allow ACK for = non-INVITEs
(no flames please, just a bit of humor)

/sean

>-----Original Message-----
>From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
>Sent: Monday, July 02, 2001 1:21 PM
>To: adam.roach@ericsson.com
>Cc: sip@ietf.org
>Subject: RE: [Sip] Forking: a modest = proposal.
>
>
>The problem is not so much INVITE vs. SUBSCRIBE = than a classic case of
>state management. The reason INVITE supports = forking is the three ways
>handshake in the INVITE/200/ACK sequence, which = allows for cancellation
>of branches that are not selected. We can only = subscribe forking in
>methods that either have no side effect (e.g. = Notify) or that include a
>three ways handshake.
>
>There are quite a few reasons to support forking = -- think for
>example of
>doing discovery through a multicast channel. But = we must make sure that
>if a SUBSCRIBE request is multicast or forked, a = three ways
>handshake is
>requested before any notification is sent. We = could possibly achieve
>that by having a specific acceptation code, e.g. = "I received a forked
>subscribe, I am ready to serve you, but please = confirm first."
>
>-- Christian Huitema
>
>> -----Original Message-----
>> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
>> Sent: Monday, July 02, 2001 9:45 AM
>> To: sip@ietf.org
>> Subject: [Sip] Forking: a modest = proposal.
>>
>> I'm putting together the SUB/NOT draft (we = should go into nits
>> on Monday), and am currently wrestling with = the issue of forking.
>>
>> I have what I think is an elegant solution, = given the immediate
>> NOTIFY mechanism that we have agreed on. = Certain camps have
>objections
>> to this mechanism, and thinks that all but = the first SUBSCRIBE should
>> be made to fail (by sending a 400 class = response). I don't see this
>> difference of opinion as intractable, but = it is something that will
>> take a considerable amount of time = (discussion, work, etc) to reach
>> consensus.
>>
>> On reflection, I realize that this entire = situation just highlights
>> a thorn we've had in our paw the entire = time.
>>
>> Given that all transactions complete = (basically) immediately (with
>> the exception of INVITEs), forking *any* = non-INVITE request is just
>> a race waiting to happen. It usually just = leads to heartburn when
>> you attempt to analyze how it's going to = work with non-INVITE methods
>> (as in the SUBSCRIBE example).
>>
>> Since there seems to be a general feeling = that all but the first
>> received request should "fail" in = some general sense (usually by
>> the request initiator not finding out about = the response), I'd
>> like to float a proposal:
>>
>> Deprecate forking of non-INVITEs.
>>
>> Despite my tongue-in-cheek subject line, = I'm serious.
>>
>> SIP is not going to Draft Standard this = time around, so maintaining
>> absolute compatibility with RFC 2543 isn't = strictly required. No one
>> has come up with a useful application of = forking non-INVITEs (except,
>> arguably, my proposal that a forked = SUBSCRIBE can install several
>> subscriptions, with the subsequent NOTIFY = messages establishing the
>> legs, routes, and contacts as necessary). = Forking non-INVITEs adds
>> complexity to the protocol, extra work to = all extensions, and
>> headaches all around. And as long as people = insist that
>nothing useful
>> can come from forking anything but an = INVITE, there is no gain to be
>> had by leaving this "feature" in = the protocol.
>>
>> As long as it is understood at a general = protocol level that forking
>> of non-INVITEs is disallowed, I have no = problem rejecting the
>additional
>> NOTIFY legs we find out about. If we = continue to pretend that forking
>> of non-INVITEs is a useful concept, I can't = see the logic behind
>refusing
>> to allow successful forking of = SUBSCRIBEs.
>>
>> Comments, etc, encouraged -- even if just = to voice assent.
>>
>> /a
>>
>>
>> = _______________________________________________
>> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the = core SIP 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  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP = 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_01C10329.70D62770-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 16:39:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25541 for ; Mon, 2 Jul 2001 16:39:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25344; Mon, 2 Jul 2001 15:13:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25305 for ; Mon, 2 Jul 2001 15:13:53 -0400 (EDT) Received: from mr1.ash.ops.us.uu.net (mr1.ash.ops.us.uu.net [198.5.241.86]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01447 for ; Mon, 2 Jul 2001 15:13:07 -0400 (EDT) Received: from overhill by mr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: user2.sentito.com [65.202.222.2] (may be forged)) id QQkvyy25156 for ; Mon, 2 Jul 2001 19:13:49 GMT From: "Frank W. Miller" To: Date: Mon, 2 Jul 2001 15:13:14 -0400 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Call forwarding feature support Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I posted this on the bell-labs list this morning but have been advised to move to the ietf list instead. I have a question having to do with call forwarding. Lets say we have a call that arrives at a SIP user agent and call forwarding is active at that user agent. Further, lets assume that part of the call is carried over the PSTN. There are two possibilities, 1) the call is forwarded to another SIP location, and 2) the call is forwarded to another phone that is on the PSTN. It seems to me that in the first case, only SIP redirection is necessary and that this may be transparent to the PSTN leg of the call? In the second case, there may be some SS7 interaction required. Has anyone looked at this and if so is there any documentation on preferred approaches? If not, does anyone have any thoughts on how it should be done? Thanks, FM -- Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. www.sentito.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 2 22:29:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03723 for ; Mon, 2 Jul 2001 22:29:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08337; Mon, 2 Jul 2001 22:17:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08309 for ; Mon, 2 Jul 2001 22:17:02 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25347 for ; Mon, 2 Jul 2001 22:16:16 -0400 (EDT) Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 19:13:10 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 19:13:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 2 Jul 2001 19:12:56 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 19:12:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Forking: a modest proposal. Date: Mon, 2 Jul 2001 19:12:22 -0700 Message-ID: Thread-Topic: [Sip] Forking: a modest proposal. thread-index: AcEDKNbAa0fpuwU1SqqOJKMAeWSKkgAPEA0Q From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 03 Jul 2001 02:12:24.0460 (UTC) FILETIME=[997A64C0:01C10365] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA08310 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > The problem, of course, with requiring a three-way handshake involving > the response to the method is that forking proxies drop all but the first > response (except for INVITEs), so sending a forward indication to > complete the handshake is impossible. This is not quite true. If you require a 3 ways handshake, then the forking proxy will only carry the first positive response, and will reject the other ones; but in a 3-ways handshake mode, it should reply with a "cancel" if it drops a positive response. The positive response will have to be an ACCK, or very similar. Obviously, if proxies drop all responses but one, only one responder will receive the ACK; the other ones would have sent negative responses, or would have receive a cancel, or would have time out before receiving the ack if the proxy failed to cancel. The mechanism can be extended to multicast operation. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 3 00:58:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05809 for ; Tue, 3 Jul 2001 00:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12777; Tue, 3 Jul 2001 00:37:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12747 for ; Tue, 3 Jul 2001 00:37:41 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22523 for ; Tue, 3 Jul 2001 00:36:58 -0400 (EDT) From: Jon.Peterson@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id EAA16987; Tue, 3 Jul 2001 04:37:39 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id EAA11025; Tue, 3 Jul 2001 04:37:38 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3BXW5ZYA>; Mon, 2 Jul 2001 22:37:39 -0600 Message-ID: <6384220893BCD411BDFE0008C791B79CA3E680@N0228IDC1.oss.level3.com> To: afarhan@rediffmail.com, sip@ietf.org Subject: RE: [Sip] Adhoc group messaging Date: Mon, 2 Jul 2001 22:37:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The SIP extensions for Instant Messaging and Presence are currently discussed in the SIMPLE working group rather than the SIP WG. You can subscribe to the SIMPLE WG mailing list (or access the archives) by going to: http://mailman.dynamicsoft.com/mailman/listinfo/simple FYI in light of your proposal below, a forthcoming issue of the document set on the MESSAGE method defines a new way of setting up an IM session between two parties that uses the INVITE method with a special SDP indicating that MESSAGEs are to be exchanged directly between the parties. As it turns out, this allow the IM extension to take advantage of the conferencing methods used for VoIP, including building an IM 'conference server' or even probably using some fully-meshed models if you were so inclined. If you glance through the archives of the SIMPLE mailing list, you'll find some further information on this, or you can wait for the new drafts (which should appear in the relatively short term). Jon Peterson Level(3) Communications -----Original Message----- From: Ashhar Farhan [mailto:afarhan@rediffmail.com] Sent: Monday, July 02, 2001 1:22 AM To: sip@ietf.org Subject: [Sip] Adhoc group messaging While chatting with a peer, an IM user would typically like to add a third participant to the chat. This is currently not possible in SIP MESSAGE. MESSAGE rfc recommends that a group@host url should be used for multi-participant chatting. a group id is not available in peer chats that are one to one and have to include a third recepient (sort of CC of email UAs). although group@host is definitely the best thing for large chat groups, most of chat interactivity takes place within smaller groups of people who interact with each other and do often need to chat with about 3-4 participants at a time. this kind of chatting can be accomplished in principle by making each of the participants send a copy of MESSAGE to all the other participants. If the group grows too big, and the bandwidth gets constrained, then they ought to move to a scheduled group chat server. However, for most of the times it is enough to be able to chat with 3-4 pariticipants at a time. Do note that these groups are created without any schedule and grow out of a 1-1 chat. My recommendation would be that: 1. A sends B a MESSAGE, B sends a reply back with the same Call-ID. so that we have identified a sequence of MESSAGEs that can be displayed within a particular instance of User interface (like a window). 2. A wants C to join in the chat. A sends some reques(s) to C. At this point, what needs to be done is that: 2.1 C should get a list of all the participants from A. 2.2 C should get the group messaging ID (probably the shared Calli-ID) for all these messages so that this thread of messages to the other participants can be distinguished from any other threads that maybe concurrently engaged in by C. Alternatively, instead of the Call-ID, even Subject can be used (probably a combination of the two is going to be the only unique thing). 2.3 Others have to be informed of additon of C to the chat group. 2.4 All the future MESSAGEs and NOTIFYcations are send to the updated list of participants by all. one possible implementation for this is that we base this on SUBSCRIBE/NOTIFY. Step 1:A participant is added by sending a SUBSCRIBE to the new particpant. Step 2:The new pariticipant responds back by accepting the SUBSCRIPTION. The participant who has added the new participant also sends a NOTIFY to other participants who can update their chat lists with the userid of the new participant. - farhan@hotfoon.com ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Tue Jul 3 09:52:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12785 for ; Tue, 3 Jul 2001 09:52:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C90744348; Tue, 3 Jul 2001 09:53:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lists.bell-labs.com (Postfix) with ESMTP id D83AA44336 for ; Tue, 3 Jul 2001 09:52:37 -0400 (EDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 5CBE8140; Tue, 3 Jul 2001 08:52:38 -0500 (CDT) Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 928A0256 for ; Tue, 3 Jul 2001 08:52:37 -0500 (CDT) Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 15:52:36 +0200 Message-ID: From: "Mathieu, Marie-Noelle" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C103C7.B697A010" Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Jul 2001 15:54:43 +0200 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C103C7.B697A010 Content-Type: text/plain; charset="iso-8859-1" unsubscribe Marie-Noelle Mathieu Compaq TPU Engineering development Tel: +33 (0) 4.92.95.61.37 Fax: +33 (0) 4.92.95.63.63 Email: Marie-noelle.mathieu@compaq.com ------_=_NextPart_001_01C103C7.B697A010 Content-Type: text/html; charset="iso-8859-1"
unsubscribe

Marie-Noelle Mathieu
Compaq TPU Engineering development

Tel:     +33 (0) 4.92.95.61.37  
Fax:    +33 (0) 4.92.95.63.63 
Email:  Marie-noelle.mathieu@compaq.com


 
------_=_NextPart_001_01C103C7.B697A010-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Tue Jul 3 09:57:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15988 for ; Tue, 3 Jul 2001 09:57:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08341; Tue, 3 Jul 2001 09:45:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08311 for ; Tue, 3 Jul 2001 09:45:37 -0400 (EDT) Received: from ridgeway.ridgeway-sys.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07559 for ; Tue, 3 Jul 2001 09:43:52 -0400 (EDT) Received: by RIDGEWAY with Internet Mail Service (5.5.2653.19) id <3BNYV2QW>; Tue, 3 Jul 2001 14:44:00 +0100 Message-ID: <00533D13955AD411AF3800A0C9B42639C2A4B9@RIDGEWAY> From: Steve Davies To: "'sip@ietf.org'" Date: Tue, 3 Jul 2001 14:43:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C103C6.314F19C0" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C103C6.314F19C0 Content-Type: text/plain; charset="iso-8859-1" subscribe ------_=_NextPart_001_01C103C6.314F19C0 Content-Type: text/html; charset="iso-8859-1"

subscribe

------_=_NextPart_001_01C103C6.314F19C0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Tue Jul 3 10:59:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25216 for ; Tue, 3 Jul 2001 10:59:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB61B44361; Tue, 3 Jul 2001 11:00:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from paris.packetizer.org (rdu26-248-199.nc.rr.com [66.26.248.199]) by lists.bell-labs.com (Postfix) with ESMTP id 6DA9E4435F for ; Mon, 2 Jul 2001 14:41:07 -0400 (EDT) Received: from paulejw2k (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id f62Ih2H20621; Mon, 2 Jul 2001 14:43:02 -0400 Message-ID: <020201c10326$72f42cd0$815d6640@cisco.com> From: "Paul E. Jones" To: "Anders Kristensen" Cc: , References: <3B33455C.A01A4E4E@lab.ntt.co.jp> <3B3CD087.7673029D@avaya.com> <00fa01c10296$5e0e25e0$0401a8c0@berlin> <3B409793.175A635C@dynamicsoft.com> <00b701c10319$695c7fe0$815d6640@cisco.com> <3B40AC31.901404E0@dynamicsoft.com> Subject: Re: [SIP] SIP Message segmentation problem over TCP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 2 Jul 2001 14:40:20 -0400 Content-Transfer-Encoding: 7bit Anders, Ah, you're right: my words did imply that SIP's method was illogical, didn't it? Sorry. Indeed, SIP's method is logical, just less efficient in terms of detecting message boundaries. Paul ----- Original Message ----- From: "Anders Kristensen" To: "Paul E. Jones" Cc: ; Sent: Monday, July 02, 2001 1:15 PM Subject: Re: [SIP] SIP Message segmentation problem over TCP > You said "TPKT (RFC 1006) would have been the logical thing to do". This > implies SIP is doing something less logical wouldn't you say? > > SIP clearly puts cleanliness and simplicity above efficiency. I believe > it's fair to say that this has proven to be a winning strategy for > protocol design. > > Anders > > > "Paul E. Jones" wrote: > > > > Anders, > > > > I didn't say it was illogical: it's just inefficient. > > > > Paul > > > > ----- Original Message ----- > > From: "Anders Kristensen" > > To: "Paul E. Jones" > > Cc: ; > > Sent: Monday, July 02, 2001 11:47 AM > > Subject: Re: [SIP] SIP Message segmentation problem over TCP > > > > > SIP is based on HTTP and you can blame HTTP for this particular aspect > > > of SIP. Using a Content-Length header is perfectly logical, BTW. > > > > > > Cheers, > > > Anders > > > > > > > > > "Paul E. Jones" wrote: > > > > > > > > Chandra, > > > > > > > > TPKT (RFC 1006) would have been the logical thing to do. However, as > > SIP is > > > > an ASCII-based protocol, which requires the parsers to look though long > > > > strings like "Content-Length" for information (then perform expensive > > > > arithmetic in order to actually calculate the length in this case), > > using > > > > TPKT would look like a "kludge" in the protocol. > > > > > > > > While the IETF has a history of engineering more efficient protocols, > > SIP > > > > was not engineered with processing efficiency in mind. > > > > > > > > Paul > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Tue Jul 3 12:13:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10963 for ; Tue, 3 Jul 2001 12:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12719; Tue, 3 Jul 2001 11:41:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12687 for ; Tue, 3 Jul 2001 11:41:48 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09468 for ; Tue, 3 Jul 2001 11:41:04 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f63EsEp05535; Tue, 3 Jul 2001 09:54:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f63EsD601490; Tue, 3 Jul 2001 09:54:13 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id JAA03661; Tue, 3 Jul 2001 09:54:13 -0500 (CDT) Reply-To: To: "'Christian Huitema'" , Cc: Subject: RE: [Sip] Forking: a modest proposal. Date: Tue, 3 Jul 2001 09:54:09 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985022518F7@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > The problem, of course, with requiring a three-way > handshake involving > > the response to the method is that forking proxies drop all but the > first > > response (except for INVITEs), so sending a forward indication to > > complete the handshake is impossible. > > This is not quite true. If you require a 3 ways handshake, then the > forking proxy will only carry the first positive response, and will > reject the other ones; but in a 3-ways handshake mode, it should reply > with a "cancel" if it drops a positive response. What? You lost me there. Who is sending the cancel, and to whom? The proxy to the subscriber? The proxy to the node receiving the SUBSCRIBE request? The node receiving the SUBSCRIBE request to the proxy? The subscriber to the proxy? I can't envision any scenario in which this makes sense without some radical changes to the way that SIP works. > The positive response > will have to be an ACCK, or very similar. Obviously, if > proxies drop all > responses but one, only one responder will receive the ACK; the other > ones would have sent negative responses, or would have > receive a cancel, > or would have time out before receiving the ack if the proxy failed to > cancel. The mechanism can be extended to multicast operation. I fear you may be speaking from a theoretical standpoint. The prospect that I would be able to convince anyone to completely rework the way that SIP proxies operate (and on a method-by-method basis, even) is a bit overoptimistic. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 3 12:37:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11800 for ; Tue, 3 Jul 2001 12:37:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14490; Tue, 3 Jul 2001 12:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14460 for ; Tue, 3 Jul 2001 12:15:07 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11009 for ; Tue, 3 Jul 2001 12:14:21 -0400 (EDT) Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Jul 2001 08:54:33 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 3 Jul 2001 08:54:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 3 Jul 2001 08:54:24 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 3 Jul 2001 08:53:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Forking: a modest proposal. Date: Tue, 3 Jul 2001 08:53:37 -0700 Message-ID: Thread-Topic: [Sip] Forking: a modest proposal. thread-index: AcEDz/cw+MOz6MXhTNyJk+sZqXObJwABcTCA From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 03 Jul 2001 15:53:39.0109 (UTC) FILETIME=[53752550:01C103D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA14461 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > > The problem, of course, with requiring a three-way > > handshake involving > > > the response to the method is that forking proxies drop all but the > > first > > > response (except for INVITEs), so sending a forward indication to > > > complete the handshake is impossible. > > > > This is not quite true. If you require a 3 ways handshake, then the > > forking proxy will only carry the first positive response, and will > > reject the other ones; but in a 3-ways handshake mode, it should reply > > with a "cancel" if it drops a positive response. > > What? You lost me there. Who is sending the cancel, and to whom? > The proxy to the subscriber? The proxy to the node receiving the > SUBSCRIBE request? The node receiving the SUBSCRIBE request to the > proxy? The subscriber to the proxy? I can't envision any scenario > in which this makes sense without some radical changes to the way > that SIP works. In the case of "subscribe", a proxy that drops a definitive & positive response is doing something harsh to the responding user agent. The UA has installed state as a result of the SUBSCRIBE, and by dropping the response the proxy is making sure that this state will become useless. It seems that sending back some form of cancellation would be appropriate. Indeed, as you point out, we cannot expect all proxies to be modified to a new behavior. This is why we have to have an end-to-end mechanism that confirms that a subscription is valid, the equivalent of an ACK. In the absence of such confirmation, the presentity can clear the subscribe "session." Indeed, the three-ways handshake is only needed if we want to ensure that we have exactly one respondent for any given subscribe session. Another possibility is to leave a session active on every UA that sent a positive response. The watcher will receive several NOTIFY, from various presentity, and may be able to sort it out. On the other hand, I don't believe that just banning fork is an option. Fork may happen "naturally", e.g. if an acknowledgement is lost, the subscribe is repeated, and a stateless proxy routes the repeated subscribe to a different presentity. Fork also happens naturally if the subscribe request is sent over a multicast channel. We must have a way to go from there to a deterministic behavior. -- Christian Huitema _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 3 12:46:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12064 for ; Tue, 3 Jul 2001 12:46:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14801; Tue, 3 Jul 2001 12:26:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14768 for ; Tue, 3 Jul 2001 12:26:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11361 for ; Tue, 3 Jul 2001 12:25:17 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f63GQ1p25991; Tue, 3 Jul 2001 11:26:01 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f63GQ0621972; Tue, 3 Jul 2001 11:26:00 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA08527; Tue, 3 Jul 2001 11:26:00 -0500 (CDT) Reply-To: To: "'Christian Huitema'" , Cc: Subject: RE: [Sip] Forking: a modest proposal. Date: Tue, 3 Jul 2001 11:25:58 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985022518F8@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Indeed, the three-ways handshake is only needed if we want to ensure > that we have exactly one respondent for any given subscribe session. > Another possibility is to leave a session active on every UA > that sent a > positive response. The watcher will receive several NOTIFY, > from various > presentity, and may be able to sort it out. You can implement it in such a fashion that the session isn't "active" until the first (required, immediate) NOTIFY is answered with a 200 class response. It **IS** a three-way handshake. > On the other hand, I don't believe that just banning fork is > an option. > Fork may happen "naturally", e.g. if an acknowledgement is lost, the > subscribe is repeated, and a stateless proxy routes the repeated > subscribe to a different presentity. Fork also happens > naturally if the > subscribe request is sent over a multicast channel. We must have a way > to go from there to a deterministic behavior. The major difference between your "natural" forks and an intentional fork is that *all* responses to your "natural" forks will be received by the node that sent the request (unless suppressed by the remote end, in which case there is no problem); intentional forks will go through a proxy which drops all but the first positive response. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 3 15:44:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17386 for ; Tue, 3 Jul 2001 15:44:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20937; Tue, 3 Jul 2001 15:36:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20906 for ; Tue, 3 Jul 2001 15:36:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17001 for ; Tue, 3 Jul 2001 15:35:22 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f63JXo423232; Tue, 3 Jul 2001 15:33:50 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91]) by cannon.cisco.com (Mirapoint) with ESMTP id ACP00122 (AUTH pkyzivat); Tue, 3 Jul 2001 15:35:19 -0400 (EDT) Message-ID: <3B421D5C.C0A89046@cisco.com> Date: Tue, 03 Jul 2001 15:30:36 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Gonzalo Camarillo'" , Jonathan Rosenberg , Christer Holmberg , sip@ietf.org, mmusic Subject: Re: [Sip] Two SDP issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I also am in favor of a=neithersendnorrecv (or perhaps a=hold would read better). This differs from c=0.0.0.0 or a special port (I think port zero means something else. I have seen port 9 suggested for this.) The a= approach modifies how the transport(s) are used, but doesn't alter their assignment, while changing c= or the port implies changes in assignment. In the case of UDP this may not matter much, but in the case of connection oriented media it can be very important. In the case of a connection oriented media session, specifying c=0.0.0.0 could require establishing a different connection to continue communication in the other direction, or it could make it impossible to continue communication in the other direction. So, I think specifying a=sendonly or a=neithersendnorrecv should be sufficient and recommended as the way to put oneself on hold. Messing with the c= or the port should be considered an optional change that an endpoint can make when it is consistent with the form of communication being negotiated. Paul Kyzivat Cisco Systems > Mark Watson wrote: > > All, > > I like the option of using just a=sendonly to put an existing two-way > session on hold - it makes much more sense than c=0.0.0.0 for all the > reasons given in this thread. Is there any difference (for a two-way > media stream) between 'held' state and 'sendonly' state ? I'm sure SIP > will not save us from crappy 'music' on hold, so there may still be > media in the other direction. > > Also, in a multi-media session I might want to put one media stream on > hold whilst still receiving another. I can only really listen to one > person at a time, but I can see multiple video sessions on my PC > screen. So I might put the audio of a videocall on hold whilst I make > a consultation call to another party. > > In the case of a one-way session, putting this on hold basically > temporarily cancels the media stream altogether. As someone suggested, > it would be nice to have an a=neithersendnorrecv to complete the > possibilities of sendonly, recvonly, sendrecv, but would another > alternative in this case would be to set the port to zero ? > > Regards, > > Mark Watson > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 02 July 2001 20:43 > > To: Jonathan Rosenberg > > Cc: 'Paul Kyzivat'; Christer Holmberg; sip@ietf.org; mmusic > > Subject: Re: [Sip] Two SDP issues > > > > > > Hello Jonathan, > > > > > Ugly, and not my preference, but I see no other viable > > > alternative without sacrificing backwards compatibility. > > > > In this situation, I believe we should have a clear idea of what we > > understand by backwards compatibility. When a new feature is added, > it > > usually means that the addition of the new feature does not break > all > > the implementations that already work properly (but do not provide > the > > new feature). > > > > However, in this scenario, there cannot be any implementation > > that works > > properly right now. They just cannot send RTCP properly. Therefore, > in > > this situation, an elegant brand new mechanism might be > > acceptable. I do > > not think that it would be a big deal to "break" current > > implementations > > that do not work properly anyway. > > > > Regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Tue Jul 3 19:47:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28430 for ; Tue, 3 Jul 2001 19:47:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A23D94436F; Tue, 3 Jul 2001 19:48:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 48BED44370 for ; Tue, 3 Jul 2001 19:47:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 3 19:42:34 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 05ECD44388; Tue, 3 Jul 2001 19:19:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bz0017exch001p.wins.lucent.com (unknown [135.253.94.14]) by lists.bell-labs.com (Postfix) with ESMTP id A7B4A44C6A for ; Tue, 3 Jul 2001 07:01:27 -0400 (EDT) Received: by BZ0017EXCH001P with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 08:01:26 -0300 Message-ID: <0F103142B6F6D311A80E0008C71BAC29D44F06@BZ3002EXCH001U> From: "Boaventura, Alberto Magno Silveira (Alberto)" To: "Isc_Sipeg (E-mail)" , sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP and INAP interworking Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 3 Jul 2001 08:01:16 -0300 Greetings all: Regarding on the issue in subject, in ITU-T, there is the Q.1600 recommendation that establishes special rules for INAP and ISUP interworking. Thus, I am inferring that will be the same for SIP. Does this interworking encapsulate ISUP in MIME attachment in MGC that is a SSP? Or is there any special call scenario set to accommodate the SIP/INAP interworking? What is the state of the art today? I.e., is there any recommendation/draft? Thanks for any return, Alberto. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Tue Jul 3 19:51:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00884 for ; Tue, 3 Jul 2001 19:51:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28255; Tue, 3 Jul 2001 19:42:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28224 for ; Tue, 3 Jul 2001 19:42:27 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24794 for ; Tue, 3 Jul 2001 19:41:43 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f63Grow15423 for ; Tue, 3 Jul 2001 17:53:50 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 3 Jul 2001 17:53:32 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 17:53:30 +0100 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo'" , Jonathan Rosenberg Cc: "'Paul Kyzivat'" , Christer Holmberg , sip@ietf.org, mmusic Subject: RE: [Sip] Two SDP issues Date: Tue, 3 Jul 2001 17:53:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C103E0.AE20B020" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org <<< No Message Collected >>> ------_=_NextPart_001_01C103E0.AE20B020-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 4 04:04:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02517 for ; Wed, 4 Jul 2001 04:04:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22320; Wed, 4 Jul 2001 03:51:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22290 for ; Wed, 4 Jul 2001 03:51:07 -0400 (EDT) Received: from india.mercurykr.com ([165.133.13.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02174 for ; Wed, 4 Jul 2001 03:49:55 -0400 (EDT) Received: from ashwani (Param [165.133.13.33]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id NAA09746; Wed, 4 Jul 2001 13:11:43 -0600 (GMT) Message-ID: <003e01c1045e$08873480$210d85a5@dti.daewoo.co.kr> From: "Ashwani Kumar Kesharwani" To: "Steve Davies" , References: <00533D13955AD411AF3800A0C9B42639C2A4B9@RIDGEWAY> Subject: Re: [Sip] (no subject) Date: Wed, 4 Jul 2001 13:20:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C1048C.0DB0AEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C1048C.0DB0AEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Send ur subscription request to sip-request@ietf.org ----- Original Message -----=20 From: Steve Davies=20 To: 'sip@ietf.org'=20 Sent: Tuesday, July 03, 2001 7:13 PM Subject: [Sip] (no subject) subscribe=20 ------=_NextPart_000_0037_01C1048C.0DB0AEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Send ur subscription request to sip-request@ietf.org
----- Original Message -----
From:=20 Steve=20 Davies
Sent: Tuesday, July 03, 2001 = 7:13=20 PM
Subject: [Sip] (no = subject)

subscribe

------=_NextPart_000_0037_01C1048C.0DB0AEE0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 4 11:23:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08216 for ; Wed, 4 Jul 2001 11:23:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07454; Wed, 4 Jul 2001 11:07:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07425 for ; Wed, 4 Jul 2001 11:07:29 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07919 for ; Wed, 4 Jul 2001 11:06:44 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f64BH6w11008 for ; Wed, 4 Jul 2001 12:17:06 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Wed, 4 Jul 2001 12:16:44 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <3G876HBK>; Wed, 4 Jul 2001 12:16:43 +0100 Message-ID: From: "Mark Watson" To: "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" Cc: "'Paul Kyzivat'" , "'Christer Holmberg'" , "'sip@ietf.org'" , "'mmusic'" Subject: FW: [Sip] Two SDP issues Date: Wed, 4 Jul 2001 12:16:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1047A.CC7D4ED0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1047A.CC7D4ED0 Content-Type: text/plain; charset="iso-8859-1" All, I like the option of using just a=sendonly to put an existing two-way session on hold - it makes much more sense than c=0.0.0.0 for all the reasons given in this thread. Is there any difference (for a two-way media stream) between 'held' state and 'sendonly' state ? I'm sure SIP will not save us from crappy 'music' on hold, so there may still be media in the other direction. Also, in a multi-media session I might want to put one media stream on hold whilst still receiving another. I can only really listen to one person at a time, but I can see multiple video sessions on my PC screen. So I might put the audio of a videocall on hold whilst I make a consultation call to another party. In the case of a one-way session, putting this on hold basically temporarily cancels the media stream altogether. As someone suggested, it would be nice to have an a=neithersendnorrecv to complete the possibilities of sendonly, recvonly, sendrecv, but would another alternative in this case would be to set the port to zero ? Regards, Mark Watson > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 02 July 2001 20:43 > To: Jonathan Rosenberg > Cc: 'Paul Kyzivat'; Christer Holmberg; sip@ietf.org; mmusic > Subject: Re: [Sip] Two SDP issues > > > Hello Jonathan, > > > Ugly, and not my preference, but I see no other viable > > alternative without sacrificing backwards compatibility. > > In this situation, I believe we should have a clear idea of what we > understand by backwards compatibility. When a new feature is added, it > usually means that the addition of the new feature does not break all > the implementations that already work properly (but do not provide the > new feature). > > However, in this scenario, there cannot be any implementation > that works > properly right now. They just cannot send RTCP properly. Therefore, in > this situation, an elegant brand new mechanism might be > acceptable. I do > not think that it would be a big deal to "break" current > implementations > that do not work properly anyway. > > Regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C1047A.CC7D4ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [Sip] Two SDP issues

All,

I like the option of using just a=3Dsendonly to put = an existing two-way session on hold - it makes much more sense than = c=3D0.0.0.0 for all the reasons given in this thread. Is there any = difference (for a two-way media stream) between 'held' state and = 'sendonly' state ? I'm sure SIP will not save us from crappy 'music' on = hold, so there may still be media in the other direction.

Also, in a multi-media session I might want to put = one media stream on hold whilst still receiving another. I can only = really listen to one person at a time, but I can see multiple video = sessions on my PC screen. So I might put the audio of a videocall on = hold whilst I make a consultation call to another party.

In the case of a one-way session, putting this on = hold basically temporarily cancels the media stream altogether. As = someone suggested, it would be nice to have an a=3Dneithersendnorrecv = to complete the possibilities of sendonly, recvonly, sendrecv, but = would another alternative in this case would be to set the port to zero = ?

Regards,

Mark Watson



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 02 July 2001 20:43
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; Christer Holmberg; = sip@ietf.org; mmusic
> Subject: Re: [Sip] Two SDP issues
>
>
> Hello Jonathan,
>
> > Ugly, and not my preference, but I see no = other viable
> > alternative without sacrificing backwards = compatibility.
>
> In this situation, I believe we should have a = clear idea of what we
> understand by backwards compatibility. When a = new feature is added, it
> usually means that the addition of the new = feature does not break all
> the implementations that already work properly = (but do not provide the
> new feature).
>
> However, in this scenario, there cannot be any = implementation
> that works
> properly right now. They just cannot send RTCP = properly. Therefore, in
> this situation, an elegant brand new mechanism = might be
> acceptable. I do
> not think that it would be a big deal to = "break" current
> implementations
> that do not work properly anyway.
>
> Regards,
>
> Gonzalo
> --
> Gonzalo = Camarillo          &nb= sp;         Phone :   = +1 212 939 71 71
> Columbia = University          &n= bsp;       Mobile:  +358 40 702 35 = 35
> 472 Computer Science = Building        Fax   = :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY = 10027           &= nbsp;      
> = USA           &nb= sp;           &nb= sp;      Gonzalo.Camarillo@ericsson.com
>
> = _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C1047A.CC7D4ED0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 5 05:36:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05614 for ; Thu, 5 Jul 2001 05:36:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14248; Thu, 5 Jul 2001 05:21:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14219 for ; Thu, 5 Jul 2001 05:21:01 -0400 (EDT) Received: from pdc2proxy.wipro.com ([203.129.228.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05470 for ; Thu, 5 Jul 2001 05:20:10 -0400 (EDT) Received: from pdc2vwall.wipro.com (pdc2vwall.wipro.com [10.111.14.18]) by pdc2proxy.wipro.com (8.9.3/8.9.3) with SMTP id OAA01704 for ; Thu, 5 Jul 2001 14:50:36 GMT Received: from 10.111.12.18 by pdc2vwall.wipro.com (InterScan E-Mail VirusWall NT); Thu, 05 Jul 2001 14:50:13 -0700 Received: from mrshah ([10.111.11.56]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GG09CY00.D34 for ; Thu, 5 Jul 2001 14:53:22 +0000 From: "Mukesh R Shah" To: Date: Thu, 5 Jul 2001 14:54:38 +0530 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Help on Alert Info. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi All, Can any one eleborate on Alert-Info Request Header which have been mentioned in draft-ietf-sip-rfc2543bis-03.txt on page no.51. Thanks in advance Mukesh _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Thu Jul 5 09:43:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12334 for ; Thu, 5 Jul 2001 09:43:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D28444338; Thu, 5 Jul 2001 09:44:02 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id DC2AE44336 for ; Thu, 5 Jul 2001 09:43:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 5 09:38:21 EDT 2001 Received: by lists.bell-labs.com (Postfix) id B5BBA4438C; Thu, 5 Jul 2001 09:28:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id E1B2E4438B for ; Thu, 5 Jul 2001 09:28:12 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <3HBYVB0J>; Thu, 5 Jul 2001 14:28:11 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002A95612@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'sip@lists.bell-labs.com'" , "'3GPP_TSG_CN_WG1@LIST.ETSI.FR'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] A question about Authorization-Token Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Jul 2001 14:28:10 +0100 Dear All, Sorry for those who get this twice. In draft-ietf-sip-call-auth-01.txt, Authorization-Token is introduced. In 5.2.3, it reads: 5.2.3. Originating Proxy (OP) The Originating Proxy (OP) authenticates the caller, and verifies the caller is authorized to receive the requested level of QoS. In cooperation with originating Policy Decision Point (PDP-o), the OP obtains and/or generates a Media-Authorization-Token that contains sufficient information for the UAC to get the authorized bandwidth for the media streams. My question is: if Caller supports 5 codec, callee returns 3 of the five in its 183 response, how does the OP know what the final codec is going to be used. In other words, how does the OP generate a token which "contains SUFFICIENT information for the UAC to get the authorized bandwidth for the media streams."? For the terminating side, the token is generated when INVITE comes in, same question: how does the terminating proxy generate a token which "contains SUFFICIENT information for the UAC to get the authorized bandwidth for the media streams."? Only PRACK for a 183 contains SUFFICIENT information for the media which is going to be used. So, if the token is used for QoS Authorization, only PRACK can trigger this procedure. Or maybe I misunderstand the popurse of the Token, please point out what I missed. thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Thu Jul 5 11:39:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16890 for ; Thu, 5 Jul 2001 11:39:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26778; Thu, 5 Jul 2001 11:22:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26715 for ; Thu, 5 Jul 2001 11:22:28 -0400 (EDT) Received: from sjc3-1.relay.mail.uu.net (sjc3-1.relay.mail.uu.net [199.171.54.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16313; Thu, 5 Jul 2001 11:21:42 -0400 (EDT) Received: from overhill by sjc3sosrv11.alter.net with SMTP (peer crosschecked as: user2.sentito.com [65.202.222.2] (may be forged)) id QQkwjl24130; Thu, 5 Jul 2001 15:22:27 GMT From: "Frank W. Miller" To: , Date: Thu, 5 Jul 2001 11:21:52 -0400 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] TCAP from SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Not sure which is the right list for this one... Has anyone thought about whats necessary for SIP to be used to invoke TCAP functions on the SS7 network? For example, a SIP UA may need to perform a TCAP dip for a Calling Name on an incoming call. I've looked over the mailing list archives and meetings minutes and found some cursory references to TCAP but nothing substantially similar to what I'm asking here. I'd luv it if I have overlooked or not heard of something. I have thought of allowing TCAP invokations to be carried in INFO messages. The invokation could be carried as a MIME type that is a text represenation of the TCAP method and parameters. This representation could be translated into SS7 at the signaling gateway. I'm working on the specifics of it but would like to get some feedback before I waste too much time on it. Thanks, FM -- Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. www.sentito.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Thu Jul 5 11:57:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17487 for ; Thu, 5 Jul 2001 11:57:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D32DF4433D; Thu, 5 Jul 2001 11:58:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id DBB0444336 for ; Thu, 5 Jul 2001 11:57:34 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f65Ftx420226; Thu, 5 Jul 2001 11:55:59 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by dingdong.cisco.com (Mirapoint) with ESMTP id ADA02362 (AUTH akher); Thu, 5 Jul 2001 11:57:32 -0400 (EDT) Message-ID: <3B448E6D.CE4C5166@cisco.com> From: Ameet Kher Reply-To: akher@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kevin.Summers@ttimail.com Cc: smenon@sonusnet.com, hgs@cs.columbia.edu, sankaran@cs.columbia.edu, sip@lists.bell-labs.com Content-Type: multipart/alternative; boundary="------------93B77A2673E74A0966C8E702" Subject: [SIP] Codecs G729 and their various flavors Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 11:57:33 -0400 --------------93B77A2673E74A0966C8E702 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I am trying to follow up on some previous discussions on this list about whether to use dynamic payload types for various flavors of the G729 codec. Presently the IANA list has defined a static payload type and encoding name only for the G729r8 codec. Should we be using dynamic payloads for G729b, G729ab, G729a ? And use X-* as encoding names ? I am sure we cannot use the same static payload value (18) for all these flavors. - Ameet -- ****************************** AMEET KHER, Software Engineer Cisco Systems Tel : (919) 392-8431 --------------93B77A2673E74A0966C8E702 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

I am trying to follow up on some previous discussions on this list about whether to use dynamic
payload types for various flavors of the G729 codec. Presently the IANA list has defined a static payload type
and encoding name only for the G729r8 codec. Should we be using dynamic payloads for G729b, G729ab, G729a ?
And use X-* as encoding names ? I am sure we cannot use the same static payload value (18) for all these flavors.

- Ameet
 
  

-- 
******************************
AMEET KHER, Software Engineer
Cisco Systems
Tel : (919) 392-8431
  --------------93B77A2673E74A0966C8E702-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 12:21:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18337 for ; Thu, 5 Jul 2001 12:21:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B8AD4433B; Thu, 5 Jul 2001 12:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by lists.bell-labs.com (Postfix) with ESMTP id 709D544336 for ; Thu, 5 Jul 2001 12:21:28 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 12:20:31 -0400 Message-ID: From: "Shaheen, Kamel M." To: sip@lists.bell-labs.com Subject: [SIP] Naive Question Regarding Unsupported Media types in SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1056E.69342110" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Jul 2001 12:20:31 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1056E.69342110 Content-Type: text/plain; charset="iso-8859-1" Greetings SIPers, I am coming from 3GPP point of view where SIP is used to initiate Multimedia Sessions. I had a rather naive question regarding the handling of unsupported media type in SDP. Currently, the proxy (S-CSCF) sets the port number to 0 for all unsupported media types while leaving all media information and attributes in the message traveling through the network and over the air. I was wondering, Is there specific reason for that? Further, If the media type is not supported and the end terminal can not use it, why not delete the whole entry and save the bandwidth? Just wondering! Feedback is always welcomed and excuse my ignorance. Regards, Kamel Shaheen, Ph.D. InterDigital Communication ------_=_NextPart_001_01C1056E.69342110 Content-Type: text/html; charset="iso-8859-1"
Greetings SIPers,
 
I am coming from 3GPP point of view where SIP is used to initiate Multimedia Sessions.  I had a rather naive question regarding the handling of unsupported media type in SDP. Currently, the proxy (S-CSCF) sets the port number to 0 for all unsupported media types while leaving all media information and attributes in the message traveling through the network and over the air. I was wondering, Is there specific reason for that?
 
Further, If the media type is not supported and the end terminal can not use it, why not delete the whole entry and save the bandwidth? Just wondering!
 
Feedback is always welcomed and excuse my ignorance.
 
Regards,
 
Kamel Shaheen, Ph.D.
 
InterDigital Communication 
------_=_NextPart_001_01C1056E.69342110-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 12:36:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18922 for ; Thu, 5 Jul 2001 12:36:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D05A44378; Thu, 5 Jul 2001 12:37:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id A898744336 for ; Thu, 5 Jul 2001 12:36:35 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA25491; Thu, 5 Jul 2001 12:36:22 -0400 (EDT) Message-ID: <3B449786.5AD5CF2A@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: akher@cisco.com Cc: Kevin.Summers@ttimail.com, smenon@sonusnet.com, hgs@cs.columbia.edu, sankaran@cs.columbia.edu, sip@lists.bell-labs.com References: <3B448E6D.CE4C5166@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Codecs G729 and their various flavors Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 12:36:22 -0400 Content-Transfer-Encoding: 7bit Ameet Kher wrote: > > Hi > > I am trying to follow up on some previous discussions on this list > about whether to use dynamic > payload types for various flavors of the G729 codec. Presently the > IANA list has defined a static payload type > and encoding name only for the G729r8 codec. Should we be using > dynamic payloads for G729b, G729ab, G729a ? All new codecs only use dynamic payload types. > And use X-* as encoding names ? I am sure we cannot use the same Using X-* is a certifiably bad idea. The argument has been made numerous times on this list, but let me know if you'd like another rendition of it. > static payload value (18) for all these flavors. You can use the same payload type (doesn't matter if static or dynamic) if the codecs are distinguishable by looking at the payload. G.729a is just a reduced-complexity implementation, that has the same bit pattern, so there doesn't seem to be a need for a new payload type. G.729 is silence suppression and distinguishable by payload length. I have no idea what G.729ab would be; it is not mentioned at http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html > > - Ameet > > > > -- > ****************************** > AMEET KHER, Software Engineer > Cisco Systems > Tel : (919) 392-8431 > > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 12:37:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18981 for ; Thu, 5 Jul 2001 12:37:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7022344388; Thu, 5 Jul 2001 12:37:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from radisys.com (mail-gw.radisys.com [206.102.10.35]) by lists.bell-labs.com (Postfix) with ESMTP id 1A9E344336 for ; Thu, 5 Jul 2001 12:36:40 -0400 (EDT) Received: (1598 bytes) by radisys.com via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) id for sip@lists.bell-labs.com; Thu, 5 Jul 2001 09:36:40 -0700 (PDT) (Smail-3.2.0.105 1999-Mar-3 #2 built 1999-Apr-18) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAA26aqWb; Thu Jul 5 09:22:41 2001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Chao-Chi.Tong@radisys.com X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.8 |June 18, 2001) at 07/05/2001 09:22:32 AM, Serialize complete at 07/05/2001 09:22:32 AM Content-Type: multipart/alternative; boundary="=_alternative 005AB84285256A80_=" Subject: [SIP] using SIP in 3G wireless core network and mobile stations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Jul 2001 12:20:59 -0400 This is a multipart message in MIME format. --=_alternative 005AB84285256A80_= Content-Type: text/plain; charset="us-ascii" Hi, I am looking for information about where SIP is used (or planned to be used) in 3G wireless core network and/or mobile statations. Any information is appreciated. Chao-Chi Tong RadiSys Corp. --=_alternative 005AB84285256A80_= Content-Type: text/html; charset="us-ascii"
Hi,

I am looking for information about where SIP is used (or planned to be used) in 3G wireless core network and/or mobile statations. Any information is appreciated.

Chao-Chi Tong
RadiSys Corp. --=_alternative 005AB84285256A80_=-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Thu Jul 5 12:57:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19634 for ; Thu, 5 Jul 2001 12:57:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00260; Thu, 5 Jul 2001 12:40:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00227 for ; Thu, 5 Jul 2001 12:40:39 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19049 for ; Thu, 5 Jul 2001 12:39:53 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA25795; Thu, 5 Jul 2001 12:40:34 -0400 (EDT) Message-ID: <3B449882.3AB0DF8A@cs.columbia.edu> Date: Thu, 05 Jul 2001 12:40:34 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 CC: akher@cisco.com, smenon@sonusnet.com, sip@ietf.org Subject: Re: [SIP] Re: Codecs G729 and their various flavors References: <3B448E6D.CE4C5166@cisco.com> <3B449786.5AD5CF2A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > G.729 is silence suppression and distinguishable by payload length. Typo: Make that G.729 Annex B. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Thu Jul 5 12:58:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19670 for ; Thu, 5 Jul 2001 12:58:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 691A944364; Thu, 5 Jul 2001 12:59:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by lists.bell-labs.com (Postfix) with ESMTP id F12B444360 for ; Thu, 5 Jul 2001 12:58:09 -0400 (EDT) Received: from m2vwall3.wipro.com ([192.168.2.23]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id XAA08817 for ; Thu, 5 Jul 2001 23:35:01 +0530 Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GG078T00.6L6 for ; Thu, 5 Jul 2001 19:37:41 +0530 Received: from wipro.com (ntultra2.wipsys.soft.net [164.164.8.177]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NTCCGQPJ; Thu, 5 Jul 2001 19:50:43 +0530 Message-ID: <3B4474D5.1C8F60A2@wipro.com> From: Varadarajan Srinivasan Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP mail list Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 19:39:22 +0531 Content-Transfer-Encoding: 7bit Hi, We have been asked to subscribe to ietf.org mailing lists but till now we receive no intimation. Moreover, We are still getting mails in lists.bell_labs.com. Any error on our part? Regards, Varadarajan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 14:07:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21958 for ; Thu, 5 Jul 2001 14:07:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A319A44360; Thu, 5 Jul 2001 14:08:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mill.cisco.com (mill.cisco.com [161.44.131.47]) by lists.bell-labs.com (Postfix) with ESMTP id 4422D44336 for ; Thu, 5 Jul 2001 14:07:20 -0400 (EDT) Received: from SHEMANT-W2K.cisco.com (dhcp-161-44-147-138.cisco.com [161.44.147.138]) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA04571; Thu, 5 Jul 2001 14:07:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20010705140332.01c9a350@mill.cisco.com> X-Sender: shemant@mill.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Chao-Chi.Tong@radisys.com From: Hemant Singh Subject: Re: [SIP] using SIP in 3G wireless core network and mobile stations Cc: sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 14:04:41 -0400 http://www.sipcenter.com/aboutsip/sipmobil.htm is a good place to start. Hemant At 12:20 PM 7/5/2001 -0400, Chao-Chi.Tong@radisys.com wrote: >Hi, > >I am looking for information about where SIP is used (or planned to be >used) in 3G wireless core network and/or mobile statations. Any >information is appreciated. > >Chao-Chi Tong >RadiSys Corp. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 15:08:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24002 for ; Thu, 5 Jul 2001 15:08:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4AD244353; Thu, 5 Jul 2001 15:09:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 4BABA44336 for ; Thu, 5 Jul 2001 15:08:15 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GG0007KTL5JSD@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 5 Jul 2001 19:08:08 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GG000N01L5E1K@dgismtp01.wcomnet.com>; Thu, 05 Jul 2001 19:08:07 +0000 (GMT) Received: from gpaterno ([166.35.153.174]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GG000KGLL52EY@dgismtp01.wcomnet.com>; Thu, 05 Jul 2001 19:07:52 +0000 (GMT) From: Gregory Paterno Subject: RE: [SIP] Re: Codecs G729 and their various flavors In-reply-to: <3B449786.5AD5CF2A@cs.columbia.edu> To: "Henning G. Schulzrinne" Cc: sankaran@cs.columbia.edu, sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 14:07:37 -0500 Content-Transfer-Encoding: 7bit "G.729 is silence suppression and distinguishable by payload length." Where could I find information on the payload length supporting silence suppression for G.711 and G.729b? Thanks. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning G. Schulzrinne Sent: Thursday, July 05, 2001 11:36 AM To: akher@cisco.com Cc: Kevin.Summers@ttimail.com; smenon@sonusnet.com; hgs@cs.columbia.edu; sankaran@cs.columbia.edu; sip@lists.bell-labs.com Subject: [SIP] Re: Codecs G729 and their various flavors Ameet Kher wrote: > > Hi > > I am trying to follow up on some previous discussions on this list > about whether to use dynamic > payload types for various flavors of the G729 codec. Presently the > IANA list has defined a static payload type > and encoding name only for the G729r8 codec. Should we be using > dynamic payloads for G729b, G729ab, G729a ? All new codecs only use dynamic payload types. > And use X-* as encoding names ? I am sure we cannot use the same Using X-* is a certifiably bad idea. The argument has been made numerous times on this list, but let me know if you'd like another rendition of it. > static payload value (18) for all these flavors. You can use the same payload type (doesn't matter if static or dynamic) if the codecs are distinguishable by looking at the payload. G.729a is just a reduced-complexity implementation, that has the same bit pattern, so there doesn't seem to be a need for a new payload type. G.729 is silence suppression and distinguishable by payload length. I have no idea what G.729ab would be; it is not mentioned at http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html > > - Ameet > > > > -- > ****************************** > AMEET KHER, Software Engineer > Cisco Systems > Tel : (919) 392-8431 > > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 15:30:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24619 for ; Thu, 5 Jul 2001 15:30:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 655E44438E; Thu, 5 Jul 2001 15:31:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mill.cisco.com (mill.cisco.com [161.44.131.47]) by lists.bell-labs.com (Postfix) with ESMTP id 26DCD44369 for ; Thu, 5 Jul 2001 15:30:38 -0400 (EDT) Received: from SHEMANT-W2K.cisco.com (dhcp-161-44-147-138.cisco.com [161.44.147.138]) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09464; Thu, 5 Jul 2001 15:30:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20010705140732.03aa3008@mill.cisco.com> X-Sender: shemant@mill.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Chen, Xin (Xin)" From: Hemant Singh Subject: Re: [SIP] A question about Authorization-Token Cc: "'sip@lists.bell-labs.com'" , "'3GPP_TSG_CN_WG1@LIST.ETSI.FR'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> In-Reply-To: <475FF955A05DD411980D00508B6D5FB002A95612@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 05 Jul 2001 15:28:03 -0400 If caller sends 5 codecs, and your caller returned 3, the caller has returned a preferred list where the first codec from the 3 will be picked by proxy/caller UAC. So really, the one codec that got negotiated is known after the 183 is received at the OP in your case. The Media-Auth token can be generated. Hemant At 02:28 PM 7/5/2001 +0100, Chen, Xin (Xin) wrote: >Dear All, > >Sorry for those who get this twice. >In draft-ietf-sip-call-auth-01.txt, Authorization-Token is introduced. >In 5.2.3, it reads: > 5.2.3. Originating Proxy (OP) > The Originating Proxy (OP) authenticates the caller, and >verifies the caller is authorized to receive the requested level of QoS. In >cooperation with originating Policy Decision Point (PDP-o), the OP obtains >and/or generates a Media-Authorization-Token that contains sufficient >information for the UAC to get the authorized bandwidth for the media >streams. >My question is: if Caller supports 5 codec, callee returns 3 of the five in >its 183 response, how does the OP know what the final codec is going to be >used. In other words, how does the OP generate a token which "contains >SUFFICIENT information for the UAC to get the authorized bandwidth for the >media streams."? >For the terminating side, the token is generated when INVITE comes in, same >question: how does the terminating proxy generate a token which "contains >SUFFICIENT information for the UAC to get the authorized bandwidth for the >media streams."? >Only PRACK for a 183 contains SUFFICIENT information for the media which is >going to be used. So, if the token is used for QoS Authorization, only PRACK >can trigger this procedure. >Or maybe I misunderstand the popurse of the Token, please point out what I >missed. > >thanks > >Xin Chen > >Lucent Technologies >Tel: +44 1793 883137 >Mobile: +44 7799 034668 > > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Jul 5 17:03:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27501 for ; Thu, 5 Jul 2001 17:03:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E85C44369; Thu, 5 Jul 2001 17:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sapphire.int.ipverse.com (unknown [65.195.29.42]) by lists.bell-labs.com (Postfix) with ESMTP id 919EB44336 for ; Thu, 5 Jul 2001 17:03:09 -0400 (EDT) Received: by hq.ipverse.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 14:03:06 -0700 Message-ID: <9E388C880C1ED411AFE1009027E78725031100A6@hq.ipverse.com> From: Shawn Pouliotte To: "'Gregory Paterno'" , "Henning G. Schulzrinne" Cc: sankaran@cs.columbia.edu, sip@lists.bell-labs.com Subject: RE: [SIP] Re: Codecs G729 and their various flavors MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10595.DE0AF2D0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 5 Jul 2001 14:02:57 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10595.DE0AF2D0 Content-Type: text/plain; charset="iso-8859-1" Hi -G.729 is CS-ACELP, an 8kbps speech Codec (G.729r8) -G.729a (G.729 Annex A) is a reduced complexity version of G.729 and is still an 8k voice Codec -G.729b (G.729 Annex B) is a spec for Voice Activity Detection (VAD), Discontinuity Transmission (DTX), and Comfort Noise Generation (CNG). More simply stated, Annex B is silence suppression for use with G.729 or G.729a voice codecs and is not a codec in itself. G.729 and G.729a operate on a 10 mSec speech frame corresponding to 80 samples at a rate of 8kbps. This yields an 80bit speech fame every 10 mSec. If silence suppression etc. are used (such as Annex B), the frame length will vary. In the case of annex B, SID frames are 15 bits rather than 80 bits for a speech frame. Hope that helps Shawn -----Original Message----- From: Gregory Paterno [mailto:Greg.Paterno@wcom.com] Sent: Thursday, July 05, 2001 12:08 PM To: Henning G. Schulzrinne Cc: sankaran@cs.columbia.edu; sip@lists.bell-labs.com Subject: RE: [SIP] Re: Codecs G729 and their various flavors "G.729 is silence suppression and distinguishable by payload length." Where could I find information on the payload length supporting silence suppression for G.711 and G.729b? Thanks. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning G. Schulzrinne Sent: Thursday, July 05, 2001 11:36 AM To: akher@cisco.com Cc: Kevin.Summers@ttimail.com; smenon@sonusnet.com; hgs@cs.columbia.edu; sankaran@cs.columbia.edu; sip@lists.bell-labs.com Subject: [SIP] Re: Codecs G729 and their various flavors Ameet Kher wrote: > > Hi > > I am trying to follow up on some previous discussions on this list > about whether to use dynamic > payload types for various flavors of the G729 codec. Presently the > IANA list has defined a static payload type > and encoding name only for the G729r8 codec. Should we be using > dynamic payloads for G729b, G729ab, G729a ? All new codecs only use dynamic payload types. > And use X-* as encoding names ? I am sure we cannot use the same Using X-* is a certifiably bad idea. The argument has been made numerous times on this list, but let me know if you'd like another rendition of it. > static payload value (18) for all these flavors. You can use the same payload type (doesn't matter if static or dynamic) if the codecs are distinguishable by looking at the payload. G.729a is just a reduced-complexity implementation, that has the same bit pattern, so there doesn't seem to be a need for a new payload type. G.729 is silence suppression and distinguishable by payload length. I have no idea what G.729ab would be; it is not mentioned at http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html > > - Ameet > > > > -- > ****************************** > AMEET KHER, Software Engineer > Cisco Systems > Tel : (919) 392-8431 > > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. ------_=_NextPart_001_01C10595.DE0AF2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: Codecs G729 and their various flavors

Hi

-G.729 is CS-ACELP, an 8kbps speech Codec = (G.729r8)
-G.729a (G.729 Annex A) is a reduced complexity = version of G.729 and is still an 8k voice Codec
-G.729b (G.729 Annex B) is a spec for Voice Activity = Detection (VAD), Discontinuity Transmission (DTX), and Comfort Noise = Generation (CNG). More simply stated, Annex B is silence suppression = for use with G.729 or G.729a voice codecs and is not a codec in itself. =

G.729 and G.729a operate on a 10 mSec speech frame = corresponding to 80 samples at a rate of 8kbps. This yields an 80bit = speech fame every 10 mSec. If silence suppression etc. are used (such = as Annex B), the frame length will vary. In the case of annex B, SID = frames are 15 bits rather than 80 bits for a speech frame.

Hope that helps
Shawn

-----Original Message-----
From: Gregory Paterno [mailto:Greg.Paterno@wcom.com]<= /FONT>
Sent: Thursday, July 05, 2001 12:08 PM
To: Henning G. Schulzrinne
Cc: sankaran@cs.columbia.edu; = sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Codecs G729 and their various = flavors


"G.729 is silence suppression and = distinguishable by payload
length."

Where could I find information on the payload length = supporting
silence suppression for G.711 and G.729b?

Thanks.

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bel= l-labs.com]On Behalf Of Henning G.
Schulzrinne
Sent: Thursday, July 05, 2001 11:36 AM
To: akher@cisco.com
Cc: Kevin.Summers@ttimail.com; = smenon@sonusnet.com;
hgs@cs.columbia.edu;
sankaran@cs.columbia.edu; = sip@lists.bell-labs.com
Subject: [SIP] Re: Codecs G729 and their various = flavors


Ameet Kher wrote:
>
> Hi
>
> I am trying to follow up on some previous = discussions on this
list
> about whether to use dynamic
> payload types for various flavors of the G729 = codec. Presently
the
> IANA list has defined a static payload = type
> and encoding name only for the G729r8 codec. = Should we be using
> dynamic payloads for G729b, G729ab, G729a = ?

All new codecs only use dynamic payload types.

> And use X-* as encoding names ? I am sure we = cannot use the
same

Using X-* is a certifiably bad idea. The argument has = been made
numerous
times on this list, but let me know if you'd like = another
rendition of
it.

> static payload value (18) for all these = flavors.

You can use the same payload type (doesn't matter if = static or
dynamic)
if the codecs are distinguishable by looking at the = payload.
G.729a is
just a reduced-complexity implementation, that has = the same bit
pattern,
so there doesn't seem to be a need for a new payload = type.

G.729 is silence suppression and distinguishable by = payload
length.

I have no idea what G.729ab would be; it is not = mentioned at
http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.h= tml



>
> - Ameet
>
>
>
> --
> ******************************
> AMEET KHER, Software Engineer
> Cisco Systems
> Tel : (919) 392-8431
>
>

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP = protocol.
The sip-implementor's list is the place to = discuss
implementation,
and to receive advice on understanding existing = sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with = "subscribe" in the
body.


_______________________________________________
This list is for continuing development of the SIP = protocol.
The sip-implementor's list is the place to discuss = implementation,
and to receive advice on understanding existing = sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with = "subscribe" in the body.

------_=_NextPart_001_01C10595.DE0AF2D0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jul 6 05:17:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24676 for ; Fri, 6 Jul 2001 05:17:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52CFA44374; Fri, 6 Jul 2001 05:18:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2268544336 for ; Fri, 6 Jul 2001 05:17:05 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 6 05:13:43 EDT 2001 Received: by lists.bell-labs.com (Postfix) id D5BCF4438C; Fri, 6 Jul 2001 05:03:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id E15804438B for ; Fri, 6 Jul 2001 05:03:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <3HBYV4ST>; Fri, 6 Jul 2001 10:03:36 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002A95615@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Hemant Singh'" , "Chen, Xin (Xin)" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Authorization-Token MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Jul 2001 10:03:32 +0100 But in terminating side, the token is generated when INVITE comes the callee side proxy, at that moment, how does the proxy know the codecs supported by callee? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Hemant Singh [mailto:shemant@cisco.com] Sent: 05 July 2001 19:28 To: Chen, Xin (Xin) Cc: 'sip@lists.bell-labs.com'; '3GPP_TSG_CN_WG1@LIST.ETSI.FR' Subject: Re: [SIP] A question about Authorization-Token If caller sends 5 codecs, and your caller returned 3, the caller has returned a preferred list where the first codec from the 3 will be picked by proxy/caller UAC. So really, the one codec that got negotiated is known after the 183 is received at the OP in your case. The Media-Auth token can be generated. Hemant At 02:28 PM 7/5/2001 +0100, Chen, Xin (Xin) wrote: >Dear All, > >Sorry for those who get this twice. >In draft-ietf-sip-call-auth-01.txt, Authorization-Token is introduced. >In 5.2.3, it reads: > 5.2.3. Originating Proxy (OP) > The Originating Proxy (OP) authenticates the caller, and >verifies the caller is authorized to receive the requested level of QoS. In >cooperation with originating Policy Decision Point (PDP-o), the OP obtains >and/or generates a Media-Authorization-Token that contains sufficient >information for the UAC to get the authorized bandwidth for the media >streams. >My question is: if Caller supports 5 codec, callee returns 3 of the five in >its 183 response, how does the OP know what the final codec is going to be >used. In other words, how does the OP generate a token which "contains >SUFFICIENT information for the UAC to get the authorized bandwidth for the >media streams."? >For the terminating side, the token is generated when INVITE comes in, same >question: how does the terminating proxy generate a token which "contains >SUFFICIENT information for the UAC to get the authorized bandwidth for the >media streams."? >Only PRACK for a 183 contains SUFFICIENT information for the media which is >going to be used. So, if the token is used for QoS Authorization, only PRACK >can trigger this procedure. >Or maybe I misunderstand the popurse of the Token, please point out what I >missed. > >thanks > >Xin Chen > >Lucent Technologies >Tel: +44 1793 883137 >Mobile: +44 7799 034668 > > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Fri Jul 6 07:01:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26617 for ; Fri, 6 Jul 2001 07:01:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11411; Fri, 6 Jul 2001 06:53:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11384 for ; Fri, 6 Jul 2001 06:53:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26249; Fri, 6 Jul 2001 06:52:17 -0400 (EDT) Message-Id: <200107061052.GAA26249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 06 Jul 2001 06:52:17 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-events-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sip-events-00.txt Pages : 32 Date : 05-Jul-01 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-events-00.txt 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-events-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-events-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: <20010705114132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-events-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-events-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705114132.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Fri Jul 6 09:38:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02016 for ; Fri, 6 Jul 2001 09:38:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8783144350; Fri, 6 Jul 2001 09:39:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mill.cisco.com (mill.cisco.com [161.44.131.47]) by lists.bell-labs.com (Postfix) with ESMTP id 9FDA944336 for ; Fri, 6 Jul 2001 09:38:46 -0400 (EDT) Received: from SHEMANT-W2K.cisco.com (dhcp-161-44-147-138.cisco.com [161.44.147.138]) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24126; Fri, 6 Jul 2001 09:38:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706091134.01cbc218@mill.cisco.com> X-Sender: shemant@mill.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Chen, Xin (Xin)" From: Hemant Singh Subject: RE: [SIP] A question about Authorization-Token Cc: "Chen, Xin (Xin)" , "'sip@lists.bell-labs.com'" In-Reply-To: <475FF955A05DD411980D00508B6D5FB002A95615@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Jul 2001 09:36:13 -0400 You are confusing the bandwidth authorization with the bandwidth reservation step. The token is generated during the authorization stage when the codec type or its bandwidth requirements is not necessarily needed. Only when one goes to reserve the network bandwidth is the codec type required and of course the token as well. For your case at the DP, look at section 6.1.2, Figure 2. Only after the 183 message has reached the UAS, the UAS generates a RSVP-PATHt message that needs the codec info etc. and the auth token. Hemant At 10:03 AM 7/6/2001 +0100, Chen, Xin (Xin) wrote: >But in terminating side, the token is generated when INVITE comes the callee >side proxy, at that moment, how does the proxy know the codecs supported by >callee? > >Xin Chen > >Lucent Technologies >Tel: +44 1793 883137 >Mobile: +44 7799 034668 > > >-----Original Message----- >From: Hemant Singh [mailto:shemant@cisco.com] >Sent: 05 July 2001 19:28 >To: Chen, Xin (Xin) >Cc: 'sip@lists.bell-labs.com'; '3GPP_TSG_CN_WG1@LIST.ETSI.FR' >Subject: Re: [SIP] A question about Authorization-Token > > >If caller sends 5 codecs, and your caller returned 3, the caller has >returned a preferred list where the first codec from the 3 will be picked >by proxy/caller UAC. So really, the one codec that got negotiated is >known after the 183 is received at the OP in your case. >The Media-Auth token can be generated. > >Hemant > > >At 02:28 PM 7/5/2001 +0100, Chen, Xin (Xin) wrote: > >Dear All, > > > >Sorry for those who get this twice. > >In draft-ietf-sip-call-auth-01.txt, Authorization-Token is introduced. > >In 5.2.3, it reads: > > 5.2.3. Originating Proxy (OP) > > The Originating Proxy (OP) authenticates the caller, and > >verifies the caller is authorized to receive the requested level of QoS. In > >cooperation with originating Policy Decision Point (PDP-o), the OP obtains > >and/or generates a Media-Authorization-Token that contains sufficient > >information for the UAC to get the authorized bandwidth for the media > >streams. > >My question is: if Caller supports 5 codec, callee returns 3 of the five >in > >its 183 response, how does the OP know what the final codec is going to be > >used. In other words, how does the OP generate a token which "contains > >SUFFICIENT information for the UAC to get the authorized bandwidth for the > >media streams."? > >For the terminating side, the token is generated when INVITE comes in, same > >question: how does the terminating proxy generate a token which "contains > >SUFFICIENT information for the UAC to get the authorized bandwidth for the > >media streams."? > >Only PRACK for a 183 contains SUFFICIENT information for the media which is > >going to be used. So, if the token is used for QoS Authorization, only >PRACK > >can trigger this procedure. > >Or maybe I misunderstand the popurse of the Token, please point out what I > >missed. > > > >thanks > > > >Xin Chen > > > >Lucent Technologies > >Tel: +44 1793 883137 > >Mobile: +44 7799 034668 > > > > > >_______________________________________________ > >This list is for continuing development of the SIP protocol. > >The sip-implementor's list is the place to discuss implementation, > >and to receive advice on understanding existing sip. > >To subscribe to it, send mail to > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Fri Jul 6 11:02:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06588 for ; Fri, 6 Jul 2001 11:02:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17962; Fri, 6 Jul 2001 10:26:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17899 for ; Fri, 6 Jul 2001 10:26:17 -0400 (EDT) Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03978; Fri, 6 Jul 2001 10:25:28 -0400 (EDT) Received: from email.eximsoft.com ([164.164.87.130]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with ESMTP id f670TGU20601; Fri, 6 Jul 2001 19:29:16 -0500 (GMT) Received: from localhost (localhost.eximsoft.com [127.0.0.1]) by email.eximsoft.com (Postfix) with ESMTP id B9CB6690E9; Fri, 6 Jul 2001 19:55:54 +0530 (IST) Received: from postman.eximsoft.com (mcpostman [10.10.30.11]) by email.eximsoft.com (Postfix) with ESMTP id 1334A690F1; Fri, 6 Jul 2001 19:55:51 +0530 (IST) Received: from ewsmc042 (unknown [10.10.40.122]) by postman.eximsoft.com (Postfix) with SMTP id 5DA1B1F54E; Fri, 6 Jul 2001 19:57:39 +0530 (IST) From: gautham To: sip@ietf.org, sipping@ietf.org Date: Fri, 6 Jul 2001 19:47:05 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: Multipart/Mixed; boundary="Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD" MIME-Version: 1.0 Message-Id: <01070619525300.01885@ewsmc042> X-Virus-Scanned: by AMaViS snapshot-20010407 Subject: [Sip] Application Server Rationale? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/plain Content-Transfer-Encoding: 8bit Hi, I needed clarification on a few aspects of the SIP Server and Application Server interface. Please give necessary and applicable pointers if this is a repeat question on this list. Thanks in advance and in anticipation of a response. Some of the functional blocks that I would attribute to a SIP Server would typically be: Basic Call Processing, Routing, Subscriber Service Data Management (may be an HLR/VLR function or access to the same), Accounting, and other support functions. Further, the intention would then be to have another platform (the AS) that can house all services - be it CLASS-4-like services (like toll-free or LNP) or typical CLASS-5 services (subscriber initiated services, IP Centrex) and others of the likes of Pre-paid, Meet-me Conference, Click-to-talk, etc. This is very similar to the Softswitch requirements of the ISC-Softswitch Architecture. Few questions on the above: 1> Can I build an AS that is normally not in the path of the call flow and that is brought into the call flow only when a certain *trigger* and its associated criteria is detected? Analogous to the IN wherein a trigger (DP) may be armed with a certain criteria and when the DP and the criteria match, the service key (which may be the Request-URI here) is delivered to the SCP (the AS here), probably through an INVITE. 2> If the above is possible, then is it possible to use SIP (over the AS-SIP Server interface) in a manner in which the AS can instruct the SIP Server to arm (or monitor) more events for only this call? If so, how is this reported (the mechanism) - in-call arming and in-call reporting of events? 3> How are typically Call Party Handling operations carried out over this interface? Is a fine-grained control possible, as through INAP? I have gone through the proposed architecture for Application Server components (draft -rosenberg-sip-app-components-01.txt) and still would want some info on this aspect. 4> SIP baseline package propounds how a number of services such as Call Forwarding, Call Transfer, Call Hold etc. are to be handled. But suppose I want to provide an AS that can house all CLASS-5 features, what would it really take? This AS would then turn out to be a Call Stateful Proxy, with every call going through it. Is this what is then intended? But this would limit the scalability of the platform and not render the same to third-party involvement!? Coming to what the Network Architects really thought how things would work: 5> What is the SIP interface between the SIP Proxy and the AS really used for? Is it for call supervision or for transferring the handling of call processing from the SIP Proxy to the AS? Again the issue of "the condition" under which this happens comes to the fore! 6> Services like 3PCC are the easy part for the AS to address. Other services that are explicitly targeted by the INVITE from the UA are also probably fine, but what about call handling services? CPL would not help here as it is for the terminating side of the call. What about the originating side services? 7> Some conditions at the SIP Proxy, such as routing failure, may be taken care of at the Proxy itself through local/centralized policies. How would these then interact with a third-pary application on an AS - that tie with similar triggers? If some services are handled by the SIP Proxy and others by the AS, isnt there a perceived danger of complex Feature Interactions happening down-the-line? The above is definitely not something that would not have been addressed in some forum. I would appreciate if the above can either be discussed here or pointers to a prior discussion on the same can be shared. Thanks! Regards, Gautham A.N. --Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: quoted-printable
Please go = through the same=20 and lets discuss this before we send it on the list ... lets take this = on=20 priority! Please review critically - and suggest changes to the = following=20 text!
 
 
 
 
    I needed = clarification=20 on a few aspects of the SIP Server and Application Server interface. = Please give=20 necessary and applicable pointers if this is a repeat question on this = list.=20 Thanks in advance and in anticipation of a response.
 
    Some of the = functional=20 blocks that I would attribute to a SIP Server would typically be: Basic = Call=20 Processing, Routing, Subscriber Service Data Management (may be an = HLR/VLR=20 function or access to the same), Accounting, and other support = functions.=20
 
    Further, the = intention=20 would then be to have another platform (the AS) that can house all = services - be=20 it CLASS-4-like services (like toll-free or LNP) or typical CLASS-5 = services=20 (subscriber initiated services, IP Centrex) and others of the likes of = Pre-paid,=20 Meet-me Conference, Click-to-talk, etc.
 
    This is very = similar to=20 the Softswitch requirements of the ISC-Softswitch = Architecture.
 
    Few = questions on the=20 above:
1> Can I build an AS that is = normally=20 not in the path of the call flow and that is brought into the call flow = only=20 when a certain *trigger* and its associated criteria is detected? = Analogous to=20 the IN wherein a trigger (DP) may be armed with a certain criteria and = when the=20 DP and the criteria match, the service key (which may be the Request-URI = here)=20 is delivered to the SCP (the AS here), probably through an = INVITE.
 
2> If the above is possible, = then is it=20 possible to use SIP (over the AS-SIP Server interface) in a manner in = which the=20 AS can instruct the SIP Server to arm (or monitor) more events for only = this=20 call? If so, how is this reported (the mechanism) - in-call arming and = in-call=20 reporting of events?
 
3> How are typically Call = Party Handling=20 operations carried out over this interface? Is a fine-grained control = possible,=20 as through INAP? I have gone through the proposed architecture for = Application=20 Server components - and still would want some info on this = aspect.
 
4> SIP baseline package=20 propounds how a number of services such as Call Forwarding, Call = Transfer,=20 Call Hold etc. are to be handled. But suppose I want to provide an AS = that can=20 house all CLASS-5 features, what would it really take? This AS would = then turn=20 out to be a Call Stateful Proxy, with every call going through it. Is = this what=20 is then intended? But this would limit the scalability of the platform = and not=20 render the same to third-party involvement!?
 
    Coming to = what the=20 Network Architects really thought how things would work:
5> What is the SIP interface = between the=20 SIP Proxy and the AS really used for? Is it for call supervision or for=20 transferring the handling of call processing from the SIP Proxy to the = AS? Again=20 the issue of "the condition" under which this happens comes to the=20 fore!
 
6> Services like 3PCC are = the easy part=20 for the AS to address. Other services that are explicitly targeted by = the INVITE=20 from the UA are also probably fine, but what about call handling = services?=20 CPL would not help here as it is for the terminating side of the = call. What=20 about the originating side services?
 
7> Some conditions at the = SIP Proxy,=20 such as routing failure, may be taken care of at the Proxy itself = through=20 local/centralized policies. How would these then interact with a = third-pary=20 application on an AS - that tie with similar triggers? If some services = are=20 handled by the SIP Proxy and others by the AS, isnt there a perceived = danger of=20 complex Feature Interactions happening down-the-line?
 
    The above is = definitely=20 not something that would not have been addressed in some forum. I would=20 appreciate if the above can either be discussed here or pointers to a = prior=20 discussion on the same can be shared. Thanks!
 
Regards,
 
--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 11:23:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07929 for ; Fri, 6 Jul 2001 11:23:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19782; Fri, 6 Jul 2001 11:12:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19752 for ; Fri, 6 Jul 2001 11:12:05 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07219 for ; Fri, 6 Jul 2001 11:11:19 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f66FAdK11472; Fri, 6 Jul 2001 10:10:39 -0500 Message-ID: <000701c1062d$c4045dc0$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "Bill Marshall \(E-mail\)" Cc: "IETF SIP" , "Rakesh Shah \(E-mail\)" Date: Fri, 6 Jul 2001 10:10:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] cooments on draft-ietf-sip-call-auth-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A couple of nits: 1) Section 6.1.1 para 5 says "initiates a Policy-Setup message to POP-o.". The target should probably be PDP-o, not POP-o. 2) 6.1.1. para 3 says "Assuming that the call is not forwarded, the other end-point sends a 183 response to the initial INVITE, forwarded back to OP. The sentence should probably end "proxied back to OP." This change would avoid semantic conflict on "forwarded". 3) Section 6.1.1 p5 says " When OP receives the 183, it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to POP-o." -- I would like to see more discussion of how it actually gets this from the SDP, especially as there may be 37 codecs listed.Or is this covered in manyfolks? If so, there's a reference problem. -- Dean _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 12:08:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10304 for ; Fri, 6 Jul 2001 12:08:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21202; Fri, 6 Jul 2001 11:57:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21173 for ; Fri, 6 Jul 2001 11:57:12 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09604 for ; Fri, 6 Jul 2001 11:56:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f66Fuhki013260; Fri, 6 Jul 2001 11:56:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0Z41H>; Fri, 6 Jul 2001 11:57:08 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" Date: Fri, 6 Jul 2001 11:57:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Please note inconsistency in .txt and .ps/.pdf in bis-03 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, Another inconsistency between the .txt and .ps/.pdf versions of bis has been pointed out to me. The difference is in the section on URL comparison. The .ps/.pdf says: Thus, the following URLs are equivalent: sip:juser@%65xample.com:5060 sip:juser@ExAmPlE.CoM;Transport=udp while SIP:JUSER@ExAmPlE.CoM;Transport=udp sip:juser@ExAmPlE.CoM;Transport=UDP are not. whilst the .txt says: Thus, the following URLs are equivalent: sip:juser@ sip:juser@ExAmPlE.CoM;Transport=udp while SIP:JUSER@ExAmPlE.CoM;Transport=udp sip:juser@ExAmPlE.CoM;Transport=UDP are not. The .txt has missed the stuff following the %65. This is some kind of latex or compilation problem of sorts. To be clear, the hostport piece of the URL is mandatory, and thus sip:juser@ is not even a valid SIP URL. The .pdf/.ps is correct, the .txt is wrong. I will get this fixed in -04. My aplogies. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 14:59:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16186 for ; Fri, 6 Jul 2001 14:59:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26867; Fri, 6 Jul 2001 14:46:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26840 for ; Fri, 6 Jul 2001 14:46:11 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15807 for ; Fri, 6 Jul 2001 14:45:24 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f66IiqK12027 for ; Fri, 6 Jul 2001 13:44:52 -0500 Message-ID: <004b01c1064b$aab83f80$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "IETF SIP" Date: Fri, 6 Jul 2001 13:44:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Agenda Requests for IETF-51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please send me any requests for agenda time in SIP at IETF 51. Note that we will NOT be doing presentations of materials that are not the subject of active discussion in teh working groups. We would like to concentrate on resolving any issues with current work or potential work already under dicussion on teh lists. Thanks. -- Dean Willis SIP WG CoChair. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 16:50:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19473 for ; Fri, 6 Jul 2001 16:50:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29178; Fri, 6 Jul 2001 16:13:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29149 for ; Fri, 6 Jul 2001 16:13:09 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18414 for ; Fri, 6 Jul 2001 16:12:23 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f66KCN525572; Fri, 6 Jul 2001 15:12:23 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f66KCMJ16994; Fri, 6 Jul 2001 15:12:22 -0500 (CDT) Received: from pc050163 (racom-sd-13.sd.us.am.ericsson.se [142.133.141.14]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA05170; Fri, 6 Jul 2001 15:12:19 -0500 (CDT) Reply-To: From: "Adam Roach" To: "'Bob Penfield'" , "Jonathan Rosenberg" , "'Chris Hogg'" , "'Zmolek, Andrew (Andrew)'" , "Mathieu, Marie-Noelle" , Subject: RE: [Sip] RE: [Sipping] Call and call-id Date: Thu, 5 Jul 2001 21:21:59 -0500 Message-ID: <000101c10658$7fff21c0$01fea8c0@pc050163.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <00a001c100e5$25b03420$2300000a@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Jonathan Rosenberg wrote: > > > > 1. As Gonzalo indicated, overlap reuses call-id. I think > thats not such a > > good idea. Lets be explicit. If they need some extra header > to correlate > > those things, so be it. > > I think overlap's reuse of call-id meets the "set of > participants invited to > a session by a common source" definition since the > originating gateway is > the "common source". I was going to compose a long refutation of the contention that using Call-ID for the overlap solution is inappropriate. I'll forgo that, though; Bob has summed up the key argument quite concisely. I couldn't agree more. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Fri Jul 6 16:54:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19633 for ; Fri, 6 Jul 2001 16:54:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7D2444337; Fri, 6 Jul 2001 16:55:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [64.102.17.204]) by lists.bell-labs.com (Postfix) with ESMTP id 98E3A44336 for ; Fri, 6 Jul 2001 16:54:39 -0400 (EDT) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA15456; Fri, 6 Jul 2001 16:54:03 -0400 (EDT) Message-ID: <3B46256F.A781BA25@cisco.com> From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shawn Pouliotte Cc: "'Gregory Paterno'" , "Henning G. Schulzrinne" , sankaran@cs.columbia.edu, sip@lists.bell-labs.com Subject: Re: [SIP] Re: Codecs G729 and their various flavors References: <9E388C880C1ED411AFE1009027E78725031100A6@hq.ipverse.com> Content-Type: multipart/alternative; boundary="------------07B8B44FB309E45454EE8DD1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 06 Jul 2001 16:54:07 -0400 --------------07B8B44FB309E45454EE8DD1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi The fact is that g.729 /g.729a pair shall not interoperate with g.729b/g.729ab. The static payload '18' defined so far is being used for g.729/g.729a by SIP folks . Some are now interested in using g.729b/g.729ab pair for obvious advantages in VAD,DTX etc. So, my question is that why don't we have a static payload defined for g.729b/g729ab pair just like we had '18' for the other pair. Or is it legal to use '18' for this pair too ? To avoid interop issues, can we lay down rules to state that when to use '18' and when not to use '18' especially if a SIP-UA agent has the ability to support 'all' the four flavors of g729 and is interested in advertising that in its SDP ? thanks -manoj Shawn Pouliotte wrote: > > > Hi > > -G.729 is CS-ACELP, an 8kbps speech Codec (G.729r8) > -G.729a (G.729 Annex A) is a reduced complexity version of G.729 and > is still an 8k voice Codec > -G.729b (G.729 Annex B) is a spec for Voice Activity Detection (VAD), > Discontinuity Transmission (DTX), and Comfort Noise Generation (CNG). > More simply stated, Annex B is silence suppression for use with G.729 > or G.729a voice codecs and is not a codec in itself. > > G.729 and G.729a operate on a 10 mSec speech frame corresponding to 80 > samples at a rate of 8kbps. This yields an 80bit speech fame every 10 > mSec. If silence suppression etc. are used (such as Annex B), the > frame length will vary. In the case of annex B, SID frames are 15 bits > rather than 80 bits for a speech frame. > > Hope that helps > Shawn > > -----Original Message----- > From: Gregory Paterno [mailto:Greg.Paterno@wcom.com] > Sent: Thursday, July 05, 2001 12:08 PM > To: Henning G. Schulzrinne > Cc: sankaran@cs.columbia.edu; sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Codecs G729 and their various flavors > > "G.729 is silence suppression and distinguishable by payload > length." > > Where could I find information on the payload length supporting > silence suppression for G.711 and G.729b? > > Thanks. > > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning G. > Schulzrinne > Sent: Thursday, July 05, 2001 11:36 AM > To: akher@cisco.com > Cc: Kevin.Summers@ttimail.com; smenon@sonusnet.com; > hgs@cs.columbia.edu; > sankaran@cs.columbia.edu; sip@lists.bell-labs.com > Subject: [SIP] Re: Codecs G729 and their various flavors > > Ameet Kher wrote: > > > > Hi > > > > I am trying to follow up on some previous discussions on this > list > > about whether to use dynamic > > payload types for various flavors of the G729 codec. Presently > the > > IANA list has defined a static payload type > > and encoding name only for the G729r8 codec. Should we be using > > dynamic payloads for G729b, G729ab, G729a ? > > All new codecs only use dynamic payload types. > > > And use X-* as encoding names ? I am sure we cannot use the > same > > Using X-* is a certifiably bad idea. The argument has been made > numerous > times on this list, but let me know if you'd like another > rendition of > it. > > > static payload value (18) for all these flavors. > > You can use the same payload type (doesn't matter if static or > dynamic) > if the codecs are distinguishable by looking at the payload. > G.729a is > just a reduced-complexity implementation, that has the same bit > pattern, > so there doesn't seem to be a need for a new payload type. > > G.729 is silence suppression and distinguishable by payload > length. > > I have no idea what G.729ab would be; it is not mentioned at > http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html > > > > > > - Ameet > > > > > > > > -- > > ****************************** > > AMEET KHER, Software Engineer > > Cisco Systems > > Tel : (919) 392-8431 > > > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss > implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the > body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s --------------07B8B44FB309E45454EE8DD1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

The fact is that g.729 /g.729a  pair shall not interoperate with g.729b/g.729ab.
The static payload '18' defined so far is being used for g.729/g.729a by
SIP folks  .
Some are now interested in using g.729b/g.729ab pair for obvious advantages in
VAD,DTX etc.

So, my question is that why don't we have a static payload defined for g.729b/g729ab
pair just like we had '18' for the other pair.

Or is it legal to use '18' for this pair too ?

To avoid interop issues, can we lay down rules to state that when to use '18' and when
not to use '18' especially if a SIP-UA agent has the ability to support 'all' the four flavors of
g729 and is interested in advertising that in its SDP ?

thanks
-manoj
 

Shawn Pouliotte wrote:

 

Hi

-G.729 is CS-ACELP, an 8kbps speech Codec (G.729r8)
-G.729a (G.729 Annex A) is a reduced complexity version of G.729 and is still an 8k voice Codec
-G.729b (G.729 Annex B) is a spec for Voice Activity Detection (VAD), Discontinuity Transmission (DTX), and Comfort Noise Generation (CNG). More simply stated, Annex B is silence suppression for use with G.729 or G.729a voice codecs and is not a codec in itself.

G.729 and G.729a operate on a 10 mSec speech frame corresponding to 80 samples at a rate of 8kbps. This yields an 80bit speech fame every 10 mSec. If silence suppression etc. are used (such as Annex B), the frame length will vary. In the case of annex B, SID frames are 15 bits rather than 80 bits for a speech frame.

Hope that helps
Shawn

-----Original Message-----
From: Gregory Paterno [mailto:Greg.Paterno@wcom.com]
Sent: Thursday, July 05, 2001 12:08 PM
To: Henning G. Schulzrinne
Cc: sankaran@cs.columbia.edu; sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Codecs G729 and their various flavors

"G.729 is silence suppression and distinguishable by payload
length."

Where could I find information on the payload length supporting
silence suppression for G.711 and G.729b?

Thanks.

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning G.
Schulzrinne
Sent: Thursday, July 05, 2001 11:36 AM
To: akher@cisco.com
Cc: Kevin.Summers@ttimail.com; smenon@sonusnet.com;
hgs@cs.columbia.edu;
sankaran@cs.columbia.edu; sip@lists.bell-labs.com
Subject: [SIP] Re: Codecs G729 and their various flavors

Ameet Kher wrote:
>
> Hi
>
> I am trying to follow up on some previous discussions on this
list
> about whether to use dynamic
> payload types for various flavors of the G729 codec. Presently
the
> IANA list has defined a static payload type
> and encoding name only for the G729r8 codec. Should we be using
> dynamic payloads for G729b, G729ab, G729a ?

All new codecs only use dynamic payload types.

> And use X-* as encoding names ? I am sure we cannot use the
same

Using X-* is a certifiably bad idea. The argument has been made
numerous
times on this list, but let me know if you'd like another
rendition of
it.

> static payload value (18) for all these flavors.

You can use the same payload type (doesn't matter if static or
dynamic)
if the codecs are distinguishable by looking at the payload.
G.729a is
just a reduced-complexity implementation, that has the same bit
pattern,
so there doesn't seem to be a need for a new payload type.

G.729 is silence suppression and distinguishable by payload
length.

I have no idea what G.729ab would be; it is not mentioned at
http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html
 

>
> - Ameet
>
>
>
> --
> ******************************
> AMEET KHER, Software Engineer
> Cisco Systems
> Tel : (919) 392-8431
>
>

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss
implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the
body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s
  --------------07B8B44FB309E45454EE8DD1-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jul 6 17:35:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20690 for ; Fri, 6 Jul 2001 17:35:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E95744337; Fri, 6 Jul 2001 17:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sapphire.int.ipverse.com (unknown [65.195.29.42]) by lists.bell-labs.com (Postfix) with ESMTP id 6258144336 for ; Fri, 6 Jul 2001 17:35:06 -0400 (EDT) Received: by hq.ipverse.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jul 2001 14:35:06 -0700 Message-ID: <9E388C880C1ED411AFE1009027E78725031100B0@hq.ipverse.com> From: Shawn Pouliotte To: "'Colin Perkins'" , Manoj Bhatia Cc: Shawn Pouliotte , "'Gregory Paterno'" , "Henning G. Schulzrinne" , sankaran@cs.columbia.edu, sip@lists.bell-labs.com Subject: RE: [SIP] Re: Codecs G729 and their various flavors MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10663.86253980" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 6 Jul 2001 14:35:06 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10663.86253980 Content-Type: text/plain Hi There, You don't need a different payload type for 729b/729ab as you can determine that you are receiving silence from the payload length. Voice is nx10 bytes and silence is 4 bytes. Silence and Voice can be sent together giving (nx10)+4 as payload length hence payload type 18 along with payload length is enough to determine what is being sent. As 729a and 729 codecs can also interoperate with one-another, you don't need to distinguish between the 2 payloads. Hope that helps Shawn -----Original Message----- From: Colin Perkins [mailto:csp@isi.edu] Sent: Friday, July 06, 2001 2:13 PM To: Manoj Bhatia Cc: Shawn Pouliotte; 'Gregory Paterno'; Henning G. Schulzrinne; sankaran@cs.columbia.edu; sip@lists.bell-labs.com Subject: Re: [SIP] Re: Codecs G729 and their various flavors The rules for use and signalling of G.729 in RTP are defined in: draft-ietf-avt-profile-new-10.txt and draft-ietf-avt-rtp-mime-04.txt According to those drafts, it is legal to use payload type 18 for Annex B frames (indeed, that is the default). They also define a parameter for use in SDP a=fmtp: lines to explicitly signal the presence/absence of annex B frames if that is necessary. If there are problems with these definitions, they should be brought to the attention of the AVT working group, since the revised profile is about to be submitted for publication as a draft standard RFC. Colin --> Manoj Bhatia writes: >Hi > >The fact is that g.729 /g.729a pair shall not interoperate with >g.729b/g.729ab. >The static payload '18' defined so far is being used for g.729/g.729a by > >SIP folks . >Some are now interested in using g.729b/g.729ab pair for obvious >advantages in >VAD,DTX etc. > >So, my question is that why don't we have a static payload defined for >g.729b/g729ab >pair just like we had '18' for the other pair. > >Or is it legal to use '18' for this pair too ? > >To avoid interop issues, can we lay down rules to state that when to use >'18' and when >not to use '18' especially if a SIP-UA agent has the ability to support >'all' the four flavors of >g729 and is interested in advertising that in its SDP ? > >thanks >-manoj > > >Shawn Pouliotte wrote: > >> >> >> Hi >> >> -G.729 is CS-ACELP, an 8kbps speech Codec (G.729r8) >> -G.729a (G.729 Annex A) is a reduced complexity version of G.729 and >> is still an 8k voice Codec >> -G.729b (G.729 Annex B) is a spec for Voice Activity Detection (VAD), >> Discontinuity Transmission (DTX), and Comfort Noise Generation (CNG). >> More simply stated, Annex B is silence suppression for use with G.729 >> or G.729a voice codecs and is not a codec in itself. >> >> G.729 and G.729a operate on a 10 mSec speech frame corresponding to 80 >> samples at a rate of 8kbps. This yields an 80bit speech fame every 10 >> mSec. If silence suppression etc. are used (such as Annex B), the >> frame length will vary. In the case of annex B, SID frames are 15 bits >> rather than 80 bits for a speech frame. >> >> Hope that helps >> Shawn >> >> -----Original Message----- >> From: Gregory Paterno [mailto:Greg.Paterno@wcom.com] >> Sent: Thursday, July 05, 2001 12:08 PM >> To: Henning G. Schulzrinne >> Cc: sankaran@cs.columbia.edu; sip@lists.bell-labs.com >> Subject: RE: [SIP] Re: Codecs G729 and their various flavors >> >> "G.729 is silence suppression and distinguishable by payload >> length." >> >> Where could I find information on the payload length supporting >> silence suppression for G.711 and G.729b? >> >> Thanks. >> >> -----Original Message----- >> From: sip-admin@lists.bell-labs.com >> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Henning G. >> Schulzrinne >> Sent: Thursday, July 05, 2001 11:36 AM >> To: akher@cisco.com >> Cc: Kevin.Summers@ttimail.com; smenon@sonusnet.com; >> hgs@cs.columbia.edu; >> sankaran@cs.columbia.edu; sip@lists.bell-labs.com >> Subject: [SIP] Re: Codecs G729 and their various flavors >> >> Ameet Kher wrote: >> > >> > Hi >> > >> > I am trying to follow up on some previous discussions on this >> list >> > about whether to use dynamic >> > payload types for various flavors of the G729 codec. Presently >> the >> > IANA list has defined a static payload type >> > and encoding name only for the G729r8 codec. Should we be using >> > dynamic payloads for G729b, G729ab, G729a ? >> >> All new codecs only use dynamic payload types. >> >> > And use X-* as encoding names ? I am sure we cannot use the >> same >> >> Using X-* is a certifiably bad idea. The argument has been made >> numerous >> times on this list, but let me know if you'd like another >> rendition of >> it. >> >> > static payload value (18) for all these flavors. >> >> You can use the same payload type (doesn't matter if static or >> dynamic) >> if the codecs are distinguishable by looking at the payload. >> G.729a is >> just a reduced-complexity implementation, that has the same bit >> pattern, >> so there doesn't seem to be a need for a new payload type. >> >> G.729 is silence suppression and distinguishable by payload >> length. >> >> I have no idea what G.729ab would be; it is not mentioned at >> http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.html >> >> >> > >> > - Ameet >> > >> > >> > >> > -- >> > ****************************** >> > AMEET KHER, Software Engineer >> > Cisco Systems >> > Tel : (919) 392-8431 >> > >> > >> >> -- >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> _______________________________________________ >> This list is for continuing development of the SIP protocol. >> The sip-implementor's list is the place to discuss >> implementation, >> and to receive advice on understanding existing sip. >> To subscribe to it, send mail to >> sip-implementors-request@cs.columbia.edu with "subscribe" in the >> body. >> >> _______________________________________________ >> This list is for continuing development of the SIP protocol. >> The sip-implementor's list is the place to discuss implementation, >> and to receive advice on understanding existing sip. >> To subscribe to it, send mail to >> sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > >-- >Manoj Bhatia | | | >manojb@cisco.com | :|: :|: >7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: >Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s ------_=_NextPart_001_01C10663.86253980 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: Codecs G729 and their various flavors

Hi There,

You don't need a different payload type for = 729b/729ab as you can determine that you are receiving silence from the = payload length. Voice is nx10 bytes and silence is 4 bytes. Silence and = Voice can be sent together giving (nx10)+4 as payload length hence = payload type 18 along with payload length is enough to determine what = is being sent.

As 729a and 729 codecs can also interoperate with = one-another, you don't need to distinguish between the 2 payloads. =

Hope that helps
Shawn

-----Original Message-----
From: Colin Perkins [mailto:csp@isi.edu]
Sent: Friday, July 06, 2001 2:13 PM
To: Manoj Bhatia
Cc: Shawn Pouliotte; 'Gregory Paterno'; Henning G. = Schulzrinne;
sankaran@cs.columbia.edu; = sip@lists.bell-labs.com
Subject: Re: [SIP] Re: Codecs G729 and their various = flavors


The rules for use and signalling of G.729 in RTP are = defined in:
        draft-ietf-avt-profile-new-10.txt
and     = draft-ietf-avt-rtp-mime-04.txt

According to those drafts, it is legal to use payload = type 18 for Annex B
frames (indeed, that is the default). They also = define a parameter for use
in SDP a=3Dfmtp: lines to explicitly signal the = presence/absence of annex B
frames if that is necessary.

If there are problems with these definitions, they = should be brought to the
attention of the AVT working group, since the = revised profile is about to
be submitted for publication as a draft standard = RFC.

Colin




--> Manoj Bhatia writes:
>Hi
>
>The fact is that g.729 /g.729a  pair shall = not interoperate with
>g.729b/g.729ab.
>The static payload '18' defined so far is being = used for g.729/g.729a by
>
>SIP folks  .
>Some are now interested in using g.729b/g.729ab = pair for obvious
>advantages in
>VAD,DTX etc.
>
>So, my question is that why don't we have a = static payload defined for
>g.729b/g729ab
>pair just like we had '18' for the other = pair.
>
>Or is it legal to use '18' for this pair too = ?
>
>To avoid interop issues, can we lay down rules = to state that when to use
>'18' and when
>not to use '18' especially if a SIP-UA agent has = the ability to support
>'all' the four flavors of
>g729 and is interested in advertising that in = its SDP ?
>
>thanks
>-manoj
>
>
>Shawn Pouliotte wrote:
>
>>
>>
>> Hi
>>
>> -G.729 is CS-ACELP, an 8kbps speech Codec = (G.729r8)
>> -G.729a (G.729 Annex A) is a reduced = complexity version of G.729 and
>> is still an 8k voice Codec
>> -G.729b (G.729 Annex B) is a spec for Voice = Activity Detection (VAD),
>> Discontinuity Transmission (DTX), and = Comfort Noise Generation (CNG).
>> More simply stated, Annex B is silence = suppression for use with G.729
>> or G.729a voice codecs and is not a codec = in itself.
>>
>> G.729 and G.729a operate on a 10 mSec = speech frame corresponding to 80
>> samples at a rate of 8kbps. This yields an = 80bit speech fame every 10
>> mSec. If silence suppression etc. are used = (such as Annex B), the
>> frame length will vary. In the case of = annex B, SID frames are 15 bits
>> rather than 80 bits for a speech = frame.
>>
>> Hope that helps
>> Shawn
>>
>> -----Original Message-----
>> From: Gregory Paterno [mailto:Greg.Paterno@wcom.com]<= /FONT>
>> Sent: Thursday, July 05, 2001 12:08 = PM
>> To: Henning G. Schulzrinne
>> Cc: sankaran@cs.columbia.edu; = sip@lists.bell-labs.com
>> Subject: RE: [SIP] Re: Codecs G729 and = their various flavors
>>
>> "G.729 is silence suppression and = distinguishable by payload
>> length."
>>
>> Where could I find information on the = payload length supporting
>> silence suppression for G.711 and = G.729b?
>>
>> Thanks.
>>
>> -----Original Message-----
>> From: sip-admin@lists.bell-labs.com
>> [mailto:sip-admin@lists.bel= l-labs.com]On Behalf Of Henning G.
>> Schulzrinne
>> Sent: Thursday, July 05, 2001 11:36 = AM
>> To: akher@cisco.com
>> Cc: Kevin.Summers@ttimail.com; = smenon@sonusnet.com;
>> hgs@cs.columbia.edu;
>> sankaran@cs.columbia.edu; = sip@lists.bell-labs.com
>> Subject: [SIP] Re: Codecs G729 and their = various flavors
>>
>> Ameet Kher wrote:
>> >
>> > Hi
>> >
>> > I am trying to follow up on some = previous discussions on this
>> list
>> > about whether to use dynamic
>> > payload types for various flavors of = the G729 codec. Presently
>> the
>> > IANA list has defined a static payload = type
>> > and encoding name only for the G729r8 = codec. Should we be using
>> > dynamic payloads for G729b, G729ab, = G729a ?
>>
>> All new codecs only use dynamic payload = types.
>>
>> > And use X-* as encoding names ? I am = sure we cannot use the
>> same
>>
>> Using X-* is a certifiably bad idea. The = argument has been made
>> numerous
>> times on this list, but let me know if = you'd like another
>> rendition of
>> it.
>>
>> > static payload value (18) for all = these flavors.
>>
>> You can use the same payload type (doesn't = matter if static or
>> dynamic)
>> if the codecs are distinguishable by = looking at the payload.
>> G.729a is
>> just a reduced-complexity implementation, = that has the same bit
>> pattern,
>> so there doesn't seem to be a need for a = new payload type.
>>
>> G.729 is silence suppression and = distinguishable by payload
>> length.
>>
>> I have no idea what G.729ab would be; it is = not mentioned at
>> http://www.itu.int/itudoc/itu-t/rec/g/g700-799/index.h= tml
>>
>>
>> >
>> > - Ameet
>> >
>> >
>> >
>> > --
>> > ******************************
>> > AMEET KHER, Software Engineer
>> > Cisco Systems
>> > Tel : (919) 392-8431
>> >
>> >
>>
>> --
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>> = _______________________________________________
>> This list is for continuing development of = the SIP protocol.
>> The sip-implementor's list is the place to = discuss
>> implementation,
>> and to receive advice on understanding = existing sip.
>> To subscribe to it, send mail to
>> sip-implementors-request@cs.columbia.edu = with "subscribe" in the
>> body.
>>
>> = _______________________________________________
>> This list is for continuing development of = the SIP protocol.
>> The sip-implementor's list is the place to = discuss implementation,
>> and to receive advice on understanding = existing sip.
>> To subscribe to it, send mail to
>> sip-implementors-request@cs.columbia.edu = with "subscribe" in the body.
>
>--
>Manoj = Bhatia           =             =     |        = |         |
>manojb@cisco.com       &= nbsp;           &= nbsp;   |       = :|:       :|:
>7025 Kit Creek Road, RTP, NC - 27709   = |     :|||||:   :|||||:
>Ph: 919-392-3873  = Fax:919-392-6801     |  C i s c o S y s t e m = s

------_=_NextPart_001_01C10663.86253980-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Fri Jul 6 21:53:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26227 for ; Fri, 6 Jul 2001 21:53:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07662; Fri, 6 Jul 2001 21:34:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07631 for ; Fri, 6 Jul 2001 21:33:57 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25112 for ; Fri, 6 Jul 2001 21:33:09 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f671VOK12873; Fri, 6 Jul 2001 20:31:24 -0500 Message-ID: <011501c10684$66bd0d40$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: , References: <61D824C63B99D311975E00508B0CC985022518EA@eamrcnt717.exu.ericsson.se> Subject: Re: [Sip] Forking: a modest proposal. Date: Fri, 6 Jul 2001 20:30:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Well, I've made the less modest proposal before that forking could be removed entirely from the specification. It seems to be an unpopular suggestion in some quarters, but I like to bring it up before IETF meetings as a matter of tradition (and in hopes that someday certain critical parties will agree). Admittedly, most of you people are way brighter than me. But I find that the branches and tags and special cases and stuff introduced to make forking work regularly confuse my pointy little head, and seem to occasionally trip up other folks as well. It really makes me sweat every time I have to think about how a proposed extension will interact with forking, and in the Texas summer, extra perspiration could be dangerous. On the other hand I have to admit that I do USE forking all the time -- inbound calls to my phone hit a forking proxy and land on three SIP phones and my cell phone roughly simultaneously. But it also seems that what we desired from forking could be readily implemented as application logic without as much complexity in the core protocol, and I think such an application would meet my needs as a forking user (I've always wanted to say that about users). This would also allow forking-like behavior for new messages on an as-needed-by-application-logic basis. And acceptance of such a proposal would settle once and for all whether non-INVITE messages get forked. Any takers? -- Dean ----- Original Message ----- From: To: Sent: Monday, July 02, 2001 11:44 AM Subject: [Sip] Forking: a modest proposal. > I'm putting together the SUB/NOT draft (we should go into nits > on Monday), and am currently wrestling with the issue of forking. > > I have what I think is an elegant solution, given the immediate > NOTIFY mechanism that we have agreed on. Certain camps have objections > to this mechanism, and thinks that all but the first SUBSCRIBE should > be made to fail (by sending a 400 class response). I don't see this > difference of opinion as intractable, but it is something that will > take a considerable amount of time (discussion, work, etc) to reach > consensus. > > On reflection, I realize that this entire situation just highlights > a thorn we've had in our paw the entire time. > > Given that all transactions complete (basically) immediately (with > the exception of INVITEs), forking *any* non-INVITE request is just > a race waiting to happen. It usually just leads to heartburn when > you attempt to analyze how it's going to work with non-INVITE methods > (as in the SUBSCRIBE example). > > Since there seems to be a general feeling that all but the first > received request should "fail" in some general sense (usually by > the request initiator not finding out about the response), I'd > like to float a proposal: > > Deprecate forking of non-INVITEs. > > Despite my tongue-in-cheek subject line, I'm serious. > > SIP is not going to Draft Standard this time around, so maintaining > absolute compatibility with RFC 2543 isn't strictly required. No one > has come up with a useful application of forking non-INVITEs (except, > arguably, my proposal that a forked SUBSCRIBE can install several > subscriptions, with the subsequent NOTIFY messages establishing the > legs, routes, and contacts as necessary). Forking non-INVITEs adds > complexity to the protocol, extra work to all extensions, and > headaches all around. And as long as people insist that nothing useful > can come from forking anything but an INVITE, there is no gain to be > had by leaving this "feature" in the protocol. > > As long as it is understood at a general protocol level that forking > of non-INVITEs is disallowed, I have no problem rejecting the additional > NOTIFY legs we find out about. If we continue to pretend that forking > of non-INVITEs is a useful concept, I can't see the logic behind refusing > to allow successful forking of SUBSCRIBEs. > > Comments, etc, encouraged -- even if just to voice assent. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 23:01:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28223 for ; Fri, 6 Jul 2001 23:01:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09202; Fri, 6 Jul 2001 22:45:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09173 for ; Fri, 6 Jul 2001 22:45:12 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28071 for ; Fri, 6 Jul 2001 22:44:27 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA05922; Fri, 6 Jul 2001 22:45:11 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA27386; Fri, 6 Jul 2001 22:45:08 -0400 (EDT) Message-ID: <3B467771.5549104B@cs.columbia.edu> Date: Fri, 06 Jul 2001 22:44:01 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Gross, Gerhard" , "'bidulock@openss7.org'" , Jonathan Rosenberg , "'Rosen, Brian'" , "'Jiri Kuthan'" , Ashhar Farhan , "'sip@ietf.org'" Subject: Re: [SIP] Authentication and billing through proxy/re-direct server References: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com> <15160.43070.343030.890219@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Not to argue with the basic points made, but maybe some operational reality would help. I think it's worth remembering that different applications have different requirements. For example, in a PBX rebilling application, something that's within, say, 5% accurate is going to be good enough. For these applications, a TCP connection between proxy server and gateway, with restricted source address trust on the gateway, is in the "good enough" category. Also, speaking from experience, almost all small gateways don't have the ability to do authentication or call/packet-level accounting (and would be significantly more expensive or complicated if they did). Thus, you probably have a choice: spend $10k on a carrier-strength gateway or on occasion measure a phone call wrong by a few seconds. Given the cents/minute we're talking about, this seems like a fair trade-off. Ideally, even simple gateways would support at least some shared-secret authentication or IPsec. Many hotels measure calls starting N seconds after ringing, regardless of whether somebody picked up or not. Certainly not precise and allows "cheating", but in the scheme of things, not one of the major problems in the world. If the gateway is close to the accounting proxy server, packet loss is very unlikely. Accounting is like voting or audio equipment: beyond a certain limit of accuracy, costs grow exponentially and it's much better to accept that life isn't completely fair. In real life, we don't weigh mail for postage with the same precision as gold. Given that most calls are still metered on a minute-by-minute basis, random errors in the sub-minute range are not likely to be significant. It's probably much more important to have rough alarms in place, to, for example, catch if a call inadvertently never gets hung up or some fraud is in progress. Michael Thomas wrote: > > As Jonathan points out, this is trivially defrauded. > > The rule is simple: if you don't see the begin/end > of the actual media stream (either directly or > through some router that controls, say, QoS > resources), or whatever other kind of session you In almost all cases, what matters is not the media stream, but the PSTN signaling, since that determines the actual cost of call termination and out-of-pocket expenses to other providers. It doesn't matter whether the caller was talking or silent the whole time. > might be basing session duration based billing on, > then you are just whistling in the dark. Moving > the call statefulness to a PDP only obfuscates > which box got defrauded. > > Mike > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 6 23:27:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28540 for ; Fri, 6 Jul 2001 23:27:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09908; Fri, 6 Jul 2001 23:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09876 for ; Fri, 6 Jul 2001 23:11:58 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28318 for ; Fri, 6 Jul 2001 23:11:13 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA06657; Fri, 6 Jul 2001 23:11:59 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id XAA27456; Fri, 6 Jul 2001 23:11:57 -0400 (EDT) Message-ID: <3B467DB6.417834D9@cs.columbia.edu> Date: Fri, 06 Jul 2001 23:10:46 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: adam.roach@ericsson.com, sip@ietf.org Subject: Re: [Sip] Forking: a modest proposal. References: <61D824C63B99D311975E00508B0CC985022518EA@eamrcnt717.exu.ericsson.se> <011501c10684$66bd0d40$ee036e3f@dfw.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Well, I've made the less modest proposal before that forking could be > removed entirely from the specification. It seems to be an unpopular > suggestion in some quarters, but I like to bring it up before IETF meetings > as a matter of tradition (and in hopes that someday certain critical parties > will agree). > > Admittedly, most of you people are way brighter than me. But I find that the > branches and tags and special cases and stuff introduced to make forking > work regularly confuse my pointy little head, and seem to occasionally trip > up other folks as well. It really makes me sweat every time I have to think > about how a proposed extension will interact with forking, and in the Texas > summer, extra perspiration could be dangerous. > > On the other hand I have to admit that I do USE forking all the time -- > inbound calls to my phone hit a forking proxy and land on three SIP phones > and my cell phone roughly simultaneously. > > But it also seems that what we desired from forking could be readily > implemented as application logic without as much complexity in the core > protocol, and I think such an application would meet my needs as a forking > user (I've always wanted to say that about users). This would also allow > forking-like behavior for new messages on an as-needed-by-application-logic > basis. And acceptance of such a proposal would settle once and for all > whether non-INVITE messages get forked. > The problem is that once you implement "forking" at the B2B-UA level, you also need loop detection and most of the other features and pretty soon, you'll be back to where we started, one layer up, except that every system will implement them differently. It may well be that splitting them across two layers would've been the right thing, but I doubt that the overall system would be less complex. (I agree that tags could be avoided if the B2BUA uses, say, a new call-ID for each branch.) Some of the complexities are due to the desire to keep proxies call stateless. If you are willing to make them call stateful, things like multiple 200 can probably be avoided. Again, a trade-off with some cost. Thus, I think this is a far more complex trade-off. Without a complete design of the alternatives, I'm afraid that we'd be deluding us in terms of overall system complexity. Even email has various forking problems, even though the "branches" are completely independent, as the usual complaints about vacation emails and confirmation receipts (think of them as multiple final responses..) show. I agree that for most messages (such as MESSAGE), forking-like behavior is much more like an email reflector and should be treated as such, invisible to the sender. Henning _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 7 00:39:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29702 for ; Sat, 7 Jul 2001 00:39:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11482; Sat, 7 Jul 2001 00:10:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA11456 for ; Sat, 7 Jul 2001 00:10:48 -0400 (EDT) Received: from mailweb15.rediffmail.com (IDENT:qmailr@[203.199.83.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29335 for ; Sat, 7 Jul 2001 00:10:02 -0400 (EDT) Received: (qmail 17763 invoked by uid 510); 7 Jul 2001 04:12:56 -0000 Date: 7 Jul 2001 04:12:56 -0000 Message-ID: <20010707041256.17762.qmail@mailweb15.rediffmail.com> Received: from unknown (203.197.251.12) by rediffmail.com via HTTP; 07 Jul 2001 04:12:56 -0000 MIME-Version: 1.0 To: "schulzrinne@cs.columbia.edu" , "mat@cisco.com" Subject: [SIP] Authentication and billing through proxy/re-direct server CC: "gerhard.gross@intel.com" , "bidulock@openss7.org" , "jdrosen@dynamicsoft.com" , "Brian.Rosen@marconi.com" , "kuthan@fokus.gmd.de" , "sip@ietf.org" From: "Ashhar Farhan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit by now, it is well understood that some sort of recording of the calls made by a third party call-logging system is a requirement for many operative networks. therefore we need a way of propagating CDRs to a remote entity. for this, we have three options available to us: 1) introduce a new type of request message. 2) use NOTIFY with CDR in the body. 3) use MESSAGE with CDR in the body. my personaly preference will be to NOTIFY the remote call-logger. this is the simpler part of the issue. about authentication: authentication of a client with the gateway is a requirement. this requirement is not necessarily for the purposes of billing. for instance, an enterprise gateway may want to provide access to only certain caller. or a personal gateway run at home over the DSL where only some are allowed to call. at all these times, the gateway needs to authenticate the caller without any secret-sharing between them. therefore, there is a clear need for the participation of the registrar or some other authenticating service to do this. if A calls B. B asks C is A real? C says yes because i have his secret. while we could demand that the callers obtain their PGP keys, this is not a workable solution. we need a simple, effective solution for this within the SIP functionality (correct me if i am wrong on this). my suggestions are like this: 1) Caller A issues an INVITE for the gateway to the proxy server. 2) proxy server challenges A, receives the correct response. 3) proxy server now proxies the INVITE to the gateway with no authentication. 4) gateway challenges the proxy. proxy responds back with the digest over the message headers, gateway password and the nonce issued by the gateway (as described in the SIP RFC). the second scheme is completely within the SIP framework. i wonder if a stateless implementation of this scheme is possible. ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Sat Jul 7 01:43:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02321 for ; Sat, 7 Jul 2001 01:43:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AD3944337; Sat, 7 Jul 2001 01:44:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104]) by lists.bell-labs.com (Postfix) with ESMTP id 3D4C744336 for ; Sat, 7 Jul 2001 01:43:06 -0400 (EDT) Received: from softgear ([203.253.3.209]) by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f675Xak18544 for ; Sat, 7 Jul 2001 14:33:36 +0900 (KST) From: "Softgear Ko" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: [SIP] reserve bandwidth for codec Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Jul 2001 14:44:29 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA02321 Hello. I have read draft-manyfolks-sip-resource-01.txt. After UA received sdp with qos, UA will try to reserve network resource with RSVP. Because RSVP do reservation with Token bucket parameters, We must know bandwidth or token bucket parameters for each codec. Where can I get more information about this? Thanks. Softgear KoÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ From sip-admin@ietf.org Sat Jul 7 04:13:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16669 for ; Sat, 7 Jul 2001 04:13:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24974; Sat, 7 Jul 2001 04:06:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24942 for ; Sat, 7 Jul 2001 04:06:30 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16634 for ; Sat, 7 Jul 2001 04:05:45 -0400 (EDT) Received: from blazer (dwillis4.directlink.net [63.64.250.85]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6784eK13279; Sat, 7 Jul 2001 03:04:40 -0500 Message-ID: <002101c106bb$b384a430$01000001@blazer> From: "Dean Willis" To: , , "Ashhar Farhan" Cc: , , , , , References: <20010707041256.17762.qmail@mailweb15.rediffmail.com> Subject: Re: [SIP] Authentication and billing through proxy/re-direct server Date: Sat, 7 Jul 2001 03:06:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Fourth choice -- use one of the many AAA protocols like AAA or DIAMETER that is currently used to deliver CDRs. -- Dean ----- Original Message ----- From: "Ashhar Farhan" To: ; Cc: ; ; ; ; ; Sent: Friday, July 06, 2001 11:12 PM Subject: [SIP] Authentication and billing through proxy/re-direct server > by now, it is well understood that some sort of recording of the calls made by a third party call-logging system is a requirement for many operative networks. therefore we need a way of propagating CDRs to a remote entity. > for this, we have three options available to us: > 1) introduce a new type of request message. > 2) use NOTIFY with CDR in the body. > 3) use MESSAGE with CDR in the body. > my personaly preference will be to NOTIFY the remote call-logger. > this is the simpler part of the issue. > > about authentication: > authentication of a client with the gateway is a requirement. this requirement is not necessarily for the purposes of billing. for instance, an enterprise gateway may want to provide access to only certain caller. or a personal gateway run at home over the DSL where only some are allowed to call. > > at all these times, the gateway needs to authenticate the caller without any secret-sharing between them. therefore, there is a clear need for the participation of the registrar or some other authenticating service to do this. > if A calls B. B asks C is A real? C says yes because i have his secret. > > while we could demand that the callers obtain their PGP keys, this is not a workable solution. we need a simple, effective solution for this within the SIP functionality (correct me if i am wrong on this). > > my suggestions are like this: > > 1) Caller A issues an INVITE for the gateway to the proxy server. > 2) proxy server challenges A, receives the correct response. > 3) proxy server now proxies the INVITE to the gateway with no authentication. > 4) gateway challenges the proxy. proxy responds back with the digest over the message headers, gateway password and the nonce issued by the gateway (as described in the SIP RFC). > > the second scheme is completely within the SIP framework. i wonder if a stateless implementation of this scheme is possible. > > > ____________________________________________________ > Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Sat Jul 7 12:54:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20271 for ; Sat, 7 Jul 2001 12:54:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47C3044337; Sat, 7 Jul 2001 12:55:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cgpro.iccx.net (webmail.iccx.net [166.93.205.11]) by lists.bell-labs.com (Postfix) with ESMTP id E7B0044336 for ; Sat, 7 Jul 2001 12:54:34 -0400 (EDT) Received: from [166.93.76.151] (HELO hasher99) by cgpro.iccx.net (CommuniGate Pro SMTP 3.4.6) with ESMTP id 62438360; Sat, 07 Jul 2001 10:54:24 -0600 Reply-To: From: "Michel A. Maddux" To: "'Wai Wu'" , "'Hidefumi Nakamura'" , Subject: RE: [SIP] Congestion control Message-ID: <000301c10705$7224a680$194c5da6@cxo.dec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C106D3.278A3680" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <60A9CA50081AD4118BD60040F60C1A9F0A3DC8@NT-SERVER> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 7 Jul 2001 10:54:09 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C106D3.278A3680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [SIP] Congestion control -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Wai Wu Sent: Friday, June 22, 2001 11:16 AM To: 'Hidefumi Nakamura'; sip@lists.bell-labs.com Subject: RE: [SIP] Congestion control "but what should "proxy A" do if it receives other INVITE messages for proxyB, say, from UAc, within the period indicated in "retry-after" field? Should proxy-A send "503" to UAc or transfer the INVITE message to proxy-B even if proxy-A already has the information that proxy-B is in congestion?" Wai writes: >> In my implementation, proxy A still forwards the INVITE message to proxy-B for UAc. This is so since the UA the UAc is trying to contact might very well be different from that of UAa. Take the example of proxy-B forwards the request to two different PSTN gateway, one for local calls and the other for international calls. The international all gateway might be down but not the local call gateway. ===== I concur. Proxy A should send the INVITE anyway, as the congestion or cause of the 503 retry condition is most likely a transient condition. There is no way to predict in advance whether the congestion has cleared prior to the INVITE; to assume this knowledge and allow proxy A to send a 503 is an error. thanks. /m. ------=_NextPart_000_0004_01C106D3.278A3680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Congestion control
 
-----Original Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On=20 Behalf Of Wai Wu
Sent: Friday, June 22, 2001 11:16=20 AM
To: 'Hidefumi Nakamura';=20 sip@lists.bell-labs.com
Subject: RE: [SIP] Congestion=20 control

"but what should "proxy A"
do if it=20 receives other INVITE messages for proxyB, say, from UAc, = within=20
the period indicated in "retry-after" field? =
Should proxy-A send "503" to UAc or transfer the INVITE = message=20
to proxy-B even if proxy-A already has the = information that=20 proxy-B
is in congestion?"  

Wai=20 writes: 

 >> In my = implementation, proxy A=20 still forwards the INVITE message to proxy-B for UAc. This is so since = the UA=20 the UAc is trying  to contact might very well be = different from=20 that of UAa. Take the example of proxy-B forwards the request to two = different=20 PSTN gateway, one for local calls and the other for international = calls. The=20 international all gateway might be down but not the local call=20 gateway.  

=3D=3D=3D=3D=3D

I=20 concur.  Proxy A should send the INVITE anyway, as the congestion = or=20 cause of the 503 retry condition is most likely a transient = condition. =20 There is no way to predict in advance whether the congestion has = cleared prior=20 to the INVITE; to assume this knowledge and allow proxy A to send a = 503 is an=20 error. thanks. /m.

 

 

------=_NextPart_000_0004_01C106D3.278A3680-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@ietf.org Sat Jul 7 23:37:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27230 for ; Sat, 7 Jul 2001 23:37:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21313; Sat, 7 Jul 2001 23:32:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21286 for ; Sat, 7 Jul 2001 23:32:34 -0400 (EDT) Received: from yourwebsite.com (cd-179-62.ra30.dc.capu.net [64.50.179.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27176 for ; Sat, 7 Jul 2001 23:31:46 -0400 (EDT) From: lprice@capu.net Message-Id: <200107080331.XAA27176@ietf.org> Reply-To: lprice@capu.net To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 7 Jul 2001 23:28:22 -0400 Subject: [Sip] Ride the Wave of Success!!/FREE MEMBERSHIP!!! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org JOIN NOW FOR FREE!!! SERIOUS ONLINE INCOME: NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS We are a FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER 60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.; THE MEMBERSHIP IS FREE at. http://onlineprofits.50megs.com. . Enter your first and last name and email address. Afterwards you will start recieving various emails about company and the business opportunity. Also, you will become a FREE MEMBER and you can START SHOPPING from at least 70 brand name online stores and BE ENTERED in our monthly $100 shopping spree!. Take your time and review our company's benefits and opportunities. . GUARANTEED minimum commission every month . you can get 200 members a month added to you downline . Free Software . and a strong team support Now remember anybody that signs up after you will be in your downline. This is very important if you want join our company and get a monthly check. Don't pass this one up. GET YOUR FREE MEMBERSHIP AT: http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton. We will talk soon, GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 12:37:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20925 for ; Mon, 9 Jul 2001 12:37:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01300; Mon, 9 Jul 2001 12:13:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01271 for ; Mon, 9 Jul 2001 12:13:13 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19957 for ; Mon, 9 Jul 2001 12:12:24 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f69GDBp26351; Mon, 9 Jul 2001 11:13:11 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f69GDAS25113; Mon, 9 Jul 2001 11:13:10 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA07465; Mon, 9 Jul 2001 11:13:10 -0500 (CDT) Reply-To: To: "'Henning Schulzrinne'" , "Dean Willis" Cc: , Subject: RE: [Sip] Forking: a modest proposal. Date: Mon, 9 Jul 2001 11:13:09 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225190E@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <3B467DB6.417834D9@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > The problem is that once you implement "forking" at the B2B-UA level, > you also need loop detection and most of the other features and pretty > soon, you'll be back to where we started, one layer up, except that > every system will implement them differently. It may well be that > splitting them across two layers would've been the right thing, but I > doubt that the overall system would be less complex. (I agree > that tags > could be avoided if the B2BUA uses, say, a new call-ID for > each branch.) I think it would be far less complex, since it doesn't impact every silly little detail of every single extension. By making it an application on top of the protocol, it becomes an issue for the application designer. By and large, such a designer will be able to make reasonable decisions, like: "I have no idea what method XYZZY means, so forking it would be absurd." Currently, since it is part of the spec, forking proxies will say "XYZZY is just a method. I'm method agnostic. I'll fork it!" I'm 100% behind Dean's proposal, and would be interested to see how, say, a hum vote on the topic would turn out. Can we have a short rant on this topic in London followed by a poll for rough consensus? /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 13:14:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22266 for ; Mon, 9 Jul 2001 13:14:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02587; Mon, 9 Jul 2001 12:51:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02553 for ; Mon, 9 Jul 2001 12:51:06 -0400 (EDT) Received: from imr2.ericy.com ([12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21396 for ; Mon, 9 Jul 2001 12:50:18 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f69GoB526555 for ; Mon, 9 Jul 2001 11:50:11 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f69GoBc26028 for ; Mon, 9 Jul 2001 11:50:11 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jul 09 11:50:10 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJXFTD>; Mon, 9 Jul 2001 11:50:10 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'sip@ietf.org'" Date: Mon, 9 Jul 2001 11:50:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10897.336697D0" Subject: [Sip] Encryption negotiation? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10897.336697D0 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a simple question but I've been unable to find an answer in the spec, FAQ, or mailing list archives (though I may have overlooked something obvious). When using the Encryption: header in a request, is there a way for the UAS to reject the request *and* indicate that the request was rejected because the UAS was unable to decrypt the body? Should a warning header be used? What about an option tag for encryption? (i.e. is there a way to negotiate support of encryption?) I would expect that many implementations that don't support encryption might return something like a 415 or a 400. Any comments? Sean Olson Ericsson Inc. sean.olson@ericsson.com ------_=_NextPart_001_01C10897.336697D0 Content-Type: text/html; charset="iso-8859-1" Encryption negotiation?

Hi,

I have a simple question but I've been unable
to find an answer in the spec, FAQ, or mailing
list archives (though I may have overlooked
something obvious).

When using the Encryption: header in a request,
is there a way for the UAS to reject the request
*and* indicate that the request was rejected because
the UAS was unable to decrypt the body? Should a
warning header be used? What about an option tag
for encryption? (i.e. is there a way to negotiate
support of encryption?) I would expect that many
implementations that don't support encryption
might return something like a 415 or a 400.

Any comments?

Sean Olson
Ericsson Inc.
sean.olson@ericsson.com

------_=_NextPart_001_01C10897.336697D0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 17:37:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29165 for ; Mon, 9 Jul 2001 17:37:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10909; Mon, 9 Jul 2001 17:05:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10879 for ; Mon, 9 Jul 2001 17:05:04 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28606 for ; Mon, 9 Jul 2001 17:04:15 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f69L4Wh16782 for ; Mon, 9 Jul 2001 14:04:32 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f69L4Vg19030 for ; Mon, 9 Jul 2001 14:04:32 -0700 (PDT) Received: from CHSHARP-W2K1.cisco.com (rtp-vpn-144.cisco.com [10.82.192.144]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA20122 for ; Mon, 9 Jul 2001 14:04:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20010709164939.01e8c390@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 17:04:18 -0400 To: sip@ietf.org From: Chip Sharp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The following production is in Appendix C: escaped = "%" hex hex HEX is capitalized in its production. While this is legal according to RFC2234, is it possible to use the same case? I assume this is academic, but why include Appendix C instead of referencing RFC2234 and listing the exceptions/additions? Why use "|" for alternatives instead of the "/" defined in RFC2234? Thanks, Chip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 19:46:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01342 for ; Mon, 9 Jul 2001 19:46:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14948; Mon, 9 Jul 2001 19:28:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14919 for ; Mon, 9 Jul 2001 19:28:34 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01021 for ; Mon, 9 Jul 2001 19:27:46 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f69NUYP22879 for ; Mon, 9 Jul 2001 19:30:34 -0400 Message-Id: <5.1.0.14.2.20010709191355.02c14ec0@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 19:24:05 -0400 To: sip@ietf.org From: Jay Batson Subject: Re: [Sip] Forking: a modest proposal. In-Reply-To: <3B467DB6.417834D9@cs.columbia.edu> References: <61D824C63B99D311975E00508B0CC985022518EA@eamrcnt717.exu.ericsson.se> <011501c10684$66bd0d40$ee036e3f@dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_293746905==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_293746905==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:10 PM 7/6/01, Henning Schulzrinne wrote: >The problem is that once you implement "forking" at the B2B-UA level, >you also need loop detection and most of the other features and pretty >soon, you'll be back to where we started, one layer up, except that >every system will implement them differently. It may well be that >splitting them across two layers would've been the right thing, but I >doubt that the overall system would be less complex. (I agree that tags >could be avoided if the B2BUA uses, say, a new call-ID for each branch.) Of course, *that* problem could be solved by deprecating B2BUAs, which are truly and deeply evil IMHO.... Watching the list from afar as I do, I observe that there is a significant and growing temptation to fall back on doing everything via B2BUAs now, less and less of a discipline to force things into the proxy/server model, with the resulting behavior / architecture starting to feel more and more like Megaco. This is a bad thing. On the Forking topic, since I'm so far removed from true engineering, I thought forking *was* an application behavior, and not a part of the protocol. So despite the fact that my opinion shouldn't count for much 'cause I'm not rigorously informed or thinking as rigorously about it as I should, I'd probably take Adam up on his notion to keep forking at the application level. Comments from an anarchist who has more of a vested interest in the edge than the middle.... -jb ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) --=====================_293746905==_.ALT Content-Type: text/html; charset="us-ascii" At 11:10 PM 7/6/01, Henning Schulzrinne wrote:
The problem is that once you implement "forking" at the B2B-UA level,
you also need loop detection and most of the other features and pretty
soon, you'll be back to where we started, one layer up, except that
every system will implement them differently. It may well be that
splitting them across two layers would've been the right thing, but I
doubt that the overall system would be less complex. (I agree that tags
could be avoided if the B2BUA uses, say, a new call-ID for each branch.)


Of course, *that* problem could be solved by deprecating B2BUAs, which are truly and deeply evil IMHO....  Watching the list from afar as I do, I observe that there is a significant and growing temptation to fall back on doing everything via B2BUAs now, less and less of a discipline to force things into the proxy/server model, with the resulting behavior / architecture starting to feel more and more like Megaco.  This is a bad thing.

On the Forking topic, since I'm so far removed from true engineering, I thought forking *was* an application behavior, and not a part of the protocol.  So despite the fact that my opinion shouldn't count for much 'cause I'm not rigorously informed or thinking as rigorously about it as I should, I'd probably take Adam up on his notion to keep forking at the application level.

Comments from an anarchist who has more of a vested interest in the edge than the middle....
-jb

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:jbatson@pingtel.com
781-938-5306 (office)

--=====================_293746905==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 21:06:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02816 for ; Mon, 9 Jul 2001 21:06:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16425; Mon, 9 Jul 2001 20:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16396 for ; Mon, 9 Jul 2001 20:27:18 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02192 for ; Mon, 9 Jul 2001 20:26:29 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA05216; Mon, 9 Jul 2001 20:27:15 -0400 (EDT) Message-ID: <3B4A4BE2.C90949E5@cs.columbia.edu> Date: Mon, 09 Jul 2001 20:27:14 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Chip Sharp CC: sip@ietf.org Subject: Re: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt References: <4.3.2.7.2.20010709164939.01e8c390@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chip Sharp wrote: > > The following production is in Appendix C: > escaped = "%" hex hex > > HEX is capitalized in its production. While this is legal according to > RFC2234, is it possible to use the same case? Yes, this should be consistent. > > I assume this is academic, but why include Appendix C instead of > referencing RFC2234 and listing the exceptions/additions? Why use "|" for > alternatives instead of the "/" defined in RFC2234? > This is annoying, but since rfc2534bis inherits definitions from RFC 2068 (HTTP/1.1), which does not quite use RFC 2234, we can either - use RFC 2234 and remove all references in syntax to RFC 2068 - keep the | notation (and a few other modifications relative to 2234) from RFC 2068 Beyond the / vs. |, the major difference is that RFC 2234 is a character-oriented grammar, while SIP (and HTTP) use a word-oriented grammar. We'd have to add a lot of LWSP everywhere in the grammar, basically between every token, as in Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM becomes Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM and more complicated grammars become even messier. I'm not convinced that this visual noise aids understanding, but there may be other reasons to do this. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 9 23:41:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06691 for ; Mon, 9 Jul 2001 23:41:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20898; Mon, 9 Jul 2001 23:23:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20867 for ; Mon, 9 Jul 2001 23:23:19 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06123 for ; Mon, 9 Jul 2001 23:22:31 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6A3NJO02017 for ; Mon, 9 Jul 2001 23:23:19 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6A3NJj01998 for ; Mon, 9 Jul 2001 23:23:19 -0400 (EDT) Received: by IL0015EXCH001H with Internet Mail Service (5.5.2650.21) id <3MSJD2LQ>; Mon, 9 Jul 2001 22:25:01 -0500 Message-ID: From: "Dolan, Michael F (Mike)" To: Ashhar Farhan , schulzrinne@cs.columbia.edu, mat@cisco.com Cc: gerhard.gross@intel.com, bidulock@openss7.org, jdrosen@dynamicsoft.com, Brian.Rosen@marconi.com, kuthan@fokus.gmd.de, sip@ietf.org Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er Date: Mon, 9 Jul 2001 22:23:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ashhar, 3GPP2 is planning to use DIAMETER to capture and share such call record data across system boundaries. The AAA broker approach works well in this application. Is it necessary to re-create that entire mechanism in SIP as well (along with proper authentication, etc.)? Mike Dolan Lucent Technologies - Bell Labs 263 Shuman Blvd., Room 2D-229 Naperville, IL 60566-7050, USA * Office: +1.630.979.1033 * Mobile: +1.630.697.3549 * Email: mfdolan@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Ashhar Farhan [mailto:afarhan@rediffmail.com] Sent: Friday, July 06, 2001 11:13 PM To: schulzrinne@cs.columbia.edu; mat@cisco.com Cc: gerhard.gross@intel.com; bidulock@openss7.org; jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com; kuthan@fokus.gmd.de; sip@ietf.org Subject: [SIP] Authentication and billing through proxy/re-direct server by now, it is well understood that some sort of recording of the calls made by a third party call-logging system is a requirement for many operative networks. therefore we need a way of propagating CDRs to a remote entity. for this, we have three options available to us: 1) introduce a new type of request message. 2) use NOTIFY with CDR in the body. 3) use MESSAGE with CDR in the body. my personaly preference will be to NOTIFY the remote call-logger. this is the simpler part of the issue. about authentication: authentication of a client with the gateway is a requirement. this requirement is not necessarily for the purposes of billing. for instance, an enterprise gateway may want to provide access to only certain caller. or a personal gateway run at home over the DSL where only some are allowed to call. at all these times, the gateway needs to authenticate the caller without any secret-sharing between them. therefore, there is a clear need for the participation of the registrar or some other authenticating service to do this. if A calls B. B asks C is A real? C says yes because i have his secret. while we could demand that the callers obtain their PGP keys, this is not a workable solution. we need a simple, effective solution for this within the SIP functionality (correct me if i am wrong on this). my suggestions are like this: 1) Caller A issues an INVITE for the gateway to the proxy server. 2) proxy server challenges A, receives the correct response. 3) proxy server now proxies the INVITE to the gateway with no authentication. 4) gateway challenges the proxy. proxy responds back with the digest over the message headers, gateway password and the nonce issued by the gateway (as described in the SIP RFC). the second scheme is completely within the SIP framework. i wonder if a stateless implementation of this scheme is possible. ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@lists.bell-labs.com Tue Jul 10 04:35:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25385 for ; Tue, 10 Jul 2001 04:35:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9B7244355; Tue, 10 Jul 2001 04:36:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104]) by lists.bell-labs.com (Postfix) with ESMTP id 1811D44337 for ; Tue, 10 Jul 2001 04:35:25 -0400 (EDT) Received: from softgear ([203.253.3.209]) by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f6A8Q1k07289 for ; Tue, 10 Jul 2001 17:26:01 +0900 (KST) From: "Softgear Ko" To: "sip@lists.bell-labs.c" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Subject: [SIP] RSVP and SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 10 Jul 2001 17:36:25 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA25385 Hello. I have asked similar question before. But I have not received any answer. Draft-manyfolks-sip-resource-01.txt is saying that UA can reserve resource using RSVP. But Sdp doesn't send detail information about reservation. Basically, RSVP requires Tspec(r,b,p,m,M) even if Controlled load service case. SDP informs kind of codec and direction only. Because we can't know how many sample is in one IP packet from SIP or SDP, It is hard to determine Tspec or Reservation Spec exactly. I think that draft-manyfolks-sip-resource-01.txt or other draft must consider this issue. Thanks. Softgear. ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ From sip-admin@ietf.org Tue Jul 10 06:12:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26126 for ; Tue, 10 Jul 2001 06:12:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09298; Tue, 10 Jul 2001 05:47:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09242 for ; Tue, 10 Jul 2001 05:46:45 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25972 for ; Tue, 10 Jul 2001 05:45:49 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51L6W8>; Tue, 10 Jul 2001 02:45:44 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning G. Schulzrinne'" , Chip Sharp Cc: sip@ietf.org Subject: RE: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt Date: Tue, 10 Jul 2001 02:45:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Beyond the / vs. |, the major difference is that RFC 2234 is a > character-oriented grammar, while SIP (and HTTP) use a word-oriented > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > basically between every token, as in > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > becomes > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > and more complicated grammars become even messier. I'm not convinced > that this visual noise aids understanding, but there may be other > reasons to do this. Well just to stir the pot a little ...... isn't LWS only allowed on the right hand side of the colon and not on the left. Robert. > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 10, 2001 1:27 AM > To: Chip Sharp > Cc: sip@ietf.org > Subject: Re: [Sip] ABNF comment/nit on > draft-ietf-sip-rfc2543bis-03.txt > > > Chip Sharp wrote: > > > > The following production is in Appendix C: > > escaped = "%" hex hex > > > > HEX is capitalized in its production. While this is legal > according to > > RFC2234, is it possible to use the same case? > > Yes, this should be consistent. > > > > > I assume this is academic, but why include Appendix C instead of > > referencing RFC2234 and listing the exceptions/additions? > Why use "|" for > > alternatives instead of the "/" defined in RFC2234? > > > > This is annoying, but since rfc2534bis inherits definitions from RFC > 2068 (HTTP/1.1), which does not quite use RFC 2234, we can either > > - use RFC 2234 and remove all references in syntax to RFC 2068 > > - keep the | notation (and a few other modifications relative to 2234) > from RFC 2068 > > Beyond the / vs. |, the major difference is that RFC 2234 is a > character-oriented grammar, while SIP (and HTTP) use a word-oriented > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > basically between every token, as in > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > becomes > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > and more complicated grammars become even messier. I'm not convinced > that this visual noise aids understanding, but there may be other > reasons to do this. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 08:39:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27746 for ; Tue, 10 Jul 2001 08:39:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13433; Tue, 10 Jul 2001 08:07:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12658 for ; Tue, 10 Jul 2001 07:39:18 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26908 for ; Tue, 10 Jul 2001 07:38:28 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GG900HJO9OLNM@firewall.mcit.com> for sip@ietf.org; Tue, 10 Jul 2001 11:38:45 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GG9001019OKZX@dgismtp02.wcomnet.com>; Tue, 10 Jul 2001 11:38:45 +0000 (GMT) Received: from hsinnreich ([166.42.32.54]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GG900M8E9O7VX@dgismtp02.wcomnet.com>; Tue, 10 Jul 2001 11:38:32 +0000 (GMT) Date: Tue, 10 Jul 2001 06:38:31 -0500 From: Henry Sinnreich Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er In-reply-to: To: "Dolan, Michael F (Mike)" , Ashhar Farhan , schulzrinne@cs.columbia.edu, mat@cisco.com Cc: gerhard.gross@intel.com, bidulock@openss7.org, jdrosen@dynamicsoft.com, Brian.Rosen@marconi.com, kuthan@fokus.gmd.de, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >3GPP2 is planning to use DIAMETER Other approaches at the AAA level such as using XML/SSL may be preferable to Diameter. Diameter would certainly make a very poor application policy server - see . AAA should not be burdened with legacy from dial-up, but rather fit into the W3C web services architecture. What do you think? Thanks, Henry -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Dolan, Michael F (Mike) Sent: Monday, July 09, 2001 10:23 PM To: Ashhar Farhan; schulzrinne@cs.columbia.edu; mat@cisco.com Cc: gerhard.gross@intel.com; bidulock@openss7.org; jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com; kuthan@fokus.gmd.de; sip@ietf.org Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er Ashhar, 3GPP2 is planning to use DIAMETER to capture and share such call record data across system boundaries. The AAA broker approach works well in this application. Is it necessary to re-create that entire mechanism in SIP as well (along with proper authentication, etc.)? Mike Dolan Lucent Technologies - Bell Labs 263 Shuman Blvd., Room 2D-229 Naperville, IL 60566-7050, USA * Office: +1.630.979.1033 * Mobile: +1.630.697.3549 * Email: mfdolan@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Ashhar Farhan [mailto:afarhan@rediffmail.com] Sent: Friday, July 06, 2001 11:13 PM To: schulzrinne@cs.columbia.edu; mat@cisco.com Cc: gerhard.gross@intel.com; bidulock@openss7.org; jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com; kuthan@fokus.gmd.de; sip@ietf.org Subject: [SIP] Authentication and billing through proxy/re-direct server by now, it is well understood that some sort of recording of the calls made by a third party call-logging system is a requirement for many operative networks. therefore we need a way of propagating CDRs to a remote entity. for this, we have three options available to us: 1) introduce a new type of request message. 2) use NOTIFY with CDR in the body. 3) use MESSAGE with CDR in the body. my personaly preference will be to NOTIFY the remote call-logger. this is the simpler part of the issue. about authentication: authentication of a client with the gateway is a requirement. this requirement is not necessarily for the purposes of billing. for instance, an enterprise gateway may want to provide access to only certain caller. or a personal gateway run at home over the DSL where only some are allowed to call. at all these times, the gateway needs to authenticate the caller without any secret-sharing between them. therefore, there is a clear need for the participation of the registrar or some other authenticating service to do this. if A calls B. B asks C is A real? C says yes because i have his secret. while we could demand that the callers obtain their PGP keys, this is not a workable solution. we need a simple, effective solution for this within the SIP functionality (correct me if i am wrong on this). my suggestions are like this: 1) Caller A issues an INVITE for the gateway to the proxy server. 2) proxy server challenges A, receives the correct response. 3) proxy server now proxies the INVITE to the gateway with no authentication. 4) gateway challenges the proxy. proxy responds back with the digest over the message headers, gateway password and the nonce issued by the gateway (as described in the SIP RFC). the second scheme is completely within the SIP framework. i wonder if a stateless implementation of this scheme is possible. ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 08:39:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27766 for ; Tue, 10 Jul 2001 08:39:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13377; Tue, 10 Jul 2001 08:06:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08207 for ; Tue, 10 Jul 2001 05:07:03 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25656 for ; Tue, 10 Jul 2001 05:06:11 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6A96xN26379 for ; Tue, 10 Jul 2001 11:06:59 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Tue Jul 10 11:06:59 2001 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 11:06:58 +0200 Message-ID: <7BA41B5547CCD411833B0002A52CD45703728251@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Dolan, Michael F (Mike)'" , Ashhar Farhan , schulzrinne@cs.columbia.edu, mat@cisco.com Cc: gerhard.gross@intel.com, bidulock@openss7.org, jdrosen@dynamicsoft.com, Brian.Rosen@marconi.com, kuthan@fokus.gmd.de, sip@ietf.org Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er Date: Tue, 10 Jul 2001 11:06:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mike, That is indeed a good question. I personally like the fact of SIP and an OSP-token or some other token. Let a seperate node decide the policy and the permissions. Such a node can also be used for AAA functionality linked via DIAMETER etc. What SIP can do is sending an MESSAGE with additional information that is necessary for accounting, eg start time of a session and perhaps another to indicate the end-time and perhaps the selected QoS class etc. But this would be more as an addition and not to replace the current systems for AAA. Maybe for real-time accounting? Then an operator gets an indication of the possible charges of a call and can see whether the user has enough credit on the account. And the AAA systems will sent the CDR and other acounting information at a later time.(the latter may be slow when you are a roaming mobile caller). I haven't had any time yet to look deeper into this matter. Personally I like to get an indication of cost immediately when I place a call, it doesn't have to be 100% correct. But that are my own 2 cents. Arnoud van Wijk _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk Innovation Unit Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Dolan, Michael F (Mike) [mailto:mfdolan@lucent.com] Sent: dinsdag 10 jul 2001 5:23 To: Ashhar Farhan; schulzrinne@cs.columbia.edu; mat@cisco.com Cc: gerhard.gross@intel.com; bidulock@openss7.org; jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com; kuthan@fokus.gmd.de; sip@ietf.org Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er Ashhar, 3GPP2 is planning to use DIAMETER to capture and share such call record data across system boundaries. The AAA broker approach works well in this application. Is it necessary to re-create that entire mechanism in SIP as well (along with proper authentication, etc.)? Mike Dolan Lucent Technologies - Bell Labs 263 Shuman Blvd., Room 2D-229 Naperville, IL 60566-7050, USA * Office: +1.630.979.1033 * Mobile: +1.630.697.3549 * Email: mfdolan@lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Ashhar Farhan [mailto:afarhan@rediffmail.com] Sent: Friday, July 06, 2001 11:13 PM To: schulzrinne@cs.columbia.edu; mat@cisco.com Cc: gerhard.gross@intel.com; bidulock@openss7.org; jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com; kuthan@fokus.gmd.de; sip@ietf.org Subject: [SIP] Authentication and billing through proxy/re-direct server by now, it is well understood that some sort of recording of the calls made by a third party call-logging system is a requirement for many operative networks. therefore we need a way of propagating CDRs to a remote entity. for this, we have three options available to us: 1) introduce a new type of request message. 2) use NOTIFY with CDR in the body. 3) use MESSAGE with CDR in the body. my personaly preference will be to NOTIFY the remote call-logger. this is the simpler part of the issue. about authentication: authentication of a client with the gateway is a requirement. this requirement is not necessarily for the purposes of billing. for instance, an enterprise gateway may want to provide access to only certain caller. or a personal gateway run at home over the DSL where only some are allowed to call. at all these times, the gateway needs to authenticate the caller without any secret-sharing between them. therefore, there is a clear need for the participation of the registrar or some other authenticating service to do this. if A calls B. B asks C is A real? C says yes because i have his secret. while we could demand that the callers obtain their PGP keys, this is not a workable solution. we need a simple, effective solution for this within the SIP functionality (correct me if i am wrong on this). my suggestions are like this: 1) Caller A issues an INVITE for the gateway to the proxy server. 2) proxy server challenges A, receives the correct response. 3) proxy server now proxies the INVITE to the gateway with no authentication. 4) gateway challenges the proxy. proxy responds back with the digest over the message headers, gateway password and the nonce issued by the gateway (as described in the SIP RFC). the second scheme is completely within the SIP framework. i wonder if a stateless implementation of this scheme is possible. ____________________________________________________ Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 10:13:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29929 for ; Tue, 10 Jul 2001 10:13:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16865; Tue, 10 Jul 2001 09:46:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16777 for ; Tue, 10 Jul 2001 09:46:46 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29235 for ; Tue, 10 Jul 2001 09:45:57 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA11136; Tue, 10 Jul 2001 09:46:25 -0400 (EDT) Message-ID: <3B4B0731.2FE18B2B@cs.columbia.edu> Date: Tue, 10 Jul 2001 09:46:25 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: Chip Sharp , sip@ietf.org Subject: Re: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > > Beyond the / vs. |, the major difference is that RFC 2234 is a > > character-oriented grammar, while SIP (and HTTP) use a word-oriented > > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > > basically between every token, as in > > > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > > > becomes > > > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > > > and more complicated grammars become even messier. I'm not convinced > > that this visual noise aids understanding, but there may be other > > reasons to do this. > > Well just to stir the pot a little ...... isn't LWS only allowed on > the right hand side of the colon and not on the left. > Anywhere between tokens. Subject : something is perfectly legal. See test1.txt of the torture tests, for example. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 10:20:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00084 for ; Tue, 10 Jul 2001 10:20:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17848; Tue, 10 Jul 2001 10:07:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17817 for ; Tue, 10 Jul 2001 10:07:42 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29715 for ; Tue, 10 Jul 2001 10:06:53 -0400 (EDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA18112; Tue, 10 Jul 2001 10:07:40 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id KAA07402; Tue, 10 Jul 2001 10:07:40 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15179.3115.134676.885669@grandcentral.cs.columbia.edu> Date: Tue, 10 Jul 2001 10:07:39 -0400 (EDT) To: "Henning G. Schulzrinne" Cc: Chip Sharp , sip@ietf.org Subject: Re: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt In-Reply-To: <3B4A4BE2.C90949E5@cs.columbia.edu> References: <4.3.2.7.2.20010709164939.01e8c390@dogwood.cisco.com> <3B4A4BE2.C90949E5@cs.columbia.edu> X-Mailer: VM 6.75 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Monday, July 9 2001, "Henning G. Schulzrinne" wrote to "Chip Sharp, sip@ietf.org" saying: > Beyond the / vs. |, the major difference is that RFC 2234 is a > character-oriented grammar, while SIP (and HTTP) use a word-oriented > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > basically between every token, as in > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > becomes > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > and more complicated grammars become even messier. I'm not convinced > that this visual noise aids understanding, but there may be other > reasons to do this. The main motivation for this, IMO, would be that, currently, you have to do a fairly close reading of the spec in order to determine where LWSP is allowed. For instance, consider (just as an example extracted from a quick browsing of the spec): Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] delay = *(DIGIT) [ "." *(DIGIT) ] As I understand it, LWSP is *allowed* before and after the colon, is *required* between the timestamp and the delay, and is *forbidden* before and after the decimal points, and between the digits. I think this interpretation is probably derivable from the implicit-lwsp rules (since "." is a word character but ":" isn't) but it's very non-obvious. I've made some attempts at automatically generating a SIP parser from the grammar in the spec. The LWSP issue is by far the hardest thing to resolve. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 10:25:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00368 for ; Tue, 10 Jul 2001 10:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17197; Tue, 10 Jul 2001 09:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17166 for ; Tue, 10 Jul 2001 09:52:45 -0400 (EDT) Received: from sapphire.int.ipverse.com ([65.195.29.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29395 for ; Tue, 10 Jul 2001 09:51:56 -0400 (EDT) Received: from default.ipverse.com (hide4.etsi.org [212.234.161.7]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L4T5KJN8; Tue, 10 Jul 2001 06:52:15 -0700 Message-Id: <5.1.0.14.2.20010710065039.02156b10@mail.ipverse.com> X-Sender: matt@mail.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 06:52:04 -0700 To: "Dean Willis" , From: Matt Holdrege Subject: Re: [Sip] Forking: a modest proposal. In-Reply-To: <011501c10684$66bd0d40$ee036e3f@dfw.dynamicsoft.com> References: <61D824C63B99D311975E00508B0CC985022518EA@eamrcnt717.exu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Any way to simplify some of the tougher scenarios we have would be fine with me. I think we should at least discuss your proposal in London, either in the meeting or in the pub. At 06:30 PM 7/6/2001, Dean Willis wrote: >Well, I've made the less modest proposal before that forking could be >removed entirely from the specification. It seems to be an unpopular >suggestion in some quarters, but I like to bring it up before IETF meetings >as a matter of tradition (and in hopes that someday certain critical parties >will agree). > >Admittedly, most of you people are way brighter than me. But I find that the >branches and tags and special cases and stuff introduced to make forking >work regularly confuse my pointy little head, and seem to occasionally trip >up other folks as well. It really makes me sweat every time I have to think >about how a proposed extension will interact with forking, and in the Texas >summer, extra perspiration could be dangerous. > >On the other hand I have to admit that I do USE forking all the time -- >inbound calls to my phone hit a forking proxy and land on three SIP phones >and my cell phone roughly simultaneously. > >But it also seems that what we desired from forking could be readily >implemented as application logic without as much complexity in the core >protocol, and I think such an application would meet my needs as a forking >user (I've always wanted to say that about users). This would also allow >forking-like behavior for new messages on an as-needed-by-application-logic >basis. And acceptance of such a proposal would settle once and for all >whether non-INVITE messages get forked. > >Any takers? > >-- >Dean > > >----- Original Message ----- >From: >To: >Sent: Monday, July 02, 2001 11:44 AM >Subject: [Sip] Forking: a modest proposal. > > > > I'm putting together the SUB/NOT draft (we should go into nits > > on Monday), and am currently wrestling with the issue of forking. > > > > I have what I think is an elegant solution, given the immediate > > NOTIFY mechanism that we have agreed on. Certain camps have objections > > to this mechanism, and thinks that all but the first SUBSCRIBE should > > be made to fail (by sending a 400 class response). I don't see this > > difference of opinion as intractable, but it is something that will > > take a considerable amount of time (discussion, work, etc) to reach > > consensus. > > > > On reflection, I realize that this entire situation just highlights > > a thorn we've had in our paw the entire time. > > > > Given that all transactions complete (basically) immediately (with > > the exception of INVITEs), forking *any* non-INVITE request is just > > a race waiting to happen. It usually just leads to heartburn when > > you attempt to analyze how it's going to work with non-INVITE methods > > (as in the SUBSCRIBE example). > > > > Since there seems to be a general feeling that all but the first > > received request should "fail" in some general sense (usually by > > the request initiator not finding out about the response), I'd > > like to float a proposal: > > > > Deprecate forking of non-INVITEs. > > > > Despite my tongue-in-cheek subject line, I'm serious. > > > > SIP is not going to Draft Standard this time around, so maintaining > > absolute compatibility with RFC 2543 isn't strictly required. No one > > has come up with a useful application of forking non-INVITEs (except, > > arguably, my proposal that a forked SUBSCRIBE can install several > > subscriptions, with the subsequent NOTIFY messages establishing the > > legs, routes, and contacts as necessary). Forking non-INVITEs adds > > complexity to the protocol, extra work to all extensions, and > > headaches all around. And as long as people insist that nothing useful > > can come from forking anything but an INVITE, there is no gain to be > > had by leaving this "feature" in the protocol. > > > > As long as it is understood at a general protocol level that forking > > of non-INVITEs is disallowed, I have no problem rejecting the additional > > NOTIFY legs we find out about. If we continue to pretend that forking > > of non-INVITEs is a useful concept, I can't see the logic behind refusing > > to allow successful forking of SUBSCRIBEs. > > > > Comments, etc, encouraged -- even if just to voice assent. > > > > /a > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 10:34:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01502 for ; Tue, 10 Jul 2001 10:34:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18117; Tue, 10 Jul 2001 10:15:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18091 for ; Tue, 10 Jul 2001 10:15:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29961 for ; Tue, 10 Jul 2001 10:14:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09911; Tue, 10 Jul 2001 10:14:34 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23955; Tue, 10 Jul 2001 10:14:36 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 10:14:35 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465733@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Lennox'" , "Henning G. Schulzrinne" Cc: Chip Sharp , sip@ietf.org Subject: RE: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt Date: Tue, 10 Jul 2001 10:14:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org FWIW, I'll volunteer to do this if we think it's really worth it. Proofing it will take more work than editing, for sure. I'd rather edit than proof :) Brian ABNF hacker extradinaire > -----Original Message----- > From: Jonathan Lennox [mailto:lennox@cs.columbia.edu] > Sent: Tuesday, July 10, 2001 10:08 AM > To: Henning G. Schulzrinne > Cc: Chip Sharp; sip@ietf.org > Subject: Re: [Sip] ABNF comment/nit on > draft-ietf-sip-rfc2543bis-03.txt > > > On Monday, July 9 2001, "Henning G. Schulzrinne" wrote to > "Chip Sharp, sip@ietf.org" saying: > > > Beyond the / vs. |, the major difference is that RFC 2234 is a > > character-oriented grammar, while SIP (and HTTP) use a word-oriented > > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > > basically between every token, as in > > > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > > > becomes > > > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > > > and more complicated grammars become even messier. I'm not convinced > > that this visual noise aids understanding, but there may be other > > reasons to do this. > > The main motivation for this, IMO, would be that, currently, > you have to do > a fairly close reading of the spec in order to determine where LWSP is > allowed. > > For instance, consider (just as an example extracted from a > quick browsing > of the spec): > > Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) > ] [ delay ] > delay = *(DIGIT) [ "." *(DIGIT) ] > > As I understand it, LWSP is *allowed* before and after the colon, is > *required* between the timestamp and the delay, and is > *forbidden* before > and after the decimal points, and between the digits. > > I think this interpretation is probably derivable from the > implicit-lwsp > rules (since "." is a word character but ":" isn't) but it's very > non-obvious. > > I've made some attempts at automatically generating a SIP > parser from the > grammar in the spec. The LWSP issue is by far the hardest > thing to resolve. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 10:52:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01961 for ; Tue, 10 Jul 2001 10:52:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18400; Tue, 10 Jul 2001 10:27:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18372 for ; Tue, 10 Jul 2001 10:27:08 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00643 for ; Tue, 10 Jul 2001 10:26:18 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA14361; Tue, 10 Jul 2001 10:27:04 -0400 (EDT) Message-ID: <3B4B10B8.FDDD494B@cs.columbia.edu> Date: Tue, 10 Jul 2001 10:27:04 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox CC: Chip Sharp , sip@ietf.org Subject: Re: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt References: <4.3.2.7.2.20010709164939.01e8c390@dogwood.cisco.com> <3B4A4BE2.C90949E5@cs.columbia.edu> <15179.3115.134676.885669@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > On Monday, July 9 2001, "Henning G. Schulzrinne" wrote to "Chip Sharp, sip@ietf.org" saying: > > > Beyond the / vs. |, the major difference is that RFC 2234 is a > > character-oriented grammar, while SIP (and HTTP) use a word-oriented > > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > > basically between every token, as in > > > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > > > becomes > > > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > > > and more complicated grammars become even messier. I'm not convinced > > that this visual noise aids understanding, but there may be other > > reasons to do this. > > The main motivation for this, IMO, would be that, currently, you have to do > a fairly close reading of the spec in order to determine where LWSP is > allowed. I agree; this is a problem shared across these types of grammars. RFC 2822 (the successor to RFC 822) tries to be more rigorous and now calls out LWS and FLWS explicitly. > > For instance, consider (just as an example extracted from a quick browsing > of the spec): > > Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] > delay = *(DIGIT) [ "." *(DIGIT) ] > > As I understand it, LWSP is *allowed* before and after the colon, is > *required* between the timestamp and the delay, and is *forbidden* before > and after the decimal points, and between the digits. > > I think this interpretation is probably derivable from the implicit-lwsp > rules (since "." is a word character but ":" isn't) but it's very > non-obvious. > > I've made some attempts at automatically generating a SIP parser from the > grammar in the spec. The LWSP issue is by far the hardest thing to resolve. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 16:53:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23779 for ; Tue, 10 Jul 2001 16:53:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01422; Tue, 10 Jul 2001 16:31:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01393 for ; Tue, 10 Jul 2001 16:31:24 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22246 for ; Tue, 10 Jul 2001 16:30:34 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6AEZJH21046; Tue, 10 Jul 2001 07:35:20 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f6AEb8u07223; Tue, 10 Jul 2001 07:37:08 -0700 (PDT) Received: from CHSHARP-W2K1.cisco.com (rtp-vpn-139.cisco.com [10.82.192.139]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA18521; Tue, 10 Jul 2001 07:36:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20010710103237.01f208c0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Jul 2001 10:36:51 -0400 To: "Rosen, Brian" From: Chip Sharp Subject: RE: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt Cc: "'Jonathan Lennox'" , "Henning G. Schulzrinne" , sip@ietf.org In-Reply-To: <4FBEA8857476D311A03300204840E1CF04465733@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'll volunteer to help out if there is an interest. Of course the problem is not to break existing syntax. Chip At 10:14 AM 7/10/2001, Rosen, Brian wrote: >FWIW, I'll volunteer to do this if we think it's really worth it. >Proofing it will take more work than editing, for sure. >I'd rather edit than proof :) > >Brian >ABNF hacker extradinaire ...snip... _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 17:29:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25441 for ; Tue, 10 Jul 2001 17:29:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02622; Tue, 10 Jul 2001 17:14:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02593 for ; Tue, 10 Jul 2001 17:14:47 -0400 (EDT) Received: from iere.net.avaya.com (h198-152-12-101.outland.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24824 for ; Tue, 10 Jul 2001 17:13:57 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6ALE6N27944 for ; Tue, 10 Jul 2001 17:14:06 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6ALE5P27924 for ; Tue, 10 Jul 2001 17:14:05 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10985.5E4F1168" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] Forking: a modest proposal. Date: Tue, 10 Jul 2001 15:14:56 -0600 Message-ID: Thread-Topic: [Sip] Forking: a modest proposal. Thread-Index: AcEI0MxazP77v/BVQfuDdgMixnMdgAAsrjtQ From: "Zmolek, Andrew (Andrew)" To: "Jay Batson" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10985.5E4F1168 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Of course, *that* problem could be solved by deprecating B2BUAs, which are=20 > truly and deeply evil IMHO.... Watching the list from afar as I do, I > observe that there is a significant and growing temptation to fall back on=20 > doing everything via B2BUAs now, less and less of a discipline to force > things into the proxy/server model, with the resulting behavior /=20 > architecture starting to feel more and more like Megaco. This is a bad thing. While I sympathize with your concern, I think we have painted ourselves in a=20 corner with respect to B2BUAs. There are a lot of bridging and 4+ party=20 conferencing scenarios that simply aren't workable in SIP without a B2BUA.=20 Regardless, even if we did depreciate them, there isn't much we could do to=20 prevent them from being implemented because a B2BUA is still a valid user agent. The key to preventing SIP from becoming Megaco isn't banishing B2BUAs, but rather it is ensuring that clients remain clients and not slaves.=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ------_=_NextPart_001_01C10985.5E4F1168 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Forking: a modest proposal.

> Of course, *that* problem could be solved by = deprecating B2BUAs, which are
> truly and deeply evil IMHO....  Watching = the list from afar as I do, I
> observe that there is a significant and growing = temptation to fall back on
> doing everything via B2BUAs now, less and less = of a discipline to force
> things into the proxy/server model, with the = resulting behavior /
> architecture starting to feel more and more like = Megaco.  This is a bad thing.

While I sympathize with your concern, I think we have = painted ourselves in a
corner with respect to B2BUAs. There are a lot of = bridging and 4+ party
conferencing scenarios that simply aren't workable in = SIP without a B2BUA.
Regardless, even if we did depreciate them, there = isn't much we could do to
prevent them from being implemented because a B2BUA = is still a valid user agent.
The key to preventing SIP from becoming Megaco isn't = banishing B2BUAs, but rather
it is ensuring that clients remain clients and not = slaves.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C10985.5E4F1168-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 17:40:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25860 for ; Tue, 10 Jul 2001 17:40:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02671; Tue, 10 Jul 2001 17:15:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02640 for ; Tue, 10 Jul 2001 17:15:33 -0400 (EDT) Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24875 for ; Tue, 10 Jul 2001 17:14:42 -0400 (EDT) Received: from m2vwall3.wipro.com ([192.168.2.23]) by wiprom2mx2.wipro.com (8.9.3/8.9.3) with SMTP id DAA16963 for ; Wed, 11 Jul 2001 03:53:00 +0530 Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GGA0CO00.1ZA for ; Wed, 11 Jul 2001 02:44:49 +0530 Received: from wipro.com (164.164.8.35 [164.164.8.35]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3SNTFH70; Wed, 11 Jul 2001 02:58:07 +0530 Message-ID: <3B4BBCC5.AE39A708@wipro.com> Date: Wed, 11 Jul 2001 08:12:09 +0531 From: Varadarajan Srinivasan Reply-To: srinivasan.varada@wipro.com Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: [Fwd: Re: [Sip] Encryption negotiation?] Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, One more question on the same line. Response-Key header ( Section 6:37 in bis02) in a request from UAC to UAS tells what encryption an UAS should use to encrypt the response. If UAS can't code, 420 response is sent back to UAC. What to be done when an UAC wished to send in encrypted way a request to UAS? Is this negotiation mechanism possible in SIP? Please give back your opinion if I missed any major concepts. Regards, Varadarajan "Sean Olson (EUS)" wrote: > > > Hi, > > I have a simple question but I've been unable > to find an answer in the spec, FAQ, or mailing > list archives (though I may have overlooked > something obvious). > > When using the Encryption: header in a request, > is there a way for the UAS to reject the request > *and* indicate that the request was rejected because > the UAS was unable to decrypt the body? Should a > warning header be used? What about an option tag > for encryption? (i.e. is there a way to negotiate > support of encryption?) I would expect that many > implementations that don't support encryption > might return something like a 415 or a 400. > > Any comments? > > Sean Olson > Ericsson Inc. > sean.olson@ericsson.com --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 18:49:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28224 for ; Tue, 10 Jul 2001 18:49:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05075; Tue, 10 Jul 2001 18:27:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05048 for ; Tue, 10 Jul 2001 18:27:52 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27465 for ; Tue, 10 Jul 2001 18:27:01 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f6AMTgP06618 for ; Tue, 10 Jul 2001 18:29:42 -0400 Message-Id: <5.1.0.14.2.20010710181629.034dc040@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 18:26:45 -0400 To: From: Jay Batson Subject: RE: [Sip] Forking: a modest proposal. In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_376506547==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_376506547==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bridging and conferencing problems are not sufficient justification for the profusion of B2BUAs. Most endpoints I know (hard/soft phones, gateways) have enough signal/host processing power to mix 3-4 RTP streams. So to effect a conference, you *can* work out call flows that let the endpoint bridge a small number of streams. (We have done this just fine, thank you.) This clearly doesn't scale. But since most conferences are small anyway, the only products that *MUST* use B2BUAs to do this would be big, honkin network-based conference bridges for large conferences. This is *not* who seems to be falling back on B2BUAs. Instead, it is everybody who started out by building a simple proxy/redirect/registry server. Endpoint bridging also uses slightly more bandwidth. But we should not make the protocol design a slave to today's bandwidth constraints. Conferencing itself is not sufficient justification for the predominance of B2BUAs. The primary reason so many vendors seem to be falling back on B2BUAs is that they don't *MAKE* endpoints -- just servers. The B2BUA is a convenient crutch to get more direct control over a component that is foreign to their solution. Cooperate -- don't compete -- for better control. Of course, I would agree that it is crucially important that clients remain clients. But servers should not become clients, too. It's a bad idea. To be clear, I was not being particularly serious about trying to "depricate" them from the standard. Clearly, they *are* a valid UA, and can be used as such. But the industry should think hard about the clear DOWNSIDE to falling back on a B2BUA to solve every problem. Thus, my modestly-offered podium-speech. Comments again from the marginally qualified, but somewhat religious, gallery. -jb At 05:14 PM 7/10/01, Zmolek, Andrew (Andrew) wrote: > > Of course, *that* problem could be solved by deprecating B2BUAs, which are > > truly and deeply evil IMHO.... Watching the list from afar as I do, I > > observe that there is a significant and growing temptation to fall back on > > doing everything via B2BUAs now, less and less of a discipline to force > > things into the proxy/server model, with the resulting behavior / > > architecture starting to feel more and more like Megaco. This is a bad > thing. > >While I sympathize with your concern, I think we have painted ourselves in a >corner with respect to B2BUAs. There are a lot of bridging and 4+ party >conferencing scenarios that simply aren't workable in SIP without a B2BUA. >Regardless, even if we did depreciate them, there isn't much we could do to >prevent them from being implemented because a B2BUA is still a valid user >agent. >The key to preventing SIP from becoming Megaco isn't banishing B2BUAs, but >rather >it is ensuring that clients remain clients and not slaves. > >--Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) --=====================_376506547==_.ALT Content-Type: text/html; charset="us-ascii" Bridging and conferencing problems are not sufficient justification for the profusion of B2BUAs.  Most endpoints I know (hard/soft phones, gateways) have enough signal/host processing power to mix 3-4 RTP streams.

So to effect a conference, you *can* work out call flows that let the endpoint bridge a small number of streams.  (We have done this just fine, thank you.)

This clearly doesn't scale.  But since most conferences are small anyway, the only products that *MUST* use B2BUAs to do this would be big, honkin network-based conference bridges for large conferences.  This is *not* who seems to be falling back on B2BUAs.  Instead, it is everybody who started out by building a simple proxy/redirect/registry server.

Endpoint bridging also uses slightly more bandwidth.  But we should not make the protocol design a slave to today's bandwidth constraints.

Conferencing itself is not sufficient justification for the predominance of B2BUAs.  The primary reason so many vendors seem to be falling back on B2BUAs is that they don't *MAKE* endpoints -- just servers.  The B2BUA is a convenient crutch to get more direct control over a component that is foreign to their solution.  Cooperate -- don't compete -- for better control.

Of course, I would agree that it is crucially important that clients remain clients.  But servers should not become clients, too.  It's a bad idea.

To be clear, I was not being particularly serious about trying to "depricate" them from the standard.  Clearly, they *are* a valid UA, and can be used as such.  But the industry should think hard about the clear DOWNSIDE to falling back on a B2BUA to solve every problem.  Thus, my modestly-offered podium-speech.

Comments again from the marginally qualified, but somewhat religious, gallery.
-jb

At 05:14 PM 7/10/01, Zmolek, Andrew (Andrew) wrote:

> Of course, *that* problem could be solved by deprecating B2BUAs, which are
> truly and deeply evil IMHO....  Watching the list from afar as I do, I
> observe that there is a significant and growing temptation to fall back on
> doing everything via B2BUAs now, less and less of a discipline to force
> things into the proxy/server model, with the resulting behavior /
> architecture starting to feel more and more like Megaco.  This is a bad thing.

While I sympathize with your concern, I think we have painted ourselves in a
corner with respect to B2BUAs. There are a lot of bridging and 4+ party
conferencing scenarios that simply aren't workable in SIP without a B2BUA.
Regardless, even if we did depreciate them, there isn't much we could do to
prevent them from being implemented because a B2BUA is still a valid user agent.
The key to preventing SIP from becoming Megaco isn't banishing B2BUAs, but rather
it is ensuring that clients remain clients and not slaves.

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:jbatson@pingtel.com
781-938-5306 (office)

--=====================_376506547==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 10 19:04:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28807 for ; Tue, 10 Jul 2001 19:04:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05530; Tue, 10 Jul 2001 18:42:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05505 for ; Tue, 10 Jul 2001 18:42:12 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28017 for ; Tue, 10 Jul 2001 18:41:17 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6AMdxn13792; Tue, 10 Jul 2001 18:39:59 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id ADL01279 (AUTH pkyzivat); Tue, 10 Jul 2001 18:41:33 -0400 (EDT) Message-ID: <3B4B837E.835D249C@cisco.com> Date: Tue, 10 Jul 2001 18:36:46 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Batson CC: sip@ietf.org Subject: Re: [Sip] Forking: a modest proposal. References: <5.1.0.14.2.20010710181629.034dc040@mail.pingtel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Perhaps I don't fully understand the terminology - I don't recall ever seeing a precise definition of a B2BUA. But it seems to me that an endpoint that is managing a conference *is* acting as a B2BUA. If so, then it seems you are objecting to a certain class of B2BUA. Paul Kyzivat Cisco Systems Jay Batson wrote: > > Bridging and conferencing problems are not sufficient justification > for the profusion of B2BUAs. Most endpoints I know (hard/soft phones, > gateways) have enough signal/host processing power to mix 3-4 RTP > streams. > > So to effect a conference, you *can* work out call flows that let the > endpoint bridge a small number of streams. (We have done this just > fine, thank you.) > > This clearly doesn't scale. But since most conferences are small > anyway, the only products that *MUST* use B2BUAs to do this would be > big, honkin network-based conference bridges for large conferences. > This is *not* who seems to be falling back on B2BUAs. Instead, it is > everybody who started out by building a simple proxy/redirect/registry > server. > > Endpoint bridging also uses slightly more bandwidth. But we should > not make the protocol design a slave to today's bandwidth constraints. > > Conferencing itself is not sufficient justification for the > predominance of B2BUAs. The primary reason so many vendors seem to be > falling back on B2BUAs is that they don't *MAKE* endpoints -- just > servers. The B2BUA is a convenient crutch to get more direct control > over a component that is foreign to their solution. Cooperate -- > don't compete -- for better control. > > Of course, I would agree that it is crucially important that clients > remain clients. But servers should not become clients, too. It's a > bad idea. > > To be clear, I was not being particularly serious about trying to > "depricate" them from the standard. Clearly, they *are* a valid UA, > and can be used as such. But the industry should think hard about the > clear DOWNSIDE to falling back on a B2BUA to solve every problem. > Thus, my modestly-offered podium-speech. > > Comments again from the marginally qualified, but somewhat religious, > gallery. > -jb > > At 05:14 PM 7/10/01, Zmolek, Andrew (Andrew) wrote: > > > > Of course, *that* problem could be solved by deprecating B2BUAs, > > which are > > > truly and deeply evil IMHO.... Watching the list from afar as I > > do, I > > > observe that there is a significant and growing temptation to fall > > back on > > > doing everything via B2BUAs now, less and less of a discipline to > > force > > > things into the proxy/server model, with the resulting behavior / > > > architecture starting to feel more and more like Megaco. This is > > a bad thing. > > > > While I sympathize with your concern, I think we have painted > > ourselves in a > > corner with respect to B2BUAs. There are a lot of bridging and 4+ > > party > > conferencing scenarios that simply aren't workable in SIP without a > > B2BUA. > > Regardless, even if we did depreciate them, there isn't much we > > could do to > > prevent them from being implemented because a B2BUA is still a valid > > user agent. > > The key to preventing SIP from becoming Megaco isn't banishing > > B2BUAs, but rather > > it is ensuring that clients remain clients and not slaves. > > > > --Andy Zmolek > > Technology & Standards Engineer > > CTO Standards > > Avaya Inc. > > > > zmolek@avaya.com > > +1 720 444 4001 > > ------------- > PingMe! > Jay Batson > CEO > Pingtel Corp. > mailto:jbatson@pingtel.com > 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 02:19:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26008 for ; Wed, 11 Jul 2001 02:19:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22886; Wed, 11 Jul 2001 02:05:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22855 for ; Wed, 11 Jul 2001 02:05:32 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22671 for ; Wed, 11 Jul 2001 02:04:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B64xki024730; Wed, 11 Jul 2001 02:04:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSWHWW>; Wed, 11 Jul 2001 02:05:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , adam.roach@ericsson.com, sip@ietf.org Subject: RE: [Sip] Forking: a modest proposal. Date: Wed, 11 Jul 2001 02:05:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, July 06, 2001 9:30 PM > To: adam.roach@ericsson.com; sip@ietf.org > Subject: Re: [Sip] Forking: a modest proposal. > > > Well, I've made the less modest proposal before that forking could be > removed entirely from the specification. It seems to be an unpopular > suggestion in some quarters, but I like to bring it up before > IETF meetings > as a matter of tradition (and in hopes that someday certain > critical parties > will agree). Well, "some quarters" includes me, at least (maybe only me, but I hope not :) ). The reason its in the spec is, as Henning has pointed out, to avoid the propagation of call state into the network. SIP was designed, first and foremost, as a rendezvous type of protocol that could find a user at a multitude of locations, and connect the caller to the called party across different devices. In its role as a user discovery and connection protocol, supporting the ability to reach a user at several devices is a big reuqirement. Since we were also in the business of designing Internet protocols, we wanted to push state to the edges, so that one could build a system to do basic functions without all this cruft in the middle of the network. Indeed, Jay has raised the flag on that in a separate note on this thread. Removing forking from SIP means more of those B2BUAs. Lots more, I think (in fact, pretty much all proxies will turn into B2BUAs as a default mode). So, given its there already, I'd rather keep it, and instead, do a far better job of explaining it in the spec. Its not really THAT hard, its just that the spec is not exactly lucid on this, and many other, topics. Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I agree with Christian, and I think there is consensus on this, that forking of a non-INVITE only makes sense if (1) that request establishes no state at the UASes, and the set of servers that are reached are homogeneous, so that a response from any are equivalent, or (2) a 3-way handshake can be created in some other way, specific to the method. Now, I think its fair to say that the usefulness of a method that meets (1) is not too high, and worse, we can't guarantee this property for all methods. So, indeed, the question is whether we feel its useful to define, on a method by method basis (or perhaps there is a general purpose solution lurking somehwhere?), a three-way handshake to deal with forked non-INVITE. But, if its something that has to be done on a method-by-method basis, perhaps that belongs in the application space, using a B2BUA. Now, maybe this is contradicting myself, since I just argued above that forking of INVITE belongs in the protocol, and not in the application space. But, forking of these non-INVITEs is presumably a much less common ocurrence, so that putting it in the application space is not as much a burden. I'll be sure to put this topic on my running open-issues list for London. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 02:43:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26436 for ; Wed, 11 Jul 2001 02:43:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23468; Wed, 11 Jul 2001 02:30:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23429 for ; Wed, 11 Jul 2001 02:30:13 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26148 for ; Wed, 11 Jul 2001 02:29:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B6Tjki024746 for ; Wed, 11 Jul 2001 02:29:45 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSWHXR>; Wed, 11 Jul 2001 02:30:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 11 Jul 2001 02:30:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] another modest proposal: change call-leg ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, While we're on the subject of modest proposals, here is another that I've been toying with: Change the definition of call-leg ID. Instead of To, To-tag, From, From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, the ID no longer contains the URLs. There are quite a few benefits from this: 1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The From field in this re-INVITE is NOT actually the identity of C, but rather, B. This screws up the idempotency of SIP INVITE. The From field has one meaning in INVITE, and another in re-INVITE. This makes defining policies based on the From field more complex, since they no longer work properly for re-INVITE. 2. call-leg ID lookups in gateways are much faster now, since the tags and call-ids are just strings. Matching is now case-sensitive string compares. Much easier than URL comparison. 3. Overlap dialing is easier. The reason we've had to send each digit as a new call leg, is that we needed to change the To field and the request URI. By definition, this meant a new call leg. Now, we can send all of that within a single call leg. Much cleaner. 4. The Replaces draft benefits. We've already identified a need for the Replaces header to identify the entire call leg thats being replaced. This gets big when it carries two URLs, two tags, and a call-id. Now, we can throw away the URLs. This shortens the header and makes matching of the call-leg IDs easier. 5. It works with existing proxies. THe main drawback, of course, is that this won't interoperate with rfc2543 UAs. Thats fixable with Supported; the UAC indicates Supported: new-call-leg-id in the INVITE if it understands this. In that case, any responses or re-invites that change the URLs include a Require: new-call-leg-id. I fully admit that this may not be worth the pain. However, I'd welcome comments from others on whether its useful to consider further. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 07:52:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00854 for ; Wed, 11 Jul 2001 07:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02086; Wed, 11 Jul 2001 07:42:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02000 for ; Wed, 11 Jul 2001 07:42:06 -0400 (EDT) Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00534 for ; Wed, 11 Jul 2001 07:41:14 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.182.164]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id NAA05313; Wed, 11 Jul 2001 13:41:36 +0200 (MET DST) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A86.004031C5 ; Wed, 11 Jul 2001 13:41:10 +0200 X-Lotus-FromDomain: ALCATEL To: Paul Kyzivat cc: Jay Batson , sip@ietf.org Message-ID: Date: Wed, 11 Jul 2001 13:41:03 +0200 Subject: Re: [Sip] Forking: a modest proposal. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The main reason for B2BUA is to take control over the service to be provided to the end user. So, if SIP is strictly used as a "rendez-vous" protocol over the public Best Effort Internet network, there is in principle no need for such functionality. This can become quite different if you need to handle the user plane, as in the case of conference controllers. This is still worse if you are intended to provide services having guaranteed characteristics, like confidentiality, QoS, roaming, etc. A simple SIP proxy can not provide that, then you need a more complex functionality (because the service is more complex) allowing you to take control over the user request, and that can be done with B2BUA servers. Best regards Juan Carlos Paul Kyzivat on 11/07/2001 00:36:46 To: Jay Batson cc: sip@ietf.org(bcc: Juan-Carlos ROJAS/FR/ALCATEL) Subject: Re: [Sip] Forking: a modest proposal. Perhaps I don't fully understand the terminology - I don't recall ever seeing a precise definition of a B2BUA. But it seems to me that an endpoint that is managing a conference *is* acting as a B2BUA. If so, then it seems you are objecting to a certain class of B2BUA. Paul Kyzivat Cisco Systems Jay Batson wrote: > > Bridging and conferencing problems are not sufficient justification > for the profusion of B2BUAs. Most endpoints I know (hard/soft phones, > gateways) have enough signal/host processing power to mix 3-4 RTP > streams. > > So to effect a conference, you *can* work out call flows that let the > endpoint bridge a small number of streams. (We have done this just > fine, thank you.) > > This clearly doesn't scale. But since most conferences are small > anyway, the only products that *MUST* use B2BUAs to do this would be > big, honkin network-based conference bridges for large conferences. > This is *not* who seems to be falling back on B2BUAs. Instead, it is > everybody who started out by building a simple proxy/redirect/registry > server. > > Endpoint bridging also uses slightly more bandwidth. But we should > not make the protocol design a slave to today's bandwidth constraints. > > Conferencing itself is not sufficient justification for the > predominance of B2BUAs. The primary reason so many vendors seem to be > falling back on B2BUAs is that they don't *MAKE* endpoints -- just > servers. The B2BUA is a convenient crutch to get more direct control > over a component that is foreign to their solution. Cooperate -- > don't compete -- for better control. > > Of course, I would agree that it is crucially important that clients > remain clients. But servers should not become clients, too. It's a > bad idea. > > To be clear, I was not being particularly serious about trying to > "depricate" them from the standard. Clearly, they *are* a valid UA, > and can be used as such. But the industry should think hard about the > clear DOWNSIDE to falling back on a B2BUA to solve every problem. > Thus, my modestly-offered podium-speech. > > Comments again from the marginally qualified, but somewhat religious, > gallery. > -jb > > At 05:14 PM 7/10/01, Zmolek, Andrew (Andrew) wrote: > > > > Of course, *that* problem could be solved by deprecating B2BUAs, > > which are > > > truly and deeply evil IMHO.... Watching the list from afar as I > > do, I > > > observe that there is a significant and growing temptation to fall > > back on > > > doing everything via B2BUAs now, less and less of a discipline to > > force > > > things into the proxy/server model, with the resulting behavior / > > > architecture starting to feel more and more like Megaco. This is > > a bad thing. > > > > While I sympathize with your concern, I think we have painted > > ourselves in a > > corner with respect to B2BUAs. There are a lot of bridging and 4+ > > party > > conferencing scenarios that simply aren't workable in SIP without a > > B2BUA. > > Regardless, even if we did depreciate them, there isn't much we > > could do to > > prevent them from being implemented because a B2BUA is still a valid > > user agent. > > The key to preventing SIP from becoming Megaco isn't banishing > > B2BUAs, but rather > > it is ensuring that clients remain clients and not slaves. > > > > --Andy Zmolek > > Technology & Standards Engineer > > CTO Standards > > Avaya Inc. > > > > zmolek@avaya.com > > +1 720 444 4001 > > ------------- > PingMe! > Jay Batson > CEO > Pingtel Corp. > mailto:jbatson@pingtel.com > 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 08:29:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01520 for ; Wed, 11 Jul 2001 08:29:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02722; Wed, 11 Jul 2001 08:11:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02696 for ; Wed, 11 Jul 2001 08:11:14 -0400 (EDT) Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01210 for ; Wed, 11 Jul 2001 08:10:22 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.182.164]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id OAA10701; Wed, 11 Jul 2001 14:10:49 +0200 (MET DST) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A86.0042DE53 ; Wed, 11 Jul 2001 14:10:22 +0200 X-Lotus-FromDomain: ALCATEL To: Jonathan Rosenberg cc: "'sip@ietf.org'" Message-ID: Date: Wed, 11 Jul 2001 14:10:15 +0200 Subject: Re: [Sip] another modest proposal: example in Annex B Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Still on bis-03, section B.4.1 "New media sections MUST appear below any existing media sessions". OK, that's very clear. But the example given in section B.5 shows that the new media ("m=audio 8864 RTP/AVP 110") is added *before* the existing media. Shouldn't it be corrected ? Best regards Juan Carlos _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 08:51:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01935 for ; Wed, 11 Jul 2001 08:51:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02907; Wed, 11 Jul 2001 08:22:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02878 for ; Wed, 11 Jul 2001 08:22:11 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01408 for ; Wed, 11 Jul 2001 08:21:20 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51L0QX>; Wed, 11 Jul 2001 05:21:18 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 05:21:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, I think this is a very interesting proposal that solves a few problems, makes many things _much_ easier to implement and potentially more CPU efficient - definitely a modest proposal worth considering. I do however think that selection of the To & From tags must be done with more care if this suggestion is adopted (ie space & time uniqueness of tags is more crucial). For instance, the UAS MUST always choose a To tag that is different to the From tag so that the message direction can be determined. Of course, if tags are chosen to be properly globally unique across space & time (as they should be) then this is not a problem. Regards, Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 11, 2001 7:30 AM > To: 'sip@ietf.org' > Subject: [Sip] another modest proposal: change call-leg ID > > > Folks, > > While we're on the subject of modest proposals, here is > another that I've > been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > > There are quite a few benefits from this: > > 1. A calls B, and its forwarded to C. C accepts, and later > re-INVITEs. The > From field in this re-INVITE is NOT actually the identity of > C, but rather, > B. This screws up the idempotency of SIP INVITE. The From > field has one > meaning in INVITE, and another in re-INVITE. This makes > defining policies > based on the From field more complex, since they no longer > work properly for > re-INVITE. > > 2. call-leg ID lookups in gateways are much faster now, since > the tags and > call-ids are just strings. Matching is now case-sensitive > string compares. > Much easier than URL comparison. > > 3. Overlap dialing is easier. The reason we've had to send > each digit as a > new call leg, is that we needed to change the To field and > the request URI. > By definition, this meant a new call leg. Now, we can send all of that > within a single call leg. Much cleaner. > > 4. The Replaces draft benefits. We've already identified a > need for the > Replaces header to identify the entire call leg thats being > replaced. This > gets big when it carries two URLs, two tags, and a call-id. > Now, we can > throw away the URLs. This shortens the header and makes > matching of the > call-leg IDs easier. > > 5. It works with existing proxies. > > THe main drawback, of course, is that this won't interoperate > with rfc2543 > UAs. Thats fixable with Supported; the UAC indicates Supported: > new-call-leg-id in the INVITE if it understands this. In that > case, any > responses or re-invites that change the URLs include a Require: > new-call-leg-id. > > I fully admit that this may not be worth the pain. However, > I'd welcome > comments from others on whether its useful to consider further. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 08:54:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02026 for ; Wed, 11 Jul 2001 08:54:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03484; Wed, 11 Jul 2001 08:47:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03455 for ; Wed, 11 Jul 2001 08:47:21 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01796 for ; Wed, 11 Jul 2001 08:46:29 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51L0SF>; Wed, 11 Jul 2001 05:46:28 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning G. Schulzrinne'" Cc: sip@ietf.org Subject: RE: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt Date: Wed, 11 Jul 2001 05:46:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Henning, Hmmm.... you are of course correct. However I think that bis-03 is worded rather deceptively. It explicitly says that the name is followed by a colon and that white space MAY then be used after the colon (inferring it is not allowed beforehand otherwise why would only one-side be mentioned?). --- Section 10.5 Header Field Format Header fields ("general-header", "request-header", "response-header", and "entity-header") follow the same generic header format as that given in Section 3.1 of RFC 822 [25]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. --- Robert. > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, July 10, 2001 2:46 PM > To: Fairlie-Cuninghame, Robert > Cc: Chip Sharp; sip@ietf.org > Subject: Re: [Sip] ABNF comment/nit on > draft-ietf-sip-rfc2543bis-03.txt > > > "Fairlie-Cuninghame, Robert" wrote: > > > > > Beyond the / vs. |, the major difference is that RFC 2234 is a > > > character-oriented grammar, while SIP (and HTTP) use a > word-oriented > > > grammar. We'd have to add a lot of LWSP everywhere in the grammar, > > > basically between every token, as in > > > > > > Subject = ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM > > > > > > becomes > > > > > > Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM > > > > > > and more complicated grammars become even messier. I'm > not convinced > > > that this visual noise aids understanding, but there may be other > > > reasons to do this. > > > > Well just to stir the pot a little ...... isn't LWS > only allowed on > > the right hand side of the colon and not on the left. > > > > Anywhere between tokens. > > Subject : something > > is perfectly legal. See test1.txt of the torture tests, for example. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 09:11:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02356 for ; Wed, 11 Jul 2001 09:11:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03547; Wed, 11 Jul 2001 08:49:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03522 for ; Wed, 11 Jul 2001 08:49:37 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01860 for ; Wed, 11 Jul 2001 08:48:47 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA12659; Wed, 11 Jul 2001 08:49:37 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA24110; Wed, 11 Jul 2001 08:49:34 -0400 (EDT) Message-ID: <3B4C4B06.FAFBB58C@cs.columbia.edu> Date: Wed, 11 Jul 2001 08:48:06 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Paul Kyzivat , Jay Batson , sip@ietf.org Subject: Re: [Sip] Forking: a modest proposal. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit UAs (and B2B UAs) make sense when the UA also needs to terminate media, as for large-scale conference bridges and anonymizers. I don't think anybody is arguing with that, although for conference bridges, one would hope that they are transient phenomena. (Despite the bad press, multicast is slowly emerging as an option again, at least in selected environments, such as Internet2.) I have no idea why you would need B2B UAs for roaming or what they have to do with QoS (except that they generally are likely to make QoS worse.) An additional use of B2BUAs is for media translation, but this is really only likely for multiparty calls, as quality is much better if you can avoid transcoding. (I may be underestimating the effect of the screwy licensing for G.72x and various other low-rate codecs here, which also could lead to more transcoding than is technically called for.) Juan-Carlos.Rojas@alcatel.fr wrote: > > The main reason for B2BUA is to take control over the service to be provided to the end user. > So, if SIP is strictly used as a "rendez-vous" protocol over the public Best Effort Internet network, there is in principle no need for such functionality. > This can become quite different if you need to handle the user plane, as in the case of conference controllers. > This is still worse if you are intended to provide services having guaranteed characteristics, like confidentiality, QoS, roaming, etc. A simple SIP proxy can not provide that, then you need a more complex functionality (because the service is more > complex) allowing you to take control over the user request, and that can be done with B2BUA servers. > Best regards > Juan Carlos > > Paul Kyzivat on 11/07/2001 00:36:46 > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 09:32:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02907 for ; Wed, 11 Jul 2001 09:32:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04210; Wed, 11 Jul 2001 09:17:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04179 for ; Wed, 11 Jul 2001 09:16:59 -0400 (EDT) Received: from commserver.iperia.com ([63.84.167.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02563 for ; Wed, 11 Jul 2001 09:16:09 -0400 (EDT) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jul 2001 09:15:18 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A2F4E@commserver.erictest.com> From: Gordon Ledgard To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 09:15:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I love it. It's clean. Its neat. I haven't thought this part out, but couldn't you also then let proxies along the path replace the To header with normalized addresses? Could this be part of a possible solution to our "who called me?" problem with applications? Gordon R. Ledgard > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 11, 2001 2:30 AM > To: 'sip@ietf.org' > Subject: [Sip] another modest proposal: change call-leg ID > > > Folks, > > While we're on the subject of modest proposals, here is > another that I've > been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > > There are quite a few benefits from this: > > 1. A calls B, and its forwarded to C. C accepts, and later > re-INVITEs. The > From field in this re-INVITE is NOT actually the identity of > C, but rather, > B. This screws up the idempotency of SIP INVITE. The From > field has one > meaning in INVITE, and another in re-INVITE. This makes > defining policies > based on the From field more complex, since they no longer > work properly for > re-INVITE. > > 2. call-leg ID lookups in gateways are much faster now, since > the tags and > call-ids are just strings. Matching is now case-sensitive > string compares. > Much easier than URL comparison. > > 3. Overlap dialing is easier. The reason we've had to send > each digit as a > new call leg, is that we needed to change the To field and > the request URI. > By definition, this meant a new call leg. Now, we can send all of that > within a single call leg. Much cleaner. > > 4. The Replaces draft benefits. We've already identified a > need for the > Replaces header to identify the entire call leg thats being > replaced. This > gets big when it carries two URLs, two tags, and a call-id. > Now, we can > throw away the URLs. This shortens the header and makes > matching of the > call-leg IDs easier. > > 5. It works with existing proxies. > > THe main drawback, of course, is that this won't interoperate > with rfc2543 > UAs. Thats fixable with Supported; the UAC indicates Supported: > new-call-leg-id in the INVITE if it understands this. In that > case, any > responses or re-invites that change the URLs include a Require: > new-call-leg-id. > > I fully admit that this may not be worth the pain. However, > I'd welcome > comments from others on whether its useful to consider further. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:10:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03953 for ; Wed, 11 Jul 2001 10:10:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05269; Wed, 11 Jul 2001 09:48:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05242 for ; Wed, 11 Jul 2001 09:48:25 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03232 for ; Wed, 11 Jul 2001 09:47:31 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6BDmKN20088 for ; Wed, 11 Jul 2001 15:48:21 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Jul 11 15:48:19 2001 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jul 2001 15:43:41 +0200 Message-ID: <7BA41B5547CCD411833B0002A52CD4570372825B@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'sip@ietf.org'" Date: Wed, 11 Jul 2001 15:52:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] streaming media vs conversational media, where in SIP/SDP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hello, ETSI/3GPP, Universal Mobile Telecommunications System (UMTS); QoS Concept and Architecture (3GPP TS 23.107 version 3.5.0 Release 1999), ETSI TS 123 107 v3.5.0, http://webapp.etsi.org/pda/home.asp?wki_id=12899 shows a few types of QoS, streaming, conversational, etc the problem is that I am unsure how this ends up in SIP? PINT2.0 does give SDP extensions to what type of media stream is used and thus the QoS requirement linked to it but only for VOICE. Will there be in SIP or SDP an indication if it has to be streaming or e.g conversational (which allows for less delay then streaming that can be buffered)? I appreciate the help. cheers Arnoud van Wijk _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk Innovation Unit Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:10:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03957 for ; Wed, 11 Jul 2001 10:10:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05087; Wed, 11 Jul 2001 09:44:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05058 for ; Wed, 11 Jul 2001 09:44:11 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03171 for ; Wed, 11 Jul 2001 09:43:21 -0400 (EDT) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA21872; Wed, 11 Jul 2001 09:44:06 -0400 (EDT) Message-ID: <3B4C5826.57E9DD08@cs.columbia.edu> Date: Wed, 11 Jul 2001 09:44:06 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Ledgard CC: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: Re: [Sip] another modest proposal: change call-leg ID References: <1A69639B9B6AD511812B00B0D0DE19F60A2F4E@commserver.erictest.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gordon Ledgard wrote: > > > THe main drawback, of course, is that this won't interoperate > > with rfc2543 > > UAs. Thats fixable with Supported; the UAC indicates Supported: > > new-call-leg-id in the INVITE if it understands this. In that > > case, any > > responses or re-invites that change the URLs include a Require: > > new-call-leg-id. This would only be needed in those cases where the UAC violates the existing definition of call legs, which are presumably rare (overlap dialing, possibly). All the other cases, such as call forwarding to C and then INVITEs to C, are more corner cases that work oddly right now. I think it would be worth considering if we can avoid the proliferation of new identifiers and can spell out the cases where existing things break. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:39:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03952 for ; Wed, 11 Jul 2001 10:10:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05001; Wed, 11 Jul 2001 09:42:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04974 for ; Wed, 11 Jul 2001 09:42:40 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03101 for ; Wed, 11 Jul 2001 09:41:49 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07105 for ; Wed, 11 Jul 2001 09:41:48 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07097 for ; Wed, 11 Jul 2001 09:41:48 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10A0F.5F84BC6A" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 07:42:48 -0600 Message-ID: Thread-Topic: [Sip] another modest proposal: change call-leg ID Thread-Index: AcEJ1CWppelJ4JoUQdKU0s2LLajPBwAOlXVg From: "Zmolek, Andrew (Andrew)" To: "Jonathan Rosenberg" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10A0F.5F84BC6A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a very good idea, IMHO. We have been struggling to find a cleaner solution to some of the issues Jonathan mentions and additional scenarios where it is difficult to preserve all elements of call-leg ID as presently defined. In the long run, cleaning this up helps SIP interoperability, so I think this is worth doing. Is it too late to include this in the bis draft? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 11, 2001 12:30 AM To: 'sip@ietf.org' Subject: [Sip] another modest proposal: change call-leg ID Folks, While we're on the subject of modest proposals, here is another that I've been toying with: Change the definition of call-leg ID. Instead of To, To-tag, From, From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, the ID no longer contains the URLs. There are quite a few benefits from this: 1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The From field in this re-INVITE is NOT actually the identity of C, but rather, B. This screws up the idempotency of SIP INVITE. The From field has one meaning in INVITE, and another in re-INVITE. This makes defining policies based on the From field more complex, since they no longer work properly for re-INVITE.=20 2. call-leg ID lookups in gateways are much faster now, since the tags and call-ids are just strings. Matching is now case-sensitive string compares. Much easier than URL comparison.=20 3. Overlap dialing is easier. The reason we've had to send each digit as a new call leg, is that we needed to change the To field and the request URI. By definition, this meant a new call leg. Now, we can send all of that within a single call leg. Much cleaner. 4. The Replaces draft benefits. We've already identified a need for the Replaces header to identify the entire call leg thats being replaced. This gets big when it carries two URLs, two tags, and a call-id. Now, we can throw away the URLs. This shortens the header and makes matching of the call-leg IDs easier. 5. It works with existing proxies. THe main drawback, of course, is that this won't interoperate with rfc2543 UAs. Thats fixable with Supported; the UAC indicates Supported: new-call-leg-id in the INVITE if it understands this. In that case, any responses or re-invites that change the URLs include a Require: new-call-leg-id.=20 I fully admit that this may not be worth the pain. However, I'd welcome comments from others on whether its useful to consider further. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com =20 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C10A0F.5F84BC6A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] another modest proposal: change call-leg ID

This is a very good idea, IMHO. We have been = struggling to find a cleaner solution to some of the issues Jonathan = mentions and additional scenarios where it is difficult to preserve all = elements of call-leg ID as presently defined. In the long run, cleaning = this up helps SIP interoperability, so I think this is worth = doing.  Is it too late to include this in the bis draft?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 11, 2001 12:30 AM
To: 'sip@ietf.org'
Subject: [Sip] another modest proposal: change = call-leg ID


Folks,

While we're on the subject of modest proposals, here = is another that I've
been toying with:

  Change the definition of call-leg ID. Instead = of To, To-tag, From,
  From-tag, and Call-ID, its *only* the tags and = the Call-ID. That is,
  the ID no longer contains the URLs.

There are quite a few benefits from this:

1. A calls B, and its forwarded to C. C accepts, and = later re-INVITEs. The
From field in this re-INVITE is NOT actually the = identity of C, but rather,
B. This screws up the idempotency of SIP INVITE. The = From field has one
meaning in INVITE, and another in re-INVITE. This = makes defining policies
based on the From field more complex, since they no = longer work properly for
re-INVITE.

2. call-leg ID lookups in gateways are much faster = now, since the tags and
call-ids are just strings. Matching is now = case-sensitive string compares.
Much easier than URL comparison.

3. Overlap dialing is easier. The reason we've had to = send each digit as a
new call leg, is that we needed to change the To = field and the request URI.
By definition, this meant a new call leg. Now, we can = send all of that
within a single call leg. Much cleaner.

4. The Replaces draft benefits. We've already = identified a need for the
Replaces header to identify the entire call leg thats = being replaced. This
gets big when it carries two URLs, two tags, and a = call-id. Now, we can
throw away the URLs. This shortens the header and = makes matching of the
call-leg IDs easier.

5. It works with existing proxies.

THe main drawback, of course, is that this won't = interoperate with rfc2543
UAs. Thats fixable with Supported; the UAC indicates = Supported:
new-call-leg-id in the INVITE if it understands this. = In that case, any
responses or re-invites that change the URLs include = a Require:
new-call-leg-id.

I fully admit that this may not be worth the pain. = However, I'd welcome
comments from others on whether its useful to = consider further.

-Jonathan R.


---
Jonathan D. Rosenberg, = Ph.D.           &n= bsp;    72 Eagle Rock Ave.
Chief = Scientist          &nbs= p;            = ;      First Floor
dynamicsoft         = ;            =             East = Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =   FAX:   (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000
http://www.dynamicsoft.com=
 

_______________________________________________
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C10A0F.5F84BC6A-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:43:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05828 for ; Wed, 11 Jul 2001 10:43:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06282; Wed, 11 Jul 2001 10:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06204 for ; Wed, 11 Jul 2001 10:21:20 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04378 for ; Wed, 11 Jul 2001 10:20:29 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6BEKo521398 for ; Wed, 11 Jul 2001 09:20:50 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f6BEKok01638 for ; Wed, 11 Jul 2001 09:20:50 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 11 09:20:37 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2T26Q>; Wed, 11 Jul 2001 09:20:37 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 09:20:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10A14.A61EBAE0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10A14.A61EBAE0 Content-Type: text/plain; charset="iso-8859-1" >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Wednesday, July 11, 2001 1:30 AM >To: 'sip@ietf.org' >Subject: [Sip] another modest proposal: change call-leg ID > > >Folks, > >While we're on the subject of modest proposals, here is >another that I've >been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > >There are quite a few benefits from this: > >1. A calls B, and its forwarded to C. C accepts, and later >re-INVITEs. The >From field in this re-INVITE is NOT actually the identity of >C, but rather, >B. This screws up the idempotency of SIP INVITE. The From field has one >meaning in INVITE, and another in re-INVITE. This makes >defining policies >based on the From field more complex, since they no longer >work properly for >re-INVITE. But this proposal only removes information from the call leg ID, which can't help you with this policy problem. You certainly won't define policies based on tags. I agree this is definitely a problem, but I don't think this is a solution. There are also cases where you want to be able to identify a session as being transferred -- having the original A/B parties is a nice thing to have. > >2. call-leg ID lookups in gateways are much faster now, since >the tags and >call-ids are just strings. Matching is now case-sensitive >string compares. >Much easier than URL comparison. True. Of course, this wouldn't be an issue if the To:/From: were immutable -- a modest proposal of my own :). > >3. Overlap dialing is easier. The reason we've had to send >each digit as a >new call leg, is that we needed to change the To field and the >request URI. >By definition, this meant a new call leg. Now, we can send all of that >within a single call leg. Much cleaner. Does this mean a gateway will have to generate a new tag for each endpoint it supports? > >4. The Replaces draft benefits. We've already identified a need for the >Replaces header to identify the entire call leg thats being >replaced. This >gets big when it carries two URLs, two tags, and a call-id. Now, we can >throw away the URLs. This shortens the header and makes matching of the >call-leg IDs easier. The replaces problem is simpler. You are talking about a pre-existing call leg. This makes matching simpler and therefore the proposal of using only the tags in this case is a reasonable one. The real problem with using only tags is the *possibility* for clashes -- are tags sufficiently unique? For Replaces:, I feel comfortable saying yes. For the more general case, I'm not sure I do. > >5. It works with existing proxies. What about the overlapped dialing case? > >THe main drawback, of course, is that this won't interoperate >with rfc2543 >UAs. Thats fixable with Supported; the UAC indicates Supported: >new-call-leg-id in the INVITE if it understands this. In that case, any >responses or re-invites that change the URLs include a Require: >new-call-leg-id. > >I fully admit that this may not be worth the pain. However, I'd welcome >comments from others on whether its useful to consider further. > >-Jonathan R. Does this have any impacts on the ways in which UAs allocate tags? (esp. across restarts?) /sean ------_=_NextPart_001_01C10A14.A61EBAE0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] another modest proposal: change call-leg ID

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: Wednesday, July 11, 2001 1:30 AM
>To: 'sip@ietf.org'
>Subject: [Sip] another modest proposal: change call-leg ID
>
>
>Folks,
>
>While we're on the subject of modest proposals, here is
>another that I've
>been toying with:
>
>  Change the definition of call-leg ID. Instead of To, To-tag, From,
>  From-tag, and Call-ID, its *only* the tags and the Call-ID. That is,
>  the ID no longer contains the URLs.
>
>There are quite a few benefits from this:
>
>1. A calls B, and its forwarded to C. C accepts, and later
>re-INVITEs. The
>From field in this re-INVITE is NOT actually the identity of
>C, but rather,
>B. This screws up the idempotency of SIP INVITE. The From field has one
>meaning in INVITE, and another in re-INVITE. This makes
>defining policies
>based on the From field more complex, since they no longer
>work properly for
>re-INVITE.

But this proposal only removes information from the call leg ID,
which can't help you with this policy problem. You certainly
won't define policies based on tags. I agree this is
definitely a problem, but I don't think this is a solution.
There are also cases where you want to be able to identify a
session as being transferred -- having the original A/B parties
is a nice thing to have.

>
>2. call-leg ID lookups in gateways are much faster now, since
>the tags and
>call-ids are just strings. Matching is now case-sensitive
>string compares.
>Much easier than URL comparison.

True. Of course, this wouldn't be an issue if the To:/From: were
immutable -- a modest proposal of my own :).

>
>3. Overlap dialing is easier. The reason we've had to send
>each digit as a
>new call leg, is that we needed to change the To field and the
>request URI.
>By definition, this meant a new call leg. Now, we can send all of that
>within a single call leg. Much cleaner.

Does this mean a gateway will have to generate a new tag for
each endpoint it supports?

>
>4. The Replaces draft benefits. We've already identified a need for the
>Replaces header to identify the entire call leg thats being
>replaced. This
>gets big when it carries two URLs, two tags, and a call-id. Now, we can
>throw away the URLs. This shortens the header and makes matching of the
>call-leg IDs easier.

The replaces problem is simpler. You are talking about a pre-existing
call leg. This makes matching simpler and therefore the proposal of
using only the tags in this case is a reasonable one. The real
problem with using only tags is the *possibility* for clashes -- are
tags sufficiently unique? For Replaces:, I feel comfortable saying yes.
For the more general case, I'm not sure I do.

>
>5. It works with existing proxies.

What about the overlapped dialing case?

>
>THe main drawback, of course, is that this won't interoperate
>with rfc2543
>UAs. Thats fixable with Supported; the UAC indicates Supported:
>new-call-leg-id in the INVITE if it understands this. In that case, any
>responses or re-invites that change the URLs include a Require:
>new-call-leg-id.
>
>I fully admit that this may not be worth the pain. However, I'd welcome
>comments from others on whether its useful to consider further.
>
>-Jonathan R.

Does this have any impacts on the ways in which UAs allocate
tags? (esp. across restarts?)

/sean

------_=_NextPart_001_01C10A14.A61EBAE0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:44:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05844 for ; Wed, 11 Jul 2001 10:44:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06342; Wed, 11 Jul 2001 10:22:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06313 for ; Wed, 11 Jul 2001 10:22:22 -0400 (EDT) Received: from iere.net.avaya.com (h198-152-12-101.outland.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04415 for ; Wed, 11 Jul 2001 10:21:29 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6BELXT01254 for ; Wed, 11 Jul 2001 10:21:33 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6BELW101242 for ; Wed, 11 Jul 2001 10:21:33 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10A14.E6D71104" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] Forking: a modest proposal. Date: Wed, 11 Jul 2001 08:22:23 -0600 Message-ID: Thread-Topic: [Sip] Forking: a modest proposal. Thread-Index: AcEIkrMW1YGj1SH0R2u9AjHyGrEo0wBf69vg From: "Zmolek, Andrew (Andrew)" To: , "Henning Schulzrinne" , "Dean Willis" Cc: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10A14.E6D71104 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is very tempting to depreciate forking altogether, especially when one considers just how many value-added capabilities will have to be implemented with B2BUA capabilities (forking with automatic bridging, for instance). Simplifying the protocol here might be a very good thing, but only if we can address the loop detection issue. My own feeling is that keeping forking as it exists today isn't going to result in fewer B2BUA implementations because of the value-add temptation. If we're going to have looping, why not come up with a scheme that works equally well with forking proxies and forked bridging B2BUAs and other flavors still to be created? What is the minimum amount of information required for loop detection? Could we accomplish this by using a unique endpoint identifier like a MAC address (although a large scale or applications UA might need to append a tag to separate unique sub-entities for which it terminates calls)?=20 I believe there is a lot of value in providing for higher-level loop detection regardless of our decision on forking. The real question is whether standardized, higher-level loop detection is realistic or feasible. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, July 09, 2001 10:13 AM To: 'Henning Schulzrinne'; Dean Willis Cc: adam.roach@ericsson.com; sip@ietf.org Subject: RE: [Sip] Forking: a modest proposal. > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] >=20 > The problem is that once you implement "forking" at the B2B-UA level, > you also need loop detection and most of the other features and pretty > soon, you'll be back to where we started, one layer up, except that > every system will implement them differently. It may well be that > splitting them across two layers would've been the right thing, but I > doubt that the overall system would be less complex. (I agree=20 > that tags > could be avoided if the B2BUA uses, say, a new call-ID for=20 > each branch.) I think it would be far less complex, since it doesn't impact every silly little detail of every single extension. By making it an application on top of the protocol, it becomes an issue for the application designer. By and large, such a designer will be able to make reasonable decisions, like: "I have no idea what method XYZZY means, so forking it would be absurd." Currently, since it is part of the spec, forking proxies will say "XYZZY is just a method. I'm method agnostic. I'll fork it!" I'm 100% behind Dean's proposal, and would be interested to see how, say, a hum vote on the topic would turn out. Can we have a short rant on this topic in London followed by a poll for rough consensus? /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C10A14.E6D71104 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Forking: a modest proposal.

It is very tempting to depreciate forking altogether, = especially when one considers just how many value-added capabilities = will have to be implemented with B2BUA capabilities (forking with = automatic bridging, for instance). Simplifying the protocol here might = be a very good thing, but only if we can address the loop detection = issue.

My own feeling is that keeping forking as it exists = today isn't going to result in fewer B2BUA implementations because of = the value-add temptation. If we're going to have looping, why not come = up with a scheme that works equally well with forking proxies and forked = bridging B2BUAs and other flavors still to be created?

What is the minimum amount of information required for = loop detection? Could we accomplish this by using a unique endpoint = identifier like a MAC address (although a large scale or applications UA = might need to append a tag to separate unique sub-entities for which it = terminates calls)?

I believe there is a lot of value in providing for = higher-level loop detection regardless of our decision on forking. The = real question is whether standardized, higher-level loop detection is = realistic or feasible.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, July 09, 2001 10:13 AM
To: 'Henning Schulzrinne'; Dean Willis
Cc: adam.roach@ericsson.com; sip@ietf.org
Subject: RE: [Sip] Forking: a modest proposal.


> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbi= a.edu]
>
> The problem is that once you implement = "forking" at the B2B-UA level,
> you also need loop detection and most of the = other features and pretty
> soon, you'll be back to where we started, one = layer up, except that
> every system will implement them differently. It = may well be that
> splitting them across two layers would've been = the right thing, but I
> doubt that the overall system would be less = complex. (I agree
> that tags
> could be avoided if the B2BUA uses, say, a new = call-ID for
> each branch.)

I think it would be far less complex, since it doesn't = impact every
silly little detail of every single extension. By = making it an application
on top of the protocol, it becomes an issue for the = application designer.
By and large, such a designer will be able to make = reasonable decisions,
like: "I have no idea what method XYZZY means, = so forking it would
be absurd."

Currently, since it is part of the spec, forking = proxies will say
"XYZZY is just a method. I'm method agnostic. = I'll fork it!"

I'm 100% behind Dean's proposal, and would be = interested to see
how, say, a hum vote on the topic would turn out. Can = we have a
short rant on this topic in London followed by a poll = for rough
consensus?

/a


_______________________________________________
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C10A14.E6D71104-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:44:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05869 for ; Wed, 11 Jul 2001 10:44:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06441; Wed, 11 Jul 2001 10:24:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06376 for ; Wed, 11 Jul 2001 10:24:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04738; Wed, 11 Jul 2001 10:23:21 -0400 (EDT) Message-Id: <200107111423.KAA04738@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 11 Jul 2001 10:23:21 -0400 Subject: [Sip] I-D ACTION:draft-sijben-rtp-proxy-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP proxies for firewall traversal Author(s) : M. de Boer et al. Filename : draft-sijben-rtp-proxy-00.txt Pages : 23 Date : 10-Jul-01 This draft describes how a MEGACO controlled RTP proxy can be used to provide firewall traversal for media flows for SIP calls. The MEGACO profile described in this draft can be used to support any UDP flow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sijben-rtp-proxy-00.txt 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-sijben-rtp-proxy-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-sijben-rtp-proxy-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: <20010710154021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sijben-rtp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sijben-rtp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710154021.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 10:45:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05897 for ; Wed, 11 Jul 2001 10:45:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06489; Wed, 11 Jul 2001 10:24:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06460 for ; Wed, 11 Jul 2001 10:24:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04754; Wed, 11 Jul 2001 10:23:30 -0400 (EDT) Message-Id: <200107111423.KAA04754@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, confctr@isi.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 11 Jul 2001 10:23:30 -0400 Subject: [Sip] I-D ACTION:draft-boer-sip-src-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Specifying unicast media source addresses in SIP Author(s) : M. de Boer et al. Filename : draft-boer-sip-src-00.txt Pages : 6 Date : 10-Jul-01 This draft describes a method to specify source IP addresses and ports of a media stream in a SIP call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boer-sip-src-00.txt 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-boer-sip-src-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-boer-sip-src-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: <20010710154030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-boer-sip-src-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-boer-sip-src-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710154030.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 11:19:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07147 for ; Wed, 11 Jul 2001 11:19:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07504; Wed, 11 Jul 2001 10:53:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07472 for ; Wed, 11 Jul 2001 10:53:44 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06110 for ; Wed, 11 Jul 2001 10:52:53 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6BErEl23759; Wed, 11 Jul 2001 07:53:15 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR21062; Wed, 11 Jul 2001 07:52:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA06351; Wed, 11 Jul 2001 07:52:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.26699.494697.624695@thomasm-u1.cisco.com> Date: Wed, 11 Jul 2001 07:52:59 -0700 (PDT) To: "Zmolek, Andrew (Andrew)" Cc: , "Henning Schulzrinne" , "Dean Willis" , Subject: RE: [Sip] Forking: a modest proposal. In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The cost of B2BUA's is introducing a lot more brittleness into the network. Sometimes this is unavoidable, but when it isn't it shouldn't be encouraged. The second line of defense here, IMO, would be to just fail back to the UAC with lists of candidates and let it sift through the resulting graph. Mike Zmolek, Andrew (Andrew) writes: > It is very tempting to depreciate forking altogether, especially when > one considers just how many value-added capabilities will have to be > implemented with B2BUA capabilities (forking with automatic bridging, > for instance). Simplifying the protocol here might be a very good thing, > but only if we can address the loop detection issue. > > My own feeling is that keeping forking as it exists today isn't going to > result in fewer B2BUA implementations because of the value-add > temptation. If we're going to have looping, why not come up with a > scheme that works equally well with forking proxies and forked bridging > B2BUAs and other flavors still to be created? > > What is the minimum amount of information required for loop detection? > Could we accomplish this by using a unique endpoint identifier like a > MAC address (although a large scale or applications UA might need to > append a tag to separate unique sub-entities for which it terminates > calls)? > > I believe there is a lot of value in providing for higher-level loop > detection regardless of our decision on forking. The real question is > whether standardized, higher-level loop detection is realistic or > feasible. > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > > > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, July 09, 2001 10:13 AM > To: 'Henning Schulzrinne'; Dean Willis > Cc: adam.roach@ericsson.com; sip@ietf.org > Subject: RE: [Sip] Forking: a modest proposal. > > > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > > > The problem is that once you implement "forking" at the B2B-UA level, > > you also need loop detection and most of the other features and pretty > > soon, you'll be back to where we started, one layer up, except that > > every system will implement them differently. It may well be that > > splitting them across two layers would've been the right thing, but I > > doubt that the overall system would be less complex. (I agree > > that tags > > could be avoided if the B2BUA uses, say, a new call-ID for > > each branch.) > > I think it would be far less complex, since it doesn't impact every > silly little detail of every single extension. By making it an > application > on top of the protocol, it becomes an issue for the application > designer. > By and large, such a designer will be able to make reasonable decisions, > like: "I have no idea what method XYZZY means, so forking it would > be absurd." > > Currently, since it is part of the spec, forking proxies will say > "XYZZY is just a method. I'm method agnostic. I'll fork it!" > > I'm 100% behind Dean's proposal, and would be interested to see > how, say, a hum vote on the topic would turn out. Can we have a > short rant on this topic in London followed by a poll for rough > consensus? > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > > RE: [Sip] Forking: a modest proposal. > > > > >

It is very tempting to depreciate forking altogether, especially when one considers just how many value-added capabilities will have to be implemented with B2BUA capabilities (forking with automatic bridging, for instance). Simplifying the protocol here might be a very good thing, but only if we can address the loop detection issue.

> >

My own feeling is that keeping forking as it exists today isn't going to result in fewer B2BUA implementations because of the value-add temptation. If we're going to have looping, why not come up with a scheme that works equally well with forking proxies and forked bridging B2BUAs and other flavors still to be created?

> >

What is the minimum amount of information required for loop detection? Could we accomplish this by using a unique endpoint identifier like a MAC address (although a large scale or applications UA might need to append a tag to separate unique sub-entities for which it terminates calls)?

> >

I believe there is a lot of value in providing for higher-level loop detection regardless of our decision on forking. The real question is whether standardized, higher-level loop detection is realistic or feasible.

> >

--Andy Zmolek > >
    Technology & Standards Engineer > >
      CTO Standards > >
        Avaya Inc. >

> >

            zmolek@avaya.com > >
              +1 720 444 4001 >

>
> >

-----Original Message----- > >
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > >
Sent: Monday, July 09, 2001 10:13 AM > >
To: 'Henning Schulzrinne'; Dean Willis > >
Cc: adam.roach@ericsson.com; sip@ietf.org > >
Subject: RE: [Sip] Forking: a modest proposal. >

>
> >

> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > >
> > >
> The problem is that once you implement "forking" at the B2B-UA level, > >
> you also need loop detection and most of the other features and pretty > >
> soon, you'll be back to where we started, one layer up, except that > >
> every system will implement them differently. It may well be that > >
> splitting them across two layers would've been the right thing, but I > >
> doubt that the overall system would be less complex. (I agree > >
> that tags > >
> could be avoided if the B2BUA uses, say, a new call-ID for > >
> each branch.) >

> >

I think it would be far less complex, since it doesn't impact every > >
silly little detail of every single extension. By making it an application > >
on top of the protocol, it becomes an issue for the application designer. > >
By and large, such a designer will be able to make reasonable decisions, > >
like: "I have no idea what method XYZZY means, so forking it would > >
be absurd." >

> >

Currently, since it is part of the spec, forking proxies will say > >
"XYZZY is just a method. I'm method agnostic. I'll fork it!" >

> >

I'm 100% behind Dean's proposal, and would be interested to see > >
how, say, a hum vote on the topic would turn out. Can we have a > >
short rant on this topic in London followed by a poll for rough > >
consensus? >

> >

/a >

>
> >

_______________________________________________ > >
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip > >
This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 11:47:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08525 for ; Wed, 11 Jul 2001 11:47:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08011; Wed, 11 Jul 2001 11:04:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07926 for ; Wed, 11 Jul 2001 11:04:04 -0400 (EDT) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06490 for ; Wed, 11 Jul 2001 11:03:12 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18338; Wed, 11 Jul 2001 11:03:28 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKU05466; Wed, 11 Jul 2001 11:03:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010711104805.00b2ba28@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 11:05:48 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Sip] Forking: a modest proposal. Cc: "'Dean Willis'" , adam.roach@ericsson.com, sip@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: quoted-printable Jonathan,

If you really want to push the call state to the edge, then there should be forking redirect servers, not proxies.  If forking is needed, the associated information should be sent back to the UAC and let it do the forking of requests and handling responses.  Some of the previous discussion indicates ambiguity over whether the forking proxy is handling the transaction responses or the UAC.  Doesn't seem clean to me.

The reason for the forking is service related, not session setup related and as such you open pandoras box to other service-related "cruft" being introduced to the base protocol.  It seems that the main advance of SIP over legacy protocols was that adherence to general purpose mechanisms that are not service specific.  Where the legacy systems made a distinction between basic call setup and supplementary services, they did not keep the protocol elements associated with each separate. 

Now, it appears that SIP has addressed the basic session setup elements and is facing the same issues of how to do more advance services as before.  Question is, do you start adding protocol elements that are needed by only certain classes of services?  After that, when do you stop?  Is there another way to handle service-specific data that is peculiar to an application (e.g. supplementary service) but not general to all sessions?

Mike


At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote:


 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Friday, July 06, 2001 9:30 PM
> To: adam.roach@ericsson.com; sip@ietf.org
> Subject: Re: [Sip] Forking: a modest proposal.
>
>
> Well, I've made the less modest proposal before that forking could be
> removed entirely from the specification. It seems to be an unpopular
> suggestion in some quarters, but I like to bring it up before
> IETF meetings
> as a matter of tradition (and in hopes that someday certain
> critical parties
> will agree).

Well, "some quarters" includes me, at least (maybe only me, but I hope not
:) ).

The reason its in the spec is, as Henning has pointed out, to avoid the
propagation of call state into the network. SIP was designed, first and
foremost, as a rendezvous type of protocol that could find a user at a
multitude of locations, and connect the caller to the called party across
different devices. In its role as a user discovery and connection protocol,
supporting the ability to reach a user at several devices is a big
reuqirement. Since we were also in the business of designing Internet
protocols, we wanted to push state to the edges, so that one could build a
system to do basic functions without all this cruft in the middle of the
network. Indeed, Jay has raised the flag on that in a separate note on this
thread. Removing forking from SIP means more of those B2BUAs. Lots more, I
think (in fact, pretty much all proxies will turn into B2BUAs as a default
mode). So, given its there already, I'd rather keep it, and instead, do a
far better job of explaining it in the spec. Its not really THAT hard, its
just that the spec is not exactly lucid on this, and many other, topics.

Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I
agree with Christian, and I think there is consensus on this, that forking
of a non-INVITE only makes sense if (1) that request establishes no state at
the UASes, and the set of servers that are reached are homogeneous, so that
a response from any are equivalent, or (2) a 3-way handshake can be created
in some other way, specific to the method. Now, I think its fair to say that
the usefulness of a method that meets (1) is not too high, and worse, we
can't guarantee this property for all methods. So, indeed, the question is
whether we feel its useful to define, on a method by method basis (or
perhaps there is a general purpose solution lurking somehwhere?), a
three-way handshake to deal with forked non-INVITE.

But, if its something that has to be done on a method-by-method basis,
perhaps that belongs in the application space, using a B2BUA. Now, maybe
this is contradicting myself, since I just argued above that forking of
INVITE belongs in the protocol, and not in the application space. But,
forking of these non-INVITEs is presumably a much less common ocurrence, so
that putting it in the application space is not as much a burden.

I'll be sure to put this topic on my running open-issues list for London.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.            = ;    72 Eagle Rock Ave.
Chief Scientist           &= nbsp;            = ;     First Floor
dynamicsoft           = ;            &nb= sp;         East Hanover, NJ 07936
jdrosen@dynamicsoft.com         = ;            FAX:   (973) 952-5050
http://www.jdrosen.net  = ;            &nb= sp;      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 13:22:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12318 for ; Wed, 11 Jul 2001 13:22:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10539; Wed, 11 Jul 2001 12:32:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10508 for ; Wed, 11 Jul 2001 12:32:27 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10155 for ; Wed, 11 Jul 2001 12:31:33 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17555 for ; Wed, 11 Jul 2001 12:31:31 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17551 for ; Wed, 11 Jul 2001 12:31:30 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10A27.14D863D4" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 10:32:31 -0600 Message-ID: Thread-Topic: [Sip] another modest proposal: change call-leg ID Thread-Index: AcEJ1CWppelJ4JoUQdKU0s2LLajPBwAUqCbA From: "Zmolek, Andrew (Andrew)" To: "Jonathan Rosenberg" Cc: "Grothe, Lew E (Lew)" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10A27.14D863D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan- Would your proposal in any way enable a rogue endpoint to alter or take over a session by replicating a valid set of Call-ID and tags?=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 11, 2001 12:30 AM To: 'sip@ietf.org' Subject: [Sip] another modest proposal: change call-leg ID Folks, While we're on the subject of modest proposals, here is another that I've been toying with: Change the definition of call-leg ID. Instead of To, To-tag, From, From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, the ID no longer contains the URLs. There are quite a few benefits from this: 1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The From field in this re-INVITE is NOT actually the identity of C, but rather, B. This screws up the idempotency of SIP INVITE. The From field has one meaning in INVITE, and another in re-INVITE. This makes defining policies based on the From field more complex, since they no longer work properly for re-INVITE.=20 2. call-leg ID lookups in gateways are much faster now, since the tags and call-ids are just strings. Matching is now case-sensitive string compares. Much easier than URL comparison.=20 3. Overlap dialing is easier. The reason we've had to send each digit as a new call leg, is that we needed to change the To field and the request URI. By definition, this meant a new call leg. Now, we can send all of that within a single call leg. Much cleaner. 4. The Replaces draft benefits. We've already identified a need for the Replaces header to identify the entire call leg thats being replaced. This gets big when it carries two URLs, two tags, and a call-id. Now, we can throw away the URLs. This shortens the header and makes matching of the call-leg IDs easier. 5. It works with existing proxies. THe main drawback, of course, is that this won't interoperate with rfc2543 UAs. Thats fixable with Supported; the UAC indicates Supported: new-call-leg-id in the INVITE if it understands this. In that case, any responses or re-invites that change the URLs include a Require: new-call-leg-id.=20 I fully admit that this may not be worth the pain. However, I'd welcome comments from others on whether its useful to consider further. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com =20 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C10A27.14D863D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] another modest proposal: change call-leg ID

Jonathan-

Would your proposal in any way enable a rogue endpoint = to alter or take over a session by replicating a valid set of Call-ID = and tags?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 11, 2001 12:30 AM
To: 'sip@ietf.org'
Subject: [Sip] another modest proposal: change = call-leg ID


Folks,

While we're on the subject of modest proposals, here = is another that I've
been toying with:

  Change the definition of call-leg ID. Instead = of To, To-tag, From,
  From-tag, and Call-ID, its *only* the tags and = the Call-ID. That is,
  the ID no longer contains the URLs.

There are quite a few benefits from this:

1. A calls B, and its forwarded to C. C accepts, and = later re-INVITEs. The
From field in this re-INVITE is NOT actually the = identity of C, but rather,
B. This screws up the idempotency of SIP INVITE. The = From field has one
meaning in INVITE, and another in re-INVITE. This = makes defining policies
based on the From field more complex, since they no = longer work properly for
re-INVITE.

2. call-leg ID lookups in gateways are much faster = now, since the tags and
call-ids are just strings. Matching is now = case-sensitive string compares.
Much easier than URL comparison.

3. Overlap dialing is easier. The reason we've had to = send each digit as a
new call leg, is that we needed to change the To = field and the request URI.
By definition, this meant a new call leg. Now, we can = send all of that
within a single call leg. Much cleaner.

4. The Replaces draft benefits. We've already = identified a need for the
Replaces header to identify the entire call leg thats = being replaced. This
gets big when it carries two URLs, two tags, and a = call-id. Now, we can
throw away the URLs. This shortens the header and = makes matching of the
call-leg IDs easier.

5. It works with existing proxies.

THe main drawback, of course, is that this won't = interoperate with rfc2543
UAs. Thats fixable with Supported; the UAC indicates = Supported:
new-call-leg-id in the INVITE if it understands this. = In that case, any
responses or re-invites that change the URLs include = a Require:
new-call-leg-id.

I fully admit that this may not be worth the pain. = However, I'd welcome
comments from others on whether its useful to = consider further.

-Jonathan R.


---
Jonathan D. Rosenberg, = Ph.D.           &n= bsp;    72 Eagle Rock Ave.
Chief = Scientist          &nbs= p;            = ;      First Floor
dynamicsoft         = ;            =             East = Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =   FAX:   (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000
http://www.dynamicsoft.com=
 

_______________________________________________
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C10A27.14D863D4-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 13:40:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12981 for ; Wed, 11 Jul 2001 13:40:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11407; Wed, 11 Jul 2001 13:08:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11376 for ; Wed, 11 Jul 2001 13:08:52 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11690 for ; Wed, 11 Jul 2001 13:08:01 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6BCw0ki025111; Wed, 11 Jul 2001 08:58:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSW2BL>; Wed, 11 Jul 2001 08:58:28 -0400 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Jonathan Rosenberg , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 08:58:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, July 11, 2001 8:21 AM > To: 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: RE: [Sip] another modest proposal: change call-leg ID > > > Hi Jonathan, > > I think this is a very interesting proposal that solves a few > problems, > makes many things _much_ easier to implement and potentially more CPU > efficient - definitely a modest proposal worth considering. > > I do however think that selection of the To & From tags must > be done with > more care if this suggestion is adopted (ie space & time > uniqueness of tags > is more crucial). For instance, the UAS MUST always choose a > To tag that is > different to the From tag so that the message direction can > be determined. > Of course, if tags are chosen to be properly globally unique > across space & > time (as they should be) then this is not a problem. Right. Note that Call-ID is already supposed to be globally unique, which helps. Choosing unique tags across space and time would also generally be useful for other purposes. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 14:59:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16133 for ; Wed, 11 Jul 2001 14:59:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13509; Wed, 11 Jul 2001 14:31:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13480 for ; Wed, 11 Jul 2001 14:31:12 -0400 (EDT) Received: from dal-mail2.ricochet.net (dal-mail1.ricochet.net [204.179.143.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14873 for ; Wed, 11 Jul 2001 14:30:20 -0400 (EDT) From: shh@ricochet.net Received: from shiv-mcet (mg-6311210-141.sfc2-mg2.ricochet.net [63.112.10.141]) by dal-mail2.ricochet.net (8.9.3/8.9.3) with SMTP id NAA14726; Wed, 11 Jul 2001 13:11:41 -0500 (CDT) Message-Id: <3.0.1.32.20010711112015.00e64e20@pop.ricochet.net> X-Sender: shh@pop.ricochet.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jul 2001 11:20:15 -0700 To: Jonathan Rosenberg , "'sip@ietf.org'" Subject: Re: [Sip] another modest proposal: change call-leg ID In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think this is an excellent proposal. I support this. While we are at it I would like to make another proposal, kind of related. Currently call-ids unnecessarily contain the IP address of the client. This gets into the way of hiding information in case of firewall traversal. One easy way would be to md5 this or some function that keeps the uniqueness of callid. Shiv Haris shh@microappliances.com At 02:30 AM 7/11/2001 -0400, Jonathan Rosenberg wrote: >Folks, > >While we're on the subject of modest proposals, here is another that I've >been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > >There are quite a few benefits from this: > >1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The >>From field in this re-INVITE is NOT actually the identity of C, but rather, >B. This screws up the idempotency of SIP INVITE. The From field has one >meaning in INVITE, and another in re-INVITE. This makes defining policies >based on the From field more complex, since they no longer work properly for >re-INVITE. > >2. call-leg ID lookups in gateways are much faster now, since the tags and >call-ids are just strings. Matching is now case-sensitive string compares. >Much easier than URL comparison. > >3. Overlap dialing is easier. The reason we've had to send each digit as a >new call leg, is that we needed to change the To field and the request URI. >By definition, this meant a new call leg. Now, we can send all of that >within a single call leg. Much cleaner. > >4. The Replaces draft benefits. We've already identified a need for the >Replaces header to identify the entire call leg thats being replaced. This >gets big when it carries two URLs, two tags, and a call-id. Now, we can >throw away the URLs. This shortens the header and makes matching of the >call-leg IDs easier. > >5. It works with existing proxies. > >THe main drawback, of course, is that this won't interoperate with rfc2543 >UAs. Thats fixable with Supported; the UAC indicates Supported: >new-call-leg-id in the INVITE if it understands this. In that case, any >responses or re-invites that change the URLs include a Require: >new-call-leg-id. > >I fully admit that this may not be worth the pain. However, I'd welcome >comments from others on whether its useful to consider further. > >-Jonathan R. > > >--- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 15:03:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16274 for ; Wed, 11 Jul 2001 15:03:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13615; Wed, 11 Jul 2001 14:38:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12997 for ; Wed, 11 Jul 2001 14:22:37 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14553 for ; Wed, 11 Jul 2001 14:21:42 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BHP0l18417; Wed, 11 Jul 2001 10:25:01 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAS02735; Wed, 11 Jul 2001 10:24:42 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06374; Wed, 11 Jul 2001 10:24:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.35801.300578.114666@thomasm-u1.cisco.com> Date: Wed, 11 Jul 2001 10:24:41 -0700 (PDT) To: Henning Schulzrinne Cc: Michael Thomas , "Gross, Gerhard" , "'bidulock@openss7.org'" , Jonathan Rosenberg , "'Rosen, Brian'" , "'Jiri Kuthan'" , Ashhar Farhan , "'sip@ietf.org'" Subject: Re: [SIP] Authentication and billing through proxy/re-direct server In-Reply-To: <3B467771.5549104B@cs.columbia.edu> References: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com> <15160.43070.343030.890219@thomasm-u1.cisco.com> <3B467771.5549104B@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > > > As Jonathan points out, this is trivially defrauded. > > > > The rule is simple: if you don't see the begin/end > > of the actual media stream (either directly or > > through some router that controls, say, QoS > > resources), or whatever other kind of session you > > In almost all cases, what matters is not the media stream, but the PSTN > signaling, since that determines the actual cost of call termination and > out-of-pocket expenses to other providers. It doesn't matter whether the > caller was talking or silent the whole time. While I don't disagree with your time-and-place kind of argument re PBX's, etc, there's a fairly trivial scenario which doesn't involve the PSTN that could lead to QoS fraud with untrustworthy cooperating UA's. The DQoS/media authorization draft talks about this ad-nauseum, but the basic point is that if you don't have some sort of choke on the media, then you're pretty wide open to people sending a BYE to the signaling intermediaries while happily honoring an X-Not-Really end to end. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 17:45:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21611 for ; Wed, 11 Jul 2001 17:45:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17392; Wed, 11 Jul 2001 17:31:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17363 for ; Wed, 11 Jul 2001 17:31:09 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21109 for ; Wed, 11 Jul 2001 17:30:19 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f6BLWlP23350; Wed, 11 Jul 2001 17:32:47 -0400 Message-Id: <5.1.0.14.2.20010711172649.02cc6340@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 17:27:48 -0400 To: "Zmolek, Andrew (Andrew)" , "Jonathan Rosenberg" From: Jay Batson Subject: RE: [Sip] another modest proposal: change call-leg ID Cc: "Grothe, Lew E (Lew)" , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_72913413==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_72913413==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed /me resists saying something like "Rogue endpoints? Nah -- nobody would ever *think* of building something uncontrolled, would they?" ;-) Just kidding. -jb At 12:32 PM 7/11/01, Zmolek, Andrew (Andrew) wrote: >Jonathan- > >Would your proposal in any way enable a rogue endpoint to alter or take >over a session by replicating a valid set of Call-ID and tags? > >--Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > >-----Original Message----- >From: Jonathan Rosenberg >[mailto:jdrosen@dynamicsoft.com] >Sent: Wednesday, July 11, 2001 12:30 AM >To: 'sip@ietf.org' >Subject: [Sip] another modest proposal: change call-leg ID > >Folks, > >While we're on the subject of modest proposals, here is another that I've >been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > >There are quite a few benefits from this: > >1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The > From field in this re-INVITE is NOT actually the identity of C, but rather, >B. This screws up the idempotency of SIP INVITE. The >From field has one >meaning in INVITE, and another in re-INVITE. This makes defining policies >based on the From field more complex, since they no longer work properly for >re-INVITE. > >2. call-leg ID lookups in gateways are much faster now, since the tags and >call-ids are just strings. Matching is now case-sensitive string compares. >Much easier than URL comparison. > >3. Overlap dialing is easier. The reason we've had to send each digit as a >new call leg, is that we needed to change the To field and the request URI. >By definition, this meant a new call leg. Now, we can send all of that >within a single call leg. Much cleaner. > >4. The Replaces draft benefits. We've already identified a need for the >Replaces header to identify the entire call leg thats being replaced. This >gets big when it carries two URLs, two tags, and a call-id. Now, we can >throw away the URLs. This shortens the header and makes matching of the >call-leg IDs easier. > >5. It works with existing proxies. > >THe main drawback, of course, is that this won't interoperate with rfc2543 >UAs. Thats fixable with Supported; the UAC indicates Supported: >new-call-leg-id in the INVITE if it understands this. In that case, any >responses or re-invites that change the URLs include a Require: >new-call-leg-id. > >I fully admit that this may not be worth the pain. However, I'd welcome >comments from others on whether its useful to consider further. > >-Jonathan R. > >--- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: >(973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing >list >http://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) --=====================_72913413==_.ALT Content-Type: text/html; charset="us-ascii" /me resists saying something like "Rogue endpoints?  Nah -- nobody would ever *think* of building something uncontrolled, would they?"  ;-)

Just kidding.
-jb


At 12:32 PM 7/11/01, Zmolek, Andrew (Andrew) wrote:

Jonathan-

Would your proposal in any way enable a rogue endpoint to alter or take over a session by replicating a valid set of Call-ID and tags?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 11, 2001 12:30 AM
To: 'sip@ietf.org'
Subject: [Sip] another modest proposal: change call-leg ID

Folks,

While we're on the subject of modest proposals, here is another that I've
been toying with:

  Change the definition of call-leg ID. Instead of To, To-tag, From,
  From-tag, and Call-ID, its *only* the tags and the Call-ID. That is,
  the ID no longer contains the URLs.

There are quite a few benefits from this:

1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The
From field in this re-INVITE is NOT actually the identity of C, but rather,
B. This screws up the idempotency of SIP INVITE. The >From field has one
meaning in INVITE, and another in re-INVITE. This makes defining policies
based on the From field more complex, since they no longer work properly for
re-INVITE.

2. call-leg ID lookups in gateways are much faster now, since the tags and
call-ids are just strings. Matching is now case-sensitive string compares.
Much easier than URL comparison.

3. Overlap dialing is easier. The reason we've had to send each digit as a
new call leg, is that we needed to change the To field and the request URI.
By definition, this meant a new call leg. Now, we can send all of that
within a single call leg. Much cleaner.

4. The Replaces draft benefits. We've already identified a need for the
Replaces header to identify the entire call leg thats being replaced. This
gets big when it carries two URLs, two tags, and a call-id. Now, we can
throw away the URLs. This shortens the header and makes matching of the
call-leg IDs easier.

5. It works with existing proxies.

THe main drawback, of course, is that this won't interoperate with rfc2543
UAs. Thats fixable with Supported; the UAC indicates Supported:
new-call-leg-id in the INVITE if it understands this. In that case, any
responses or re-invites that change the URLs include a Require:
new-call-leg-id.

I fully admit that this may not be worth the pain. However, I'd welcome
comments from others on whether its useful to consider further.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

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

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:jbatson@pingtel.com
781-938-5306 (office)

--=====================_72913413==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 17:45:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21641 for ; Wed, 11 Jul 2001 17:45:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17494; Wed, 11 Jul 2001 17:32:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17461 for ; Wed, 11 Jul 2001 17:32:24 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21138 for ; Wed, 11 Jul 2001 17:31:33 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6BLWGp19962; Wed, 11 Jul 2001 16:32:16 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6BLWGW10648; Wed, 11 Jul 2001 16:32:16 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA05214; Wed, 11 Jul 2001 16:32:15 -0500 (CDT) Reply-To: To: "'Henning Schulzrinne'" , Cc: "Paul Kyzivat" , "Jay Batson" , Subject: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) Date: Wed, 11 Jul 2001 16:32:14 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251934@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3B4C4B06.FAFBB58C@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > An additional use of B2BUAs is for media translation, but > this is really > only likely for multiparty calls, as quality is much better if you can > avoid transcoding. Sort of. Wireless-to-landline calls go through a GSM-to-G.711 transcoder; most wireless-to-wireless calls go GSM-to-G.711-to-GSM. (Substitute various other heavily-compressed codecs for "GSM" to make the above sentence apply all over the world). Since the audio characteristics of most phones is so crappy, and since an 8 kHz sampling rate is rather dismal, most people don't even notice. > (I may be underestimating the effect of the screwy > licensing for G.72x and various other low-rate codecs here, which also > could lead to more transcoding than is technically called for.) Three letters: AMR 3GPP is going for AMR as a default codec, with the implication that G.711 *will* *not* be used. Bakeoffs have shown that many firmware SIP implementations use G.711 exclusively. In the short term, transcoders will abound. This is why (I feel) we need to come up with a good architecture to support transcoding which doesn't require a B2BUA. No, I'm not proposing a work item (we do protocols, not architectures); I'm just thinking out loud. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 17:51:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21786 for ; Wed, 11 Jul 2001 17:51:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16986; Wed, 11 Jul 2001 17:28:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16896 for ; Wed, 11 Jul 2001 17:28:15 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21067 for ; Wed, 11 Jul 2001 17:27:24 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f6BLTlP23293; Wed, 11 Jul 2001 17:29:47 -0400 Message-Id: <5.1.0.14.2.20010711171630.02cd82f0@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 17:18:46 -0400 To: Michael Hammer From: Jay Batson Subject: RE: [Sip] Forking: a modest proposal. Cc: "'Dean Willis'" , adam.roach@ericsson.com, sip@ietf.org In-Reply-To: <4.3.2.7.2.20010711104805.00b2ba28@cia.cisco.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_72733174==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_72733174==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Very thoughtful response, Michael. I find it interesting that server companies aren't making much more extensive use of redirect. It scales well, it keeps (potentially unnecessary) servers out of a long list of Route-Recorded waystations that delay message delivery. Etc. I suspect it is because of business issues, not technical issues. If one is building a server, one needs insure that the server adds lots of value and stays "in the loop" sufficiently in order that that server pulls in enough revenue.... Especially if you don't make clients/UAs as well. Which is why folks like Sylantro, Broadsoft, and others (whom I'm not letting see this by virtue of *not* copying the list) are basically *not* implementing even Proxies, but full, big-honkin B2BUAs as their core architecture (I think). There is, in the product world, a deep temptation to be in the control loop wherever possible -- vs. wherever necessary.... Cheers -jb At 11:05 AM 7/11/01, you wrote: >Jonathan, > >If you really want to push the call state to the edge, then there should >be forking redirect servers, not proxies. If forking is needed, the >associated information should be sent back to the UAC and let it do the >forking of requests and handling responses. Some of the previous >discussion indicates ambiguity over whether the forking proxy is handling >the transaction responses or the UAC. Doesn't seem clean to me. > >The reason for the forking is service related, not session setup related >and as such you open pandoras box to other service-related "cruft" being >introduced to the base protocol. It seems that the main advance of SIP >over legacy protocols was that adherence to general purpose mechanisms >that are not service specific. Where the legacy systems made a >distinction between basic call setup and supplementary services, they did >not keep the protocol elements associated with each separate. > >Now, it appears that SIP has addressed the basic session setup elements >and is facing the same issues of how to do more advance services as >before. Question is, do you start adding protocol elements that are >needed by only certain classes of services? After that, when do you >stop? Is there another way to handle service-specific data that is >peculiar to an application (e.g. supplementary service) but not general to >all sessions? > >Mike > > >At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote: > > >> >> >> > -----Original Message----- >> > From: Dean Willis [mailto:dean.willis@softarmor.com] >> > Sent: Friday, July 06, 2001 9:30 PM >> > To: adam.roach@ericsson.com; sip@ietf.org >> > Subject: Re: [Sip] Forking: a modest proposal. >> > >> > >> > Well, I've made the less modest proposal before that forking could be >> > removed entirely from the specification. It seems to be an unpopular >> > suggestion in some quarters, but I like to bring it up before >> > IETF meetings >> > as a matter of tradition (and in hopes that someday certain >> > critical parties >> > will agree). >> >>Well, "some quarters" includes me, at least (maybe only me, but I hope not >>:) ). >> >>The reason its in the spec is, as Henning has pointed out, to avoid the >>propagation of call state into the network. SIP was designed, first and >>foremost, as a rendezvous type of protocol that could find a user at a >>multitude of locations, and connect the caller to the called party across >>different devices. In its role as a user discovery and connection protocol, >>supporting the ability to reach a user at several devices is a big >>reuqirement. Since we were also in the business of designing Internet >>protocols, we wanted to push state to the edges, so that one could build a >>system to do basic functions without all this cruft in the middle of the >>network. Indeed, Jay has raised the flag on that in a separate note on this >>thread. Removing forking from SIP means more of those B2BUAs. Lots more, I >>think (in fact, pretty much all proxies will turn into B2BUAs as a default >>mode). So, given its there already, I'd rather keep it, and instead, do a >>far better job of explaining it in the spec. Its not really THAT hard, its >>just that the spec is not exactly lucid on this, and many other, topics. >> >>Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I >>agree with Christian, and I think there is consensus on this, that forking >>of a non-INVITE only makes sense if (1) that request establishes no state at >>the UASes, and the set of servers that are reached are homogeneous, so that >>a response from any are equivalent, or (2) a 3-way handshake can be created >>in some other way, specific to the method. Now, I think its fair to say that >>the usefulness of a method that meets (1) is not too high, and worse, we >>can't guarantee this property for all methods. So, indeed, the question is >>whether we feel its useful to define, on a method by method basis (or >>perhaps there is a general purpose solution lurking somehwhere?), a >>three-way handshake to deal with forked non-INVITE. >> >>But, if its something that has to be done on a method-by-method basis, >>perhaps that belongs in the application space, using a B2BUA. Now, maybe >>this is contradicting myself, since I just argued above that forking of >>INVITE belongs in the protocol, and not in the application space. But, >>forking of these non-INVITEs is presumably a much less common ocurrence, so >>that putting it in the application space is not as much a burden. >> >>I'll be sure to put this topic on my running open-issues list for London. >> >>-Jonathan R. >>--- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>Sip mailing list http://www.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 >http://www.ietf.org/mailman/listinfo/sip This list is for NEW development >of the core SIP Protocol Use sip-implementors@cs.columbia.edu for >questions on current sip Use sipping@ietf.org for new developments on the >application of sip ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) --=====================_72733174==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Very thoughtful response, Michael.

I find it interesting that server companies aren't making much more extensive use of redirect.  It scales well, it keeps (potentially unnecessary) servers out of a long list of Route-Recorded waystations that delay message delivery.  Etc.

I suspect it is because of business issues, not technical issues.  If one is building a server, one needs insure that the server adds lots of value and stays "in the loop" sufficiently in order that that server pulls in enough revenue....

Especially if you don't make clients/UAs as well.  Which is why folks like Sylantro, Broadsoft, and others (whom I'm not letting see this by virtue of *not* copying the list) are basically *not* implementing even Proxies, but full, big-honkin B2BUAs as their core architecture (I think).

There is, in the product world, a deep temptation to be in the control loop wherever possible -- vs. wherever necessary....

Cheers
-jb

At 11:05 AM 7/11/01, you wrote:

Jonathan,

If you really want to push the call state to the edge, then there should be forking redirect servers, not proxies.  If forking is needed, the associated information should be sent back to the UAC and let it do the forking of requests and handling responses.  Some of the previous discussion indicates ambiguity over whether the forking proxy is handling the transaction responses or the UAC.  Doesn't seem clean to me.

The reason for the forking is service related, not session setup related and as such you open pandoras box to other service-related "cruft" being introduced to the base protocol.  It seems that the main advance of SIP over legacy protocols was that adherence to general purpose mechanisms that are not service specific.  Where the legacy systems made a distinction between basic call setup and supplementary services, they did not keep the protocol elements associated with each separate. 

Now, it appears that SIP has addressed the basic session setup elements and is facing the same issues of how to do more advance services as before.  Question is, do you start adding protocol elements that are needed by only certain classes of services?  After that, when do you stop?  Is there another way to handle service-specific data that is peculiar to an application (e.g. supplementary service) but not general to all sessions?

Mike


At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote:


 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Friday, July 06, 2001 9:30 PM
> To: adam.roach@ericsson.com; sip@ietf.org
> Subject: Re: [Sip] Forking: a modest proposal.
>
>
> Well, I've made the less modest proposal before that forking could be
> removed entirely from the specification. It seems to be an unpopular
> suggestion in some quarters, but I like to bring it up before
> IETF meetings
> as a matter of tradition (and in hopes that someday certain
> critical parties
> will agree).

Well, "some quarters" includes me, at least (maybe only me, but I hope not
:) ).

The reason its in the spec is, as Henning has pointed out, to avoid the
propagation of call state into the network. SIP was designed, first and
foremost, as a rendezvous type of protocol that could find a user at a
multitude of locations, and connect the caller to the called party across
different devices. In its role as a user discovery and connection protocol,
supporting the ability to reach a user at several devices is a big
reuqirement. Since we were also in the business of designing Internet
protocols, we wanted to push state to the edges, so that one could build a
system to do basic functions without all this cruft in the middle of the
network. Indeed, Jay has raised the flag on that in a separate note on this
thread. Removing forking from SIP means more of those B2BUAs. Lots more, I
think (in fact, pretty much all proxies will turn into B2BUAs as a default
mode). So, given its there already, I'd rather keep it, and instead, do a
far better job of explaining it in the spec. Its not really THAT hard, its
just that the spec is not exactly lucid on this, and many other, topics.

Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I
agree with Christian, and I think there is consensus on this, that forking
of a non-INVITE only makes sense if (1) that request establishes no state at
the UASes, and the set of servers that are reached are homogeneous, so that
a response from any are equivalent, or (2) a 3-way handshake can be created
in some other way, specific to the method. Now, I think its fair to say that
the usefulness of a method that meets (1) is not too high, and worse, we
can't guarantee this property for all methods. So, indeed, the question is
whether we feel its useful to define, on a method by method basis (or
perhaps there is a general purpose solution lurking somehwhere?), a
three-way handshake to deal with forked non-INVITE.

But, if its something that has to be done on a method-by-method basis,
perhaps that belongs in the application space, using a B2BUA. Now, maybe
this is contradicting myself, since I just argued above that forking of
INVITE belongs in the protocol, and not in the application space. But,
forking of these non-INVITEs is presumably a much less common ocurrence, so
that putting it in the application space is not as much a burden.

I'll be sure to put this topic on my running open-issues list for London.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.            = ;    72 Eagle Rock Ave.
Chief Scientist           &= nbsp;            = ;     First Floor
dynamicsoft           = ;            &nb= sp;         East Hanover, NJ 07936
jdrosen@dynamicsoft.com         = ;            FAX:   (973) 952-5050
http://www.jdrosen.net   &n= bsp;            =   PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 http= ://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use= sip-implementors@cs.columbia.edu for questions on current sip Use= sipping@ietf.org for new developments on the application of sip=

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:jbatson@pingtel.com
781-938-5306 (office)

--=====================_72733174==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 17:55:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21889 for ; Wed, 11 Jul 2001 17:55:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17860; Wed, 11 Jul 2001 17:48:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17833 for ; Wed, 11 Jul 2001 17:48:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21670 for ; Wed, 11 Jul 2001 17:47:41 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA12755; Wed, 11 Jul 2001 17:47:53 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07832; Wed, 11 Jul 2001 17:47:57 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 17:47:55 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465771@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'adam.roach@ericsson.com'" , "'Henning Schulzrinne'" , Juan-Carlos.Rojas@alcatel.fr Cc: Paul Kyzivat , Jay Batson , sip@ietf.org Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Date: Wed, 11 Jul 2001 17:47:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My .02 on this is that we should aim, as much as possible for DESTINATION TRANSCODING. There are other names for this. Basically, in means that the end device, whatever it may be should, in as many cases as possible, accept whatever may be thrown at it, and convert it ONCE to whatever it needs to. This allows, for example, a mobile-to-mobile call to have zero to one transcode stages, and not require -711-. Of course you can never enforce this, and you have to allow for transcoders in the middle, but it really makes the quality go down fast to have two transcoding stages. The thing to remember is that intermediate steps often don't know what the REAL destination coder is, they tend to only know the coder at the edge of their own domain. Brian Brian > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Wednesday, July 11, 2001 5:32 PM > To: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr > Cc: Paul Kyzivat; Jay Batson; sip@ietf.org > Subject: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > proposal.) > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > > > An additional use of B2BUAs is for media translation, but > > this is really > > only likely for multiparty calls, as quality is much better > if you can > > avoid transcoding. > > Sort of. Wireless-to-landline calls go through a GSM-to-G.711 > transcoder; most wireless-to-wireless calls go GSM-to-G.711-to-GSM. > (Substitute various other heavily-compressed codecs for "GSM" to > make the above sentence apply all over the world). > > Since the audio characteristics of most phones is so crappy, and > since an 8 kHz sampling rate is rather dismal, most people don't > even notice. > > > (I may be underestimating the effect of the screwy > > licensing for G.72x and various other low-rate codecs here, > which also > > could lead to more transcoding than is technically called for.) > > Three letters: AMR > > 3GPP is going for AMR as a default codec, with the implication that > G.711 *will* *not* be used. > > Bakeoffs have shown that many firmware SIP implementations use > G.711 exclusively. > > In the short term, transcoders will abound. > > This is why (I feel) we need to come up with a good architecture > to support transcoding which doesn't require a B2BUA. No, I'm not > proposing a work item (we do protocols, not architectures); I'm > just thinking out loud. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 18:03:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22149 for ; Wed, 11 Jul 2001 18:03:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17736; Wed, 11 Jul 2001 17:41:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17707 for ; Wed, 11 Jul 2001 17:41:34 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21421 for ; Wed, 11 Jul 2001 17:40:42 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51MBTR>; Wed, 11 Jul 2001 14:40:41 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'shh@ricochet.net'" , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 14:40:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Shiv, Please reread bis-03. UA's concerned about revealing their identity are not required to include their address. bis-3 says abotu Call-ID: --- callid = token [ "@" token ] Call-ID = ( "Call-ID" j "i" ) ":" callid The callid MUST be a globally unique identifier and MUST NOT be reused for later calls. Use of crypto-graphically random identifiers [28] is RECOMMENDED. Implementations MAY use the form "localid@host". Call-IDs are case-sensitive and are simply compared byte-by-byte. --- Robert. > -----Original Message----- > From: shh@ricochet.net [mailto:shh@ricochet.net] > Sent: Wednesday, July 11, 2001 7:20 PM > To: Jonathan Rosenberg; 'sip@ietf.org' > Subject: Re: [Sip] another modest proposal: change call-leg ID > > > > I think this is an excellent proposal. I support this. > > While we are at it I would like to make another proposal, > kind of related. > Currently call-ids unnecessarily contain the IP address of the client. > This gets into the way of hiding information in case of firewall > traversal. One easy way would be to md5 this or some function > that keeps the uniqueness of callid. > > Shiv Haris > shh@microappliances.com > > At 02:30 AM 7/11/2001 -0400, Jonathan Rosenberg wrote: > >Folks, > > > >While we're on the subject of modest proposals, here is > another that I've > >been toying with: > > > > Change the definition of call-leg ID. Instead of To, To-tag, From, > > From-tag, and Call-ID, its *only* the tags and the > Call-ID. That is, > > the ID no longer contains the URLs. > > > >There are quite a few benefits from this: > > > >1. A calls B, and its forwarded to C. C accepts, and later > re-INVITEs. The > >>From field in this re-INVITE is NOT actually the identity > of C, but rather, > >B. This screws up the idempotency of SIP INVITE. The From > field has one > >meaning in INVITE, and another in re-INVITE. This makes > defining policies > >based on the From field more complex, since they no longer > work properly for > >re-INVITE. > > > >2. call-leg ID lookups in gateways are much faster now, > since the tags and > >call-ids are just strings. Matching is now case-sensitive > string compares. > >Much easier than URL comparison. > > > >3. Overlap dialing is easier. The reason we've had to send > each digit as a > >new call leg, is that we needed to change the To field and > the request URI. > >By definition, this meant a new call leg. Now, we can send > all of that > >within a single call leg. Much cleaner. > > > >4. The Replaces draft benefits. We've already identified a > need for the > >Replaces header to identify the entire call leg thats being > replaced. This > >gets big when it carries two URLs, two tags, and a call-id. > Now, we can > >throw away the URLs. This shortens the header and makes > matching of the > >call-leg IDs easier. > > > >5. It works with existing proxies. > > > >THe main drawback, of course, is that this won't > interoperate with rfc2543 > >UAs. Thats fixable with Supported; the UAC indicates Supported: > >new-call-leg-id in the INVITE if it understands this. In > that case, any > >responses or re-invites that change the URLs include a Require: > >new-call-leg-id. > > > >I fully admit that this may not be worth the pain. However, > I'd welcome > >comments from others on whether its useful to consider further. > > > >-Jonathan R. > > > > > >--- > >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.jdrosen.net PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > > > >_______________________________________________ > >Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 18:03:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22167 for ; Wed, 11 Jul 2001 18:03:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18084; Wed, 11 Jul 2001 17:56:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17994 for ; Wed, 11 Jul 2001 17:56:24 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21886 for ; Wed, 11 Jul 2001 17:55:32 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51MBV3>; Wed, 11 Jul 2001 14:55:31 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jay Batson'" , "Zmolek, Andrew (Andrew)" , Jonathan Rosenberg Cc: "Grothe, Lew E (Lew)" , sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 14:55:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think people can always build rogue endpoints or proxies but as far as I can see this proposal doesn't change the "security" situation. If the rogue entity can change/replicate the tag value then it could just as easily change/replicate the whole URL (and vice versa). Additionally if authentication is employed then the tag is just as protected as the whole URL (since it is a subset). It does however raise the point that if a message is signed then an intermediate proxy may not modify the rest of the URL (while maintaining the same tag value) but I think this is a desirable rather than undesirable property. [Just as a proxy may not currently change the display name on a signed message even though this does not affect the call-leg id.] Cheers, Robert. -----Original Message----- From: Jay Batson [mailto:jbatson@pingtel.com] Sent: Wednesday, July 11, 2001 10:28 PM To: Zmolek, Andrew (Andrew); Jonathan Rosenberg Cc: Grothe, Lew E (Lew); sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID /me resists saying something like "Rogue endpoints? Nah -- nobody would ever *think* of building something uncontrolled, would they?" ;-) Just kidding. -jb At 12:32 PM 7/11/01, Zmolek, Andrew (Andrew) wrote: Jonathan- Would your proposal in any way enable a rogue endpoint to alter or take over a session by replicating a valid set of Call-ID and tags? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Wednesday, July 11, 2001 12:30 AM To: 'sip@ietf.org' Subject: [Sip] another modest proposal: change call-leg ID Folks, While we're on the subject of modest proposals, here is another that I've been toying with: Change the definition of call-leg ID. Instead of To, To-tag, From, From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, the ID no longer contains the URLs. There are quite a few benefits from this: 1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The From field in this re-INVITE is NOT actually the identity of C, but rather, B. This screws up the idempotency of SIP INVITE. The >From field has one meaning in INVITE, and another in re-INVITE. This makes defining policies based on the From field more complex, since they no longer work properly for re-INVITE. 2. call-leg ID lookups in gateways are much faster now, since the tags and call-ids are just strings. Matching is now case-sensitive string compares. Much easier than URL comparison. 3. Overlap dialing is easier. The reason we've had to send each digit as a new call leg, is that we needed to change the To field and the request URI. By definition, this meant a new call leg. Now, we can send all of that within a single call leg. Much cleaner. 4. The Replaces draft benefits. We've already identified a need for the Replaces header to identify the entire call leg thats being replaced. This gets big when it carries two URLs, two tags, and a call-id. Now, we can throw away the URLs. This shortens the header and makes matching of the call-leg IDs easier. 5. It works with existing proxies. THe main drawback, of course, is that this won't interoperate with rfc2543 UAs. Thats fixable with Supported; the UAC indicates Supported: new-call-leg-id in the INVITE if it understands this. In that case, any responses or re-invites that change the URLs include a Require: new-call-leg-id. I fully admit that this may not be worth the pain. However, I'd welcome comments from others on whether its useful to consider further. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 18:22:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22672 for ; Wed, 11 Jul 2001 18:22:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17968; Wed, 11 Jul 2001 17:55:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17941 for ; Wed, 11 Jul 2001 17:55:40 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21857 for ; Wed, 11 Jul 2001 17:54:48 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6BLsu507594; Wed, 11 Jul 2001 16:54:56 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6BLsuW19904; Wed, 11 Jul 2001 16:54:56 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA06301; Wed, 11 Jul 2001 16:54:55 -0500 (CDT) Reply-To: To: "'Jay Batson'" , "Zmolek, Andrew (Andrew)" , "Jonathan Rosenberg" Cc: "Grothe, Lew E (Lew)" , Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 16:54:53 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251937@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <5.1.0.14.2.20010711172649.02cc6340@mail.pingtel.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yeah, yeah -- you never stir the pot just for the sake of it, Jay. :) To address Andrew's question: it is completely unclear how this would allow hijacking of a call any more than the previous schemes did. If a system is set up in a way that is so brittle as to allow the call to be taken over with just tags, that same system will have an identical problem under the current scheme, in which it could be hijacked using tags and URIs. Or I could be missing something. Outline a hypothetical situation in which a call could be hijacked under the scheme Jonathan proposes, but in such a way that is not currently possible. /a -----Original Message----- From: Jay Batson [mailto:jbatson@pingtel.com] Sent: Wednesday, July 11, 2001 4:28 PM To: Zmolek, Andrew (Andrew); Jonathan Rosenberg Cc: Grothe, Lew E (Lew); sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID /me resists saying something like "Rogue endpoints? Nah -- nobody would ever *think* of building something uncontrolled, would they?" ;-) Just kidding. -jb At 12:32 PM 7/11/01, Zmolek, Andrew (Andrew) wrote: Jonathan- Would your proposal in any way enable a rogue endpoint to alter or take over a session by replicating a valid set of Call-ID and tags? --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 11, 2001 12:30 AM To: 'sip@ietf.org' Subject: [Sip] another modest proposal: change call-leg ID Folks, While we're on the subject of modest proposals, here is another that I've been toying with: Change the definition of call-leg ID. Instead of To, To-tag, From, From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, the ID no longer contains the URLs. There are quite a few benefits from this: 1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The From field in this re-INVITE is NOT actually the identity of C, but rather, B. This screws up the idempotency of SIP INVITE. The >From field has one meaning in INVITE, and another in re-INVITE. This makes defining policies based on the From field more complex, since they no longer work properly for re-INVITE. 2. call-leg ID lookups in gateways are much faster now, since the tags and call-ids are just strings. Matching is now case-sensitive string compares. Much easier than URL comparison. 3. Overlap dialing is easier. The reason we've had to send each digit as a new call leg, is that we needed to change the To field and the request URI. By definition, this meant a new call leg. Now, we can send all of that within a single call leg. Much cleaner. 4. The Replaces draft benefits. We've already identified a need for the Replaces header to identify the entire call leg thats being replaced. This gets big when it carries two URLs, two tags, and a call-id. Now, we can throw away the URLs. This shortens the header and makes matching of the call-leg IDs easier. 5. It works with existing proxies. THe main drawback, of course, is that this won't interoperate with rfc2543 UAs. Thats fixable with Supported; the UAC indicates Supported: new-call-leg-id in the INVITE if it understands this. In that case, any responses or re-invites that change the URLs include a Require: new-call-leg-id. I fully admit that this may not be worth the pain. However, I'd welcome comments from others on whether its useful to consider further. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 18:24:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22756 for ; Wed, 11 Jul 2001 18:24:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18507; Wed, 11 Jul 2001 18:06:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18478 for ; Wed, 11 Jul 2001 18:06:31 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22283 for ; Wed, 11 Jul 2001 18:05:40 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6BM5I511615; Wed, 11 Jul 2001 17:05:18 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6BM5He16039; Wed, 11 Jul 2001 17:05:17 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA06718; Wed, 11 Jul 2001 17:05:17 -0500 (CDT) Reply-To: To: "'Rosen, Brian'" , , "'Henning Schulzrinne'" , Cc: "Paul Kyzivat" , "Jay Batson" , Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Date: Wed, 11 Jul 2001 17:05:15 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251938@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <4FBEA8857476D311A03300204840E1CF04465771@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On IP, transcoding is best accomplished as you describe. I think you missed my point, though: I was illustrating the fact that an absurd amount of transcoding goes on currently, and that it doesn't really hurt because phones sound crappy to start with. People put up with transcoding, and cannot usually tell the difference. The single codec conversion of which you speak is what I'm referring to when I say that we need a good, non-B2BUA solution for transcoding. To summarize what I was trying to say: transcoders will be present. They should not break the signaling. We need to make this happen. /a > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, July 11, 2001 4:48 PM > To: 'adam.roach@ericsson.com'; 'Henning Schulzrinne'; > Juan-Carlos.Rojas@alcatel.fr > Cc: Paul Kyzivat; Jay Batson; sip@ietf.org > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > proposa l.) > > > My .02 on this is that we should aim, as much as possible > for DESTINATION TRANSCODING. There are other names for this. > > Basically, in means that the end device, whatever it may be > should, in as many cases as possible, accept whatever > may be thrown at it, and convert it ONCE to whatever it > needs to. This allows, for example, a mobile-to-mobile > call to have zero to one transcode stages, and not require > -711-. > > Of course you can never enforce this, and you have to > allow for transcoders in the middle, but it really > makes the quality go down fast to have two transcoding > stages. The thing to remember is that intermediate > steps often don't know what the REAL destination coder is, > they tend to only know the coder at the edge of their own > domain. > > Brian > > Brian > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Wednesday, July 11, 2001 5:32 PM > > To: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr > > Cc: Paul Kyzivat; Jay Batson; sip@ietf.org > > Subject: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > > proposal.) > > > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > > > > > An additional use of B2BUAs is for media translation, but > > > this is really > > > only likely for multiparty calls, as quality is much better > > if you can > > > avoid transcoding. > > > > Sort of. Wireless-to-landline calls go through a GSM-to-G.711 > > transcoder; most wireless-to-wireless calls go GSM-to-G.711-to-GSM. > > (Substitute various other heavily-compressed codecs for "GSM" to > > make the above sentence apply all over the world). > > > > Since the audio characteristics of most phones is so crappy, and > > since an 8 kHz sampling rate is rather dismal, most people don't > > even notice. > > > > > (I may be underestimating the effect of the screwy > > > licensing for G.72x and various other low-rate codecs here, > > which also > > > could lead to more transcoding than is technically called for.) > > > > Three letters: AMR > > > > 3GPP is going for AMR as a default codec, with the implication that > > G.711 *will* *not* be used. > > > > Bakeoffs have shown that many firmware SIP implementations use > > G.711 exclusively. > > > > In the short term, transcoders will abound. > > > > This is why (I feel) we need to come up with a good architecture > > to support transcoding which doesn't require a B2BUA. No, I'm not > > proposing a work item (we do protocols, not architectures); I'm > > just thinking out loud. > > > > /a > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 18:30:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23005 for ; Wed, 11 Jul 2001 18:30:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18550; Wed, 11 Jul 2001 18:07:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18520 for ; Wed, 11 Jul 2001 18:07:03 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22286 for ; Wed, 11 Jul 2001 18:06:12 -0400 (EDT) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f6BM8gP23763; Wed, 11 Jul 2001 18:08:42 -0400 Message-Id: <5.1.0.14.2.20010711173513.00ace590@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jul 2001 17:37:58 -0400 To: "Henning G. Schulzrinne" From: Jay Batson Subject: Re: [Sip] Forking: a modest proposal. Cc: sip@ietf.org In-Reply-To: <3B4CC5B5.AF723CC1@cs.columbia.edu> References: <5.1.0.14.2.20010711171630.02cd82f0@mail.pingtel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_75065508==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_75065508==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Well, that email wasn't, in fact, actually intended to go to the list. In fact, it was plain and simple bad form to *NOT* make my comments publicly in the first place, vs. making them instead in a private email. For this I dutifully suck up to, and offer my apologies to our buddies at Broadsoft and Sylantro. Despite this, I stand by my observations on the use of B2BUAs, redirect servers, etc. in my prior email. I know that, as far as I am concerned, I don what little bit of Engineering Hat I have left to me when I contribute to this forum. In that role, I use the list to speak my mind -- without particular regard to how it might sound to our partners. I simply remind our partners to remember that I *do* wear a different hat -- a business / strategic relationship hat. And in that role, I remain fully committed to cause Pingtel to work hard to grow this market with *all* SIP product vendors -- technical differences aside. On a continuing basis, though, I trust that all of us -- myself included -- can feel free to make use of this kind of forum to have healthy disagreements about things *on the way to* working together. Cheers -jb At 05:31 PM 7/11/01, you wrote: >Jay Batson wrote: > > > > Very thoughtful response, Michael. > > > > I find it interesting that server companies aren't making much more > > extensive use of redirect. It scales well, it keeps (potentially > > unnecessary) servers out of a long list of Route-Recorded waystations > > that delay message delivery. Etc. > > > > I suspect it is because of business issues, not technical issues. If > > one is building a server, one needs insure that the server adds lots > > of value and stays "in the loop" sufficiently in order that that > > server pulls in enough revenue.... > > > > Especially if you don't make clients/UAs as well. Which is why folks > > like Sylantro, Broadsoft, and others (whom I'm not letting see this by > >Actually, you did copy sip@ietf.org - unless this was meant as a joke... > > > > virtue of *not* copying the list) are basically *not* implementing > > even Proxies, but full, big-honkin B2BUAs as their core architecture > > (I think). > > > > There is, in the product world, a deep temptation to be in the control > > loop wherever possible -- vs. wherever necessary.... > > > > Cheers > > -jb > > > > At 11:05 AM 7/11/01, you wrote: > > > > > Jonathan, > > > > > > If you really want to push the call state to the edge, then there > > > should be forking redirect servers, not proxies. If forking is > > > needed, the associated information should be sent back to the UAC > > > and let it do the forking of requests and handling responses. Some > > > of the previous discussion indicates ambiguity over whether the > > > forking proxy is handling the transaction responses or the UAC. > > > Doesn't seem clean to me. > > > > > > The reason for the forking is service related, not session setup > > > related and as such you open pandoras box to other service-related > > > "cruft" being introduced to the base protocol. It seems that the > > > main advance of SIP over legacy protocols was that adherence to > > > general purpose mechanisms that are not service specific. Where the > > > legacy systems made a distinction between basic call setup and > > > supplementary services, they did not keep the protocol elements > > > associated with each separate. > > > > > > Now, it appears that SIP has addressed the basic session setup > > > elements and is facing the same issues of how to do more advance > > > services as before. Question is, do you start adding protocol > > > elements that are needed by only certain classes of services? After > > > that, when do you stop? Is there another way to handle > > > service-specific data that is peculiar to an application (e.g. > > > supplementary service) but not general to all sessions? > > > > > > Mike > > > > > > > > > At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote: > > > > > > > > >> > > >> > > >> > -----Original Message----- > > >> > From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> > Sent: Friday, July 06, 2001 9:30 PM > > >> > To: adam.roach@ericsson.com; sip@ietf.org > > >> > Subject: Re: [Sip] Forking: a modest proposal. > > >> > > > >> > > > >> > Well, I've made the less modest proposal before that forking > > >> could be > > >> > removed entirely from the specification. It seems to be an > > >> unpopular > > >> > suggestion in some quarters, but I like to bring it up before > > >> > IETF meetings > > >> > as a matter of tradition (and in hopes that someday certain > > >> > critical parties > > >> > will agree). > > >> > > >> Well, "some quarters" includes me, at least (maybe only me, but I > > >> hope not > > >> :) ). > > >> > > >> The reason its in the spec is, as Henning has pointed out, to > > >> avoid the > > >> propagation of call state into the network. SIP was designed, > > >> first and > > >> foremost, as a rendezvous type of protocol that could find a user > > >> at a > > >> multitude of locations, and connect the caller to the called party > > >> across > > >> different devices. In its role as a user discovery and connection > > >> protocol, > > >> supporting the ability to reach a user at several devices is a big > > >> reuqirement. Since we were also in the business of designing > > >> Internet > > >> protocols, we wanted to push state to the edges, so that one could > > >> build a > > >> system to do basic functions without all this cruft in the middle > > >> of the > > >> network. Indeed, Jay has raised the flag on that in a separate > > >> note on this > > >> thread. Removing forking from SIP means more of those B2BUAs. Lots > > >> more, I > > >> think (in fact, pretty much all proxies will turn into B2BUAs as a > > >> default > > >> mode). So, given its there already, I'd rather keep it, and > > >> instead, do a > > >> far better job of explaining it in the spec. Its not really THAT > > >> hard, its > > >> just that the spec is not exactly lucid on this, and many other, > > >> topics. > > >> > > >> Now, back to the original question: to fork, or not-to-fork, > > >> non-INVITEs. I > > >> agree with Christian, and I think there is consensus on this, that > > >> forking > > >> of a non-INVITE only makes sense if (1) that request establishes > > >> no state at > > >> the UASes, and the set of servers that are reached are > > >> homogeneous, so that > > >> a response from any are equivalent, or (2) a 3-way handshake can > > >> be created > > >> in some other way, specific to the method. Now, I think its fair > > >> to say that > > >> the usefulness of a method that meets (1) is not too high, and > > >> worse, we > > >> can't guarantee this property for all methods. So, indeed, the > > >> question is > > >> whether we feel its useful to define, on a method by method basis > > >> (or > > >> perhaps there is a general purpose solution lurking somehwhere?), > > >> a > > >> three-way handshake to deal with forked non-INVITE. > > >> > > >> But, if its something that has to be done on a method-by-method > > >> basis, > > >> perhaps that belongs in the application space, using a B2BUA. Now, > > >> maybe > > >> this is contradicting myself, since I just argued above that > > >> forking of > > >> INVITE belongs in the protocol, and not in the application space. > > >> But, > > >> forking of these non-INVITEs is presumably a much less common > > >> ocurrence, so > > >> that putting it in the application space is not as much a burden. > > >> > > >> I'll be sure to put this topic on my running open-issues list for > > >> London. > > >> > > >> -Jonathan R. > > >> --- > > >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > >> Chief Scientist First Floor > > >> dynamicsoft East Hanover, NJ 07936 > > >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > >> http://www.jdrosen.net PHONE: (973) 952-5000 > > >> http://www.dynamicsoft.com > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP 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 > > > http://www.ietf.org/mailman/listinfo/sip This list is for NEW > > > development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > ------------- > > PingMe! > > Jay Batson > > CEO > > Pingtel Corp. > > mailto:jbatson@pingtel.com > > 781-938-5306 (office) > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) --=====================_75065508==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, that email wasn't, in fact, actually intended to go to the list.  In fact, it was plain and simple bad form to *NOT* make my comments publicly in the first place, vs. making them instead in a private email.  For this I dutifully suck up to, and offer my apologies to our buddies at Broadsoft and Sylantro.

Despite this, I stand by my observations on the use of B2BUAs, redirect servers, etc. in my prior email.  I know that, as far as I am concerned, I don what little bit of Engineering Hat I have left to me when I contribute to this forum.  In that role, I use the list to speak my mind -- without particular regard to how it might sound to our partners.

I simply remind our partners to remember that I *do* wear a different hat -- a business / strategic relationship hat.  And in that role, I remain fully committed to cause Pingtel to work hard to grow this market with *all* SIP product vendors -- technical differences aside.

On a continuing basis, though, I trust that all of us -- myself included -- can feel free to make use of this kind of forum to have healthy disagreements about things *on the way to* working together.

Cheers
-jb

At 05:31 PM 7/11/01, you wrote:

Jay Batson wrote:
>
> Very thoughtful response, Michael.
>
> I find it interesting that server companies aren't making much more
> extensive use of redirect.  It scales well, it keeps (potentially
> unnecessary) servers out of a long list of Route-Recorded waystations
> that delay message delivery.  Etc.
>
> I suspect it is because of business issues, not technical issues.  If
> one is building a server, one needs insure that the server adds lots
> of value and stays "in the loop" sufficiently in order that that
> server pulls in enough revenue....
>
> Especially if you don't make clients/UAs as well.  Which is why folks
> like Sylantro, Broadsoft, and others (whom I'm not letting see this by

Actually, you did copy sip@ietf.org - unless this was meant as a joke...


> virtue of *not* copying the list) are basically *not* implementing
> even Proxies, but full, big-honkin B2BUAs as their core architecture
> (I think).
>
> There is, in the product world, a deep temptation to be in the control
> loop wherever possible -- vs. wherever necessary....
>
> Cheers
> -jb
>
> At 11:05 AM 7/11/01, you wrote:
>
> > Jonathan,
> >
> > If you really want to push the call state to the edge, then there
> > should be forking redirect servers, not proxies.  If forking is
> > needed, the associated information should be sent back to the UAC
> > and let it do the forking of requests and handling responses.  Some
> > of the previous discussion indicates ambiguity over whether the
> > forking proxy is handling the transaction responses or the UAC.
> > Doesn't seem clean to me.
> >
> > The reason for the forking is service related, not session setup
> > related and as such you open pandoras box to other service-related
> > "cruft" being introduced to the base protocol.  It seems that the
> > main advance of SIP over legacy protocols was that adherence to
> > general purpose mechanisms that are not service specific.  Where the
> > legacy systems made a distinction between basic call setup and
> > supplementary services, they did not keep the protocol elements
> > associated with each separate.
> >
> > Now, it appears that SIP has addressed the basic session setup
> > elements and is facing the same issues of how to do more advance
> > services as before.  Question is, do you start adding protocol
> > elements that are needed by only certain classes of services?  After
> > that, when do you stop?  Is there another way to handle
> > service-specific data that is peculiar to an application (e.g.
> > supplementary service) but not general to all sessions?
> >
> > Mike
> >
> >
> > At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote:
> >
> >
> >>
> >>
> >> > -----Original Message-----
> >> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> >> > Sent: Friday, July 06, 2001 9:30 PM
> >> > To: adam.roach@ericsson.com; sip@ietf.org
> >> > Subject: Re: [Sip] Forking: a modest proposal.
> >> >
> >> >
> >> > Well, I've made the less modest proposal before that forking
> >> could be
> >> > removed entirely from the specification. It seems to be an
> >> unpopular
> >> > suggestion in some quarters, but I like to bring it up before
> >> > IETF meetings
> >> > as a matter of tradition (and in hopes that someday certain
> >> > critical parties
> >> > will agree).
> >>
> >> Well, "some quarters" includes me, at least (maybe only me, but I
> >> hope not
> >> :) ).
> >>
> >> The reason its in the spec is, as Henning has pointed out, to
> >> avoid the
> >> propagation of call state into the network. SIP was designed,
> >> first and
> >> foremost, as a rendezvous type of protocol that could find a user
> >> at a
> >> multitude of locations, and connect the caller to the called party
> >> across
> >> different devices. In its role as a user discovery and connection
> >> protocol,
> >> supporting the ability to reach a user at several devices is a big
> >> reuqirement. Since we were also in the business of designing
> >> Internet
> >> protocols, we wanted to push state to the edges, so that one could
> >> build a
> >> system to do basic functions without all this cruft in the middle
> >> of the
> >> network. Indeed, Jay has raised the flag on that in a separate
> >> note on this
> >> thread. Removing forking from SIP means more of those B2BUAs. Lots
> >> more, I
> >> think (in fact, pretty much all proxies will turn into B2BUAs as a
> >> default
> >> mode). So, given its there already, I'd rather keep it, and
> >> instead, do a
> >> far better job of explaining it in the spec. Its not really THAT
> >> hard, its
> >> just that the spec is not exactly lucid on this, and many other,
> >> topics.
> >>
> >> Now, back to the original question: to fork, or not-to-fork,
> >> non-INVITEs. I
> >> agree with Christian, and I think there is consensus on this, that
> >> forking
> >> of a non-INVITE only makes sense if (1) that request establishes
> >> no state at
> >> the UASes, and the set of servers that are reached=20 are
> >> homogeneous, so that
> >> a response from any are equivalent, or (2) a 3-way handshake can
> >> be created
> >> in some other way, specific to the method. Now, I think its fair
> >> to say that
> >> the usefulness of a method that meets (1) is not too high, and
> >> worse, we
> >> can't guarantee this property for all methods. So, indeed, the
> >> question is
> >> whether we feel its useful to define, on a method by method basis
> >> (or
> >> perhaps there is a general purpose solution lurking somehwhere?),
> >> a
> >> three-way handshake to deal with forked non-INVITE.
> >>
> >> But, if its something that has to be done on a method-by-method
> >> basis,
> >> perhaps that belongs in the application space, using a B2BUA. Now,
> >> maybe
> >> this is contradicting myself, since I just argued above that
> >> forking of
> >> INVITE belongs in the protocol, and not in the application space.
> >> But,
> >> forking of these non-INVITEs is presumably a much less common
> >> ocurrence, so
> >> that putting it in the application space is not as much a burden.
> >>
> >> I'll be sure to put this topic on my running open-issues list for
> >> London.
> >>
> >> -Jonathan R.
> >> ---
> >> Jonathan D. Rosenberg, Ph.D.            = ;    72 Eagle Rock Ave.
> >> Chief Scientist           &= nbsp;            = ;     First Floor
> >> dynamicsoft           = ;            &nb= sp;         East Hanover, NJ 07936
> >> jdrosen@dynamicsoft.com         = ;            FAX:   (973) 952-5050
> >> http://www.jdrosen.net    &n= bsp;           PHONE: (973) 952-5000
> >> http://www.dynamicsoft.com
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP 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
> > http= ://www.ietf.org/mailman/listinfo/sip This list is for NEW
> > development of the core SIP Protocol Use
> > sip-implementors@cs.columbia.edu for questions on current sip= Use
> > sipping@ietf.org for new developments on the application of= sip
>
> -------------
> PingMe!
> Jay Batson
> CEO
> Pingtel Corp.
> mailto:jbatson@pingtel.com
> 781-938-5306 (office)

--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:jbatson@pingtel.com
781-938-5306 (office)

--=====================_75065508==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 19:44:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24980 for ; Wed, 11 Jul 2001 19:44:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19665; Wed, 11 Jul 2001 19:01:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19634 for ; Wed, 11 Jul 2001 19:01:03 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23895 for ; Wed, 11 Jul 2001 19:00:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6BMxuRX007327; Wed, 11 Jul 2001 18:59:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3W6DK80V>; Wed, 11 Jul 2001 19:00:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , "'Jay Batson'" , "Zmolek, Andrew (Andrew)" , Jonathan Rosenberg Cc: "Grothe, Lew E (Lew)" , sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 19:00:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, July 11, 2001 5:55 PM > To: 'Jay Batson'; Zmolek, Andrew (Andrew); Jonathan Rosenberg > Cc: Grothe, Lew E (Lew); sip@ietf.org > Subject: RE: [Sip] another modest proposal: change call-leg ID > > > I think people can always build rogue endpoints or proxies > but as far as I > can see this proposal doesn't change the "security" > situation. Absolutely. Nothing changes as a result of this proposal. > If the rogue > entity can change/replicate the tag value then it could just as easily > change/replicate the whole URL (and vice versa). Additionally if > authentication is employed then the tag is just as protected > as the whole > URL (since it is a subset). > > It does however raise the point that if a message is signed then an > intermediate proxy may not modify the rest of the URL (while > maintaining the > same tag value) but I think this is a desirable rather than > undesirable > property. [Just as a proxy may not currently change the > display name on a > signed message even though this does not affect the call-leg id.] Well, the proposal is not meant to support proxies modifying the To/From, but rather, allow endpoints to change the To/From in the middle of the call. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 19:44:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24982 for ; Wed, 11 Jul 2001 19:44:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19803; Wed, 11 Jul 2001 19:05:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19717 for ; Wed, 11 Jul 2001 19:05:32 -0400 (EDT) Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24104 for ; Wed, 11 Jul 2001 19:04:42 -0400 (EDT) Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Thu, 12 Jul 2001 01:04:01 +0200 Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id <3NF0ZXGR>; Thu, 12 Jul 2001 01:04:56 +0200 Message-ID: From: "Agboh, Charles" To: "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Thu, 12 Jul 2001 01:04:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a stupid question that may not be directly related to this thread....How is the b2bua talking to the transcoder or are they co-located in the same device? If not then is it doing this using SIP or MGCP? If it is the latter then is this architecture (sorry) just another softswitch MGC-type of device controlling an MG or is there more? -Charles > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 11, 2001 2:58 PM > To: 'Fairlie-Cuninghame, Robert'; Jonathan Rosenberg; 'sip@ietf.org' > Subject: RE: [Sip] another modest proposal: change call-leg ID > > > > > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Sent: Wednesday, July 11, 2001 8:21 AM > > To: 'Jonathan Rosenberg'; 'sip@ietf.org' > > Subject: RE: [Sip] another modest proposal: change call-leg ID > > > > > > Hi Jonathan, > > > > I think this is a very interesting proposal that solves a few > > problems, > > makes many things _much_ easier to implement and > potentially more CPU > > efficient - definitely a modest proposal worth considering. > > > > I do however think that selection of the To & From tags must > > be done with > > more care if this suggestion is adopted (ie space & time > > uniqueness of tags > > is more crucial). For instance, the UAS MUST always choose a > > To tag that is > > different to the From tag so that the message direction can > > be determined. > > Of course, if tags are chosen to be properly globally unique > > across space & > > time (as they should be) then this is not a problem. > > Right. Note that Call-ID is already supposed to be globally > unique, which > helps. Choosing unique tags across space and time would also > generally be > useful for other purposes. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 19:44:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24978 for ; Wed, 11 Jul 2001 19:43:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19891; Wed, 11 Jul 2001 19:15:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19864 for ; Wed, 11 Jul 2001 19:15:01 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24326 for ; Wed, 11 Jul 2001 19:14:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6BNDuRX007409; Wed, 11 Jul 2001 19:13:56 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3W6DK9AV>; Wed, 11 Jul 2001 19:14:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson (EUS)'" , Jonathan Rosenberg , "'sip@ietf.org'" Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 19:14:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, July 11, 2001 10:21 AM To: 'Jonathan Rosenberg'; 'sip@ietf.org' Subject: RE: [Sip] another modest proposal: change call-leg ID >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Wednesday, July 11, 2001 1:30 AM >To: 'sip@ietf.org' >Subject: [Sip] another modest proposal: change call-leg ID > >>1. A calls B, and its forwarded to C. C accepts, and later >>re-INVITEs. The >>From field in this re-INVITE is NOT actually the identity of >>C, but rather, >>B. This screws up the idempotency of SIP INVITE. The From field has one >>meaning in INVITE, and another in re-INVITE. This makes >>defining policies >>based on the From field more complex, since they no longer >>work properly for >>re-INVITE. > >But this proposal only removes information from the call leg ID, >which can't help you with this policy problem. You certainly >won't define policies based on tags. I agree this is >definitely a problem, but I don't think this is a solution. >There are also cases where you want to be able to identify a >session as being transferred -- having the original A/B parties No; the point is that when C sends a re-INVITE, it would place its own address in the From field, rather than B's. This way, I could define a policy like "reject requests with the domain foo.com", and this would work sensibly for INVITEs and re-INVITEs alike, rather than it working for re-INVITEs sometimes, depending on whether the call was forwarded. >> >>3. Overlap dialing is easier. The reason we've had to send >>each digit as a >>new call leg, is that we needed to change the To field and the >>request URI. >>By definition, this meant a new call leg. Now, we can send all of that >>within a single call leg. Much cleaner. > >Does this mean a gateway will have to generate a new tag for >each endpoint it supports? The gateway would need to generate a new tag for each call leg it accepts. The idea is that tags should be globally unique across space and time. >>4. The Replaces draft benefits. We've already identified a need for the >>Replaces header to identify the entire call leg thats being >>replaced. This >>gets big when it carries two URLs, two tags, and a call-id. Now, we can >>throw away the URLs. This shortens the header and makes matching of the >>call-leg IDs easier. > >The replaces problem is simpler. You are talking about a pre-existing >call leg. This makes matching simpler and therefore the proposal of >using only the tags in this case is a reasonable one. The real >problem with using only tags is the *possibility* for clashes -- are >tags sufficiently unique? For Replaces:, I feel comfortable saying yes. >For the more general case, I'm not sure I do. Well, part of the proposal as I mention above is that tags should be globally unqiue across space and time. Its just helpful for identifiers to have this property, since you don't need to worry about clashes or horrible special-case problems related to that. > >>5. It works with existing proxies. > >What about the overlapped dialing case? Sure, nothing has changed. For overlap, the updated digits come in new transactions within the same call leg, rather than new call legs. This doesn't change the fact that they are new transactions. Now, as a corollary, the transaction ID can be alternatively defined as the to tag, from tag, call-id, cseq, top via (branch id alone is actually sufficient if computed as unique as well). If the branch ID is always there, and is computed as a hash of the r-uri by the proxy which inserts it, then you don't need to include the r-uri in the transaction ID, since its effectively there through the via branch ID. This means transaction IDs can also be URI-less. Just a thought. >Does this have any impacts on the ways in which UAs allocate >tags? (esp. across restarts?) Yes. In all cases, tags really need to be globally unique across space and time. If you want to survive across restarts, you also need to select tags from some set X, such that there exists some indicator function F, for which: F(x) = 1, for x ELEMENT of X F(x) = 0, for x not-ELEMENT of X In other words, you can tell from the tag that it was created by this instance of the proxy. A simple solution is to append a globally unqiue ID with an instance ID. That has both the uniqueness property, and also meets the requirement above. We discussed this issue at the last IETF, and I proposed that wording to this effect be included in the spec. The consensus, as I recall, was not to include it, but rather, leave this additional computational aspect to whatever extension deals with restarts (a draft is pending on that; I've finished the first cut and it will be done before Friday). However, I think the baseline requirement for global uniqueness across space/time should be in bis itself. Other properties can augment that. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 19:49:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25153 for ; Wed, 11 Jul 2001 19:49:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19987; Wed, 11 Jul 2001 19:23:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19963 for ; Wed, 11 Jul 2001 19:23:17 -0400 (EDT) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24491 for ; Wed, 11 Jul 2001 19:22:26 -0400 (EDT) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA26899; Wed, 11 Jul 2001 19:22:45 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKU10176; Wed, 11 Jul 2001 19:22:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010711192051.00b51f28@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 19:25:05 -0400 To: From: Michael Hammer Subject: Re: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) Cc: "'Henning Schulzrinne'" , , "Paul Kyzivat" , "Jay Batson" , In-Reply-To: <61D824C63B99D311975E00508B0CC98502251934@eamrcnt717.exu.er icsson.se> References: <3B4C4B06.FAFBB58C@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org You may also be interested to know that in TIA there was a feature called vocoder-bypass that essentially mapped the bits into only part of the 64k stream and left it in codec form when it was known that both sides used the same codec. That was to avoid the small but additive degradation that occurred at every coding-decoding interface. Mike At 04:32 PM 7/11/2001 -0500, adam.roach@ericsson.com wrote: > > -----Original Message----- > > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > > > > An additional use of B2BUAs is for media translation, but > > this is really > > only likely for multiparty calls, as quality is much better if you can > > avoid transcoding. > >Sort of. Wireless-to-landline calls go through a GSM-to-G.711 >transcoder; most wireless-to-wireless calls go GSM-to-G.711-to-GSM. >(Substitute various other heavily-compressed codecs for "GSM" to >make the above sentence apply all over the world). > >Since the audio characteristics of most phones is so crappy, and >since an 8 kHz sampling rate is rather dismal, most people don't >even notice. > > > (I may be underestimating the effect of the screwy > > licensing for G.72x and various other low-rate codecs here, which also > > could lead to more transcoding than is technically called for.) > >Three letters: AMR > >3GPP is going for AMR as a default codec, with the implication that >G.711 *will* *not* be used. > >Bakeoffs have shown that many firmware SIP implementations use >G.711 exclusively. > >In the short term, transcoders will abound. > >This is why (I feel) we need to come up with a good architecture >to support transcoding which doesn't require a B2BUA. No, I'm not >proposing a work item (we do protocols, not architectures); I'm >just thinking out loud. > >/a > > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 20:20:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25802 for ; Wed, 11 Jul 2001 20:20:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20598; Wed, 11 Jul 2001 19:52:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20560 for ; Wed, 11 Jul 2001 19:52:13 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25198 for ; Wed, 11 Jul 2001 19:51:22 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6BNpnZ05792; Wed, 11 Jul 2001 16:51:49 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT00519; Wed, 11 Jul 2001 16:51:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA06432; Wed, 11 Jul 2001 16:51:38 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.59018.305686.519459@thomasm-u1.cisco.com> Date: Wed, 11 Jul 2001 16:51:38 -0700 (PDT) To: Cc: "'Henning Schulzrinne'" , , "Paul Kyzivat" , "Jay Batson" , Subject: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) In-Reply-To: <61D824C63B99D311975E00508B0CC98502251934@eamrcnt717.exu.ericsson.se> References: <3B4C4B06.FAFBB58C@cs.columbia.edu> <61D824C63B99D311975E00508B0CC98502251934@eamrcnt717.exu.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit adam.roach@ericsson.com writes: > This is why (I feel) we need to come up with a good architecture > to support transcoding which doesn't require a B2BUA. No, I'm not > proposing a work item (we do protocols, not architectures); I'm > just thinking out loud. Well, stop it :-) I sense that what you're hoping for is the moral equivalent of an RTP NAT and to that I say TANSTAAFL. There's a variety of ways that you could implement and/or control your transcoder box, but let's not allow delusion to creep in here that what is finally shaked and baked isn't, in fact, a form of an application layer gateway, lest the curse of Deering be upon you :-) Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 21:11:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26407 for ; Wed, 11 Jul 2001 21:11:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21661; Wed, 11 Jul 2001 20:51:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21628 for ; Wed, 11 Jul 2001 20:51:33 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26170 for ; Wed, 11 Jul 2001 20:50:41 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f6C0pUb44045; Wed, 11 Jul 2001 20:51:30 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Jonathan Rosenberg'" , Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Wed, 11 Jul 2001 20:55:03 -0400 Message-ID: <004b01c10a6d$49badaa0$2b01a8c0@broadsoft.com> 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 Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > > There are quite a few benefits from this: > > 1. A calls B, and its forwarded to C. C accepts, and later > re-INVITEs. The > From field in this re-INVITE is NOT actually the identity of > C, but rather, > B. This screws up the idempotency of SIP INVITE. The From > field has one > meaning in INVITE, and another in re-INVITE. This makes > defining policies > based on the From field more complex, since they no longer > work properly for > re-INVITE. The Remote-Party-ID of the Privacy draft already provides this information if it is passed during re-INVITE transactions and reflects appropriate changes when leaving trusted boundaries. Allowing the To and From headers to be changed on a call-leg potentially could allow the Privacy draft to incorporate the rpi-token into the To and From without the need of the Remote-Party-ID header. However I guess that proxies couldn't change the certain headers if the message is signed. > 2. call-leg ID lookups in gateways are much faster now, since > the tags and > call-ids are just strings. Matching is now case-sensitive > string compares. > Much easier than URL comparison. This is a good enough reason for me. > 4. The Replaces draft benefits. We've already identified a > need for the > Replaces header to identify the entire call leg thats being > replaced. This > gets big when it carries two URLs, two tags, and a call-id. > Now, we can > throw away the URLs. This shortens the header and makes > matching of the > call-leg IDs easier. Sounds good. > 5. It works with existing proxies. > > THe main drawback, of course, is that this won't interoperate > with rfc2543 > UAs. Thats fixable with Supported; the UAC indicates Supported: > new-call-leg-id in the INVITE if it understands this. In that > case, any > responses or re-invites that change the URLs include a Require: > new-call-leg-id. This works when the change occurs in the re-invite and it contains Require and Proxy-Require. It doesn't work if the change is in the INVITE response unless the UAC added Proxy-Require to the INVITE. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 11 21:11:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26418 for ; Wed, 11 Jul 2001 21:11:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21714; Wed, 11 Jul 2001 20:53:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21684 for ; Wed, 11 Jul 2001 20:53:25 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26186 for ; Wed, 11 Jul 2001 20:52:33 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6C0rAp25242; Wed, 11 Jul 2001 19:53:10 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6C0rAX07853; Wed, 11 Jul 2001 19:53:10 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id TAA11774; Wed, 11 Jul 2001 19:53:09 -0500 (CDT) Reply-To: To: "'Michael Thomas'" , Cc: "'Henning Schulzrinne'" , , "Paul Kyzivat" , "Jay Batson" , Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) Date: Wed, 11 Jul 2001 19:53:08 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251940@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <15180.59018.305686.519459@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > From: Michael Thomas [mailto:mat@cisco.com] > > adam.roach@ericsson.com writes: > > This is why (I feel) we need to come up with a good architecture > > to support transcoding which doesn't require a B2BUA. No, I'm not > > proposing a work item (we do protocols, not architectures); I'm > > just thinking out loud. > > Well, stop it :-) > > I sense that what you're hoping for is the moral equivalent > of an RTP NAT and to that I say TANSTAAFL. There's a variety > of ways that you could implement and/or control your transcoder > box, but let's not allow delusion to creep in here that what > is finally shaked and baked isn't, in fact, a form of an > application layer gateway, lest the curse of Deering be upon > you :-) Okay, now you've provoked me. :) The fact that you would assume that the *signalling* needs to go through some special box to allow transcoding just highlights how entrenched the mindset that I'm railing against has become. This is a fallacy that no one seems to even question. Allow me to clarify. If we have network-provided transcoding, we'll need to send the RTP through some transcoder box. There are two ways to achieve this. The trivial solution is to send the signaling through some transcoder control box; it acts as a B2BUA, in much the same way that a conference bridge would. (This is extremely simple for terminals to do: if you send me an INVITE for a codec I don't know, I send you a 305 response to tell you to go to my transcoder -- or, if I get a 488 or 606, I send a new invite through my transcoder). Alternately, when a codec mismatch is detected, you can set up some relationship whereby the terminal communicates with a transcoder using an appropriate protocol (H.248 comes to mind) to pre-arrange the fact that media coming in to the transcoder on a negotiated port will be transcoded and sent to the terminal (and the same thing in the reverse direction). Both approaches work, and one of them will *need* to be deployed. The former has all the drawbacks of a B2BUA combined with the drawbacks of needing a transcoder in the network; the latter merely has the drawbacks of having a transcoder. Unfortunately, most people seem to be leaning towards the first solution -- which is terrible, in my mind. Just because we're having to use a transcoder should not mean that feature transparency is destroyed. I'm trying to being attention to the fact that using a B2BUA for this application is EVIL, and should be avoided when possible. I agree that trying to put a "transparent" SIP proxy in the path to munge the SDP is completely the wrong answer, and -- lest anyone be confused -- such a solution is absolutely nothing like what I was suggesting. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 04:45:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16790 for ; Thu, 12 Jul 2001 04:45:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09110; Thu, 12 Jul 2001 04:20:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09079 for ; Thu, 12 Jul 2001 04:20:49 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14009 for ; Thu, 12 Jul 2001 04:20:00 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 12 Jul 2001 08:20:51 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 12 Jul 2001 09:21:05 +0100 Message-ID: <3B4D5DB2.4C600C55@ubiquity.net> Date: Thu, 12 Jul 2001 09:20:02 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" CC: "'Jay Batson'" , "Zmolek, Andrew (Andrew)" , Jonathan Rosenberg , "Grothe, Lew E (Lew)" , sip@ietf.org Subject: Re: [Sip] another modest proposal: change call-leg ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2001 08:21:05.0402 (UTC) FILETIME=[984E05A0:01C10AAB] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > I think people can always build rogue endpoints or proxies but as far as I > can see this proposal doesn't change the "security" situation. If the rogue > entity can change/replicate the tag value then it could just as easily > change/replicate the whole URL (and vice versa). Additionally if > authentication is employed then the tag is just as protected as the whole > URL (since it is a subset). Just a small point, the tags are in headers which authentication leaves unprotected, I submitted a draft yesterday attempting to fix this issue. James Undery _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 07:16:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03173 for ; Thu, 12 Jul 2001 07:16:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13012; Thu, 12 Jul 2001 07:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12981 for ; Thu, 12 Jul 2001 07:06:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01580; Thu, 12 Jul 2001 07:06:03 -0400 (EDT) Message-Id: <200107121106.HAA01580@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Jul 2001 07:06:03 -0400 Subject: [Sip] I-D ACTION:draft-undery-sip-digest-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Authentication: SIP Digest Access Authentication Author(s) : J. Undery Filename : draft-undery-sip-digest-00.txt Pages : 11 Date : 11-Jul-01 The Session Initiation Protocol [2] currently uses the HTTP digest authentication algorithm [3] for simple authentication of SIP requests. This scheme does not allow for the inclusion of headers important to the integrity of a SIP request including To, From, Call-ID, CSeq, Contact and Expires headers. This document attempts to address this issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-undery-sip-digest-00.txt 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-undery-sip-digest-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-undery-sip-digest-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: <20010711155729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-undery-sip-digest-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-undery-sip-digest-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010711155729.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 07:26:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04340 for ; Thu, 12 Jul 2001 07:26:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13056; Thu, 12 Jul 2001 07:06:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13024 for ; Thu, 12 Jul 2001 07:06:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01610; Thu, 12 Jul 2001 07:06:08 -0400 (EDT) Message-Id: <200107121106.HAA01610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Jul 2001 07:06:08 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Cookies Author(s) : D. Willis, B. Rosen Filename : draft-willis-sip-cookies-00.txt Pages : 9 Date : 11-Jul-01 This document describes an extension to SIP (RFC 2543) to provide a mechanism for storing state and other information in SIP comparable to the HTTP state mechanisms defined in RFC 2109. This extension includes a new SIP header ('Cookie:'), an option tag for feature negotiation ('cookie') and IANA registration considerations for registering the 'cookie' extension, semantics of the value of the Cookie: header, and behavioral rules for processing these headers by SIP nodes supporting the 'cookie' extension. This document also briefly discusses possible uses of cookies, and security considerations for their use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt 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-willis-sip-cookies-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-willis-sip-cookies-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: <20010711155737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-cookies-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-cookies-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010711155737.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 10:33:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28431 for ; Thu, 12 Jul 2001 10:33:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17551; Thu, 12 Jul 2001 10:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17519 for ; Thu, 12 Jul 2001 10:20:17 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26491 for ; Thu, 12 Jul 2001 10:19:28 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CEJuZ27607; Thu, 12 Jul 2001 07:19:56 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT08871; Thu, 12 Jul 2001 07:19:45 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA06732; Thu, 12 Jul 2001 07:19:45 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.45568.874800.526497@thomasm-u1.cisco.com> Date: Thu, 12 Jul 2001 07:19:44 -0700 (PDT) To: Cc: "'Michael Thomas'" , "'Henning Schulzrinne'" , , "Paul Kyzivat" , "Jay Batson" , Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) In-Reply-To: <61D824C63B99D311975E00508B0CC98502251940@eamrcnt717.exu.ericsson.se> References: <15180.59018.305686.519459@thomasm-u1.cisco.com> <61D824C63B99D311975E00508B0CC98502251940@eamrcnt717.exu.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit adam.roach@ericsson.com writes: > > From: Michael Thomas [mailto:mat@cisco.com] > > I sense that what you're hoping for is the moral equivalent > > of an RTP NAT and to that I say TANSTAAFL. There's a variety > > of ways that you could implement and/or control your transcoder > > box, but let's not allow delusion to creep in here that what > > is finally shaked and baked isn't, in fact, a form of an > > application layer gateway, lest the curse of Deering be upon > > you :-) > > Okay, now you've provoked me. :) > > The fact that you would assume that the *signalling* needs to go through > some special box to allow transcoding just highlights how entrenched the > mindset that I'm railing against has become. This is a fallacy that no > one seems to even question. Ectually, I didn't make that assumption. In fact, "control" was meant to allude to what you describe below... > The former has all the drawbacks of a B2BUA combined with the drawbacks of > needing a transcoder in the network; the latter merely has the drawbacks > of having a transcoder. Unfortunately, most people seem to be leaning > towards the first solution -- which is terrible, in my mind. Just because > we're having to use a transcoder should not mean that feature transparency > is destroyed. I'm trying to being attention to the fact that using a B2BUA > for this application is EVIL, and should be avoided when possible. It really depends, I suspect. The drawback of using MGC/MG like decompositions is that there is: a) a lot of code needed to drive the MG if you're the MGC b) a fundamental assumption of trust between the MGC and MC. c) (soft) real time requirements between MG and MGC For a simple handset, say, pretending to be a big old honkin' MGC is probably overkill, and may run afoul of the flash memory gods. The trust issue might be overcome by properly "virtualizing" the MG, but there's some question in my mind whether that could be done in practice. For (c), you'd *really* have to careful... if I were trying to control an MG over a krufty cellular link, say, it would be interesting times, as they say. I'm not dissing the idea, mind you. It's just that it's not with its own set of considerations. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 11:56:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10278 for ; Thu, 12 Jul 2001 11:56:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18728; Thu, 12 Jul 2001 10:58:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17200 for ; Thu, 12 Jul 2001 10:09:08 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24945 for ; Thu, 12 Jul 2001 10:08:19 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CE8HZ21895; Thu, 12 Jul 2001 07:08:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT08760; Thu, 12 Jul 2001 07:08:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA06729; Thu, 12 Jul 2001 07:08:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.44870.707472.817137@thomasm-u1.cisco.com> Date: Thu, 12 Jul 2001 07:08:06 -0700 (PDT) To: "Henning G. Schulzrinne" Cc: Michael Thomas , "Gross, Gerhard" , "'bidulock@openss7.org'" , Jonathan Rosenberg , "'Rosen, Brian'" , "'Jiri Kuthan'" , Ashhar Farhan , "'sip@ietf.org'" Subject: Re: [SIP] Authentication and billing through proxy/re-direct server In-Reply-To: <3B4CBFAE.8E51825C@cs.columbia.edu> References: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com> <15160.43070.343030.890219@thomasm-u1.cisco.com> <3B467771.5549104B@cs.columbia.edu> <15180.35801.300578.114666@thomasm-u1.cisco.com> <3B4CBFAE.8E51825C@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > Michael Thomas wrote: > > While I don't disagree with your time-and-place > > kind of argument re PBX's, etc, there's a fairly > > trivial scenario which doesn't involve the PSTN > > that could lead to QoS fraud with untrustworthy > > cooperating UA's. The DQoS/media authorization > > draft talks about this ad-nauseum, but the basic > > point is that if you don't have some sort of choke > > on the media, then you're pretty wide open to > > people sending a BYE to the signaling > > intermediaries while happily honoring an > > X-Not-Really end to end. > > > > Assuming that the proxy server and gateway are in the same trust domain, > this is fairly hard, since I would log the BYE request only if there's > been a 200 from the right party. Yes, you need to deal with max-hops, > but that would not trigger a 200. That's not what I'm assuming. I'm assuming that we're two bad guys colluding to get free enhanced quality of service from my service provider, or you-name-the-service which relies on accurately knowing the begin and end of calls (like, oh say, calling cards). Unless you have some access to the media, we can always tell the service provider that the call is over and merrily take advantage of our fR33q0S. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 11:56:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10295 for ; Thu, 12 Jul 2001 11:56:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18297; Thu, 12 Jul 2001 10:39:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18267 for ; Thu, 12 Jul 2001 10:39:39 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29184 for ; Thu, 12 Jul 2001 10:38:51 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51MDJM>; Thu, 12 Jul 2001 07:38:47 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Thu, 12 Jul 2001 07:38:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > Well, the proposal is not meant to support proxies modifying > the To/From, > but rather, allow endpoints to change the To/From in the > middle of the call. > Hi Jonathan, Perhaps not but I think it could it be used for such a purpose with _huge_ advantage (especially in telephony applications) and yet without being too open to wholesale abuse. It may also deprecate some of the reasons that people are using B2BUA-like devices merely so that they can rewrite the To/From fields (for subscriber identity hiding). [Where transport-layer identity screening is not important, eg, on a multi-user server or gateway.] For instance, in telephony applications where it is desired that the caller can be determined from the From URL, the ingress & egress gateway be able to map the From URL into a global number context (eg local source number 567-1111 must be mapped to +1-203-567-1111 at the ingress gateway and then the egress gateway must map this back into the appropriate representation for the egress domain). This means that there must be a lot of routing knowledge embedded in each and every endpoint for the correct number format of the caller at the egress. Heaven forbid when you have internal numbering and DID lines, etc,etc in the picture. This is not a problem for the request-uri because it changes hop-by-hop. For instance, are request-uri of tel:5672222 can be automatically changed to tel:+12035672222 when a proxy routes it to an international domain. This is has previously not been possible for a pure proxy because it changes the call-leg id. Now with this proposal a proxy can also remap the To & From numbers into an appropriate format as the leave a number domain. As with all routing problems they are all a function of local policy. Example using a local extension-based dial plan request-uri: tel:95672222 From: tel:1111 could be remapped to request-uri: sip:5672222@my_voip_provider.com From: sip:1111@nuera.com In this example the From tel:1111 has no significance outside of internal number domain. Unless every phone is configured with logic to determine the external globally reachable domain to insert - the From becomes useless. What if there are multiple external domains involved? !!!This removes a huge burden from the configuration of endpoints!!! Now some might argue that this is the purpose of Remote-Party-Id. I still believe it has its purpose - there may often be multiple representations of the Remote-Party-Id. The way I see it is that the From URL provides the preferred representation and something that still makes sense to a UA that does not implement Remote-Party-Id extension. It will also be helpful in actually providing a From URL that can be used to contact/callback the caller (from the callee's domain). I can only see this good for encouraging people to solving these real requirements the right way. My two cents. Robert. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 11:57:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10436 for ; Thu, 12 Jul 2001 11:57:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18970; Thu, 12 Jul 2001 11:00:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18932 for ; Thu, 12 Jul 2001 11:00:17 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02065 for ; Thu, 12 Jul 2001 10:59:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05487; Thu, 12 Jul 2001 10:59:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04949; Thu, 12 Jul 2001 10:59:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Jul 2001 10:59:47 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465778@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'adam.roach@ericsson.com'" , "'Michael Thomas'" Cc: "'Henning Schulzrinne'" , Juan-Carlos.Rojas@alcatel.fr, Paul Kyzivat , Jay Batson , sip@ietf.org Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Date: Thu, 12 Jul 2001 10:59:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I like almost all of what you are saying, but one part is a little confusing. If I have a SIP end point, and it's not a PSTN gateway, but a sipphone, and it doesn't have a codec for whatever is coming at it, you don't want the sipphone to know about transcoders and Megaco do you? You want some intermediate proxy server to recognize the problem and DTRT. I really do buy into the central argument that just because the media stream is going through an extra device DOESN'T mean the signalling has to. Brian > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Wednesday, July 11, 2001 8:53 PM > To: 'Michael Thomas'; adam.roach@ericsson.com > Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; Paul Kyzivat; > Jay Batson; sip@ietf.org > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > proposal.) > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > adam.roach@ericsson.com writes: > > > This is why (I feel) we need to come up with a good architecture > > > to support transcoding which doesn't require a B2BUA. No, I'm not > > > proposing a work item (we do protocols, not architectures); I'm > > > just thinking out loud. > > > > Well, stop it :-) > > > > I sense that what you're hoping for is the moral equivalent > > of an RTP NAT and to that I say TANSTAAFL. There's a variety > > of ways that you could implement and/or control your transcoder > > box, but let's not allow delusion to creep in here that what > > is finally shaked and baked isn't, in fact, a form of an > > application layer gateway, lest the curse of Deering be upon > > you :-) > > Okay, now you've provoked me. :) > > The fact that you would assume that the *signalling* needs to > go through > some special box to allow transcoding just highlights how > entrenched the > mindset that I'm railing against has become. This is a fallacy that no > one seems to even question. > > Allow me to clarify. > > If we have network-provided transcoding, we'll need to send the RTP > through some transcoder box. There are two ways to achieve this. > > The trivial solution is to send the signaling through some transcoder > control box; it acts as a B2BUA, in much the same way that a > conference > bridge would. (This is extremely simple for terminals to do: > if you send > me an INVITE for a codec I don't know, I send you a 305 > response to tell > you to go to my transcoder -- or, if I get a 488 or 606, I send a new > invite through my transcoder). > > Alternately, when a codec mismatch is detected, you can set up some > relationship whereby the terminal communicates with a transcoder using > an appropriate protocol (H.248 comes to mind) to pre-arrange the fact > that media coming in to the transcoder on a negotiated port will be > transcoded and sent to the terminal (and the same thing in the reverse > direction). > > Both approaches work, and one of them will *need* to be deployed. > > The former has all the drawbacks of a B2BUA combined with the > drawbacks of > needing a transcoder in the network; the latter merely has > the drawbacks > of having a transcoder. Unfortunately, most people seem to be leaning > towards the first solution -- which is terrible, in my mind. > Just because > we're having to use a transcoder should not mean that feature > transparency > is destroyed. I'm trying to being attention to the fact that > using a B2BUA > for this application is EVIL, and should be avoided when possible. > > I agree that trying to put a "transparent" SIP proxy in the > path to munge > the SDP is completely the wrong answer, and -- lest anyone be > confused -- > such a solution is absolutely nothing like what I was suggesting. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 13:18:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22256 for ; Thu, 12 Jul 2001 13:18:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22310; Thu, 12 Jul 2001 12:59:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22281 for ; Thu, 12 Jul 2001 12:59:47 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19588 for ; Thu, 12 Jul 2001 12:58:59 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CGxPZ29077 for ; Thu, 12 Jul 2001 09:59:26 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT12058; Thu, 12 Jul 2001 09:59:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA06790; Thu, 12 Jul 2001 09:59:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.55126.833691.522462@thomasm-u1.cisco.com> Date: Thu, 12 Jul 2001 09:59:02 -0700 (PDT) To: sip@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] finally... a SIP security threats/requirements/framework draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've been threatening to produce one of these for quite some time and have finally gotten around to doing so. This is a first cut, and mainly intended to try to capture as much of what I could remember requirements and threats-wise (and I've probably not remembered everything...), as well as taking a stab at a generalized framework for producing secured SIP headers using MIME attachments to arbitrary points in the proxy routed path which tries to be neutral to the various crypto-systems folks might want to use in the future (radius, smime, kerberos...). Hopefully, this will stimulate some discussion. Until it shows up in the drafts repository, you can fetch a version of it at: http://www.mtcc.com/standards/draft-thomas-sip-sec-framework-00.txt Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 16:03:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16046 for ; Thu, 12 Jul 2001 16:03:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26860; Thu, 12 Jul 2001 15:45:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26829 for ; Thu, 12 Jul 2001 15:45:11 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13321 for ; Thu, 12 Jul 2001 15:44:23 -0400 (EDT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GGD000DMLIGUF@firewall.mcit.com> for sip@ietf.org; Thu, 12 Jul 2001 19:44:40 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GGD00901LICCS@dgismtp03.wcomnet.com>; Thu, 12 Jul 2001 19:44:39 +0000 (GMT) Received: from hsinnreich ([166.35.226.44]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GGD0091MLHT6S@dgismtp03.wcomnet.com>; Thu, 12 Jul 2001 19:44:19 +0000 (GMT) Date: Thu, 12 Jul 2001 14:44:18 -0500 From: Henry Sinnreich Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) In-reply-to: <61D824C63B99D311975E00508B0CC98502251940@eamrcnt717.exu.ericsson.se> To: adam.roach@ericsson.com Cc: "'Henning Schulzrinne'" , "'Michael Thomas'" , Juan-Carlos.Rojas@alcatel.fr, Paul Kyzivat , Jay Batson , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit agree, except >H.248 comes to mind >> Well, stop it :-) Henry -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of adam.roach@ericsson.com Sent: Wednesday, July 11, 2001 7:53 PM To: 'Michael Thomas'; adam.roach@ericsson.com Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; Paul Kyzivat; Jay Batson; sip@ietf.org Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposal.) > From: Michael Thomas [mailto:mat@cisco.com] > > adam.roach@ericsson.com writes: > > This is why (I feel) we need to come up with a good architecture > > to support transcoding which doesn't require a B2BUA. No, I'm not > > proposing a work item (we do protocols, not architectures); I'm > > just thinking out loud. > > Well, stop it :-) > > I sense that what you're hoping for is the moral equivalent > of an RTP NAT and to that I say TANSTAAFL. There's a variety > of ways that you could implement and/or control your transcoder > box, but let's not allow delusion to creep in here that what > is finally shaked and baked isn't, in fact, a form of an > application layer gateway, lest the curse of Deering be upon > you :-) Okay, now you've provoked me. :) The fact that you would assume that the *signalling* needs to go through some special box to allow transcoding just highlights how entrenched the mindset that I'm railing against has become. This is a fallacy that no one seems to even question. Allow me to clarify. If we have network-provided transcoding, we'll need to send the RTP through some transcoder box. There are two ways to achieve this. The trivial solution is to send the signaling through some transcoder control box; it acts as a B2BUA, in much the same way that a conference bridge would. (This is extremely simple for terminals to do: if you send me an INVITE for a codec I don't know, I send you a 305 response to tell you to go to my transcoder -- or, if I get a 488 or 606, I send a new invite through my transcoder). Alternately, when a codec mismatch is detected, you can set up some relationship whereby the terminal communicates with a transcoder using an appropriate protocol (H.248 comes to mind) to pre-arrange the fact that media coming in to the transcoder on a negotiated port will be transcoded and sent to the terminal (and the same thing in the reverse direction). Both approaches work, and one of them will *need* to be deployed. The former has all the drawbacks of a B2BUA combined with the drawbacks of needing a transcoder in the network; the latter merely has the drawbacks of having a transcoder. Unfortunately, most people seem to be leaning towards the first solution -- which is terrible, in my mind. Just because we're having to use a transcoder should not mean that feature transparency is destroyed. I'm trying to being attention to the fact that using a B2BUA for this application is EVIL, and should be avoided when possible. I agree that trying to put a "transparent" SIP proxy in the path to munge the SDP is completely the wrong answer, and -- lest anyone be confused -- such a solution is absolutely nothing like what I was suggesting. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 16:57:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23216 for ; Thu, 12 Jul 2001 16:57:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28073; Thu, 12 Jul 2001 16:34:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28044 for ; Thu, 12 Jul 2001 16:34:39 -0400 (EDT) Received: from smtp.monmouth.com (smtp.monmouth.com [209.191.58.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20066 for ; Thu, 12 Jul 2001 16:33:51 -0400 (EDT) Received: from aplion.com ([205.229.218.99]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6CKYgF87220 for ; Thu, 12 Jul 2001 16:34:42 -0400 (EDT) Message-ID: <3B4E0A3C.8CA3D7FD@aplion.com> Date: Thu, 12 Jul 2001 16:36:12 -0400 From: Ravi Shiroor Organization: Aplion Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] registration thru nat Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i am trying to use trial version of hearme softphone to register with public proxy servers. i am failing, i think, because i am behind nat. any sip ua (handset/softphone) available which can work from behind nat? thanks, ravi. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 18:34:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05830 for ; Thu, 12 Jul 2001 18:34:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00011; Thu, 12 Jul 2001 18:14:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29978 for ; Thu, 12 Jul 2001 18:14:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03169 for ; Thu, 12 Jul 2001 18:13:13 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6CMDkp18745; Thu, 12 Jul 2001 17:13:46 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6CMDk304340; Thu, 12 Jul 2001 17:13:46 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA26136; Thu, 12 Jul 2001 17:13:45 -0500 (CDT) Reply-To: To: "'Rosen, Brian'" , , "'Michael Thomas'" Cc: "'Henning Schulzrinne'" , , "Paul Kyzivat" , "Jay Batson" , Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Date: Thu, 12 Jul 2001 17:13:44 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251946@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF04465778@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It doesn't necessarily have to be Megaco. I just threw that out as an example, since I think everyone here is familiar with the basic operations it can perform. I *do*, however, think that this is something that the endpoint itself will initiate, for a variety of reasons: - Without some really hokey provisioning going on, the node in the middle of the network won't know my terminal's capabilities; it cannot make the right decision. - I (as an end-user) will possibly be charged for using these network transcoders. I can easily envision getting a call with my a special ring that means "this will be a slightly more expensive call since it will use a transcoder," and decide to reject or accept it based on that information combined with the identity of the calling party. I would like to be able to do this real-time by e.g. pressing "answer" or "reject" on my terminal, not based on some long-running policy provisioned into the handset and/or a server in the network. - Anything in the middle of the network doing the "Right Thing" will be munging the SDP. This is a horrible hack: it breaks security models (my signed messages are suddenly tampered with!); it may necessarily remove attributes that my endpoint wanted to see; it will need upgrading when SDPng is deployed... Given these arguments, all that is left is the question of *how* the terminal brings the transcoder into the loop. On its face, it needs to be able to say "take incoming media encoded by this codec from this port, transcode it to a different codec, and send it to a specific IP address at a particular port." The list of protocols which are designed to say this sort of thing is rather short. I'll leave it as an exercise for the readers of this list to find any beyond those that have already been mentioned. /a > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, July 12, 2001 10:00 AM > To: 'adam.roach@ericsson.com'; 'Michael Thomas' > Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; Paul Kyzivat; > Jay Batson; sip@ietf.org > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > proposa l.) > > > I like almost all of what you are saying, but one part is > a little confusing. > > If I have a SIP end point, and it's not a PSTN gateway, but > a sipphone, and it doesn't have a codec for whatever is > coming at it, you don't want the sipphone to know about > transcoders and Megaco do you? You want some intermediate > proxy server to recognize the problem and DTRT. > > I really do buy into the central argument that just because > the media stream is going through an extra device DOESN'T > mean the signalling has to. > > Brian > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Wednesday, July 11, 2001 8:53 PM > > To: 'Michael Thomas'; adam.roach@ericsson.com > > Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; > Paul Kyzivat; > > Jay Batson; sip@ietf.org > > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > > proposal.) > > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > adam.roach@ericsson.com writes: > > > > This is why (I feel) we need to come up with a good > architecture > > > > to support transcoding which doesn't require a B2BUA. > No, I'm not > > > > proposing a work item (we do protocols, not architectures); I'm > > > > just thinking out loud. > > > > > > Well, stop it :-) > > > > > > I sense that what you're hoping for is the moral equivalent > > > of an RTP NAT and to that I say TANSTAAFL. There's a variety > > > of ways that you could implement and/or control your transcoder > > > box, but let's not allow delusion to creep in here that what > > > is finally shaked and baked isn't, in fact, a form of an > > > application layer gateway, lest the curse of Deering be upon > > > you :-) > > > > Okay, now you've provoked me. :) > > > > The fact that you would assume that the *signalling* needs to > > go through > > some special box to allow transcoding just highlights how > > entrenched the > > mindset that I'm railing against has become. This is a > fallacy that no > > one seems to even question. > > > > Allow me to clarify. > > > > If we have network-provided transcoding, we'll need to send the RTP > > through some transcoder box. There are two ways to achieve this. > > > > The trivial solution is to send the signaling through some > transcoder > > control box; it acts as a B2BUA, in much the same way that a > > conference > > bridge would. (This is extremely simple for terminals to do: > > if you send > > me an INVITE for a codec I don't know, I send you a 305 > > response to tell > > you to go to my transcoder -- or, if I get a 488 or 606, I > send a new > > invite through my transcoder). > > > > Alternately, when a codec mismatch is detected, you can set up some > > relationship whereby the terminal communicates with a > transcoder using > > an appropriate protocol (H.248 comes to mind) to > pre-arrange the fact > > that media coming in to the transcoder on a negotiated port will be > > transcoded and sent to the terminal (and the same thing in > the reverse > > direction). > > > > Both approaches work, and one of them will *need* to be deployed. > > > > The former has all the drawbacks of a B2BUA combined with the > > drawbacks of > > needing a transcoder in the network; the latter merely has > > the drawbacks > > of having a transcoder. Unfortunately, most people seem to > be leaning > > towards the first solution -- which is terrible, in my mind. > > Just because > > we're having to use a transcoder should not mean that feature > > transparency > > is destroyed. I'm trying to being attention to the fact that > > using a B2BUA > > for this application is EVIL, and should be avoided when possible. > > > > I agree that trying to put a "transparent" SIP proxy in the > > path to munge > > the SDP is completely the wrong answer, and -- lest anyone be > > confused -- > > such a solution is absolutely nothing like what I was suggesting. > > > > /a > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 12 20:25:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19073 for ; Thu, 12 Jul 2001 20:25:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02436; Thu, 12 Jul 2001 20:06:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02405 for ; Thu, 12 Jul 2001 20:05:58 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16404 for ; Thu, 12 Jul 2001 20:05:10 -0400 (EDT) Received: from jmpolk-8k (ssh-sj1.cisco.com [171.68.225.134]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA10508; Thu, 12 Jul 2001 17:04:58 -0700 (PDT) Message-Id: <4.1.20010712183644.00be5740@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 12 Jul 2001 19:02:40 -0500 To: From: "James M. Polk" Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Cc: In-Reply-To: <61D824C63B99D311975E00508B0CC98502251946@eamrcnt717.exu.er icsson.se> References: <4FBEA8857476D311A03300204840E1CF04465778@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_25190083==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_25190083==_.ALT Content-Type: text/plain; charset="us-ascii" Adam At 05:13 PM 7/12/2001 -0500, adam.roach@ericsson.com wrote: >It doesn't necessarily have to be Megaco. I just threw that >out as an example, since I think everyone here is familiar with >the basic operations it can perform. > >I *do*, however, think that this is something that the endpoint >itself will initiate, for a variety of reasons: > >- Without some really hokey provisioning going on, the node in the > middle of the network won't know my terminal's capabilities; it > cannot make the right decision. > >- I (as an end-user) will possibly be charged for using these network > transcoders. I can easily envision getting a call with my a special > ring that means "this will be a slightly more expensive call > since it will use a transcoder," and decide to reject or accept it > based on that information combined with the identity of the calling > party. I would like to be able to do this real-time by e.g. pressing > "answer" or "reject" on my terminal, not based on some long-running > policy provisioned into the handset and/or a server in the network. > >- Anything in the middle of the network doing the "Right Thing" will > be munging the SDP. This is a horrible hack: it breaks security > models (my signed messages are suddenly tampered with!); it may > necessarily remove attributes that my endpoint wanted to see; it > will need upgrading when SDPng is deployed... > >Given these arguments, all that is left is the question of *how* >the terminal brings the transcoder into the loop. On its face, it >needs to be able to say "take incoming media encoded by this codec >from this port, transcode it to a different codec, and send it to >a specific IP address at a particular port." Possibly....... use an Options Method to query a (Proxy?) server for its (known domain) capabilities for transcoding your example above: can you/anybody "take (this) incoming media encoded by this codec from this port, transcode it to a (specific) different codec....." and have that asked Server return the address of a Server/transcoder/B2BUA (pre-negotiated of not, but it should tell it so) that could perform that function.... Perhaps that might mean the initial Server returns a 3XX redirect to that specific 'other' Server. Perhaps even a second Options Method query is then sent to this redirected (to) Server (from the first response) from the originating UA in need.... Or come up with a well-known Multicast for transcoders asking for one that has this capability and the asking UA sends a redirect to the originating UA with the responding transcoders address and whatever other capabilities or authentications are required for this multi-legged group of transactions just to have a single(?) stream transcoded between two (or more) UA's. just thinking quickly and without thinking it thoroughly (hence the lack of clarity -- but you might understand the essence to make a comment) > >The list of protocols which are designed to say this sort of thing >is rather short. I'll leave it as an exercise for the readers of >this list to find any beyond those that have already been mentioned. > >/a > ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 18581 N. Dallas Parkway Dallas, Texas 75287 w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_25190083==_.ALT Content-Type: text/html; charset="us-ascii"

Adam

At 05:13 PM 7/12/2001 -0500, adam.roach@ericsson.com wrote:
>It doesn't necessarily have to be Megaco. I just threw that
>out as an example, since I think everyone here is familiar with
>the basic operations it can perform.
>
>I *do*, however, think that this is something that the endpoint
>itself will initiate, for a variety of reasons:
>
>- Without some really hokey provisioning going on, the node in the
>  middle of the network won't know my terminal's capabilities; it
>  cannot make the right decision.
>
>- I (as an end-user) will possibly be charged for using these network
>  transcoders. I can easily envision getting a call with my a special
>  ring that means "this will be a slightly more expensive call
>  since it will use a transcoder," and decide to reject or accept it
>  based on that information combined with the identity of the calling
>  party. I would like to be able to do this real-time by e.g. pressing
>  "answer" or "reject" on my terminal, not based on some long-running
>  policy provisioned into the handset and/or a server in the network.
>
>- Anything in the middle of the network doing the "Right Thing" will
>  be munging the SDP. This is a horrible hack: it breaks security
>  models (my signed messages are suddenly tampered with!); it may
>  necessarily remove attributes that my endpoint wanted to see; it
>  will need upgrading when SDPng is deployed...
>
>Given these arguments, all that is left is the question of *how*
>the terminal brings the transcoder into the loop. On its face, it
>needs to be able to say "take incoming media encoded by this codec
>from this port, transcode it to a different codec, and send it to
>a specific IP address at a particular port."

Possibly....... use an Options Method to query a (Proxy?) server for its (known domain) capabilities for transcoding your example above:

can you/anybody "take (this) incoming media encoded by this codec from this port, transcode it to a (specific) different codec....."

and have that asked Server return the address of a Server/transcoder/B2BUA (pre-negotiated of not, but it should tell it so) that could perform that function.... Perhaps that might mean the initial Server returns a 3XX redirect to that specific 'other' Server. Perhaps even a second Options Method query is then sent to this redirected (to) Server (from the first response) from the originating UA in need....

Or come up with a well-known Multicast for transcoders asking for one that has this capability and the asking UA sends a redirect to the originating UA with the responding transcoders address and whatever other capabilities or authentications are required for this multi-legged group of transactions just to have a single(?) stream transcoded between two (or more) UA's.

just thinking quickly and without thinking it thoroughly (hence the lack of clarity -- but you might understand the essence to make a comment)


>
>The list of protocols which are designed to say this sort of thing
>is rather short. I'll leave it as an exercise for the readers of
>this list to find any beyond those that have already been mentioned.
>
>/a
>
*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_25190083==_.ALT-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 02:54:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20343 for ; Fri, 13 Jul 2001 02:54:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17573; Fri, 13 Jul 2001 02:41:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17540 for ; Fri, 13 Jul 2001 02:41:08 -0400 (EDT) Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18867 for ; Fri, 13 Jul 2001 02:40:20 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.182.164]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id IAA29494; Fri, 13 Jul 2001 08:40:18 +0200 (MET DST) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A88.0024432F ; Fri, 13 Jul 2001 08:36:04 +0200 X-Lotus-FromDomain: ALCATEL To: Henning Schulzrinne cc: Paul Kyzivat , Jay Batson , sip@ietf.org Message-ID: Date: Fri, 13 Jul 2001 08:36:00 +0200 Subject: Re: [Sip] Forking: a modest proposal. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Maybe I'm missing something, but I have the feeling that you are always putting together the session control and the bearer control , which is very likely the case of real user agents, that is end-users, but definitely not the case of servers in the network, and a B2BUA is defined as appearing as a proxy (RFC2543). The splitting of the session layer and the bearer layer is the current trend of Next Generation Networks in the Telecom world, including obviously the UMTS environment. So, when I was talking about a B2BUA providing services (which is still appearing as a proxy) I was not talking about bearer manipulation, codec insertion, etc. Instead, I was talking about services provided on top of the session layer, as e.g. conference, meet-me, follow-me services, etc. Now, if the B2BUA concept includes also the bearer handling (which in my personal opinion is going against history), this should be clearly stated in 2543, and the corresponding definition should be improved. Henning Schulzrinne on 11/07/2001 14:48:06 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Paul Kyzivat , Jay Batson , sip@ietf.org Subject: Re: [Sip] Forking: a modest proposal. UAs (and B2B UAs) make sense when the UA also needs to terminate media, as for large-scale conference bridges and anonymizers. I don't think anybody is arguing with that, although for conference bridges, one would hope that they are transient phenomena. (Despite the bad press, multicast is slowly emerging as an option again, at least in selected environments, such as Internet2.) I have no idea why you would need B2B UAs for roaming or what they have to do with QoS (except that they generally are likely to make QoS worse.) An additional use of B2BUAs is for media translation, but this is really only likely for multiparty calls, as quality is much better if you can avoid transcoding. (I may be underestimating the effect of the screwy licensing for G.72x and various other low-rate codecs here, which also could lead to more transcoding than is technically called for.) Juan-Carlos.Rojas@alcatel.fr wrote: > > The main reason for B2BUA is to take control over the service to be provided to the end user. > So, if SIP is strictly used as a "rendez-vous" protocol over the public Best Effort Internet network, there is in principle no need for such functionality. > This can become quite different if you need to handle the user plane, as in the case of conference controllers. > This is still worse if you are intended to provide services having guaranteed characteristics, like confidentiality, QoS, roaming, etc. A simple SIP proxy can not provide that, then you need a more complex functionality (because the service is more > complex) allowing you to take control over the user request, and that can be done with B2BUA servers. > Best regards > Juan Carlos > > Paul Kyzivat on 11/07/2001 00:36:46 > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 04:52:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02871 for ; Fri, 13 Jul 2001 04:52:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20675; Fri, 13 Jul 2001 04:40:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20642 for ; Fri, 13 Jul 2001 04:40:19 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01396 for ; Fri, 13 Jul 2001 04:39:26 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 08:40:18 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 09:41:03 +0100 From: "Jo Hornsby" To: "Chandarshekar, Kiran" Cc: Date: Fri, 13 Jul 2001 09:40:13 +0100 Message-ID: <002f01c10b77$6f5ffd20$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <0FA9826A747FD41195DB00508BD96BC30107AB0F@kappa.empirix.com> X-OriginalArrivalTime: 13 Jul 2001 08:41:03.0591 (UTC) FILETIME=[8CE4E770:01C10B77] Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [Sip-implementors] please clarify Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Kiran wrote: > I observe on the page 102, SIP bis-03 pdf, sec 20.2.1 Content-Length is in > error. It MUST be 224. I would agree. > I will bring it to the foreground if I find anymore. Curiously, Who am I > supposed to address such typos to? For the moment, if it's the case that you _know_ there's a bug (e.g., it's not a case of "I think that the Content-Length here is wrong because I think that '\r' and '\n' are magic and don't exist within the normal plane of octet existence"), then I would post it to the SIP list; otherwise, it might be that you're just not quite grokking fully, and SIP Implementors is the more appropriate forum [it will always &;) be picked up by those Pantheonic should the issue really turn out to be a bug]. However, I think (read as: hope) I'm right in saying that this is partially a short-term issue, since there is going to be some sort of bug-reporting/tracking system put in place for bis...certainly there's been noise on the list. HTH, - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 07:14:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19354 for ; Fri, 13 Jul 2001 07:14:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23413; Fri, 13 Jul 2001 06:52:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23329 for ; Fri, 13 Jul 2001 06:52:08 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16164 for ; Fri, 13 Jul 2001 06:51:17 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 10:52:07 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 11:46:20 +0100 From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Sean Olson (EUS)'" , Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Fri, 13 Jul 2001 11:45:29 +0100 Message-ID: <003401c10b88$ef22af10$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 13 Jul 2001 10:46:20.0441 (UTC) FILETIME=[0D493090:01C10B89] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan wrote: > Now, as a corollary, the transaction ID can be alternatively > defined as the > to tag, from tag, call-id, cseq, top via (branch id alone is actually > sufficient if computed as unique as well). I'm not sure that we currently mandate this (only the "second part" is supposed to be globally unique, but this in itself is not MUST). > If the branch ID is > always there, > and is computed as a hash of the r-uri by the proxy which inserts it, Well, I know &:) of one implementation at least that does not hash in the conventional sense... > then > you don't need to include the r-uri in the transaction ID, since its > effectively there through the via branch ID. ...but I think this will still hold. > This means > transaction IDs can > also be URI-less. Just a thought. Nice. Although if a proxy was to take this approach, is it possible it will expose it to an exploit where it will see signalling that it thinks is for one call, but is in actual fact for a different call (because (perhaps evil) UAs sniff Call-IDs)? It might well be that such proxies are way too brittle if this is the case, just wanted to float. Cheers, - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 07:32:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21515 for ; Fri, 13 Jul 2001 07:32:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23157; Fri, 13 Jul 2001 06:32:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23125 for ; Fri, 13 Jul 2001 06:32:35 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14020 for ; Fri, 13 Jul 2001 06:31:42 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 10:32:33 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 11:33:19 +0100 From: "Jo Hornsby" To: "Jonathan Rosenberg" , Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Fri, 13 Jul 2001 11:32:29 +0100 Message-ID: <003301c10b87$1dbab3b0$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 13 Jul 2001 10:33:19.0650 (UTC) FILETIME=[3BE5F020:01C10B87] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan wrote: > While we're on the subject of modest proposals, here is another that I've > been toying with: > > Change the definition of call-leg ID. Instead of To, To-tag, From, > From-tag, and Call-ID, its *only* the tags and the Call-ID. That is, > the ID no longer contains the URLs. > > There are quite a few benefits from this: [...] > 5. It works with existing proxies. Uh. I get the feeling that I'm going to look like a numpty because of this, but won't this break older proxies that attempt to be call-stateful by examining the whole From/To? Not that I'm advocating this as an approach (although I'd struggle to see a better way without the new Record-Route: ing rules), you understand. &:) > THe main drawback, of course, is that this won't interoperate with rfc2543 > UAs. Thats fixable with Supported; the UAC indicates Supported: > new-call-leg-id in the INVITE if it understands this. In that case, any > responses or re-invites that change the URLs include a Require: > new-call-leg-id. Shame. And I think this is the thing that bothers me most. If there are going to be occasions where one will be unable to change the From, then it hardly seems worth it. Still, I guess it falls back to the (presumably unspoken) knowledge that no Real Networks are going to have 2543 elements in them.... - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 07:38:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22190 for ; Fri, 13 Jul 2001 07:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24129; Fri, 13 Jul 2001 07:21:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24098 for ; Fri, 13 Jul 2001 07:21:57 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20144 for ; Fri, 13 Jul 2001 07:21:04 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 11:21:55 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 12:22:41 +0100 From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Fri, 13 Jul 2001 12:21:52 +0100 Message-ID: <003601c10b8e$0443d360$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 13 Jul 2001 11:22:41.0667 (UTC) FILETIME=[2165DD30:01C10B8E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert wrote: > Jonathan wrote: > > Well, the proposal is not meant to support proxies modifying > > the To/From, > > but rather, allow endpoints to change the To/From in the > > middle of the call. > > > Hi Jonathan, > > Perhaps not but I think it could it be used for such a purpose with _huge_ > advantage (especially in telephony applications) and yet without being too > open to wholesale abuse. It may also deprecate some of the reasons that > people are using B2BUA-like devices merely so that they can rewrite the > To/From fields (for subscriber identity hiding). [Where transport-layer > identity screening is not important, eg, on a multi-user server > or gateway.] [...] Eeek! I think this might be A Bridge Too Far. Okay, I guess that proxies could unwind any From (/ To) changes they made as responses swam back, but this is going to break loop detection and request-merge detection and I can imagine lots more with proxies that don't know these new rules, if nothing else. Just seems a little bit too much of a leap to me. - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 08:12:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26550 for ; Fri, 13 Jul 2001 08:12:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24690; Fri, 13 Jul 2001 07:48:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24660 for ; Fri, 13 Jul 2001 07:48:51 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23279 for ; Fri, 13 Jul 2001 07:48:00 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 11:48:51 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 12:49:38 +0100 From: "Jo Hornsby" To: "Jonathan Rosenberg" , "'Dean Willis'" , , Subject: RE: [Sip] Forking: a modest proposal. Date: Fri, 13 Jul 2001 12:48:49 +0100 Message-ID: <003701c10b91$c8130e20$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 13 Jul 2001 11:49:38.0797 (UTC) FILETIME=[E54851D0:01C10B91] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan wrote: > Dean wrote: > > Well, I've made the less modest proposal before that forking could be > > removed entirely from the specification. It seems to be an unpopular > > suggestion in some quarters, but I like to bring it up before > > IETF meetings as a matter of tradition (and in hopes that > > someday certain critical parties will agree). > > Well, "some quarters" includes me, at least (maybe only me, but I hope not > :) ). I'm not sure that it is possible to entirely remove it. Isn't SRV(or whatever)-based server selection a sort of forking? I realise it's not quite the same, but there are certainly elements of commonality. [...] > Now, back to the original question: to fork, or not-to-fork, > non-INVITEs. I > agree with Christian, and I think there is consensus on this, that forking > of a non-INVITE only makes sense if (1) that request establishes > no state at > the UASes, and the set of servers that are reached are > homogeneous, so that > a response from any are equivalent, Which is probably better served by SRV though, right? > or (2) a 3-way handshake can > be created > in some other way, specific to the method. Now, I think its fair > to say that > the usefulness of a method that meets (1) is not too high, and worse, we > can't guarantee this property for all methods. Indeed. The best justification for forking of a non-INVITE that I ever heard was for the old CANCEL + BYE to quickly tear down a call. However, a BYE is pretty unlikely to work if CPL appeared somewhere in the equation, and this is only an optimisation, so.... > So, indeed, the question is > whether we feel its useful to define, on a method by method basis (or > perhaps there is a general purpose solution lurking somehwhere?), a > three-way handshake to deal with forked non-INVITE. Well, I'm by no means an expert on sip-events, but something very similar to what Adam proposed with his SUBSCRIBE + immediate NOTIFYs seems an excellent starting block. Still, I'm not sure that this should be in baseline. Since we suspect that it's far less often the case, it would perhaps be more prudent to make this a draft a la SUB/NOT that does delivers nothing in itself, but rather provides a useful generic framework for other drafts. (Is there chance that SUB/NOT would become dependent in such an instance? This might cause real pain time- wise.) > But, if its something that has to be done on a method-by-method basis, > perhaps that belongs in the application space, using a B2BUA. Now, maybe > this is contradicting myself, since I just argued above that forking of > INVITE belongs in the protocol, and not in the application space. But, > forking of these non-INVITEs is presumably a much less common > ocurrence, so > that putting it in the application space is not as much a burden. I think I'm ambivalent. - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 08:17:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27232 for ; Fri, 13 Jul 2001 08:17:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24839; Fri, 13 Jul 2001 07:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24810 for ; Fri, 13 Jul 2001 07:56:21 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24215 for ; Fri, 13 Jul 2001 07:55:30 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id <3M51MG3S>; Fri, 13 Jul 2001 04:55:09 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Fri, 13 Jul 2001 04:55:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jo, > Eeek! I think this might be A Bridge Too Far. Okay, > I guess that proxies could unwind any From (/ To) changes > they made as responses swam back, but this is going to > break loop detection and request-merge detection and > I can imagine lots more with proxies that don't know these > new rules, if nothing else. Just seems a little bit too > much of a leap to me. Thanks for the response. Yeah, I definitely think that regardless of whether my addition is deemed a good idea or not we should consider JR's original suggestion independently. That was something I meant to add. The proxy would be required to remain call stateful (ie, the proxy would have to record-route) and unwind any changes it made to the To/From for this suggestion to be compatible with older proxies. Perhaps this is too great a burden to accept? (A Bridge Too Far). I still think it does have advantages though in my mind. People will do this sort of thing anyway except they may probably just use a full blown B2BUA instead - at least with this approach the two UA's can correlate the call-id in their CDR's. I've thought about the loop detection before I made the suggestion and I can't see it breaks it. Older proxies won't detect the loop (because they will see each instance as a separate call - which doesn't break anything) but given that the loop must include a proxy that does support the looser call-id definition (otherwise it wouldn't be loop) then the loop detection will be made. Right? Robert. > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Friday, July 13, 2001 12:22 PM > To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg' > Cc: sip@ietf.org > Subject: RE: [Sip] another modest proposal: change call-leg ID > > > Robert wrote: > > Jonathan wrote: > > > Well, the proposal is not meant to support proxies modifying > > > the To/From, > > > but rather, allow endpoints to change the To/From in the > > > middle of the call. > > > > > Hi Jonathan, > > > > Perhaps not but I think it could it be used for such a > purpose with _huge_ > > advantage (especially in telephony applications) and yet > without being too > > open to wholesale abuse. It may also deprecate some of the > reasons that > > people are using B2BUA-like devices merely so that they can > rewrite the > > To/From fields (for subscriber identity hiding). [Where > transport-layer > > identity screening is not important, eg, on a multi-user server > > or gateway.] > [...] > > Eeek! I think this might be A Bridge Too Far. Okay, > I guess that proxies could unwind any From (/ To) changes > they made as responses swam back, but this is going to > break loop detection and request-merge detection and > I can imagine lots more with proxies that don't know these > new rules, if nothing else. Just seems a little bit too > much of a leap to me. > > > - Jo. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 09:52:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09524 for ; Fri, 13 Jul 2001 09:52:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27253; Fri, 13 Jul 2001 09:46:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27223 for ; Fri, 13 Jul 2001 09:46:53 -0400 (EDT) Received: from smtp.monmouth.com (smtp.monmouth.com [209.191.58.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08691 for ; Fri, 13 Jul 2001 09:46:00 -0400 (EDT) Received: from aplion.com ([205.229.218.99]) by smtp.monmouth.com (8.11.4/8.11.4) with ESMTP id f6DDkpF05314 for ; Fri, 13 Jul 2001 09:46:52 -0400 (EDT) Message-ID: <3B4EFC26.2B6FCC4B@aplion.com> Date: Fri, 13 Jul 2001 09:48:22 -0400 From: Ravi Shiroor Organization: Aplion Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] registration thru nat Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i am trying to use trial version of hearme softphone to register with public proxy servers. i am failing, i think, because i am behind nat. any sip ua (handset/softphone) available which can work from behind nat? thanks, ravi. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 10:19:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13064 for ; Fri, 13 Jul 2001 10:18:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27966; Fri, 13 Jul 2001 10:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27936 for ; Fri, 13 Jul 2001 10:08:24 -0400 (EDT) Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11506 for ; Fri, 13 Jul 2001 10:07:31 -0400 (EDT) From: duncan.mills@vf.vodafone.co.uk Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id PAA28227; Fri, 13 Jul 2001 15:07:51 +0100 (BST) Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 13 Jul 2001 15:05:20 +0100 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21) id <34N3F5PN>; Fri, 13 Jul 2001 15:03:50 +0100 Message-Id: To: sip@ietf.org Date: Fri, 13 Jul 2001 15:03:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question on the Subscribe/Notify draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, I understand from the document 'draft-roach-sip-subscribe-notify-03.txt' that subscriptions must be re-freshed in a similar manner to which registrations are re-freshed. My question is, can I set the expires header in SUBSCRIBE messages to a very high time (e.g. days) whilst retaining the registration duration reasonably low (e.g. hours) ? In other words I may want the UA to re-register every hour but I don't want it to have to re-subscribe too often... The draft seems to not forbid such behaviour, but am I missing something else? Best Regards, Duncan MILLS _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 10:24:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13893 for ; Fri, 13 Jul 2001 10:24:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27433; Fri, 13 Jul 2001 09:56:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27406 for ; Fri, 13 Jul 2001 09:56:28 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09895 for ; Fri, 13 Jul 2001 09:55:35 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6DDu5p03621; Fri, 13 Jul 2001 08:56:05 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6DDu4218719; Fri, 13 Jul 2001 08:56:04 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id IAA25323; Fri, 13 Jul 2001 08:56:03 -0500 (CDT) Reply-To: To: , "Henning Schulzrinne" Cc: "Paul Kyzivat" , "Jay Batson" , Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) Date: Fri, 13 Jul 2001 08:56:00 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> 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 Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr > > Maybe I'm missing something, but I have the feeling that you > are always putting together the session control and the > bearer control , which is very likely the case of real user > agents, that is end-users, but definitely not the case of > servers in the > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > The splitting of the session layer and the bearer layer is > the current trend of Next Generation Networks in the Telecom > world, including obviously the UMTS environment. > > So, when I was talking about a B2BUA providing services > (which is still appearing as a proxy) I was not talking about > bearer manipulation, codec insertion, etc. Instead, I was > talking about services provided on top of the session layer, > as e.g. conference, > meet-me, follow-me services, etc. Forgive my agreeing with you, but maybe you *are* missing something. I'd be very interested in the scenarios under which you beleive a B2BUA can provide any value add in the conference and meet-me scenarios without any corresponding node in the media path. I'm also very interested in knowing how acting as a B2BUA instead of a proxy when providing a find-me/follow-me service helps in any way. Given that using a B2BUA destroys feature transparency, the unnecssary insertion in this case seems very short sighted. /a _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 10:36:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15575 for ; Fri, 13 Jul 2001 10:36:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28092; Fri, 13 Jul 2001 10:11:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28061 for ; Fri, 13 Jul 2001 10:11:47 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11984 for ; Fri, 13 Jul 2001 10:10:54 -0400 (EDT) From: sean.olson@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6DEBD521402; Fri, 13 Jul 2001 09:11:13 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6DEBD227344; Fri, 13 Jul 2001 09:11:13 -0500 (CDT) Received: from e0000865ab2db (pc050200.exu.ericsson.se [138.85.50.200]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id JAA26392; Fri, 13 Jul 2001 09:11:12 -0500 (CDT) Reply-To: To: , Subject: RE: [Sip] Question on the Subscribe/Notify draft Date: Fri, 13 Jul 2001 09:11:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA28062 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The REGISTER and SUBSCRIBE are independent. You can set the Expires: to different values if you want with no ill consequences. Regards, Sean Olson Ericsson Inc. >-----Original Message----- >From: duncan.mills@vf.vodafone.co.uk >[mailto:duncan.mills@vf.vodafone.co.uk] >Sent: Friday, July 13, 2001 9:04 AM >To: sip@ietf.org >Subject: [Sip] Question on the Subscribe/Notify draft > > >Hi all, > >I understand from the document >'draft-roach-sip-subscribe-notify-03.txt' >that subscriptions must be re-freshed in a similar manner to which >registrations are re-freshed. > >My question is, can I set the expires header in SUBSCRIBE >messages to a very >high time (e.g. days) whilst retaining the registration >duration reasonably >low (e.g. hours) ? > >In other words I may want the UA to re-register every hour but >I don't want >it to have to re-subscribe too often... > >The draft seems to not forbid such behaviour, but am I missing >something >else? > >Best Regards, > >Duncan MILLS > > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 12:05:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28668 for ; Fri, 13 Jul 2001 12:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00827; Fri, 13 Jul 2001 11:55:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00796 for ; Fri, 13 Jul 2001 11:55:32 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27036 for ; Fri, 13 Jul 2001 11:54:40 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jul 2001 15:55:32 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 13 Jul 2001 16:56:21 +0100 From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] another modest proposal: change call-leg ID Date: Fri, 13 Jul 2001 16:55:31 +0100 Message-ID: <004801c10bb4$3ed638d0$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 13 Jul 2001 15:56:21.0098 (UTC) FILETIME=[5C2434A0:01C10BB4] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert wrote: > > Eeek! I think this might be A Bridge Too Far. Okay, > > I guess that proxies could unwind any From (/ To) changes > > they made as responses swam back, but this is going to > > break loop detection and request-merge detection and > > I can imagine lots more with proxies that don't know these > > new rules, if nothing else. Just seems a little bit too > > much of a leap to me. > > Thanks for the response. > > Yeah, I definitely think that regardless of whether my addition > is deemed a > good idea or not we should consider JR's original suggestion > independently. > > That was something I meant to add. The proxy would be required to remain > call stateful (ie, the proxy would have to record-route) and unwind any > changes it made to the To/From for this suggestion to be compatible with > older proxies. No, I don't think that call statefulness is required. It just needs to unwind on a transaction basis. (If you're thinking that call statefulness could enable it to "resume" the original From / To on a re-INVITE, think what a downstream Record-Routed proxy would see on a re-INVITE from the callee....) > Perhaps this is too great a burden to accept? (A Bridge Too > Far). I still think it does have advantages though in my mind. Oh yeah, I can see advantages, but I feel it's a little bit too brittle: playing with such fundamental headers now. > Peoplewill > do this sort of thing anyway except they may probably just use a > full blown > B2BUA instead - at least with this approach the two UA's can correlate the > call-id in their CDR's. > > I've thought about the loop detection before I made the suggestion and I > can't see it breaks it. Older proxies won't detect the loop (because they > will see each instance as a separate call - which doesn't break anything) > but given that the loop must include a proxy that does support the looser > call-id definition (otherwise it wouldn't be loop) then the loop detection > will be made. Right? True, true. Didn't think it through enough. - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 13:57:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15003 for ; Fri, 13 Jul 2001 13:57:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03087; Fri, 13 Jul 2001 13:30:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03058 for ; Fri, 13 Jul 2001 13:30:47 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11057 for ; Fri, 13 Jul 2001 13:29:56 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA05546; Fri, 13 Jul 2001 17:30:44 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02440; Fri, 13 Jul 2001 17:30:43 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFWVVWA>; Fri, 13 Jul 2001 11:30:42 -0600 Message-ID: <17052388D394D411803900508BDFFAF6013DCA6E@n0214idc1.oss.level3.com> To: sip@ietf.org Cc: sean.olson@ericsson.com Subject: RE: [Sip] Maintaining transport between servers (was: Transport p arm in Rec ord-Route) Date: Fri, 13 Jul 2001 11:30:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I haven't heard further on this thread. Do we have WG concensus the transport parm should be allowed in RR? -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, June 27, 2001 9:11 AM To: Hearty, John Subject: RE: [Sip] Maintaining transport between servers (was: Transport p arm in Rec ord-Route) That is what I was talking about. I agree that we should allow the transport parm in the RR. /sean >-----Original Message----- >From: John.Hearty@Level3.com [ mailto:John.Hearty@Level3.com ] >Sent: Wednesday, June 27, 2001 10:01 AM >To: sean.olson@ericsson.com; sip@ietf.org >Subject: RE: [Sip] Maintaining transport between servers (was: >Transport >p arm in Rec ord-Route) > > > Are you referring to the discussions involving a proxy being >able to add >the RR looking a certain way in the request, and modify the RR in the >response to look different to the other side? That would work >to solve my >latest concern. We still need to get past the verbage disallowing the >transport parm in the RR. > >John > > >-----Original Message----- >From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] >Sent: Wednesday, June 27, 2001 8:43 AM >To: Hearty, John; sip@ietf.org >Subject: RE: [Sip] Maintaining transport between servers (was: >Transport p >arm in Rec ord-Route) > > > >I thought we agree the RR could be asymmetric. That is >the RR could be different in either direction to allow >for the types of variations that you are speaking of. > >/sean > >>-----Original Message----- >>From: John.Hearty@Level3.com [ mailto:John.Hearty@Level3.com >< mailto:John.Hearty@Level3.com > ] >>Sent: Wednesday, June 27, 2001 9:19 AM >>To: sip@ietf.org >>Subject: [Sip] Maintaining transport between servers (was: Transport >>parm in Rec ord-Route) >> >> >> >> I had another thought on this prompting me to rename the >>thread. The goal >>is to use the same transport between two servers for subsequent >>transactions. Simply putting the transport in a record-route has an >>undesirable side affect. That route could be used by the hop >>on either side >>of the server that added it. In the original example, if UAS sent a >>subsequent request it might try to do it over TLS when all >>that is needed >>there is UDP. We need some mechanism in SIP to communicate a desired >>transport between two specific servers in the Route list that >>will work for >>subsequent requests in either direction. >> >>John >> >> >> >>> We have encountered a problem with the requirement in 16.3 where >>>Record-Route MUST NOT contain the transport parameter. I >>realize this was >>>designed to handle the possibility of requiring a UA that >>does not support >>a >>>particular transport to use said transport, resulting in a failure. >>>However, this also causes problems when the proxy must use only one >>>transport for all transactions. Take for example a proxy (B) >>in a private >>>network that has a TLS connection with a trusted peer proxy >>(A) on the open >>>Internet. The flow for an Invite might be something like: >>> >>>UAC -> proxy (A) -> proxy (B) -> UAS >>> >>> Now if both proxies are record-routed without the transport >parm, the >>>initial transaction could be setup on TLS OK based on proxy >>(A) routing >>>decisions, but if a subsequent transaction such as BYE came >>from the UAC, >>>proxy (A) would see a Route header with no transport parm, >>use it as the >>>req-URI which, lacking a transport parm results in using >>default UDP (see >>>reference below). Since proxy (B) only trusts and listens >>for requests >>over >>>a TLS connection, the request fails. >>> >>>From section 2, descrition of URL parameters: >>> >>>UDP is to be assumed when no explicit transport parameter is >included. >>> >>> Perhaps some new verbage is needed describing proxy >>behaviour and how to >>>select the transport protocol when not specified, i.e. look >>for open TLS or >>>TCP sockets to the destination first. This still might not >>help if for >>>example the transport was TCP and the socket timed out due to >>inactivity. >>>There may be other ways around this problem I have not >>thought through yet. >>>Comments? >>> >>> >>>John Hearty >>>Level3 >>> >> >>_______________________________________________ >>Sip mailing list http://www.ietf.org/mailman/listinfo/sip >< http://www.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 15:54:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00928 for ; Fri, 13 Jul 2001 15:54:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05532; Fri, 13 Jul 2001 15:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05503 for ; Fri, 13 Jul 2001 15:29:56 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27463 for ; Fri, 13 Jul 2001 15:29:04 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DJSpRX021861 for ; Fri, 13 Jul 2001 15:28:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC40Q7>; Fri, 13 Jul 2001 15:29:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Fri, 13 Jul 2001 15:29:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] new I-D on early media Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I've just submitted an I-D on early media. As we agreed upon previously, the concept of early media would be done as an extension, where it could be handled properly. The draft proposal fixes all of the known problems with early media, I believe, and is also nicely backwards compatible with the existing early media approaches. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-early-media-00.txt Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 16:17:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04245 for ; Fri, 13 Jul 2001 16:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06850; Fri, 13 Jul 2001 16:09:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06819 for ; Fri, 13 Jul 2001 16:09:25 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02839 for ; Fri, 13 Jul 2001 16:08:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DK8ARX022233; Fri, 13 Jul 2001 16:08:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC40VA>; Fri, 13 Jul 2001 16:08:44 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Cc: "'rohc@cdt.luth.se'" Date: Fri, 13 Jul 2001 16:08:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] New I-D on compression of SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I've just submitted a new I-D on compression of SIP messages, particularly for wireless links. Until the draft appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 19:28:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28191 for ; Fri, 13 Jul 2001 19:28:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09884; Fri, 13 Jul 2001 18:42:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09855 for ; Fri, 13 Jul 2001 18:42:10 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22773 for ; Fri, 13 Jul 2001 18:41:18 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6DMfTT14310 for ; Fri, 13 Jul 2001 18:41:29 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6DMfTB14303 for ; Fri, 13 Jul 2001 18:41:29 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BED.12F21336" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 13 Jul 2001 16:42:19 -0600 Message-ID: Thread-Topic: REFER call matching Thread-Index: AcEL7RxJ4wXfv/eQQVa4934i+V+Y8Q== From: "Zmolek, Andrew (Andrew)" To: Subject: [Sip] REFER call matching Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10BED.12F21336 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose A transfers B to C when A and C share more than one active call leg (perhaps each has hundreds of active calls). What mechanism ensures that the correct leg between A and C is replaced by C when C receives the correct token from B?=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 ------_=_NextPart_001_01C10BED.12F21336 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable REFER call matching

Suppose A transfers B to C when A and C share more = than one active call leg (perhaps each has hundreds of active calls). = What mechanism ensures that the correct leg between A and C is replaced = by C when C receives the correct token from B?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

------_=_NextPart_001_01C10BED.12F21336-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 13 23:47:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29838 for ; Fri, 13 Jul 2001 23:47:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15573; Fri, 13 Jul 2001 23:36:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15542 for ; Fri, 13 Jul 2001 23:36:00 -0400 (EDT) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28513 for ; Fri, 13 Jul 2001 23:35:07 -0400 (EDT) Received: from pingtel.com (h0080c7f24588.ne.mediaone.net [66.31.105.187]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f6E3b9P22052; Fri, 13 Jul 2001 23:37:09 -0400 Message-ID: <3B4FBDDC.3449FE2A@pingtel.com> Date: Fri, 13 Jul 2001 23:34:52 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: sip@ietf.org Subject: Re: [Sip] REFER call matching References: Content-Type: multipart/alternative; boundary="------------E937C68FFF07818FA5615CE3" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------E937C68FFF07818FA5615CE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://search.ietf.org/internet-drafts/draft-biggs-sip-replaces-00.txt "Zmolek, Andrew (Andrew)" wrote: > Suppose A transfers B to C when A and C share more than > one active call leg (perhaps each has hundreds of active > calls). What mechanism ensures that the correct leg > between A and C is replaced by C when C receives the > correct token from B? > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 --------------E937C68FFF07818FA5615CE3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit http://search.ietf.org/internet-drafts/draft-biggs-sip-replaces-00.txt

"Zmolek, Andrew (Andrew)" wrote:

Suppose A transfers B to C when A and C share more than one active call leg (perhaps each has hundreds of active calls). What mechanism ensures that the correct leg between A and C is replaced by C when C receives the correct token from B?

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001

--------------E937C68FFF07818FA5615CE3-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 14 02:47:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04402 for ; Sat, 14 Jul 2001 02:47:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26389; Sat, 14 Jul 2001 01:54:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26359 for ; Sat, 14 Jul 2001 01:54:15 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20382 for ; Sat, 14 Jul 2001 01:53:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6E5rBRX024361 for ; Sat, 14 Jul 2001 01:53:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYCVANB>; Sat, 14 Jul 2001 01:53:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Sat, 14 Jul 2001 01:53:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] new I-D on recovery of UA failures Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I've submitted an I-D to the archives which discusses the problem of "crash-and-restart" recovery in a SIP UA. It discusses broader, more interesting applications of the recovery mechanism, and details the requirements on how to do it effectively. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 06:15:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05007 for ; Mon, 16 Jul 2001 06:15:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02756; Mon, 16 Jul 2001 05:54:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02727 for ; Mon, 16 Jul 2001 05:54:56 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02762 for ; Mon, 16 Jul 2001 05:54:02 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 16 Jul 2001 09:54:57 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 16 Jul 2001 10:55:55 +0100 From: "Jo Hornsby" To: Subject: RE: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Mon, 16 Jul 2001 10:54:56 +0100 Message-ID: <005901c10ddd$5e191480$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200107121106.HAA01610@ietf.org> X-OriginalArrivalTime: 16 Jul 2001 09:55:55.0243 (UTC) FILETIME=[815DDBB0:01C10DDD] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Quick Question. Why are "non-participatory" Redirect Servers required to copy the Cookie header into responses? Am I being really dull here? Thanks, - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 07:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12964 for ; Mon, 16 Jul 2001 07:15:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04413; Mon, 16 Jul 2001 07:02:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04383 for ; Mon, 16 Jul 2001 07:02:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10658; Mon, 16 Jul 2001 07:01:20 -0400 (EDT) Message-Id: <200107161101.HAA10658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Jul 2001 07:01:19 -0400 Subject: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple way of Reliability of Provisional Responses in SIP Author(s) : K. Kiss et al. Filename : draft-kiss-sip-s100rel-00.txt Pages : 11 Date : 13-Jul-01 This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. The extension can be seen as an alternative proposal of [6], where the method PRACK and the package 100rel are described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kiss-sip-s100rel-00.txt 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-kiss-sip-s100rel-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-kiss-sip-s100rel-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: <20010713124346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kiss-sip-s100rel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kiss-sip-s100rel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 07:18:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13306 for ; Mon, 16 Jul 2001 07:18:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04451; Mon, 16 Jul 2001 07:02:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04423 for ; Mon, 16 Jul 2001 07:02:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10721; Mon, 16 Jul 2001 07:01:31 -0400 (EDT) Message-Id: <200107161101.HAA10721@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Jul 2001 07:01:31 -0400 Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Proxy-Supported header field Author(s) : B. Hoeneisen et al. Filename : draft-hoeneisen-sip-proxy-supported-00.txt Pages : 11 Date : 13-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a User Agent Client (UAC) to request that a particular protocol extension has to be used to process the request. The User Agent Server (UAS) declines the request if it does not support the extension. Recently also means have been defined for the User Agent Server (UAS) to determine which extensions are supported by the User Agent Client (UAC). Furthermore there are also means for requiring proxy servers to understand certain features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt 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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-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: <20010713124407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hoeneisen-sip-proxy-supported-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124407.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 07:19:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13393 for ; Mon, 16 Jul 2001 07:19:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04333; Mon, 16 Jul 2001 07:01:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04302 for ; Mon, 16 Jul 2001 07:01:46 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10479; Mon, 16 Jul 2001 07:00:54 -0400 (EDT) Message-Id: <200107161100.HAA10479@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Jul 2001 07:00:54 -0400 Subject: [Sip] I-D ACTION:draft-agrawal-sip-h323-interworking-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP-H.323 Interworking Author(s) : H. Agrawal Filename : draft-agrawal-sip-h323-interworking-01.txt Pages : 121 Date : 13-Jul-01 This document describes the interworking between SIP and H.323 protocols. It defines the the logical entity known as the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between the SIP (Session Initiation Protocol) and H.323 protocols. This includes the call sequence mapping, message parameter mapping, translation between H.245 and SDP, state machines, and handling of different call procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-01.txt 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-agrawal-sip-h323-interworking-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-agrawal-sip-h323-interworking-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010713124303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-agrawal-sip-h323-interworking-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-agrawal-sip-h323-interworking-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124303.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 18:20:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22340 for ; Mon, 16 Jul 2001 18:20:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22003; Mon, 16 Jul 2001 17:51:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21972 for ; Mon, 16 Jul 2001 17:51:19 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17692 for ; Mon, 16 Jul 2001 17:50:26 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6GLpIm09323; Mon, 16 Jul 2001 17:51:19 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA28746; Mon, 16 Jul 2001 16:51:17 -0500 (CDT) Message-ID: <3B5361D0.DF2EE3F7@lucent.com> Date: Mon, 16 Jul 2001 16:51:12 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] new I-D on recovery of UA failures References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Folks, > > I've submitted an I-D to the archives which discusses the problem of > "crash-and-restart" recovery in a SIP UA. It discusses broader, more > interesting applications of the recovery mechanism, and details the > requirements on how to do it effectively. Jonathan: Quick question: in Section 4, when UA3 cannot reconstitute a call (after UA2, the original UA, has failed), why does UA1 send a BYE? Does sending a BYE help at all? If UA3 could not reconstitute the call, it will probably not be able to process the BYE as well. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 16 18:29:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23301 for ; Mon, 16 Jul 2001 18:29:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22534; Mon, 16 Jul 2001 18:09:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22500 for ; Mon, 16 Jul 2001 18:09:42 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20754 for ; Mon, 16 Jul 2001 18:08:48 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6GM9cN17431 for ; Tue, 17 Jul 2001 00:09:38 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 17 00:09:37 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 00:09:37 +0200 Message-ID: From: "Lars-Erik Jonsson (EPL)" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Cc: "'rohc@cdt.luth.se'" Date: Tue, 17 Jul 2001 00:09:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [rohc] New I-D on compression of SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, First of all I have to say that I think it is good that we now have several contributors to this discussion about signaling compression, e.g. SIP compression. I have read your draft and have a number of comments but before I take them all I would like to ask you for some clarifications about how you mean this new "protocol shim" is introduced in reality. You say that it becomes a new alternate transport but it is not clear how this is indicated. Is your intention to create a new "UDP-compress" transport protocol (new protocol ID)? Cheers, /L-E > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: den 13 juli 2001 22:09 > To: 'sip@ietf.org' > Cc: 'rohc@cdt.luth.se' > Subject: [rohc] New I-D on compression of SIP > > > Folks, > > I've just submitted a new I-D on compression of SIP messages, > particularly > for wireless links. Until the draft appears in the archives, > you can pick up > a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 17 01:42:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13232 for ; Tue, 17 Jul 2001 01:42:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09330; Tue, 17 Jul 2001 01:20:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09301 for ; Tue, 17 Jul 2001 01:20:39 -0400 (EDT) Received: from boca-isbu-nt04.boca.unispheresolutions.com (exchange.br-unispheresolutions.com [63.111.211.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05752 for ; Tue, 17 Jul 2001 01:19:47 -0400 (EDT) Received: by boca-isbu-nt04.boca.unispheresolutions.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 01:20:17 -0400 Message-ID: <153BDA136259D311859900A0C99B5263FA0CBA@boca-isbu-nt04.boca.unispheresolutions.com> From: "Buller, Jeremy" To: "'Vijay Gurbani '" , "'Jonathan Rosenberg '" Cc: "''sip@ietf.org' '" Subject: RE: [Sip] new I-D on recovery of UA failures Date: Tue, 17 Jul 2001 01:20:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Vijay, > Quick question: in Section 4, when UA3 cannot reconstitute a call (after > UA2, the original UA, has failed), why does UA1 send a BYE? Does > sending a BYE help at all? If UA3 could not reconstitute the call, it > will probably not be able to process the BYE as well. My understanding was that UA3 would have received the INVITE, determined that it could not reconstitute the call (using the description in section 6) and then responded with a 481. Btw, I liked the ideas for the 'To' tag enhancement algorithm. A BYE is then 'required' to be sent from UA1 and UA3 should be capable of handling this, thus terminating the interaction between UA1 and UA3 in the 'standard' way. Best regards, Jim Buller _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 17 09:41:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06037 for ; Tue, 17 Jul 2001 09:41:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21055; Tue, 17 Jul 2001 09:20:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21026 for ; Tue, 17 Jul 2001 09:20:06 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02870 for ; Tue, 17 Jul 2001 09:19:10 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Jul 2001 13:20:04 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 17 Jul 2001 14:20:06 +0100 Message-ID: <3B543B63.DC2B657C@ubiquity.net> Date: Tue, 17 Jul 2001 14:19:31 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EPL)" CC: "'Jonathan Rosenberg'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: Re: [Sip] RE: [rohc] New I-D on compression of SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2001 13:20:06.0589 (UTC) FILETIME=[3226A6D0:01C10EC3] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Lars-Erik Jonsson (EPL)" wrote: > Hi Jonathan, > > First of all I have to say that I think it is good that we now have several contributors to this discussion about signaling compression, e.g. SIP compression. I have read your draft and have a number of comments but before I take them all I would like to ask you for some clarifications about how you mean this new "protocol shim" is introduced in reality. You say that it becomes a new alternate transport but it is not clear how this is indicated. Is your intention to create a new "UDP-compress" transport protocol (new protocol ID)? I think by this Jonathan means to have a new transport parameter for SIP URLs and position the encoding/decoding just above the UDP "stack" code and below the SIP "stack" code. My major concern is the lack of a message acknowledgement mechanism, I know why this was done, however, in the pathelogical case in SIP where all the Request transmissions are lost, the decoder will never update it's codebook from then on adding to the overheads not helping. James _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 17 10:40:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19294 for ; Tue, 17 Jul 2001 10:40:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22151; Tue, 17 Jul 2001 10:04:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22122 for ; Tue, 17 Jul 2001 10:04:07 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10488 for ; Tue, 17 Jul 2001 10:03:10 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6HE43902025 for ; Tue, 17 Jul 2001 10:04:03 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6HE42V02005; Tue, 17 Jul 2001 10:04:02 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA25682; Tue, 17 Jul 2001 09:04:01 -0500 (CDT) Message-ID: <3B5445CA.7359CA42@lucent.com> Date: Tue, 17 Jul 2001 09:03:54 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Buller, Jeremy" CC: "'Jonathan Rosenberg '" , "''sip@ietf.org' '" Subject: Re: [Sip] new I-D on recovery of UA failures References: <153BDA136259D311859900A0C99B5263FA0CBA@boca-isbu-nt04.boca.unispheresolutions.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Buller, Jeremy" wrote: > > Hi Vijay, > > > Quick question: in Section 4, when UA3 cannot reconstitute a call (after > > UA2, the original UA, has failed), why does UA1 send a BYE? Does > > sending a BYE help at all? If UA3 could not reconstitute the call, > it will probably not be able to process the BYE as well. > My understanding was that UA3 would have received the INVITE, > determined that it could not reconstitute the call (using the > description in section 6) and then responded with a 481. Btw, > I liked the ideas for the 'To' tag enhancement algorithm. A > BYE is then 'required' to be sent from UA1 and UA3 should be > capable of handling this, thus terminating the interaction > between UA1 and UA3 in the 'standard' way. Hi Jim: I still don't think UA3 will honor the BYE if it send a 481. As far as it is concerned, it could not establish a (reconstituted) session, hence it send the 481. So why should it honor a BYE? According to the spec, a session (barring early media) is established by the UAS sending a 200 OK, not a 481. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 17 14:56:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16316 for ; Tue, 17 Jul 2001 14:56:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01807; Tue, 17 Jul 2001 14:17:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01775 for ; Tue, 17 Jul 2001 14:17:08 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08509 for ; Tue, 17 Jul 2001 14:16:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HIFvRX012009; Tue, 17 Jul 2001 14:15:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 14:16:32 -0400 Message-ID: From: Igor Slepchin To: "'Jay Batson'" , Michael Hammer Cc: "'Dean Willis'" , adam.roach@ericsson.com, sip@ietf.org Subject: RE: [Sip] Forking: a modest proposal. Date: Tue, 17 Jul 2001 14:16:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Well, redirect is not as perfect as it may first sound. It has at least the following two problems: 1. Increased call setup latency (the redirect response has to travel all the way back to the client before it can be acted upon) 2. It's not always possible to have the call redirected. For example, in ACD environment the only address available to the UAC should be sip:customerservice@company.com; you would not want to give away individual addresses of your customer reps by sending them back in a 3xx response. Besides, those addresses may not even be reachable outside of company.com network. Thank you, Igor Slepchin -----Original Message----- From: Jay Batson [mailto:jbatson@pingtel.com] Very thoughtful response, Michael. I find it interesting that server companies aren't making much more extensive use of redirect. It scales well, it keeps (potentially unnecessary) servers out of a long list of Route-Recorded waystations that delay message delivery. Etc. I suspect it is because of business issues, not technical issues. If one is building a server, one needs insure that the server adds lots of value and stays "in the loop" sufficiently in order that that server pulls in enough revenue.... Especially if you don't make clients/UAs as well. Which is why folks like Sylantro, Broadsoft, and others (whom I'm not letting see this by virtue of *not* copying the list) are basically *not* implementing even Proxies, but full, big-honkin B2BUAs as their core architecture (I think). There is, in the product world, a deep temptation to be in the control loop wherever possible -- vs. wherever necessary.... Cheers -jb At 11:05 AM 7/11/01, you wrote: Jonathan, If you really want to push the call state to the edge, then there should be forking redirect servers, not proxies. If forking is needed, the associated information should be sent back to the UAC and let it do the forking of requests and handling responses. Some of the previous discussion indicates ambiguity over whether the forking proxy is handling the transaction responses or the UAC. Doesn't seem clean to me. The reason for the forking is service related, not session setup related and as such you open pandoras box to other service-related "cruft" being introduced to the base protocol. It seems that the main advance of SIP over legacy protocols was that adherence to general purpose mechanisms that are not service specific. Where the legacy systems made a distinction between basic call setup and supplementary services, they did not keep the protocol elements associated with each separate. Now, it appears that SIP has addressed the basic session setup elements and is facing the same issues of how to do more advance services as before. Question is, do you start adding protocol elements that are needed by only certain classes of services? After that, when do you stop? Is there another way to handle service-specific data that is peculiar to an application (e.g. supplementary service) but not general to all sessions? Mike At 02:05 AM 7/11/2001 -0400, Jonathan Rosenberg wrote: > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, July 06, 2001 9:30 PM > To: adam.roach@ericsson.com; sip@ietf.org > Subject: Re: [Sip] Forking: a modest proposal. > > > Well, I've made the less modest proposal before that forking could be > removed entirely from the specification. It seems to be an unpopular > suggestion in some quarters, but I like to bring it up before > IETF meetings > as a matter of tradition (and in hopes that someday certain > critical parties > will agree). Well, "some quarters" includes me, at least (maybe only me, but I hope not :) ). The reason its in the spec is, as Henning has pointed out, to avoid the propagation of call state into the network. SIP was designed, first and foremost, as a rendezvous type of protocol that could find a user at a multitude of locations, and connect the caller to the called party across different devices. In its role as a user discovery and connection protocol, supporting the ability to reach a user at several devices is a big reuqirement. Since we were also in the business of designing Internet protocols, we wanted to push state to the edges, so that one could build a system to do basic functions without all this cruft in the middle of the network. Indeed, Jay has raised the flag on that in a separate note on this thread. Removing forking from SIP means more of those B2BUAs. Lots more, I think (in fact, pretty much all proxies will turn into B2BUAs as a default mode). So, given its there already, I'd rather keep it, and instead, do a far better job of explaining it in the spec. Its not really THAT hard, its just that the spec is not exactly lucid on this, and many other, topics. Now, back to the original question: to fork, or not-to-fork, non-INVITEs. I agree with Christian, and I think there is consensus on this, that forking of a non-INVITE only makes sense if (1) that request establishes no state at the UASes, and the set of servers that are reached are homogeneous, so that a response from any are equivalent, or (2) a 3-way handshake can be created in some other way, specific to the method. Now, I think its fair to say that the usefulness of a method that meets (1) is not too high, and worse, we can't guarantee this property for all methods. So, indeed, the question is whether we feel its useful to define, on a method by method basis (or perhaps there is a general purpose solution lurking somehwhere?), a three-way handshake to deal with forked non-INVITE. But, if its something that has to be done on a method-by-method basis, perhaps that belongs in the application space, using a B2BUA. Now, maybe this is contradicting myself, since I just argued above that forking of INVITE belongs in the protocol, and not in the application space. But, forking of these non-INVITEs is presumably a much less common ocurrence, so that putting it in the application space is not as much a burden. I'll be sure to put this topic on my running open-issues list for London. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------------- PingMe! Jay Batson CEO Pingtel Corp. mailto:jbatson@pingtel.com 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 07:02:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27392 for ; Wed, 18 Jul 2001 07:02:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07514; Wed, 18 Jul 2001 06:42:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07486 for ; Wed, 18 Jul 2001 06:42:12 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22275 for ; Wed, 18 Jul 2001 06:41:18 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6IAfj618901 for ; Wed, 18 Jul 2001 03:41:45 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAB20061; Wed, 18 Jul 2001 03:41:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08447; Wed, 18 Jul 2001 03:41:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.26595.349664.456815@thomasm-u1.cisco.com> Date: Wed, 18 Jul 2001 03:41:39 -0700 (PDT) To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt In-Reply-To: <200107121106.HAA01610@ietf.org> References: <200107121106.HAA01610@ietf.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, I'll bite. How does this differ from the state draft? I've scanned it over and it looks to be doing about the same thing. What am I missing? Mike Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIP Cookies > Author(s) : D. Willis, B. Rosen > Filename : draft-willis-sip-cookies-00.txt > Pages : 9 > Date : 11-Jul-01 > > This document describes an extension to SIP (RFC 2543) to provide a > mechanism for storing state and other information in SIP comparable > to the HTTP state mechanisms defined in RFC 2109. This extension > includes a new SIP header ('Cookie:'), an option tag for feature > negotiation ('cookie') and IANA registration considerations for > registering the 'cookie' extension, semantics of the value of the > Cookie: header, and behavioral rules for processing these headers by > SIP nodes supporting the 'cookie' extension. This document also > briefly discusses possible uses of cookies, and security > considerations for their use. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt > > 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-willis-sip-cookies-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-willis-sip-cookies-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. > Content-Type: text/plain > Content-ID: <20010711155737.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-willis-sip-cookies-00.txt > Content-Type: text/plain > Content-ID: <20010711155737.I-D@ietf.org> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 07:16:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00627 for ; Wed, 18 Jul 2001 07:16:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08263; Wed, 18 Jul 2001 07:01:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08235 for ; Wed, 18 Jul 2001 07:01:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26283; Wed, 18 Jul 2001 07:00:38 -0400 (EDT) Message-Id: <200107181100.HAA26283@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, rohc@cdt.luth.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jul 2001 07:00:38 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-early-media-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Early Media Author(s) : J. Rosenberg Filename : draft-rosenberg-sip-early-media-00.txt Pages : 23 Date : 17-Jul-01 Early Media is the ability of two SIP user agents to communicate before a SIP call is actually established. Support for early media is important largely for interoperability with the PSTN. Unfortunately, many SIP devices are providing this capability today without a well- documented, consistent, and complete solution. We define the problem of early media, document and describe the difficulties with the current approach used in SIP UAs, and present a more formal protocol mechanism that resolves these difficulties A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-early-media-00.txt 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-rosenberg-sip-early-media-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-rosenberg-sip-early-media-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: <20010717133445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-early-media-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-early-media-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717133445.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 07:16:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00625 for ; Wed, 18 Jul 2001 07:16:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08220; Wed, 18 Jul 2001 07:01:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08193 for ; Wed, 18 Jul 2001 07:01:17 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26112; Wed, 18 Jul 2001 07:00:22 -0400 (EDT) Message-Id: <200107181100.HAA26112@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jul 2001 07:00:22 -0400 Subject: [Sip] I-D ACTION:draft-lass-sip-remote-call-setup-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Call Setup Author(s) : S. Lass Filename : draft-lass-sip-remote-call-setup-00.txt Pages : 5 Date : 17-Jul-01 This document describes a method for 3rd Party call setup using the SIP REFER [2] message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lass-sip-remote-call-setup-00.txt 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-lass-sip-remote-call-setup-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-lass-sip-remote-call-setup-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: <20010717133416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lass-sip-remote-call-setup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lass-sip-remote-call-setup-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717133416.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 07:18:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00901 for ; Wed, 18 Jul 2001 07:18:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08359; Wed, 18 Jul 2001 07:03:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08329 for ; Wed, 18 Jul 2001 07:03:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27159; Wed, 18 Jul 2001 07:02:09 -0400 (EDT) Message-Id: <200107181102.HAA27159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jul 2001 07:02:09 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-cc-framework-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP Call Control - Framework Author(s) : B. Campbell Filename : draft-ietf-sip-cc-framework-00.txt Pages : 7 Date : 17-Jul-01 This document proposes that SIP call control features be added in a modular fashion, using an open-ended framework of extensions instead of a single extension. This memo proposes a modular design philosophy for call control extensions, and lists current work-in-progress call control related drafts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-cc-framework-00.txt 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-cc-framework-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-cc-framework-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: <20010717134043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717134043.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 07:23:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01506 for ; Wed, 18 Jul 2001 07:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07890; Wed, 18 Jul 2001 07:00:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07847 for ; Wed, 18 Jul 2001 07:00:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25180; Wed, 18 Jul 2001 06:58:38 -0400 (EDT) Message-Id: <200107181058.GAA25180@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, rohc@cdt.luth.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Jul 2001 06:58:38 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Compression of SIP Author(s) : J. Rosenberg Filename : draft-rosenberg-rohc-sip-udpcomp-00.txt Pages : 12 Date : 17-Jul-01 The Session Initiation Protocol (SIP), along with many other IP protocols used for multimedia communications, are UDP-based, textual protocols engineered for bandwidth rich links. As a result, these messages have not been optimized for message size. With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G wireless, the large size of these messages is problematic, primarily for latency reasons. As a result, we propose a protocol shim between SIP (or any other UDP based protocol meeting our requirements) and UDP in order to efficiently compress SIP messages. Preliminary results have shown compression gains of up to 8:1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-rohc-sip-udpcomp-00.txt 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-rosenberg-rohc-sip-udpcomp-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-rosenberg-rohc-sip-udpcomp-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: <20010717133103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-rohc-sip-udpcomp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-rohc-sip-udpcomp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717133103.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 11:28:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19390 for ; Wed, 18 Jul 2001 11:28:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14990; Wed, 18 Jul 2001 11:03:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14962 for ; Wed, 18 Jul 2001 11:03:38 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12260 for ; Wed, 18 Jul 2001 11:02:42 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6IF3Zo01715 for ; Wed, 18 Jul 2001 11:03:35 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10581 for ; Wed, 18 Jul 2001 11:03:32 -0400 (EDT) Message-ID: <3B55A6DE.7687B3A9@lucent.com> Date: Wed, 18 Jul 2001 11:10:22 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Mail List Content-Type: multipart/mixed; boundary="------------69AF2A3EB69AC5D5515C9F65" Subject: [Sip] BIS-03 and UAS BYEs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------69AF2A3EB69AC5D5515C9F65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The first paragraph of 15.4 of draft-ietf-sip-rfc2543bis-03 is a big improvement being more explicit about when subsequent requests can be sent but there still seems one ambiguity. Since BYE and CANCEL are neither "regular transactions" or "INVITE transactions", they are not covered by the paragraph. But my greater concern is when UAS state is not in "Completed" state (Figure 11) and yet INVITE transaction is over: can UAS send BYE. That is, UAS has returned 200 OK but not yet received ACK, called party hangs up (or otherwise called UAS wishes to terminate): can it send BYE. I believe that it should NOT. That it must wait for ACK and then send BYE (or wait for 7- 200 OKs without receiving ACK), but I cannot see that this is covered by the paragraph. Is it covered somewhere else? -- Waiting for the other shoe to drop while hoping it's a one legged man. ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------69AF2A3EB69AC5D5515C9F65 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------69AF2A3EB69AC5D5515C9F65-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 12:22:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05309 for ; Wed, 18 Jul 2001 12:22:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17025; Wed, 18 Jul 2001 11:49:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16941 for ; Wed, 18 Jul 2001 11:49:42 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25943 for ; Wed, 18 Jul 2001 11:48:46 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18914 for ; Wed, 18 Jul 2001 11:48:46 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18904 for ; Wed, 18 Jul 2001 11:48:45 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FA1.460AB946" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Wed, 18 Jul 2001 09:49:48 -0600 Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Thread-Index: AcEPeImAliiySe29RqC2kp/fZl0lxAAJ+n4w From: "Zmolek, Andrew (Andrew)" To: "Michael Thomas" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C10FA1.460AB946 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been waiting for someone to ask this question. I was planning on writing an I-D on cookies myself until I studied the state draft and decided that although the draft itself gives undue emphasis to proxies, the state header still does what we want.=20 My hope is that we can decide on one and only one mechanism for passing state cookies. If we can accomplish the same thing by a tweak to the state draft, particularly with respect to examples, then let's ride that horse. If there's a fatal flaw with the state header, then let's dump it in favor of a cookie header. But I can't see a good reason to clutter the standard with both. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, July 18, 2001 4:42 AM To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt OK, I'll bite. How does this differ from the state draft? I've scanned it over and it looks to be doing about the same thing. What am I missing? Mike Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : SIP Cookies > Author(s) : D. Willis, B. Rosen > Filename : draft-willis-sip-cookies-00.txt > Pages : 9 > Date : 11-Jul-01 > =09 > This document describes an extension to SIP (RFC 2543) to provide a=20 > mechanism for storing state and other information in SIP comparable=20 > to the HTTP state mechanisms defined in RFC 2109. This extension=20 > includes a new SIP header ('Cookie:'), an option tag for feature=20 > negotiation ('cookie') and IANA registration considerations for=20 > registering the 'cookie' extension, semantics of the value of the=20 > Cookie: header, and behavioral rules for processing these headers by=20 > SIP nodes supporting the 'cookie' extension. This document also=20 > briefly discusses possible uses of cookies, and security=20 > considerations for their use. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt >=20 > 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-willis-sip-cookies-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 >=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-willis-sip-cookies-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <20010711155737.I-D@ietf.org> >=20 > ENCODING mime > FILE /internet-drafts/draft-willis-sip-cookies-00.txt > Content-Type: text/plain > Content-ID: <20010711155737.I-D@ietf.org> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C10FA1.460AB946 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt

I've been waiting for someone to ask this question. I = was planning on writing an I-D on cookies myself until I studied the = state draft and decided that although the draft itself gives undue = emphasis to proxies, the state header still does what we want. =

My hope is that we can decide on one and only one = mechanism for passing state cookies. If we can accomplish the same thing = by a tweak to the state draft, particularly with respect to examples, = then let's ride that horse. If there's a fatal flaw with the state = header, then let's dump it in favor of a cookie header. But I can't see = a good reason to clutter the standard with both.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, July 18, 2001 4:42 AM
To: sip@ietf.org
Subject: [Sip] I-D = ACTION:draft-willis-sip-cookies-00.txt



OK, I'll bite. How does this differ from the = state
draft?  I've scanned it over and it looks to = be
doing about the same thing. What am I missing?

            Mike


Internet-Drafts@ietf.org writes:
 > A New Internet-Draft is available from the = on-line Internet-Drafts directories.
 >
 >
 >      Title   =         : SIP Cookies
 >      = Author(s)       : D. Willis, B. = Rosen
 >      = Filename        : = draft-willis-sip-cookies-00.txt
 >      Pages   =         : 9
 >      = Date            : = 11-Jul-01
 >     
 > This document describes an extension to = SIP (RFC 2543) to provide a
 > mechanism for storing state and other = information in SIP comparable
 > to the HTTP state mechanisms defined in = RFC 2109.  This extension
 > includes a new SIP header ('Cookie:'), an = option tag for feature
 > negotiation ('cookie') and IANA = registration considerations for
 > registering the 'cookie' extension, = semantics of the value of the
 > Cookie: header, and behavioral rules for = processing these headers by
 > SIP nodes supporting the 'cookie' = extension. This document also
 > briefly discusses possible uses of = cookies, and security
 > considerations for their use.
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt
 >
 > 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-willis-sip-cookies-00.txt".
 >
 > A list of Internet-Drafts directories can = be found in
 > http://www.ietf.org/shadow.html<= /A>
 > or ftp://ftp.ietf.org/iet= f/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-willis-sip-cookies-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.
 > Content-Type: text/plain
 > Content-ID:  = <20010711155737.I-D@ietf.org>
 >
 > ENCODING mime
 > FILE = /internet-drafts/draft-willis-sip-cookies-00.txt
 > Content-Type: text/plain
 > Content-ID:  = <20010711155737.I-D@ietf.org>

_______________________________________________
Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C10FA1.460AB946-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 12:51:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11026 for ; Wed, 18 Jul 2001 12:51:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19335; Wed, 18 Jul 2001 12:38:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19308 for ; Wed, 18 Jul 2001 12:38:47 -0400 (EDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08211 for ; Wed, 18 Jul 2001 12:37:51 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA00470; Wed, 18 Jul 2001 16:38:10 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 18 Jul 2001 16:38:08 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3X1M8K7L>; Wed, 18 Jul 2001 09:38:06 -0700 Message-ID: From: "Rahman, Mohib" To: "'Terry L Anderson'" , SIP Mail List Cc: "'jdrosen@dynamicsoft.com'" Subject: RE: [Sip] BIS-03 and UAS BYEs Date: Wed, 18 Jul 2001 09:37:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Terry, Two weeks back similar discussion was continued in sip-implementors mailing list and conclusion was that BYE can be sent by the Called party if it sends seven 200 OKs and receives no ACK. Actually BYE makes sense if the call is established. And in this scenario from the UAS perspective the call is established. But I don't see any explicit reference of this scenario in bis-03. Does anybody see this in bis-03? Regards, mohib -----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Wednesday, July 18, 2001 8:10 AM To: SIP Mail List Subject: [Sip] BIS-03 and UAS BYEs The first paragraph of 15.4 of draft-ietf-sip-rfc2543bis-03 is a big improvement being more explicit about when subsequent requests can be sent but there still seems one ambiguity. Since BYE and CANCEL are neither "regular transactions" or "INVITE transactions", they are not covered by the paragraph. But my greater concern is when UAS state is not in "Completed" state (Figure 11) and yet INVITE transaction is over: can UAS send BYE. That is, UAS has returned 200 OK but not yet received ACK, called party hangs up (or otherwise called UAS wishes to terminate): can it send BYE. I believe that it should NOT. That it must wait for ACK and then send BYE (or wait for 7- 200 OKs without receiving ACK), but I cannot see that this is covered by the paragraph. Is it covered somewhere else? -- Waiting for the other shoe to drop while hoping it's a one legged man. ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 21:29:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24369 for ; Wed, 18 Jul 2001 21:29:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08435; Wed, 18 Jul 2001 21:09:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00276 for ; Tue, 17 Jul 2001 13:57:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: [Sip] Note Well Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 18 21:49:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00461 for ; Wed, 18 Jul 2001 21:49:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08397; Wed, 18 Jul 2001 21:09:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28887 for ; Tue, 17 Jul 2001 13:27:41 -0400 (EDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26319; Tue, 17 Jul 2001 13:26:36 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Transfer-Encoding: 7bit Subject: [Sip] Note Well Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 04:23:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29186 for ; Thu, 19 Jul 2001 04:23:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26887; Thu, 19 Jul 2001 03:57:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26856 for ; Thu, 19 Jul 2001 03:57:31 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26116 for ; Thu, 19 Jul 2001 03:56:36 -0400 (EDT) Received: from hvssa01.nl.lucent.com (h135-85-68-2.lucent.com [135.85.68.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6J7vVJ16129 for ; Thu, 19 Jul 2001 03:57:31 -0400 (EDT) Received: by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA12825; Thu, 19 Jul 2001 09:57:30 +0200 (MET DST) Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Received: from lucent.com by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA12812; Thu, 19 Jul 2001 09:57:26 +0200 (MET DST) Message-ID: <3B569224.9415E3D8@lucent.com> Date: Thu, 19 Jul 2001 09:54:12 +0200 From: Michel de Boer X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Original-CC: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: Re: [Sip] New I-D on compression of SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, You state that one of the ways to achieve message size reduction is to define a binary encoding, but that this introduces interoperability problems. How can a compression scheme based on dynamically constructed codebooks be simpler? In my opinion this approach is more prone to interoperability issues. Codebooks can get out of sync. As codebooks are specific to a sender- receiver pair, an entity communicating with multiple other entities, i.e. a proxy talking to many UA's must manage multiple codebooks. For trouble shooting one might want to monitor a network interface and analyze SIP messages coming in. It's impossible to read a compressed message. Regards, Michel Jonathan Rosenberg wrote: > > Folks, > > I've just submitted a new I-D on compression of SIP messages, particularly > for wireless links. Until the draft appears in the archives, you can pick up > a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 07:27:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02168 for ; Thu, 19 Jul 2001 07:27:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02879; Thu, 19 Jul 2001 07:03:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02849 for ; Thu, 19 Jul 2001 07:03:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27378; Thu, 19 Jul 2001 07:03:00 -0400 (EDT) Message-Id: <200107191103.HAA27378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jul 2001 07:03:00 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-vxml-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A SIP Interface to VoiceXML Dialog Servers Author(s) : J. Rosenberg Filename : draft-rosenberg-sip-vxml-00.txt Pages : 16 Date : 18-Jul-01 VoiceXML is an XML based scripting language for describing voice dialogs. VoiceXML interpreters run within an interpreter context that, among other tasks, provides a call control interface for accessing the interpreter. It is very natural to provide a VoIP-based interpreter context that uses SIP and RTP to communicate with the outside world. In this document, we provide detailed specifications for a SIP/RTP based interpreter context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-vxml-00.txt 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-rosenberg-sip-vxml-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-rosenberg-sip-vxml-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: <20010718141730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-vxml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-vxml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718141730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 07:27:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02219 for ; Thu, 19 Jul 2001 07:27:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03058; Thu, 19 Jul 2001 07:05:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02968 for ; Thu, 19 Jul 2001 07:05:48 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27957; Thu, 19 Jul 2001 07:04:53 -0400 (EDT) Message-Id: <200107191104.HAA27957@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jul 2001 07:04:52 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-reconstitute-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Reconsituting Call State in SIP User Agents Author(s) : J. Rosenberg Filename : draft-rosenberg-sip-reconstitute-00.txt Pages : 13 Date : 18-Jul-01 In a SIP network, call and session state resides in the user agents at the edge of the network. These user agents can be elements such as gateways, conferencing servers, and media servers whose availability is important for service delivery. In order to achieve fault tolerance for these user agents, this state must somehow be replicated to backup servers. Traditionally, replication is done through direct memory copies between a primary and its backup. However, the soft-state nature of SIP re-INVITEs means that an alternate mechanism for call state replication is possible. This document proposes mechanisms for reconstituting call state in a UA through triggered re-INVITEs from a peer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-reconstitute-00.txt 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-rosenberg-sip-reconstitute-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-rosenberg-sip-reconstitute-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: <20010718142048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-reconstitute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-reconstitute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142048.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 07:27:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02231 for ; Thu, 19 Jul 2001 07:27:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03102; Thu, 19 Jul 2001 07:06:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03071 for ; Thu, 19 Jul 2001 07:06:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28037; Thu, 19 Jul 2001 07:05:08 -0400 (EDT) Message-Id: <200107191105.HAA28037@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jul 2001 07:05:08 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-call-package-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Event Packages for Call Leg and Conference State Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-call-package-00.txt Pages : 30 Date : 18-Jul-01 This document defines two new event packages for the SIP Events architecture, along with two new data formats used in notifications for those packages. The first is a call-leg package, and the second is a conference package. The call-leg package allows users to subscribe to another user, an receive notifications about the changes in state of call legs that the user is involved in. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-call-package-00.txt 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-rosenberg-sip-call-package-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-rosenberg-sip-call-package-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: <20010718142114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-call-package-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-call-package-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142114.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 07:29:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02459 for ; Thu, 19 Jul 2001 07:29:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02841; Thu, 19 Jul 2001 07:03:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02809 for ; Thu, 19 Jul 2001 07:03:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27332; Thu, 19 Jul 2001 07:02:50 -0400 (EDT) Message-Id: <200107191102.HAA27332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jul 2001 07:02:49 -0400 Subject: [Sip] I-D ACTION:draft-mahy-sip-cc-models-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Call Control Model for SIP Author(s) : R. Mahy Filename : draft-mahy-sip-cc-models-00.txt Pages : 12 Date : 18-Jul-01 This document defines an abstract call model for describing the media relationships required for call control features in SIP, and discusses other issues related to SIP call control as part of the SIP Call Control Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sip-cc-models-00.txt 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-mahy-sip-cc-models-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-mahy-sip-cc-models-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: <20010718141711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sip-cc-models-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sip-cc-models-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718141711.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 07:34:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03022 for ; Thu, 19 Jul 2001 07:34:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02937; Thu, 19 Jul 2001 07:04:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02908 for ; Thu, 19 Jul 2001 07:04:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27637; Thu, 19 Jul 2001 07:03:52 -0400 (EDT) Message-Id: <200107191103.HAA27637@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jul 2001 07:03:52 -0400 Subject: [Sip] I-D ACTION:draft-koskelainen-sip-group-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Messaging in SIP Author(s) : P. Koskelainen, H. Schulzrinne Filename : draft-koskelainen-sip-group-00.txt Pages : Date : 18-Jul-01 This document introduces various problems and issues relating to the usage of the Session Initiation Protocol (SIP) for group messaging. Several potential extensions are analyzed and proposed. Both one-shot group messaging (paging) and session based group messaging are covered in the document. Group chat between human beings is one application for group messaging, others exists also such as SIP group messaging between robots or game applets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koskelainen-sip-group-00.txt 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-koskelainen-sip-group-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-koskelainen-sip-group-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: <20010718141859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-koskelainen-sip-group-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-koskelainen-sip-group-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718141859.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 09:41:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01535 for ; Thu, 19 Jul 2001 09:41:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06484; Thu, 19 Jul 2001 08:58:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06455 for ; Thu, 19 Jul 2001 08:58:46 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19332 for ; Thu, 19 Jul 2001 08:57:49 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6JCwiN16641 for ; Thu, 19 Jul 2001 14:58:44 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Thu Jul 19 14:58:44 2001 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 14:58:40 +0200 Message-ID: <7BA41B5547CCD411833B0002A52CD4570372827F@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-rosenberg-sip-call-package-00.txt Date: Thu, 19 Jul 2001 14:58:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I must say that I am impressed by the high numbers of drafts Jonathan is churning out of his devious mind. :-) hey Jonathan, do you get paid per published draft? :-) Anyway, great job and this will help us at the London IETF. Cheers Arnoud _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk Innovation Unit Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: donderdag 19 jul 2001 13:05 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-rosenberg-sip-call-package-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Event Packages for Call Leg and Conference State Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-call-package-00.txt Pages : 30 Date : 18-Jul-01 This document defines two new event packages for the SIP Events architecture, along with two new data formats used in notifications for those packages. The first is a call-leg package, and the second is a conference package. The call-leg package allows users to subscribe to another user, an receive notifications about the changes in state of call legs that the user is involved in. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-call-package-00.txt 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-rosenberg-sip-call-package-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-rosenberg-sip-call-package-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. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 10:02:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05786 for ; Thu, 19 Jul 2001 10:02:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07759; Thu, 19 Jul 2001 09:29:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07732 for ; Thu, 19 Jul 2001 09:29:25 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28546 for ; Thu, 19 Jul 2001 09:28:28 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JDQLO05152; Thu, 19 Jul 2001 08:26:21 -0500 Message-ID: <031b01c11056$1954bc20$56fa403f@directlink.net> From: "Dean Willis" To: "Jo Hornsby" , References: <005901c10ddd$5e191480$4e34c3c1@ubiquity.co.uk> Subject: Re: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Thu, 19 Jul 2001 08:24:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cookies persist across redirection because the logical association of a "call" (from a human rather than SIP point of view) persists across redirection. A participatory server understands the content of the cookie and may change it. For example, if one were to implement a call history function (like cc-redirect) using cookies, a redirect sever could either insert a new history cookie or update the existing history cookie to explains that a redirection has occurred, possibly with a reason why that redirection occurred. Or it might be configured for maximum privacy, and therefore rip out any cookies that might compromise privacy. Non-participatory servers don't understand the content of a cookie, therefore they do not know enough to make a decision on a cookie. They just blindly propagate the cookies that are there. For example, let's say a call is redirected twice -- once by a redirector that understands the history cookie as described above, and once by a redirector that doesn't. The first redirectory introduces a history cookie. We want that cookie to survive the second redirection. In a nutshell, this level of persistency is one thing that differentiates a "cookie" from a "state header", others being a slightly more expressive syntac and IANA maechanisms for definining "standard" cookies. One might ask why a nonparticipatory redirector returns cookies when UASes are required to store cookies and resubmit them. It's because of a case that I'm not sure is handled clearly in the current draft. How does a participatory server indicate that a particular cookie should be deleted? Remember that the UAS doesn't know whether a particular server is participatory or not on a given cookie. So one approach would be a for a UAS to discard cookies for a particular call when those cookies aren't present in a 302 response to that call. I'm not entirely happy with this approach, and the floor is open for suggestions. -- Dean ----- Original Message ----- From: "Jo Hornsby" To: Sent: Monday, July 16, 2001 4:54 AM Subject: RE: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt > Quick Question. > > Why are "non-participatory" Redirect Servers required to > copy the Cookie header into responses? Am I being really > dull here? > > Thanks, > > > - Jo. > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:01:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23747 for ; Thu, 19 Jul 2001 20:01:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17423; Thu, 19 Jul 2001 13:59:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17398 for ; Thu, 19 Jul 2001 13:59:18 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25592 for ; Thu, 19 Jul 2001 13:58:21 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:02:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23842 for ; Thu, 19 Jul 2001 20:02:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20270; Thu, 19 Jul 2001 15:28:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20243 for ; Thu, 19 Jul 2001 15:28:19 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22782 for ; Thu, 19 Jul 2001 15:27:22 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JJSJi29621 for ; Thu, 19 Jul 2001 14:28:19 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 14:28:09 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 14:28:09 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Thu, 19 Jul 2001 14:28:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] New I-D on compression of SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQhVmSjJJLAnx4EdWBSQBQi2X+DwAAeRiw To: , , Cc: , , X-OriginalArrivalTime: 19 Jul 2001 19:28:09.0408 (UTC) FILETIME=[F15CEC00:01C11088] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA20244 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > The draft talks about the encoder that learns "in some way" that the > message was received at the other end. Magic I can think of > here would either look very much like an (implicit) acknowledgement > mechanism, where the decoder and encoder on one side of the link communicate > to confirm message reception. Alternatively, message confirmation might > depend on direct signalling from the application layer to the > compression layer. However, since the SIP layer is not aware of the encoder, I > don't think that's a valid approach. I'd be interested to how this is > perceived to work. Or explicit acknowledgement, which can be either stand-lone or piggybacked on the compressed message from the other direction. This makes the compression layer independent of the upper layer (e.g. SIP in this case). Of course, if there is some interface between SIP and compression layer, we should not exclude the use of such interface. > By the way, I am not so much concerned with the pathological > case you've given above. If lower layers are dropping *all* > requests, a non-updated codebook is probably not my main worry. > But I'd agree that in the case of deteriorating network behavior, > e.g. ramping up towards an overload situation, non-updated > codebooks are going to worsen the problem. This problem can be alleviated by the static and user-specific dictionary or codebook (see http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-00.txt, a newer version has been submitted to ROHC WG and should appear soon). That also allows good compression efficiency for the first few messages in a session. Br, Zhigang > Romeo > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:06:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24808 for ; Thu, 19 Jul 2001 20:06:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20177; Thu, 19 Jul 2001 15:25:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20148 for ; Thu, 19 Jul 2001 15:25:11 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21717 for ; Thu, 19 Jul 2001 15:24:15 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.191]) by watermelon.icoe.att.com (Postfix) with ESMTP id 311FA41A12; Thu, 19 Jul 2001 21:24:40 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010719211221.06d60e58@watermelon.icoe.att.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jul 2001 21:27:18 +0200 To: jdrosen@dynamicsoft.com From: Romeo Zwart Subject: Re: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Cc: sip@ietf.org, rohc@cdt.luth.se In-Reply-To: <200107181058.GAA25180@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, In the diagram of section 4.6, the WRITE HIGH REFERENCE token is shown as identical to the WRITE HIGH token. I assume this is a typo. What is the intended token for the WRITE HIGH REFERENCE case? In the same diagram, is there a defined value for the three 'padding' bits that fill up the third octet? In section 5 you describe your proposed new LZW variant. Your 'friendly test' shows very nice results, except for the initial message in the series, which has an (expected) larger compressed size than the uncompressed size. Have you considered jumpstarting the codebook with a set of default entries (e.g. INVITE, From:, To:, etc.)? Would you expect earlier convergence? Romeo At 12:58 PM 7/18/2001, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Compression of SIP > Author(s) : J. Rosenberg > Filename : draft-rosenberg-rohc-sip-udpcomp-00.txt > Pages : 12 > Date : 17-Jul-01 > >The Session Initiation Protocol (SIP), along with many other IP >protocols used for multimedia communications, are UDP-based, textual >protocols engineered for bandwidth rich links. As a result, these >messages have not been optimized for message size. With the planned >usage of these protocols in wireless handsets as part of 2.5G and 3G >wireless, the large size of these messages is problematic, primarily >for latency reasons. As a result, we propose a protocol shim between >SIP (or any other UDP based protocol meeting our requirements) and >UDP in order to efficiently compress SIP messages. Preliminary >results have shown compression gains of up to 8:1. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-rosenberg-rohc-sip-udpcomp-00.txt > >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-rosenberg-rohc-sip-udpcomp-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-rosenberg-rohc-sip-udpcomp-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. >Content-Type: text/plain >Content-ID: <20010717133103.I-D@ietf.org> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:08:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25560 for ; Thu, 19 Jul 2001 20:08:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17788; Thu, 19 Jul 2001 14:02:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17759 for ; Thu, 19 Jul 2001 14:02:00 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26444 for ; Thu, 19 Jul 2001 14:01:01 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GGQ00IDMFE5E6@firewall.mcit.com> for sip@ietf.org; Thu, 19 Jul 2001 18:01:18 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GGQ00501FD5QO@dgismtp04.wcomnet.com> for sip@ietf.org; Thu, 19 Jul 2001 18:01:17 +0000 (GMT) Received: from wcom.com ([166.35.224.216]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GGQ00LMTFCVAU@dgismtp04.wcomnet.com> for sip@ietf.org; Thu, 19 Jul 2001 18:00:31 +0000 (GMT) Date: Thu, 19 Jul 2001 13:00:29 -0500 From: Steven Lass Subject: Re: [Sip] I-D ACTION:draft-lass-sip-remote-call-setup-00.txt To: sip@ietf.org Message-id: <3B57203D.D27EA4F6@wcom.com> Organization: WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en,pdf Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thought some list members may be interested. [also some shameless self-promotion] -steve -------- Original Message -------- Subject: Re: Fwd: [Sip] I-D ACTION:draft-lass-sip-remote-call-setup-00.txt Date: Thu, 19 Jul 2001 11:07:26 -0500 From: Steven Lass Organization: WorldCom To: Jay Batson References: <5.1.0.14.2.20010719112540.03e1b580@mail.pingtel.com> Jay, Basically, Mahy's draft has a lot more complexity (and power) than mine. He wants full call-control by a 3rd party, perhaps he has some sort of controller-service in mind. I want "click-to-dial" that is so simple, everybody writing addressbook software will incorporate it into their products. I also want to get a point-to-point signature scheme in place. Everybody does point-to-point to authentication, but nobody that I know of is using the holy grail (pki). The HMAC (point-to-point signature) stuff in my draft is new, but the "click-to-dial" is implementation/informational and does not require any protocol changes. I have no problem with PGP or SMIME for signing, I just haven't seen it widely deployed. [....] Steven Lass WorldCom (972)729-4469 Jay Batson wrote: > > I'm sure I could do a side-by-side compare, but lacking > the time (...), can you summarize how your draft differs > from draft-mahy-sip-peer-3pcc-00.txt? > > For the record, I'm a fan of the latter, and from a brief > read, a fan of your draft, too. I think my opinion of > B2BUAs is well known by now.... ;-) > > -jb > > > To: IETF-Announce: ; > > CC: sip@ietf.org > > From: Internet-Drafts@ietf.org > > Reply-to: Internet-Drafts@ietf.org > > Date: Wed, 18 Jul 2001 07:00:22 -0400 > > Subject: [Sip] I-D > > ACTION:draft-lass-sip-remote-call-setup-00.txt > > Sender: sip-admin@ietf.org > > X-Mailman-Version: 1.0 > > List-Id: Session Initiation Protocol > > X-BeenThere: sip@ietf.org > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Remote Call Setup > > Author(s) : S. Lass > > Filename : > > draft-lass-sip-remote-call-setup-00.txt > > Pages : 5 > > Date : 17-Jul-01 > > > > This document describes a method for 3rd Party call > > setup using the > > SIP REFER [2] message. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet- > > rafts/draft-lass-sip-remote-call-setup-00.txt > > > > 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-lass-sip-remote-call-setup-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-lass-sip-remote-call-setup-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. > > Content-Type: text/plain > > Content-ID: <20010717133416.I-D@ietf.org> > > > > ENCODING mime > > FILE > > /internet-drafts/draft-lass-sip-remote-call-setup-00.txt > > > > > > ------------- > PingMe! > Jay Batson > CEO > Pingtel Corp. > mailto:jbatson@pingtel.com > 781-938-5306 (office) _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:08:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25651 for ; Thu, 19 Jul 2001 20:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19369; Thu, 19 Jul 2001 14:59:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19340 for ; Thu, 19 Jul 2001 14:59:15 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13870 for ; Thu, 19 Jul 2001 14:58:18 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:08:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25650 for ; Thu, 19 Jul 2001 20:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19725; Thu, 19 Jul 2001 15:01:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19694 for ; Thu, 19 Jul 2001 15:01:10 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14452 for ; Thu, 19 Jul 2001 15:00:14 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.191]) by watermelon.icoe.att.com (Postfix) with ESMTP id 0380941A12; Thu, 19 Jul 2001 21:00:37 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010719182517.02d9e200@watermelon.icoe.att.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jul 2001 21:03:14 +0200 To: James Undery , "Lars-Erik Jonsson (EPL)" From: Romeo Zwart Subject: Re: [Sip] RE: [rohc] New I-D on compression of SIP Cc: "'Jonathan Rosenberg'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" In-Reply-To: <3B543B63.DC2B657C@ubiquity.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 03:19 PM 7/17/2001, James Undery wrote: >"Lars-Erik Jonsson (EPL)" wrote: > > First of all I have to say that I think it is good that we now have > several contributors to this discussion about signaling compression, e.g. > SIP compression. I have read your draft and have a number of comments but > before I take them all I would like to ask you for some clarifications > about how you mean this new "protocol shim" is introduced in reality. You > say that it becomes a new alternate transport but it is not clear how > this is indicated. Is your intention to create a new "UDP-compress" > transport protocol (new protocol ID)? > >I think by this Jonathan means to have a new transport parameter for SIP >URLs and position the encoding/decoding just above the UDP "stack" code >and below the SIP "stack" code. My major concern is the lack of a message >acknowledgement mechanism, I know why this was done, however, in the >pathelogical case in SIP where all the Request transmissions are lost, the >decoder will never update it's codebook from then on adding to the >overheads not helping. I agree with your concern about the absense of message acknowledgement. I am pleased that you do understand why this is the case, as I don't :-). Is it the intention to save on coding complexity or do we want to save a few bits over the wire? In the latter case, I think the intent is good, but aren't the achieved savings quite modest? In the former case, I don't think there are any savings at all, possibly complexity is worsened depending on what mechanism is chosen for the encoder to track message reception. The draft talks about the encoder that learns "in some way" that the message was received at the other end. Magic I can think of here would either look very much like an (implicit) acknowledgement mechanism, where the decoder and encoder on one side of the link communicate to confirm message reception. Alternatively, message confirmation might depend on direct signalling from the application layer to the compression layer. However, since the SIP layer is not aware of the encoder, I don't think that's a valid approach. I'd be interested to how this is perceived to work. By the way, I am not so much concerned with the pathological case you've given above. If lower layers are dropping *all* requests, a non-updated codebook is probably not my main worry. But I'd agree that in the case of deteriorating network behavior, e.g. ramping up towards an overload situation, non-updated codebooks are going to worsen the problem. Romeo _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:15:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28428 for ; Thu, 19 Jul 2001 20:15:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21270; Thu, 19 Jul 2001 15:59:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21181 for ; Thu, 19 Jul 2001 15:59:17 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02620 for ; Thu, 19 Jul 2001 15:58:19 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:17:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29174 for ; Thu, 19 Jul 2001 20:17:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26399; Thu, 19 Jul 2001 19:27:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26368 for ; Thu, 19 Jul 2001 19:27:51 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13446 for ; Thu, 19 Jul 2001 19:26:56 -0400 (EDT) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6JNRoZ05478 for ; Thu, 19 Jul 2001 19:27:51 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jul 2001 19:27:50 -0400 Message-ID: From: "Ghai, Rajat (Rajat)" To: SIP Mail List Subject: RE: [Sip] BIS-03 and UAS BYEs Date: Thu, 19 Jul 2001 19:27:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In my view, sending a BYE right away without waiting for an ACK should be OK. The reason being that, if the user has hung up, why keep that UAS blocked for 'x' amount of time while it could be initiating or terminating new calls. (makes a lot of sense for Gateways which are acting as B2B UAs and tying up precious RTP Codecs). The orphaned "ACK" which the UAS might receive later can be dropped as it does not belong to an active call and does not require a response anyway. Similarly, a UAC should be able to accept a BYE to tear down a session any time after receiving a 200 OK. It still sends an ACK (if it hasn't sent already) though followed by a response for the BYE. I do not think PROXYs get affected by this. thanks Rajat Ghai -----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Wednesday, July 18, 2001 11:10 AM To: SIP Mail List Subject: [Sip] BIS-03 and UAS BYEs The first paragraph of 15.4 of draft-ietf-sip-rfc2543bis-03 is a big improvement being more explicit about when subsequent requests can be sent but there still seems one ambiguity. Since BYE and CANCEL are neither "regular transactions" or "INVITE transactions", they are not covered by the paragraph. But my greater concern is when UAS state is not in "Completed" state (Figure 11) and yet INVITE transaction is over: can UAS send BYE. That is, UAS has returned 200 OK but not yet received ACK, called party hangs up (or otherwise called UAS wishes to terminate): can it send BYE. I believe that it should NOT. That it must wait for ACK and then send BYE (or wait for 7- 200 OKs without receiving ACK), but I cannot see that this is covered by the paragraph. Is it covered somewhere else? -- Waiting for the other shoe to drop while hoping it's a one legged man. ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:17:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29315 for ; Thu, 19 Jul 2001 20:17:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24455; Thu, 19 Jul 2001 17:59:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24425 for ; Thu, 19 Jul 2001 17:59:13 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24957 for ; Thu, 19 Jul 2001 17:58:16 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:24:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01966 for ; Thu, 19 Jul 2001 20:24:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25617; Thu, 19 Jul 2001 18:43:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25563 for ; Thu, 19 Jul 2001 18:42:56 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04962 for ; Thu, 19 Jul 2001 18:42:00 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JMdpO07125; Thu, 19 Jul 2001 17:39:51 -0500 Message-ID: <00ac01c110a3$d696b840$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "Michael Thomas" , References: <200107121106.HAA01610@ietf.org> <15189.26595.349664.456815@thomasm-u1.cisco.com> Subject: Re: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Thu, 19 Jul 2001 17:40:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Differences: 1) Much more like HTTP cookies, including most of the syntax. I believe an HTTP cookie parser could accept the syntax described in the SIP cookie draft. State headers are quite different. 2) More persistence of the cookie information -- for example, applied to new calls resulting from redirect or transfer of old one. 3) No IPR restrictions, unlike State (see Ch. 9 of state draft). 4) Clear syntax to identify the source of the cookie. 5) No Supported-header specified. This may or may not be a bonus. 6) The Cookie is not correlated with to/from/callID tags in quite the same way. 7) Obvious extensibility to define "standard" cookies. -- Dean ----- Original Message ----- From: "Michael Thomas" To: Sent: Wednesday, July 18, 2001 5:41 AM Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt > > OK, I'll bite. How does this differ from the state > draft? I've scanned it over and it looks to be > doing about the same thing. What am I missing? > > Mike > > > Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : SIP Cookies > > Author(s) : D. Willis, B. Rosen > > Filename : draft-willis-sip-cookies-00.txt > > Pages : 9 > > Date : 11-Jul-01 > > > > This document describes an extension to SIP (RFC 2543) to provide a > > mechanism for storing state and other information in SIP comparable > > to the HTTP state mechanisms defined in RFC 2109. This extension > > includes a new SIP header ('Cookie:'), an option tag for feature > > negotiation ('cookie') and IANA registration considerations for > > registering the 'cookie' extension, semantics of the value of the > > Cookie: header, and behavioral rules for processing these headers by > > SIP nodes supporting the 'cookie' extension. This document also > > briefly discusses possible uses of cookies, and security > > considerations for their use. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt > > > > 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-willis-sip-cookies-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-willis-sip-cookies-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. > > Content-Type: text/plain > > Content-ID: <20010711155737.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-willis-sip-cookies-00.txt > > Content-Type: text/plain > > Content-ID: <20010711155737.I-D@ietf.org> > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:25:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02497 for ; Thu, 19 Jul 2001 20:25:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22889; Thu, 19 Jul 2001 16:59:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22857 for ; Thu, 19 Jul 2001 16:59:15 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12574 for ; Thu, 19 Jul 2001 16:58:17 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:43:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25652 for ; Thu, 19 Jul 2001 20:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16994; Thu, 19 Jul 2001 13:39:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16965 for ; Thu, 19 Jul 2001 13:39:49 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19949 for ; Thu, 19 Jul 2001 13:38:52 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 20:59:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15803 for ; Thu, 19 Jul 2001 20:59:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25626; Thu, 19 Jul 2001 18:43:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25568 for ; Thu, 19 Jul 2001 18:42:57 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04964 for ; Thu, 19 Jul 2001 18:42:00 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JMdsO07130; Thu, 19 Jul 2001 17:39:55 -0500 Message-ID: <00ad01c110a3$d8851ac0$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "Michael Thomas" , References: <200107121106.HAA01610@ietf.org> <15189.26595.349664.456815@thomasm-u1.cisco.com> Subject: Re: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Thu, 19 Jul 2001 17:40:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Differences: 1) Much more like HTTP cookies, including most of the syntax. I believe an HTTP cookie parser could accept the syntax described in the SIP cookie draft. State headers are quite different. 2) More persistence of the cookie information -- for example, applied to new calls resulting from redirect or transfer of old one. 3) No IPR restrictions, unlike State (see Ch. 9 of state draft). 4) Clear syntax to identify the source of the cookie. 5) No Supported-header specified. This may or may not be a bonus. 6) The Cookie is not correlated with to/from/callID tags in quite the same way. 7) Obvious extensibility to define "standard" cookies. -- Dean ----- Original Message ----- From: "Michael Thomas" To: Sent: Wednesday, July 18, 2001 5:41 AM Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt > > OK, I'll bite. How does this differ from the state > draft? I've scanned it over and it looks to be > doing about the same thing. What am I missing? > > Mike > > > Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : SIP Cookies > > Author(s) : D. Willis, B. Rosen > > Filename : draft-willis-sip-cookies-00.txt > > Pages : 9 > > Date : 11-Jul-01 > > > > This document describes an extension to SIP (RFC 2543) to provide a > > mechanism for storing state and other information in SIP comparable > > to the HTTP state mechanisms defined in RFC 2109. This extension > > includes a new SIP header ('Cookie:'), an option tag for feature > > negotiation ('cookie') and IANA registration considerations for > > registering the 'cookie' extension, semantics of the value of the > > Cookie: header, and behavioral rules for processing these headers by > > SIP nodes supporting the 'cookie' extension. This document also > > briefly discusses possible uses of cookies, and security > > considerations for their use. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt > > > > 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-willis-sip-cookies-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-willis-sip-cookies-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. > > Content-Type: text/plain > > Content-ID: <20010711155737.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-willis-sip-cookies-00.txt > > Content-Type: text/plain > > Content-ID: <20010711155737.I-D@ietf.org> > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 21:00:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16256 for ; Thu, 19 Jul 2001 21:00:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27140; Thu, 19 Jul 2001 19:59:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27109 for ; Thu, 19 Jul 2001 19:59:12 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22510 for ; Thu, 19 Jul 2001 19:58:16 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 21:16:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20975 for ; Thu, 19 Jul 2001 21:16:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29328; Thu, 19 Jul 2001 20:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29244 for ; Thu, 19 Jul 2001 20:59:11 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15160 for ; Thu, 19 Jul 2001 20:58:15 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 22:32:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18277 for ; Thu, 19 Jul 2001 22:32:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00833; Thu, 19 Jul 2001 21:59:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00802 for ; Thu, 19 Jul 2001 21:59:11 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05816 for ; Thu, 19 Jul 2001 21:58:15 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 19 23:25:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08120 for ; Thu, 19 Jul 2001 23:25:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02309; Thu, 19 Jul 2001 22:59:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02278 for ; Thu, 19 Jul 2001 22:59:11 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28151 for ; Thu, 19 Jul 2001 22:58:14 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 00:15:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22676 for ; Fri, 20 Jul 2001 00:15:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03420; Thu, 19 Jul 2001 23:58:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03389 for ; Thu, 19 Jul 2001 23:58:02 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17576 for ; Thu, 19 Jul 2001 23:57:04 -0400 (EDT) Received: from softarmor.com (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with ESMTP id f6K3t3O07770 for ; Thu, 19 Jul 2001 22:55:03 -0500 Message-ID: <3B57AB97.9000204@softarmor.com> Date: Thu, 19 Jul 2001 22:55:03 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5 i686; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, my turn to be obtuse. What's the difference between the goal of this draft and draft-ietf-sip-serverfeatures-04.txt? -- Dean -------- Original Message -------- Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt Date: Mon, 16 Jul 2001 07:01:31 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Proxy-Supported header field Author(s) : B. Hoeneisen et al. Filename : draft-hoeneisen-sip-proxy-supported-00.txt Pages : 11 Date : 13-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a User Agent Client (UAC) to request that a particular protocol extension has to be used to process the request. The User Agent Server (UAS) declines the request if it does not support the extension. Recently also means have been defined for the User Agent Server (UAS) to determine which extensions are supported by the User Agent Client (UAC). Furthermore there are also means for requiring proxy servers to understand certain features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt 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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-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: <20010713124407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hoeneisen-sip-proxy-supported-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hoeneisen-sip-proxy-supported-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124407.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 00:31:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27359 for ; Fri, 20 Jul 2001 00:31:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03475; Thu, 19 Jul 2001 23:59:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA03445 for ; Thu, 19 Jul 2001 23:59:11 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17859 for ; Thu, 19 Jul 2001 23:58:13 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 01:27:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16664 for ; Fri, 20 Jul 2001 01:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04892; Fri, 20 Jul 2001 00:59:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04863 for ; Fri, 20 Jul 2001 00:59:09 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06039 for ; Fri, 20 Jul 2001 00:58:15 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6JHahO06051 for ; Thu, 19 Jul 2001 12:36:43 -0500 Message-ID: <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> Date: Thu, 19 Jul 2001 12:37:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, I've had it with one little blurb in rfc2543bis03. The line that gets quoted "a B2BUA appears as a proxy". What's it really say? from the draft: Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity that receives an invitation, and acts as a UAS to process it. In order to determine how the request should be answered, it acts as a UAC and initiates a call outwards. A B2BUA appears like a proxy, but differs in that it maintains complete call state and must remain in a call. Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior. THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a proxy, but it is NOT a proxy and not constrained by the rules of aproxy. A B2BUA is application logic which associates one or more calls. Note that "one or more" is not "exactly two" -- I actually heard someone say recently that a B2BUA could only deal with two calls at a time, because there are only two "B"s in the acronym. One must be careful when using acronyms these days. So, what does this application logic do? That's up to the application! See the line in the def that says "Since it is nothing more than a concatenation of other logical functions, no explicit definitions are needed for its behavior." The logical functions are not defined by the SIP speciication, no more than the specification of every program one could write in C++ is defined in the C++ standard. One could make a B2BUA that acts like a proxy. Bill Marshall has argued that a proxy is just a special case of a the more general B2BUA. One could also use a B2BUA as a firewall controller, a signaling anonymizer, or many other things. So why do we have proxies and not just use B2BUAs for everything? Becasuse the limitations on B2BUA that make it a "proxy" are there for a reason -- they provide for network and feature transparency. In other words, proxies provide a way to make it relatively easy to add functionality at the edge of the network and have a reasonable expectation that the new functionality will actually work. Any B2BUA that does not conform to the rules of proxy behavior needs to do so very carefully, and is extremely likely to break some sort of functionality that wasn't considered in the design of that B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, with DISRETION, and only when ABSOLUTELY NECESSARY. -- Dean ----- Original Message ----- From: To: ; "Henning Schulzrinne" Cc: "Paul Kyzivat" ; "Jay Batson" ; Sent: Friday, July 13, 2001 8:56 AM Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > > > Maybe I'm missing something, but I have the feeling that you > > are always putting together the session control and the > > bearer control , which is very likely the case of real user > > agents, that is end-users, but definitely not the case of > > servers in the > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > The splitting of the session layer and the bearer layer is > > the current trend of Next Generation Networks in the Telecom > > world, including obviously the UMTS environment. > > > > So, when I was talking about a B2BUA providing services > > (which is still appearing as a proxy) I was not talking about > > bearer manipulation, codec insertion, etc. Instead, I was > > talking about services provided on top of the session layer, > > as e.g. conference, > > meet-me, follow-me services, etc. > > Forgive my agreeing with you, but maybe you *are* missing something. > > I'd be very interested in the scenarios under which you beleive > a B2BUA can provide any value add in the conference and meet-me > scenarios without any corresponding node in the media path. > > I'm also very interested in knowing how acting as a B2BUA instead > of a proxy when providing a find-me/follow-me service helps in > any way. Given that using a B2BUA destroys feature transparency, > the unnecssary insertion in this case seems very short sighted. > > /a > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 02:03:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05249 for ; Fri, 20 Jul 2001 02:03:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14211; Fri, 20 Jul 2001 01:28:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14182 for ; Fri, 20 Jul 2001 01:28:39 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16798 for ; Fri, 20 Jul 2001 01:27:46 -0400 (EDT) Received: from blazer (dwillis4.directlink.net [63.64.250.85]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6K5PkO08119; Fri, 20 Jul 2001 00:25:46 -0500 Message-ID: <004101c110dc$caf3a820$55fa403f@blazer> From: "Dean Willis" To: "Dean Willis" , References: <61D824C63B99D311975E00508B0CC9850225194A@eamrcnt717.exu.ericsson.se> <006a01c11079$87570980$ee036e3f@dfw.dynamicsoft.com> Subject: Whoops! Re: [Sip] A B2BUA IS NOT . . . Date: Fri, 20 Jul 2001 00:28:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Looks there have been a bunch of repeats here. I'm sorry. It looks like some sort of odd problem between kevlar.softarmor.com and odin.ietf.org . . . odin kept giving an error response and kevlar kept retrying. Hmm. Any experts out there? -- Dean ----- Original Message ----- From: "Dean Willis" To: Sent: Thursday, July 19, 2001 12:37 PM Subject: [Sip] A B2BUA IS NOT A PROXY (was Re: More B2BUA ranting) > Ok, I've had it with one little blurb in rfc2543bis03. > > The line that gets quoted "a B2BUA appears as a proxy". > > What's it really say? > > from the draft: > Back-To-Back User Agent: Also known as a B2BUA, this is a logical entity > that receives an invitation, > and acts as a UAS to process it. In order to determine how the request > should be answered, it acts as > a UAC and initiates a call outwards. A B2BUA appears like a proxy, but > differs in that it maintains > complete call state and must remain in a call. Since it is nothing more than > a concatenation of other > logical functions, no explicit definitions are needed for its behavior. > > THIS DOES NOT MEAN A B2BUA IS A PROXY. IT MEANS IT LOOKS LIKE A PROXY ON A > NETWORK SCHEMATIC DRAWING. Calls come in. Calls go out. Looks kind of like a > proxy, but it is NOT a proxy and not constrained by the rules of aproxy. > > A B2BUA is application logic which associates one or more calls. Note that > "one or more" is not "exactly two" -- I actually heard someone say recently > that a B2BUA could only deal with two calls at a time, because there are > only two "B"s in the acronym. One must be careful when using acronyms these > days. > > So, what does this application logic do? That's up to the application! See > the line in the def that says "Since it is nothing more than a concatenation > of other > logical functions, no explicit definitions are needed for its behavior." The > logical functions are not defined by the SIP speciication, no more than the > specification of every program one could write in C++ is defined in the C++ > standard. One could make a B2BUA that acts like a proxy. Bill Marshall has > argued that a proxy is just a special case of a the more general B2BUA. One > could also use a B2BUA as a firewall controller, a signaling anonymizer, or > many other things. > > So why do we have proxies and not just use B2BUAs for everything? Becasuse > the limitations on B2BUA that make it a "proxy" are there for a reason -- > they provide for network and feature transparency. In other words, proxies > provide a way to make it relatively easy to add functionality at the edge of > the network and have a reasonable expectation that the new functionality > will actually work. Any B2BUA that does not conform to the rules of proxy > behavior needs to do so very carefully, and is extremely likely to break > some sort of functionality that wasn't considered in the design of that > B2BUA. This is DANGEROUS, and non-proxy B2BUAs must be used VERY CAREFULLY, > with DISRETION, and only when ABSOLUTELY NECESSARY. > > -- > Dean > > ----- Original Message ----- > From: > To: ; "Henning Schulzrinne" > > Cc: "Paul Kyzivat" ; "Jay Batson" ; > > Sent: Friday, July 13, 2001 8:56 AM > Subject: More B2BUA ranting (was RE: [Sip] Forking: a modest proposal.) > > > > > -----Original Message----- > > > From: Juan-Carlos.Rojas@alcatel.fr > > > > > > Maybe I'm missing something, but I have the feeling that you > > > are always putting together the session control and the > > > bearer control , which is very likely the case of real user > > > agents, that is end-users, but definitely not the case of > > > servers in the > > > network, and a B2BUA is defined as appearing as a proxy (RFC2543). > > > The splitting of the session layer and the bearer layer is > > > the current trend of Next Generation Networks in the Telecom > > > world, including obviously the UMTS environment. > > > > > > So, when I was talking about a B2BUA providing services > > > (which is still appearing as a proxy) I was not talking about > > > bearer manipulation, codec insertion, etc. Instead, I was > > > talking about services provided on top of the session layer, > > > as e.g. conference, > > > meet-me, follow-me services, etc. > > > > Forgive my agreeing with you, but maybe you *are* missing something. > > > > I'd be very interested in the scenarios under which you beleive > > a B2BUA can provide any value add in the conference and meet-me > > scenarios without any corresponding node in the media path. > > > > I'm also very interested in knowing how acting as a B2BUA instead > > of a proxy when providing a find-me/follow-me service helps in > > any way. Given that using a B2BUA destroys feature transparency, > > the unnecssary insertion in this case seems very short sighted. > > > > /a > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 06:50:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24217 for ; Fri, 20 Jul 2001 06:50:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22889; Fri, 20 Jul 2001 06:07:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22800 for ; Fri, 20 Jul 2001 06:07:27 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15439 for ; Fri, 20 Jul 2001 06:06:29 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 20 Jul 2001 10:07:26 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 11:07:39 +0100 From: "Jo Hornsby" To: Date: Fri, 20 Jul 2001 11:07:25 +0100 Message-ID: <00c901c11103$c66e3550$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-OriginalArrivalTime: 20 Jul 2001 10:07:39.0639 (UTC) FILETIME=[CEDF2870:01C11103] Content-Transfer-Encoding: 7bit Subject: [Sip] Equivalence of "public addresses" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit People, I'd be interested to know if anybody had any experiences / thoughts on this. Currently, I interpret bis-03 as requiring Registrars (and thus I guess Location Services that use the DB that a Registrar mutates) to treat a public address of fred.bloggs@example.com as different to fred.bloggs@example.com;transport=tcp This doesn't seem entirely useful. However, I could perhaps be more sympathetic if someone wanted frances.bloggs@example.com;magic=x to be different to frances.bloggs@example.com;magic=y Although the fact that neither of these are technically different to frances.bloggs@example.com does seem to suggest that this is a bogus approach. (Note: I am finding it difficult to come up with a reasonable parameter name, which is why I chose "magic") The classic, I think, is: 0123456789@sip-gateway.example.com being different to 0123456789@sip-gateway.example.com;user=phone . I have to admit that I do (and I expect people to start shouting at me here) find catering for such terminal mobility slightly anachronstic, since surely this is only solving a transitional concern? Not to mention the fact that have had experience of parties expecting these two to be equivalent (i.e., REGISTER as one, INVITE to the other). So the crux is that should we only be considering the user part and host part in these matters? Personally, I fluctuate on a day to day basis, so I'd be interested if anybody could ease my nausea. Thank you, - Jo. -- Jo Hornsby; IT Professional -- mailto:jhornsby@ubiquity.net Ubiquity Software Corporation -- http://www.ubiquity.net/ _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 06:58:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26010 for ; Fri, 20 Jul 2001 06:58:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23686; Fri, 20 Jul 2001 06:32:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23656 for ; Fri, 20 Jul 2001 06:32:33 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19894 for ; Fri, 20 Jul 2001 06:31:36 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 20 Jul 2001 10:32:30 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 11:29:43 +0100 From: "Jo Hornsby" To: Subject: RE: [Sip] Equivalence of "public addresses" Date: Fri, 20 Jul 2001 11:29:29 +0100 Message-ID: <00ca01c11106$dbc855e0$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <00c901c11103$c66e3550$4e34c3c1@ubiquity.co.uk> X-OriginalArrivalTime: 20 Jul 2001 10:29:43.0962 (UTC) FILETIME=[E43ACFA0:01C11106] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit [...] > Currently, I interpret bis-03 as requiring Registrars > (and thus I guess Location Services that use the DB that > a Registrar mutates) to treat a public address of > fred.bloggs@example.com > as different to > fred.bloggs@example.com;transport=tcp Whoops, I should have said: fred.bloggs@example.com as different to fred.bloggs@example.com:6000 as transport is not legal in the SIP URL of a To header. Yours slightly red-faced, - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 07:09:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27814 for ; Fri, 20 Jul 2001 07:09:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23962; Fri, 20 Jul 2001 06:48:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23933 for ; Fri, 20 Jul 2001 06:48:48 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23474 for ; Fri, 20 Jul 2001 06:47:51 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f6K9IRu12768; Fri, 20 Jul 2001 14:48:28 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f6K9Q6o16726; Fri, 20 Jul 2001 14:56:12 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256A8F.00329E6A ; Fri, 20 Jul 2001 14:42:53 +0530 X-Lotus-FromDomain: HSSBLR To: sip-implementors@cs.columbia.edu, sip@ietf.org cc: billy@div8.net, Rick_Dean@sip.3com.com Message-ID: <65256A8F.00329DC1.00@sampark.hss.hns.com> Date: Fri, 20 Jul 2001 14:42:51 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] HANDOFF for call transfer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello all, I had a question regarding the draft-dean-handoff-00.txt The draft is due to expire this month. Last discussion I could trace on the topic was in Feb ... the thread with subject "draft-ietf-sip-handoff-00pre8.txt" : http://lists.bell-labs.com/pipermail/sip/2001q1/005711.html Is there some work still continuing on this draft? Or has it been abandoned in favour of the REFER approach to transfer? If not, when can a new version of the draft be expected? The approach does seem to be simpler in some respects, but are there any downsides for which there's not much talk on this draft at present? Pointers to relevant information would be much appreciated! :) Thanks in advance, Siddharth. ================================= Siddharth Toshniwal Software Engineer Hughes Software Systems, Bangalore http://www.hssworld.com. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 08:08:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12576 for ; Fri, 20 Jul 2001 08:08:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25396; Fri, 20 Jul 2001 07:35:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25369 for ; Fri, 20 Jul 2001 07:35:51 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04696 for ; Fri, 20 Jul 2001 07:34:55 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.45]) by watermelon.icoe.att.com (Postfix) with ESMTP id 99FEE41A12; Fri, 20 Jul 2001 13:35:18 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010720124958.00a99f18@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 13:38:02 +0200 To: zhigang.liu@nokia.com, , , From: Romeo Zwart Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 09:28 PM 7/19/2001, zhigang.liu@nokia.com wrote: >> The draft talks about the encoder that learns "in some way" >> that the message was received at the other end. Magic I can >> think of here would either look very much like an (implicit) >> acknowledgement mechanism, where the decoder and encoder on >> one side of the link communicate to confirm message reception. >> Alternatively, message confirmation might depend on direct >> signalling from the application layer to the compression layer. >> However, since the SIP layer is not aware of the encoder, I >> don't think that's a valid approach. I'd be interested to >> how this is perceived to work. >Or explicit acknowledgement, which can be either stand-lone or >piggybacked on the compressed message from the other direction. >This makes the compression layer independent of the upper layer >(e.g. SIP in this case). The 3-way SCRIBE acknowledgement seems rather elaborate for what it needs to do. The ROGER draft section 5.6 shows that at least the third leg of the acknowledgement can be done implicitly too. >Of course, if there is some interface >between SIP and compression layer, we should not exclude the >use of such interface. My understanding of the SIP compression draft is that the interface is left unspecified. However, defining an internal mechanism to allow the application layer to keep track of the messages sent at the compression layer seems more complex than defining a simple acknowledgement scheme. >> By the way, I am not so much concerned with the pathological >> case you've given above. If lower layers are dropping *all* >> requests, a non-updated codebook is probably not my main worry. >> But I'd agree that in the case of deteriorating network behavior, >> e.g. ramping up towards an overload situation, non-updated >> codebooks are going to worsen the problem. > >This problem can be alleviated by the static and user-specific >dictionary or codebook (see >http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-00.txt, >a newer version has been submitted to ROHC WG and should appear >soon). That also allows good compression efficiency for the >first few messages in a session. I agree a partially static/profile dependent dictionary would be expected to show better results for the initial messages in a series of messages. In the case of mid-session network deterioration, a dynamic mechanism would add some additional overhead trying to update the codebook, whereas a static mechanism obviously would not, but I don't think that this would push the overall scale to favour static dictionaries. The version -00 SCRIBE draft does not show any examples or compression ratio assessments. Both the SIP compression draft and the ROGER draft have some very rough and hard to compare examples. Is there a draft that shows assessments of the achievable compression results with SCRIBE? Romeo _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 08:19:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14108 for ; Fri, 20 Jul 2001 08:19:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25620; Fri, 20 Jul 2001 07:45:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25589 for ; Fri, 20 Jul 2001 07:45:45 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07684 for ; Fri, 20 Jul 2001 07:44:49 -0400 (EDT) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f6KBj3J05847; Fri, 20 Jul 2001 13:45:03 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Romeo Zwart" , , , , Cc: , , Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 13:45:15 +0200 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <5.1.0.14.0.20010720124958.00a99f18@watermelon.icoe.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The version -00 SCRIBE draft does not show any examples or > compression ratio assessments. Both the SIP compression draft > and the ROGER draft have some very rough and hard to compare > examples. Is there a draft that shows assessments of the > achievable compression results with SCRIBE? I have asked Hans Hannu to make his benchmarks available to the WG -- or if anybody else has some, having them available would help. Gruesse, Carsten _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 08:53:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19347 for ; Fri, 20 Jul 2001 08:53:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26784; Fri, 20 Jul 2001 08:23:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26752 for ; Fri, 20 Jul 2001 08:23:18 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14613 for ; Fri, 20 Jul 2001 08:22:15 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 13:21:16 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DE4@RSYS002A> From: "Price, Richard" To: "'Dr. Carsten Bormann'" , Romeo Zwart , zhigang.liu@nokia.com, Romeo.Zwart@att.com, jundery@ubiquity.net, Lars-Erik.Jonsson@epl.ericsson.se Cc: jdrosen@dynamicsoft.com, sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 13:21:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, We chose the "Successful Simple SIP to SIP" call flow from Section 3.1.1 of to benchmark our own SIP compression scheme. Initially the "dictionary" of previously received messages is empty, but new messages can be compressed relative to all previously received messages. This illustrates nicely how the compression ratio goes up with a more comprehensive dictionary. The results for our scheme are as follows: Message Size Compressed Size Compression Ratio 423 152 2.78 189 6 31.50 205 16 12.81 420 28 15.00 195 4 48.75 214 8 26.75 198 2 99.00 If anyone has an alternative set of SIP messages, we could provide compression ratios for these also. Regards, Richard P -----Original Message----- From: Dr. Carsten Bormann [mailto:cabo@tzi.org] Sent: Friday, July 20, 2001 12:45 PM To: Romeo Zwart; zhigang.liu@nokia.com; Romeo.Zwart@att.com; jundery@ubiquity.net; Lars-Erik.Jonsson@epl.ericsson.se Cc: jdrosen@dynamicsoft.com; sip@ietf.org; rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > The version -00 SCRIBE draft does not show any examples or > compression ratio assessments. Both the SIP compression draft > and the ROGER draft have some very rough and hard to compare > examples. Is there a draft that shows assessments of the > achievable compression results with SCRIBE? I have asked Hans Hannu to make his benchmarks available to the WG -- or if anybody else has some, having them available would help. Gruesse, Carsten --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 10:17:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15663 for ; Fri, 20 Jul 2001 10:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29770; Fri, 20 Jul 2001 09:50:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29739 for ; Fri, 20 Jul 2001 09:49:57 -0400 (EDT) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04384 for ; Fri, 20 Jul 2001 09:49:00 -0400 (EDT) Received: from cybertron.div8.net ([64.230.141.73]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010720134924.QAHW3306.tomts8-srv.bellnexxia.net@cybertron.div8.net>; Fri, 20 Jul 2001 09:49:24 -0400 Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian)) id 15Naky-0005Zh-00; Fri, 20 Jul 2001 09:55:52 -0400 Date: Fri, 20 Jul 2001 09:55:52 -0400 From: Billy Biggs To: stoshniwal@hss.hns.com Cc: sip-implementors@cs.columbia.edu, sip@ietf.org Message-ID: <20010720095551.A21424@dumbterm.net> References: <65256A8F.00329DC1.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <65256A8F.00329DC1.00@sampark.hss.hns.com>; from stoshniwal@hss.hns.com on Fri, Jul 20, 2001 at 02:42:51PM +0530 Subject: [Sip] Re: HANDOFF for call transfer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org stoshniwal@hss.hns.com (stoshniwal@hss.hns.com): > Is there some work still continuing on this draft? Or has it been > abandoned in favour of the REFER approach to transfer? This draft is not being continued. It was basically decided at the Interim meeting in February to stick to REFER. http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 10:24:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17753 for ; Fri, 20 Jul 2001 10:24:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29993; Fri, 20 Jul 2001 09:58:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29959 for ; Fri, 20 Jul 2001 09:57:58 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07444 for ; Fri, 20 Jul 2001 09:56:59 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 14:55:58 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DE6@RSYS002A> From: "Price, Richard" To: "'Romeo Zwart'" Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 14:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Apologies to members of the SIP mailing list who haven't received my previous emails on the subject. The scheme in question is EPIC (Efficient Protocol-Independent Compression) which is a programmable compression scheme with a very high level of efficiency. There is also a "learning" version of EPIC that does not need to be programmed - we used this to obtain the results for SIP compression. The new EPIC draft is being published today - we will post a copy on our website and provide the link shortly. Regards, Richard P -----Original Message----- From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] Sent: Friday, July 20, 2001 2:11 PM To: Price, Richard Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Hi Richard, Thanks for this info, results look impressive. I am a bit confused when you say "our own SIP compression scheme". So that's not SCRIBE or ROGER, is it? Has that scheme been documented anywhere? Romeo At 02:21 PM 7/20/2001, you wrote: >Hi, > >We chose the "Successful Simple SIP to SIP" call flow from >Section 3.1.1 of to >benchmark our own SIP compression scheme. > >Initially the "dictionary" of previously received messages >is empty, but new messages can be compressed relative to all >previously received messages. This illustrates nicely how the >compression ratio goes up with a more comprehensive dictionary. > >The results for our scheme are as follows: > >Message Size Compressed Size Compression Ratio > > 423 152 2.78 > 189 6 31.50 > 205 16 12.81 > 420 28 15.00 > 195 4 48.75 > 214 8 26.75 > 198 2 99.00 > >If anyone has an alternative set of SIP messages, we could provide >compression ratios for these also. > >Regards, > >Richard P --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 10:59:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27674 for ; Fri, 20 Jul 2001 10:59:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02035; Fri, 20 Jul 2001 10:47:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02004 for ; Fri, 20 Jul 2001 10:47:02 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23837 for ; Fri, 20 Jul 2001 10:46:07 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KEl4i27573 for ; Fri, 20 Jul 2001 09:47:04 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Jul 2001 09:46:48 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 09:46:48 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 09:46:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] New I-D on compression of SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEREDvZAGnw9H0CEdWBSQBQi2X+DwAF16ew To: , , , Cc: , , X-OriginalArrivalTime: 20 Jul 2001 14:46:48.0611 (UTC) FILETIME=[CE097730:01C1112A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA02005 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] > The 3-way SCRIBE acknowledgement seems rather elaborate for > what it needs to do. The ROGER draft section 5.6 shows that > at least the third leg of the acknowledgement can be done > implicitly too. The 3-way acknowledgement is needed to handle message loss, misordering, and concurrent updates initiated by both CD entities (this is not an issue in "split mode", but an issue in "shared mode"). SCRIBE-01 has some more detail on this. (It was submitted on July 18, probably still in the queue. I'll post it somewhere and let you know the URL.) I haven't read the new ROGER draft. I'll check what you pointed out. > >Of course, if there is some interface > >between SIP and compression layer, we should not exclude the > >use of such interface. > > My understanding of the SIP compression draft is that the > interface is left unspecified. However, defining an internal > mechanism to allow the application layer to keep track of the > messages sent at the compression layer seems more complex than > defining a simple acknowledgement scheme. I agree. As you can see, I favor an explicit independent acknowledgement at compression layer. But to be fair, I can see that some application may determine what message has been received by its peer (e.g. due to request-response nature) and inform this to compression layer. However, I think acknowledgement at compression layer is cleaner and better, and should be the base of anything else. > I agree a partially static/profile dependent dictionary would > be expected to show better results for the initial messages in > a series of messages. In the case of mid-session network > deterioration, a dynamic mechanism would add some additional > overhead trying to update the codebook, whereas a static > mechanism obviously would not, but I don't think that this > would push the overall scale to favour static dictionaries. That is still an open question to me. What I can say now is that it depends (e.g. what protocol is compressed, compressor and decompressor's capability, how complex we want to go). Static/profile can be the basic mechanism, then dynamic update can further boost the compression performance. We should have a flexible framework to adapt the needs. More details can be find in SCRIBE-01. > The version -00 SCRIBE draft does not show any examples or > compression ratio assessments. Both the SIP compression draft > and the ROGER draft have some very rough and hard to compare > examples. Is there a draft that shows assessments of the > achievable compression results with SCRIBE? You will find performance data in SCRIBE-01. Br, Zhigang > Romeo > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 11:52:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10299 for ; Fri, 20 Jul 2001 11:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03124; Fri, 20 Jul 2001 11:11:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03095 for ; Fri, 20 Jul 2001 11:11:15 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29498 for ; Fri, 20 Jul 2001 11:10:19 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6KFBDT18047; Fri, 20 Jul 2001 11:11:13 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA02750; Fri, 20 Jul 2001 10:11:04 -0500 (CDT) Message-ID: <3B584A08.5B4AEB75@lucent.com> Date: Fri, 20 Jul 2001 10:11:04 -0500 From: "Kumar V. Vemuri" Reply-To: vvkumar@lucent.com Organization: Bell Labs X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Call Control Questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan, others, Greetings. I read your draft "A Call Control Model for SIP", draft-mahy-sip-cc-models-00.txt with interest. It does a good job describing various call configurations. I think a definition of what you mean by "call control model" would help me follow along better. All call models I have come across so far include call states, and transitions between states. The messages from the supported signaling protocol provide the stimulus for these transitions. Is there such a state model for SIP that includes all the SIP primitives defined thus far? If so, is there a draft that covers this? I understand from the "SIP Call Control - Framework" draft that the intent is to support a modular call control model for SIP. Does this mean there will be a modular state machine (if and when a state machine is defined)? Yes, I did also read the draft "SIP Extensions for supporting Distributed Call State", and while there is talk of state distribution among network nodes using the SIP STATE header there (and this is illustrated with some nice examples), there is again no mention of a "standard" set of states. Presumably, if a different proxy from the one that stored state on the server was given this state information at a later time in order to help process the same call (since the intent is to keep proxies effectively stateless), the second proxy should be able to interpret what the stored state really represents in the call context. I guess what I'm requesting is an explanation of how this works. There seems to be an implicit expectation in the state draft that the same proxy will receive all subsequent messages with call state information. Is the above scenario with two proxies supportable? (I realize some crypto details may have to change for this to happen). Thank you. respectfully, Kumar. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 11:54:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11096 for ; Fri, 20 Jul 2001 11:54:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02739; Fri, 20 Jul 2001 11:00:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02707 for ; Fri, 20 Jul 2001 11:00:45 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27729 for ; Fri, 20 Jul 2001 10:59:49 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.45]) by watermelon.icoe.att.com (Postfix) with ESMTP id 1D82D41A12; Fri, 20 Jul 2001 17:00:14 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010720163923.02884dc8@watermelon.icoe.att.com> X-Sender: romeo@watermelon.icoe.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 17:02:32 +0200 To: "Price, Richard" From: Romeo Zwart Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" In-Reply-To: <76C92FBBFB58D411AE760090271ED4186F9DE6@RSYS002A> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Richard, I think your draft is already in the IETF repository. I've glanced over it just now, so maybe I missed some of the fine print, but here's one comment. The compression results of your protocol seem impresssive. However, an immediate drawback of using a 'programmed' protocol like this, is that this is a rather inflexible approach. E.g. compression of new extensions popping up will not be supported until new versions of the en/decoders have been distributed to all involved nodes (network and endpoints). I think that is a practical problem in many scenarios. Romeo At 03:55 PM 7/20/2001, Price, Richard wrote: >Hi, > >Apologies to members of the SIP mailing list who haven't received >my previous emails on the subject. The scheme in question is >EPIC (Efficient Protocol-Independent Compression) which is a >programmable compression scheme with a very high level of efficiency. > >There is also a "learning" version of EPIC that does not need to be >programmed - we used this to obtain the results for SIP compression. > >The new EPIC draft is being published today - we will post a copy on >our website and provide the link shortly. > >Regards, > >Richard P > >-----Original Message----- >From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] >Sent: Friday, July 20, 2001 2:11 PM >To: Price, Richard >Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > >Hi Richard, > >Thanks for this info, results look impressive. I am a bit confused >when you say "our own SIP compression scheme". So that's not SCRIBE >or ROGER, is it? Has that scheme been documented anywhere? > >Romeo > > >At 02:21 PM 7/20/2001, you wrote: > >Hi, > > > >We chose the "Successful Simple SIP to SIP" call flow from > >Section 3.1.1 of to > >benchmark our own SIP compression scheme. > > > >Initially the "dictionary" of previously received messages > >is empty, but new messages can be compressed relative to all > >previously received messages. This illustrates nicely how the > >compression ratio goes up with a more comprehensive dictionary. > > > >The results for our scheme are as follows: > > > >Message Size Compressed Size Compression Ratio > > > > 423 152 2.78 > > 189 6 31.50 > > 205 16 12.81 > > 420 28 15.00 > > 195 4 48.75 > > 214 8 26.75 > > 198 2 99.00 > > > >If anyone has an alternative set of SIP messages, we could provide > >compression ratios for these also. > > > >Regards, > > > >Richard P _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 12:22:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18070 for ; Fri, 20 Jul 2001 12:22:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04859; Fri, 20 Jul 2001 11:52:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04832 for ; Fri, 20 Jul 2001 11:52:32 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10096 for ; Fri, 20 Jul 2001 11:51:32 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 16:51:24 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DE7@RSYS002A> From: "Price, Richard" To: "'Romeo Zwart'" Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 16:51:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, A nice property of "learning" EPIC is that we can always compress any message, but the compression ratio is proportional to how much we know about the message structure. If we know nothing at all about the message structure then the scheme behaves in an identical manner to conventional Lempel-Ziv (LZ-78). This means that we can program the scheme for SIP compression and obtain a very high compression ratio (double Lempel-Ziv) but we can still compress all future extensions. The compression ratio will gradually degrade until the programming is completely out-of-date, in which case we are back to Lempel-Ziv. Processing and memory requirements behave in the same manner: if EPIC has complete knowledge of SIP then the working memory requirements are extremely low (sub 100 bytes) since it discards all previously received data except useful strings such as URLs. Memory requirements increase as the knowledge of SIP degrades, since EPIC must store more in the dictionary to ensure a good compression ratio. I hope this alleviates your concern! Best regards, Richard P -----Original Message----- From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] Sent: Friday, July 20, 2001 4:03 PM To: Price, Richard Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Richard, I think your draft is already in the IETF repository. I've glanced over it just now, so maybe I missed some of the fine print, but here's one comment. The compression results of your protocol seem impresssive. However, an immediate drawback of using a 'programmed' protocol like this, is that this is a rather inflexible approach. E.g. compression of new extensions popping up will not be supported until new versions of the en/decoders have been distributed to all involved nodes (network and endpoints). I think that is a practical problem in many scenarios. Romeo At 03:55 PM 7/20/2001, Price, Richard wrote: >Hi, > >Apologies to members of the SIP mailing list who haven't received >my previous emails on the subject. The scheme in question is >EPIC (Efficient Protocol-Independent Compression) which is a >programmable compression scheme with a very high level of efficiency. > >There is also a "learning" version of EPIC that does not need to be >programmed - we used this to obtain the results for SIP compression. > >The new EPIC draft is being published today - we will post a copy on >our website and provide the link shortly. > >Regards, > >Richard P > >-----Original Message----- >From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] >Sent: Friday, July 20, 2001 2:11 PM >To: Price, Richard >Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > >Hi Richard, > >Thanks for this info, results look impressive. I am a bit confused >when you say "our own SIP compression scheme". So that's not SCRIBE >or ROGER, is it? Has that scheme been documented anywhere? > >Romeo > > >At 02:21 PM 7/20/2001, you wrote: > >Hi, > > > >We chose the "Successful Simple SIP to SIP" call flow from > >Section 3.1.1 of to > >benchmark our own SIP compression scheme. > > > >Initially the "dictionary" of previously received messages > >is empty, but new messages can be compressed relative to all > >previously received messages. This illustrates nicely how the > >compression ratio goes up with a more comprehensive dictionary. > > > >The results for our scheme are as follows: > > > >Message Size Compressed Size Compression Ratio > > > > 423 152 2.78 > > 189 6 31.50 > > 205 16 12.81 > > 420 28 15.00 > > 195 4 48.75 > > 214 8 26.75 > > 198 2 99.00 > > > >If anyone has an alternative set of SIP messages, we could provide > >compression ratios for these also. > > > >Regards, > > > >Richard P --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 13:11:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01880 for ; Fri, 20 Jul 2001 13:11:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06999; Fri, 20 Jul 2001 12:30:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06963 for ; Fri, 20 Jul 2001 12:30:16 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19693 for ; Fri, 20 Jul 2001 12:29:19 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KGUIi09781 for ; Fri, 20 Jul 2001 11:30:18 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Jul 2001 11:29:54 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 20 Jul 2001 11:29:53 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 20 Jul 2001 11:29:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] New I-D on compression of SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEREY+FIMpWS30EEdWBSQBQi2X+DwAJByyQ To: , , , , Cc: , , X-OriginalArrivalTime: 20 Jul 2001 16:29:53.0830 (UTC) FILETIME=[34B6FC60:01C11139] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA06964 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello, Before SCRIBE-01 shows up in the IETF repository, you can pick it up at http://people.nokia.net/~patil/draft-liu-rohc-scribe-01.txt. Some preliminary performance results can be found in Appendix A. Only static/profile dictionary was used (no dynamic dictionary update). Note that the draft focuses on a framework with necessary mechanisms to synchronize data used by compression/decompression (CD data). The framework is flexible to cover different synchronization scenarios with different complexity (and compression efficiency). Different compression algorithms can run on top of the synchronization chassis. Your comments are welcome. Br, Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 13:14:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02646 for ; Fri, 20 Jul 2001 13:14:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06822; Fri, 20 Jul 2001 12:29:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06794 for ; Fri, 20 Jul 2001 12:29:53 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19616 for ; Fri, 20 Jul 2001 12:28:55 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6KGWrG19045 for ; Fri, 20 Jul 2001 19:32:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 20 Jul 2001 19:29:35 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVC8RH>; Fri, 20 Jul 2001 19:29:35 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E08BB10@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: dean.willis@softarmor.com Subject: Re: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] Date: Fri, 20 Jul 2001 19:29:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Dean, Dean Willis wrote: > >Ok, my turn to be obtuse. What's the difference between the goal of this >draft and > >draft-ietf-sip-serverfeatures-04.txt? The main difference is, that with the Proxy-Supported mechanism the intermediate _proxy_servers_ are queried for support of certain features, whereas the draft-ietf-sip-serverfeatures-04 (Supported header field) describes a mechanism, where the _User_Agent_ informs about features itself supports. This proposal (Proxy-Supported) somehow complements the Proxy-Require mechanism. With Proxy-Supported a request goes through even if one (or more) of the intermediate proxy servers doesn't support an indicated extension, whereas Proxy-Require results in an error response in the proxy server. Hope this answers your question. br, Bernie > >-- >Dean ------------ Original Message -------- Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt Date: Mon, 16 Jul 2001 07:01:31 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Proxy-Supported header field Author(s) : B. Hoeneisen et al. Filename : draft-hoeneisen-sip-proxy-supported-00.txt Pages : 11 Date : 13-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a User Agent Client (UAC) to request that a particular protocol extension has to be used to process the request. The User Agent Server (UAS) declines the request if it does not support the extension. Recently also means have been defined for the User Agent Server (UAS) to determine which extensions are supported by the User Agent Client (UAC). Furthermore there are also means for requiring proxy servers to understand certain features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-supported-00.t xt 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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-00.txt". _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 16:06:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27583 for ; Fri, 20 Jul 2001 16:06:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14744; Fri, 20 Jul 2001 15:31:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14710 for ; Fri, 20 Jul 2001 15:31:39 -0400 (EDT) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12682 for ; Fri, 20 Jul 2001 15:30:36 -0400 (EDT) Received: from cybertron.div8.net ([64.230.141.73]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010720193100.KCZZ3894.tomts7-srv.bellnexxia.net@cybertron.div8.net>; Fri, 20 Jul 2001 15:31:00 -0400 Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian)) id 15Ng5X-0005ac-00; Fri, 20 Jul 2001 15:37:27 -0400 Date: Fri, 20 Jul 2001 15:37:27 -0400 From: Billy Biggs To: SIP List Cc: Robert Sparks , Dean Willis Message-ID: <20010720153727.A21468@dumbterm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Sip] New Replaces Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, I submitted an updated version of the Replaces draft. It's available here until its announced: http://www.billybiggs.com/sip/draft-biggs-sip-replaces-01.txt The remaining open issue is the call-leg identifier we should use. The consensus seems to be that Replaces should uniquely identify a call, regardless of how much information that requires. I'm personally a huge supporter of Jonathan's proposal to simplify call-leg identification down to callid + tags. Depending on how things look after this IETF, Replaces will either stay as it is or include the full to and from verbatim. The changes to the draft were making tags mandatory, clarifications to behavior (for example for unconnected calls), and some editorial cleanups. The next revision of this draft will appear as a SIP WG draft. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 16:06:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27684 for ; Fri, 20 Jul 2001 16:06:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15031; Fri, 20 Jul 2001 15:38:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15002 for ; Fri, 20 Jul 2001 15:37:59 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15629 for ; Fri, 20 Jul 2001 15:37:01 -0400 (EDT) From: sean.olson@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6KJbsp06381; Fri, 20 Jul 2001 14:37:54 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6KJbrj12521; Fri, 20 Jul 2001 14:37:53 -0500 (CDT) Received: from e0000865ab2db (pc050200.exu.ericsson.se [138.85.50.200]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA11726; Fri, 20 Jul 2001 14:37:53 -0500 (CDT) Reply-To: To: , Cc: Subject: RE: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] Date: Fri, 20 Jul 2001 14:37:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <034272783A93C944A6CA1D87FBF6F49E08BB10@esebe014.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA15004 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit With Proxy-Require, it is clear what is intended: you require every proxy on the path to support/use a given extension. With Proxy-Supported, this is more difficult. You are querying for the (optional) support of a feature. What does it mean for 3 out of 4 proxies to support a given feature? The biggest problem I see with this approach is that it doesn't work for the initial request (e.g INVITE). Most features that come to mind need to be invoked on the initial request and possibly subsequent requests for a call. regards, sean olson >-----Original Message----- >From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] >Sent: Friday, July 20, 2001 11:30 AM >To: sip@ietf.org >Cc: dean.willis@softarmor.com >Subject: Re: [Sip] Discussion: >draft-hoeneisen-sip-proxy-supported-00.txt] > > >Hi Dean, > >Dean Willis wrote: >> >>Ok, my turn to be obtuse. What's the difference between the >goal of this >>draft and >> >>draft-ietf-sip-serverfeatures-04.txt? > >The main difference is, that with the Proxy-Supported mechanism >the intermediate _proxy_servers_ are queried for support of certain >features, whereas the draft-ietf-sip-serverfeatures-04 >(Supported header field) describes a mechanism, where the >_User_Agent_ informs about features itself supports. > >This proposal (Proxy-Supported) somehow complements the Proxy-Require >mechanism. With Proxy-Supported a request goes through even if one >(or more) of the intermediate proxy servers doesn't support an >indicated extension, whereas Proxy-Require results in an error >response in the proxy server. > >Hope this answers your question. > >br, > Bernie > >> >>-- >>Dean > >------------ Original Message -------- >Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt >Date: Mon, 16 Jul 2001 07:01:31 -0400 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; >CC: sip@ietf.org > >--NextPart > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The SIP Proxy-Supported header field > Author(s) : B. Hoeneisen et al. > Filename : draft-hoeneisen-sip-proxy-supported-00.txt > Pages : 11 > Date : 13-Jul-01 > >The Session Initiation Protocol (SIP) provides a mechanism that >allows a User Agent Client (UAC) to request that a particular >protocol extension has to be used to process the request. The User >Agent Server (UAS) declines the request if it does not support the >extension. Recently also means have been defined for the User Agent >Server (UAS) to determine which extensions are supported by the User >Agent Client (UAC). Furthermore there are also means for requiring >proxy servers to understand certain features. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-s upported-00.t xt 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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-00.txt". _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 16:43:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14169 for ; Fri, 20 Jul 2001 16:43:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16388; Fri, 20 Jul 2001 16:19:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16357 for ; Fri, 20 Jul 2001 16:19:02 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03110 for ; Fri, 20 Jul 2001 16:18:04 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 21:17:42 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DEB@RSYS002A> From: "Price, Richard" To: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Fri, 20 Jul 2001 21:17:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] New I-Ds Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, New versions of the EPIC drafts have now been submitted to the Internet Drafts editor. In the meantime, the drafts are available from the following URLS: http://www.epic.roke.co.uk/epic/draft-ietf-rohc-tcp-epic-01.txt This draft describes the basic EPIC programmable compression scheme and uses it to generate a ROHC profile for TCP/IP compression. http://www.epic.roke.co.uk/epic/draft-price-rohc-signaling-epic-00.txt This draft describes a "learning" version of EPIC that does not require programming, and uses it to generate a ROHC profile for SIP compression. http://www.epic.roke.co.uk/epic/draft-price-rohc-epic-02.txt This draft describes an optional enhancement to EPIC which boosts the compression efficiency. We hope you have as much fun reading these drafts as we had writing them(!) Best regards, Richard Price ------------------------------------------------------------------------- Richard Price Internet Applications & Mobility Roke Manor Research Ltd. Old Salisbury Lane Romsey, Hants SO51 0ZN, UK. Telephone: +44 1794 833681 E-mail: richard.price@roke.co.uk ------------------------------------------------------------------------- -----Original Message----- From: Price, Richard Sent: Friday, July 20, 2001 2:56 PM To: 'Romeo Zwart' Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Hi, Apologies to members of the SIP mailing list who haven't received my previous emails on the subject. The scheme in question is EPIC (Efficient Protocol-Independent Compression) which is a programmable compression scheme with a very high level of efficiency. There is also a "learning" version of EPIC that does not need to be programmed - we used this to obtain the results for SIP compression. The new EPIC draft is being published today - we will post a copy on our website and provide the link shortly. Regards, Richard P -----Original Message----- From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] Sent: Friday, July 20, 2001 2:11 PM To: Price, Richard Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Hi Richard, Thanks for this info, results look impressive. I am a bit confused when you say "our own SIP compression scheme". So that's not SCRIBE or ROGER, is it? Has that scheme been documented anywhere? Romeo At 02:21 PM 7/20/2001, you wrote: >Hi, > >We chose the "Successful Simple SIP to SIP" call flow from >Section 3.1.1 of to >benchmark our own SIP compression scheme. > >Initially the "dictionary" of previously received messages >is empty, but new messages can be compressed relative to all >previously received messages. This illustrates nicely how the >compression ratio goes up with a more comprehensive dictionary. > >The results for our scheme are as follows: > >Message Size Compressed Size Compression Ratio > > 423 152 2.78 > 189 6 31.50 > 205 16 12.81 > 420 28 15.00 > 195 4 48.75 > 214 8 26.75 > 198 2 99.00 > >If anyone has an alternative set of SIP messages, we could provide >compression ratios for these also. > >Regards, > >Richard P --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 20 23:21:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19379 for ; Fri, 20 Jul 2001 23:21:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26556; Fri, 20 Jul 2001 22:52:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26495 for ; Fri, 20 Jul 2001 22:52:36 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12784; Fri, 20 Jul 2001 22:51:38 -0400 (EDT) Received: from blazer (dwillis4.directlink.net [63.64.250.85]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6L2nkO10501; Fri, 20 Jul 2001 21:49:46 -0500 Message-ID: <000e01c11190$208cb660$55fa403f@blazer> From: "Dean Willis" To: , Date: Fri, 20 Jul 2001 21:51:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Fw: agenda building reminder Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just a reminder about how the Area Directors feel we should be using our precious face-to-face meeting time. Since I can't say it any better than Scott, I've just borrowed his words . . . -- Dean ----- Original Message ----- From: "Scott Bradner" To: Sent: Friday, July 20, 2001 9:02 PM Subject: agenda building reminder > > reminder as you put together your agendas: > > There should be no "presentations" of Internet Drafts on the agendas > for the London IETF sessions. All new IDs should be discussed on the > WG mailing list. Any unresolved issues can be brought to the face to face > meeting. It is also OK to have a presentation about what was changed > between two versions of an ID. > > There is no way to reasonably judge a technical proposal from > a short presentation - and the very scarce time should be used to resolve > issues instead of trying to get incomplete understandings of IDs. > > Scott & Allison > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 21 12:14:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21090 for ; Sat, 21 Jul 2001 12:14:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18941; Sat, 21 Jul 2001 11:48:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18913 for ; Sat, 21 Jul 2001 11:48:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15846 for ; Sat, 21 Jul 2001 11:47:47 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6LFmEg12834; Sat, 21 Jul 2001 08:48:14 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAN03221; Sat, 21 Jul 2001 08:48:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09546; Sat, 21 Jul 2001 08:48:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15193.42044.863925.886231@thomasm-u1.cisco.com> Date: Sat, 21 Jul 2001 08:48:12 -0700 (PDT) To: "Sean Olson (EUS)" Cc: sip@ietf.org Subject: [Sip] Encryption negotiation? In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You might take a look at my security draft which tries to make sense of all of this. I don't think SIP has any way of returning an error right now, nor any way for a UAC to indicate to the UAS that it's response was garbled. This may be worth exploring more. One of the counterpoints to feeding errors back is that you might be giving an attacker information that it shouldn't be getting (ie, silently discarding bogons is better). A counter-counterpoint is that Kerberos, say, relies on certain errors to be processed, namely clock skew errors, so maybe it's a requirement in some situations, and optional in others. As far as negotiation goes, there's nothing in there now that I know of, but the security draft attempts to do that. Mike Sean Olson (EUS) writes: > Hi, > > I have a simple question but I've been unable > to find an answer in the spec, FAQ, or mailing > list archives (though I may have overlooked > something obvious). > > When using the Encryption: header in a request, > is there a way for the UAS to reject the request > *and* indicate that the request was rejected because > the UAS was unable to decrypt the body? Should a > warning header be used? What about an option tag > for encryption? (i.e. is there a way to negotiate > support of encryption?) I would expect that many > implementations that don't support encryption > might return something like a 415 or a 400. > > Any comments? > > Sean Olson > Ericsson Inc. > sean.olson@ericsson.com > > > > > > Encryption negotiation? > > > >

Hi, >

> >

I have a simple question but I've been unable >
to find an answer in the spec, FAQ, or mailing >
list archives (though I may have overlooked >
something obvious). >

> >

When using the Encryption: header in a request, >
is there a way for the UAS to reject the request >
*and* indicate that the request was rejected because >
the UAS was unable to decrypt the body? Should a >
warning header be used? What about an option tag >
for encryption? (i.e. is there a way to negotiate >
support of encryption?) I would expect that many >
implementations that don't support encryption >
might return something like a 415 or a 400. >

> >

Any comments? >

> >

Sean Olson >
Ericsson Inc. >
sean.olson@ericsson.com >

> > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 21 12:36:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25530 for ; Sat, 21 Jul 2001 12:36:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19841; Sat, 21 Jul 2001 12:18:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19813 for ; Sat, 21 Jul 2001 12:18:25 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21511 for ; Sat, 21 Jul 2001 12:17:29 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6LGHlg18069; Sat, 21 Jul 2001 09:17:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAN03284; Sat, 21 Jul 2001 09:17:41 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09553; Sat, 21 Jul 2001 09:17:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15193.43813.46560.76033@thomasm-u1.cisco.com> Date: Sat, 21 Jul 2001 09:17:41 -0700 (PDT) To: Jonathan Rosenberg Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: [Sip] New I-D on compression of SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Folks, > > I've just submitted a new I-D on compression of SIP messages, particularly > for wireless links. Until the draft appears in the archives, you can pick up > a copy at: Jonathan, To follow up on my passing comments, it should be noted that IPsec already has compression transforms which work in combination with encryption/message integrity. I'm not sure if TLS has this capability, but I wouldn't be surprised (nor do I think it would be hard to add if not). Thus, there's at least some amount of wheel reinvention going on here. That said, it may be interesting to consider taking the same tack as IPsec compression for SIP security which has the same problem as all encryption/compression schemes which is that you must compress before encrypting to do anything useful. Thus, it would be natural for secure SIP headers and bodies (attachments, as I propose) to allow compression transforms as well. The synergy between our two drafts, I think, may lie in something that I've been toying with: the ability to have a complete SIP application layer security scheme which not only deals with the problem which is clearly in the SIP domain (crypto for parts of the SIP payload), but could also be used to provide hop-by-hop encryption/authentication as well negating the need to require a base level secure transport mechanism (eg, IPsec, TLS). I think this is possible by extending my current proposal to insert a shim layer much like you propose in this draft here. I haven't included this in the current draft (mostly because it's not a baked idea), but it would make sense to my mind that if we allow compression, we ought to fold it into the security framework mainly because of the compress-then-encrypt problem. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 21 15:57:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24152 for ; Sat, 21 Jul 2001 15:57:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23178; Sat, 21 Jul 2001 15:18:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23151 for ; Sat, 21 Jul 2001 15:18:17 -0400 (EDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18567 for ; Sat, 21 Jul 2001 15:17:21 -0400 (EDT) Received: from BobP (h-64-105-110-12.chcgilgm.covad.net [64.105.110.12]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f6LJI9P192972; Sat, 21 Jul 2001 15:18:13 -0400 Message-ID: <001001c11219$d968f020$2300000a@acmepacket.com> From: "Bob Penfield" To: "Billy Biggs" , "SIP List" References: <20010720153727.A21468@dumbterm.net> Subject: Re: [Sip] New Replaces Draft Date: Sat, 21 Jul 2001 15:17:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Billy, The examples in section 5 and 6 use a REFER/100-Trying/200-OK message flow instead of the REFER/202-Accepted & NOTIFY/200-OK required by draft-ietf-sip-cc-transfer-04.txt. Is there a reason for this? Also, since the call leg being replaced is the one between the Transferor and the Target, shouldn't call-id 2 be passed in the Replaces header in the REFER and the INVITE? I also like the proposal to simplify call leg identification. This is question for the WG chairs, but since this extension is referred to by draft-ietf-sip-cc-transfer-05.txt, shouldn't it be a WG Item? (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Billy Biggs" To: "SIP List" Cc: "Robert Sparks" ; "Dean Willis" Sent: Friday, July 20, 2001 3:37 PM Subject: [Sip] New Replaces Draft > Hi all, > > I submitted an updated version of the Replaces draft. It's available > here until its announced: > > http://www.billybiggs.com/sip/draft-biggs-sip-replaces-01.txt > > The remaining open issue is the call-leg identifier we should use. > The consensus seems to be that Replaces should uniquely identify a call, > regardless of how much information that requires. > > I'm personally a huge supporter of Jonathan's proposal to simplify > call-leg identification down to callid + tags. Depending on how things > look after this IETF, Replaces will either stay as it is or include the > full to and from verbatim. > > The changes to the draft were making tags mandatory, clarifications to > behavior (for example for unconnected calls), and some editorial > cleanups. The next revision of this draft will appear as a SIP WG > draft. > > -- > Billy Biggs bbiggs@dumbterm.net > http://www.billybiggs.com/ wbiggs@uwaterloo.ca > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 21 16:28:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02965 for ; Sat, 21 Jul 2001 16:28:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24197; Sat, 21 Jul 2001 16:01:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24170 for ; Sat, 21 Jul 2001 16:01:14 -0400 (EDT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24901 for ; Sat, 21 Jul 2001 16:00:17 -0400 (EDT) Received: from cybertron.div8.net ([64.230.148.67]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010721200044.SPGY16844.tomts5-srv.bellnexxia.net@cybertron.div8.net>; Sat, 21 Jul 2001 16:00:44 -0400 Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian)) id 15O320-0005iN-00; Sat, 21 Jul 2001 16:07:20 -0400 Date: Sat, 21 Jul 2001 16:07:20 -0400 From: Billy Biggs To: Bob Penfield Cc: SIP List Subject: Re: [Sip] New Replaces Draft Message-ID: <20010721160720.A21962@dumbterm.net> References: <20010720153727.A21468@dumbterm.net> <001001c11219$d968f020$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001001c11219$d968f020$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Sat, Jul 21, 2001 at 03:17:52PM -0400 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Bob Penfield (bpenfield@acmepacket.com): > The examples in section 5 and 6 use a REFER/100-Trying/200-OK message > flow instead of the REFER/202-Accepted & NOTIFY/200-OK required by > draft-ietf-sip-cc-transfer-04.txt. Is there a reason for this? No reason, just my poor editing skills. I'll fix it now, and update it in the next version. > Also, since the call leg being replaced is the one between the > Transferor and the Target, shouldn't call-id 2 be passed in the > Replaces header in the REFER and the INVITE? Yeah, that's also broken. Many apologies. > This is question for the WG chairs, but since this extension is > referred to by draft-ietf-sip-cc-transfer-05.txt, shouldn't it be a WG > Item? It is, I belive, I just wanted to get it announced before IETF. Thanks, Billy -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 04:43:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07560 for ; Mon, 23 Jul 2001 04:43:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19764; Mon, 23 Jul 2001 04:19:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19736 for ; Mon, 23 Jul 2001 04:19:45 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07379 for ; Mon, 23 Jul 2001 04:18:48 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6N8JjF20170 for ; Mon, 23 Jul 2001 04:19:45 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <3YP2B3XN>; Mon, 23 Jul 2001 09:19:44 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002E4BEF3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dr. Carsten Bormann'" , Romeo Zwart , zhigang.liu@nokia.com, Romeo.Zwart@att.com, jundery@ubiquity.net, Lars-Erik.Jonsson@epl.ericsson.se, "Price, Richard" Cc: jdrosen@dynamicsoft.com, sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Mon, 23 Jul 2001 09:19:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There is a requirement to perform compression in 3GPP (and presumably in 3GPP2) between the UAS and the first proxy (UE to P-CSCF in 3GPP). TS 24.228 shows the current flows for this (version 1.1.0 is at ftp://ftp.3gpp.org/Specs/Latest_drafts/ ). Unfortunately this document only partially populates the example fields, and relies on a shorthand notation in order to identify the contents of remaining fields from the previous tables - we are looking for someone to write a macro that will do this population automatically before final publication). We have yet to choose the compression scheme, and obviously would prefer something that is IETF defined. Expect that some discussion on this should take place in the SIPPING WG 2nd session in London. One thing that should be born in mind is that there is also a requirement for encryption on the above radio interface. The encryption mechanism to be used is still under discussion. I assume that depending on whether the encryption is performed before the compression or after will have a drastic effect on the compression. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Price, Richard[SMTP:richard.price@roke.co.uk] > Sent: 20 July 2001 13:21 > To: 'Dr. Carsten Bormann'; Romeo Zwart; zhigang.liu@nokia.com; > Romeo.Zwart@att.com; jundery@ubiquity.net; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: jdrosen@dynamicsoft.com; sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > <> > Hi, > > We chose the "Successful Simple SIP to SIP" call flow from > Section 3.1.1 of to > benchmark our own SIP compression scheme. > > Initially the "dictionary" of previously received messages > is empty, but new messages can be compressed relative to all > previously received messages. This illustrates nicely how the > compression ratio goes up with a more comprehensive dictionary. > > The results for our scheme are as follows: > > Message Size Compressed Size Compression Ratio > > 423 152 2.78 > 189 6 31.50 > 205 16 12.81 > 420 28 15.00 > 195 4 48.75 > 214 8 26.75 > 198 2 99.00 > > If anyone has an alternative set of SIP messages, we could provide > compression ratios for these also. > > Regards, > > Richard P > > -----Original Message----- > From: Dr. Carsten Bormann [mailto:cabo@tzi.org] > Sent: Friday, July 20, 2001 12:45 PM > To: Romeo Zwart; zhigang.liu@nokia.com; Romeo.Zwart@att.com; > jundery@ubiquity.net; Lars-Erik.Jonsson@epl.ericsson.se > Cc: jdrosen@dynamicsoft.com; sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > > > The version -00 SCRIBE draft does not show any examples or > > compression ratio assessments. Both the SIP compression draft > > and the ROGER draft have some very rough and hard to compare > > examples. Is there a draft that shows assessments of the > > achievable compression results with SCRIBE? > > I have asked Hans Hannu to make his benchmarks available to the WG -- or > if > anybody else has some, having them available would help. > > Gruesse, Carsten > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 07:36:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11752 for ; Mon, 23 Jul 2001 07:36:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23712; Mon, 23 Jul 2001 07:14:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23682 for ; Mon, 23 Jul 2001 07:13:58 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10745 for ; Mon, 23 Jul 2001 07:12:57 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6NBDfO22184 for ; Mon, 23 Jul 2001 13:13:41 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6NBDe526893 for ; Mon, 23 Jul 2001 14:13:40 +0300 (EET DST) Message-ID: <3B5C06E4.FC09D246@lmf.ericsson.se> Date: Mon, 23 Jul 2001 14:13:40 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt References: <200107161101.HAA10658@ietf.org> Content-Type: multipart/mixed; boundary="------------4236FA31C57D97ACEADEC0C9" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------4236FA31C57D97ACEADEC0C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'm the first to admit (I've mentioned it before) that the PRACK mechanism is very "heavy", and what you propose has been discussed before (I think I was even one of those who proposed it back then...), but the argument against it was that it is against the SIP semantics, since ACK is the ONLY method which is sent without a response - and I think that makes very much sense. So, while we can (and we SHALL) come up with new cool features for SIP, we should avoid touching the protocol core. In this case we would have to change the semantics of a SIP transaction, since the bis specifies how INVITEs are handled, how ACKs are handled, and how ALL OTHER methods (standard- or extension methods) should be handled - ie we would have to change the bis too. Do we want to do that? Also, lately we've also seen that PRACK probably will be used for more than just acking a provisional response. The COMET draft shows one example, and Jonathan also gave a very interesting proposal to solve the early media issue using PRACK. These were only my personal opinions, though... I also have a few questions on the text in the draft. 6.2. UAS Behavior The third chapter says: "If the request did not include a Proxy-Supported header indicating this feature is understood by every record-route proxy, but it included a Supported or a Require header indicating this feature, the UAS either SHOULD send the provisional response using the reliability mechanism defiend in [6] or it SHOULD send the provisional response unreliably." Q1: You have a "SHOULD-OR-SHOULD" statement here. I think that SHOULD as such confuses people enough, but now I'm really lost... :) Q2: You write that if SPRACK can't be used, the UAS SHOULD send the provisional response using the mechanism defined in [6] (the PRACK method). To me this indicates that the UAS also SHOULD support the mechanism defined in [6]... Regards, Christer Holmberg Ericsson Finland --------------4236FA31C57D97ACEADEC0C9 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------4236FA31C57D97ACEADEC0C9-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 07:37:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11809 for ; Mon, 23 Jul 2001 07:37:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23241; Mon, 23 Jul 2001 06:56:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23214 for ; Mon, 23 Jul 2001 06:56:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09875; Mon, 23 Jul 2001 06:55:27 -0400 (EDT) Message-Id: <200107231055.GAA09875@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Jul 2001 06:55:27 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-cc-transfer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP Call Control - Transfer Author(s) : R. Sparks Filename : draft-ietf-sip-cc-transfer-05.txt Pages : 17 Date : 20-Jul-01 This document describes providing Call Transfer capabilites in SIP. Transfer capabilities. This work is part of the Call Control Framework A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-05.txt 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-cc-transfer-05.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-cc-transfer-05.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: <20010720083156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-transfer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-transfer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720083156.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 07:59:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12907 for ; Mon, 23 Jul 2001 07:59:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23829; Mon, 23 Jul 2001 07:22:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23801 for ; Mon, 23 Jul 2001 07:22:42 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11140 for ; Mon, 23 Jul 2001 07:21:47 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NBNHI03545 for ; Mon, 23 Jul 2001 14:23:18 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 14:22:40 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVDTA2>; Mon, 23 Jul 2001 14:22:40 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E08BB11@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: dean.willis@softarmor.com, sean.olson@ericsson.com Subject: RE: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] Date: Mon, 23 Jul 2001 14:22:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Sean! >-----Original Message----- >From: ext sean.olson@ericsson.com [mailto:sean.olson@ericsson.com] >Sent: 20. July 2001 22:38 >To: bernhard.honeisen@nokia.com; sip@ietf.org >Cc: dean.willis@softarmor.com >Subject: RE: [Sip] Discussion: >draft-hoeneisen-sip-proxy-supported-00.txt] > > >With Proxy-Require, it is clear what is intended: >you require every proxy on the path to support/use >a given extension. With Proxy-Supported, this is >more difficult. You are querying for the (optional) >support of a feature. Could you please outline a bit further, what is unclear with "Proxy-Supported"? >What does it mean for 3 out of 4 proxies to support >a given feature? Sorry, but I don't understand this question. Could you please describe the issue a bit further. >The biggest problem I see with this approach is >that it doesn't work for the initial request (e.g >INVITE). Most features that come to mind need to >be invoked on the initial request and possibly >subsequent requests for a call. First of all: "Proxy-Supported" is _not_ intended to be a general replacement for "Proxy-Require". (I wasn't sure, whether this has been misunderstood.) With "Proxy-Supported" a proxy server knows latest about the feature support in all proxies (which remain in the signalling path for subsequent requests), when the first (non-100Trying) response to the INVITE is arriving at the proxy server. For certain features this is early enough. But the more important cases are, where certain features are used only in subsequent requests. One example is described in http://www.ietf.org/internet-drafts/draft-kiss-sip-s100rel-00.txt, which proposes a light way of the provisional response acknowledgement. The main goal of the "Proxy-Supported" proposal is, that in those cases, where certain features are used only in subsequent requests, an INVITE goes through to the UAS even if one (or more) proxy servers do not support one (or more) listed feature. Furthermore it addresses only those proxy servers, which remain in the signalling path for subsequent requests. Hope things got more clear now... br, Bernie > >regards, >sean olson > >>-----Original Message----- >>From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] >>Sent: Friday, July 20, 2001 11:30 AM >>To: sip@ietf.org >>Cc: dean.willis@softarmor.com >>Subject: Re: [Sip] Discussion: >>draft-hoeneisen-sip-proxy-supported-00.txt] >> >> >>Hi Dean, >> >>Dean Willis wrote: >>> >>>Ok, my turn to be obtuse. What's the difference between the >>goal of this >>>draft and >>> >>>draft-ietf-sip-serverfeatures-04.txt? >> >>The main difference is, that with the Proxy-Supported mechanism >>the intermediate _proxy_servers_ are queried for support of certain >>features, whereas the draft-ietf-sip-serverfeatures-04 >>(Supported header field) describes a mechanism, where the >>_User_Agent_ informs about features itself supports. >> >>This proposal (Proxy-Supported) somehow complements the Proxy-Require >>mechanism. With Proxy-Supported a request goes through even if one >>(or more) of the intermediate proxy servers doesn't support an >>indicated extension, whereas Proxy-Require results in an error >>response in the proxy server. >> >>Hope this answers your question. >> >>br, >> Bernie >> >>> >>>-- >>>Dean >> >>------------ Original Message -------- >>Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt >>Date: Mon, 16 Jul 2001 07:01:31 -0400 >>From: Internet-Drafts@ietf.org >>Reply-To: Internet-Drafts@ietf.org >>To: IETF-Announce: ; >>CC: sip@ietf.org >> >>--NextPart >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : The SIP Proxy-Supported header field >> Author(s) : B. Hoeneisen et al. >> Filename : draft-hoeneisen-sip-proxy-supported-00.txt >> Pages : 11 >> Date : 13-Jul-01 >> >>The Session Initiation Protocol (SIP) provides a mechanism that >>allows a User Agent Client (UAC) to request that a particular >>protocol extension has to be used to process the request. The User >>Agent Server (UAS) declines the request if it does not support the >>extension. Recently also means have been defined for the User Agent >>Server (UAS) to determine which extensions are supported by the User >>Agent Client (UAC). Furthermore there are also means for requiring >>proxy servers to understand certain features. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-s >upported-00.t >xt > >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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-00.txt". > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 09:16:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18412 for ; Mon, 23 Jul 2001 09:16:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25743; Mon, 23 Jul 2001 08:43:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25718 for ; Mon, 23 Jul 2001 08:43:01 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15959 for ; Mon, 23 Jul 2001 08:42:06 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6NCgpO21980; Mon, 23 Jul 2001 14:42:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6NCgo528899; Mon, 23 Jul 2001 15:42:51 +0300 (EET DST) Message-ID: <3B5C1BCA.9F173AB@lmf.ericsson.se> Date: Mon, 23 Jul 2001 15:42:50 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: bernhard.honeisen@nokia.com CC: sip@ietf.org, dean.willis@softarmor.com, sean.olson@ericsson.com Subject: Re: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] References: <034272783A93C944A6CA1D87FBF6F49E08BB11@esebe014.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------481538E952573DAD4872AEF8" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------481538E952573DAD4872AEF8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, My comments... In general, I think it is a good idea if proxies somehow can indicate features that they support. For example, in the discussion about to be able to CANCEL a specific call-leg I mentined that the UAC could use that information to decide if to keep or cancel a call-leg etc etc. In the forward direction it can also be used by proxies to decided where/if to fork a request (yes, this IS related to the caller preferences draft). My opinion about your proposal (I DID understand the draft - I hope :), though, is that I think you try to make things too complicated. First, why do we need a new header (Proxy-Supported) for this? Why can't the Supported header be used, and the proxies can then check the option tags and add Record-Route parameter(s) if needed. Second (and this is what I think makes it complicated) is the proposal that the proxies shall remove option tags from the header, and remove the whole header if there are no more option tags innit... I don't think this is necessary. The UAS, and the UAC, simply have to check the Record-Route headers to check if all proxies support a specific feature. Yes, it takes a little more time, but it is more simple. Regards, Christer Holmberg Ericsson Finland bernhard.honeisen@nokia.com wrote: > > Hi Sean! > > >-----Original Message----- > >From: ext sean.olson@ericsson.com [mailto:sean.olson@ericsson.com] > >Sent: 20. July 2001 22:38 > >To: bernhard.honeisen@nokia.com; sip@ietf.org > >Cc: dean.willis@softarmor.com > >Subject: RE: [Sip] Discussion: > >draft-hoeneisen-sip-proxy-supported-00.txt] > > > > > >With Proxy-Require, it is clear what is intended: > >you require every proxy on the path to support/use > >a given extension. With Proxy-Supported, this is > >more difficult. You are querying for the (optional) > >support of a feature. > > Could you please outline a bit further, what is > unclear with "Proxy-Supported"? > > >What does it mean for 3 out of 4 proxies to support > >a given feature? > > Sorry, but I don't understand this question. > Could you please describe the issue a bit further. > > >The biggest problem I see with this approach is > >that it doesn't work for the initial request (e.g > >INVITE). Most features that come to mind need to > >be invoked on the initial request and possibly > >subsequent requests for a call. > > First of all: "Proxy-Supported" is _not_ intended to > be a general replacement for "Proxy-Require". > (I wasn't sure, whether this has been misunderstood.) > > With "Proxy-Supported" a proxy server knows latest > about the feature support in all proxies (which > remain in the signalling path for subsequent > requests), when the first (non-100Trying) response > to the INVITE is arriving at the proxy server. > For certain features this is early enough. > > But the more important cases are, where certain > features are used only in subsequent requests. > One example is described in > http://www.ietf.org/internet-drafts/draft-kiss-sip-s100rel-00.txt, > which proposes a light way of the provisional > response acknowledgement. > > The main goal of the "Proxy-Supported" proposal is, > that in those cases, where certain features are used > only in subsequent requests, an INVITE goes through > to the UAS even if one (or more) proxy servers do not > support one (or more) listed feature. > > Furthermore it addresses only those proxy servers, > which remain in the signalling path for subsequent > requests. > > Hope things got more clear now... > > br, > Bernie > > > > >regards, > >sean olson > > > >>-----Original Message----- > >>From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] > >>Sent: Friday, July 20, 2001 11:30 AM > >>To: sip@ietf.org > >>Cc: dean.willis@softarmor.com > >>Subject: Re: [Sip] Discussion: > >>draft-hoeneisen-sip-proxy-supported-00.txt] > >> > >> > >>Hi Dean, > >> > >>Dean Willis wrote: > >>> > >>>Ok, my turn to be obtuse. What's the difference between the > >>goal of this > >>>draft and > >>> > >>>draft-ietf-sip-serverfeatures-04.txt? > >> > >>The main difference is, that with the Proxy-Supported mechanism > >>the intermediate _proxy_servers_ are queried for support of certain > >>features, whereas the draft-ietf-sip-serverfeatures-04 > >>(Supported header field) describes a mechanism, where the > >>_User_Agent_ informs about features itself supports. > >> > >>This proposal (Proxy-Supported) somehow complements the Proxy-Require > >>mechanism. With Proxy-Supported a request goes through even if one > >>(or more) of the intermediate proxy servers doesn't support an > >>indicated extension, whereas Proxy-Require results in an error > >>response in the proxy server. > >> > >>Hope this answers your question. > >> > >>br, > >> Bernie > >> > >>> > >>>-- > >>>Dean > >> > >>------------ Original Message -------- > >>Subject: [Sip] I-D ACTION:draft-hoeneisen-sip-proxy-supported-00.txt > >>Date: Mon, 16 Jul 2001 07:01:31 -0400 > >>From: Internet-Drafts@ietf.org > >>Reply-To: Internet-Drafts@ietf.org > >>To: IETF-Announce: ; > >>CC: sip@ietf.org > >> > >>--NextPart > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : The SIP Proxy-Supported header field > >> Author(s) : B. Hoeneisen et al. > >> Filename : draft-hoeneisen-sip-proxy-supported-00.txt > >> Pages : 11 > >> Date : 13-Jul-01 > >> > >>The Session Initiation Protocol (SIP) provides a mechanism that > >>allows a User Agent Client (UAC) to request that a particular > >>protocol extension has to be used to process the request. The User > >>Agent Server (UAS) declines the request if it does not support the > >>extension. Recently also means have been defined for the User Agent > >>Server (UAS) to determine which extensions are supported by the User > >>Agent Client (UAC). Furthermore there are also means for requiring > >>proxy servers to understand certain features. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-s > >upported-00.t > >xt > > > >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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-00.txt". > > > >_______________________________________________ > >Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------481538E952573DAD4872AEF8 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------481538E952573DAD4872AEF8-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 11:41:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29826 for ; Mon, 23 Jul 2001 11:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02368; Mon, 23 Jul 2001 11:19:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02340 for ; Mon, 23 Jul 2001 11:19:10 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28051 for ; Mon, 23 Jul 2001 11:18:14 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NFLrG03116 for ; Mon, 23 Jul 2001 18:21:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 18:18:44 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVD6CF>; Mon, 23 Jul 2001 18:18:41 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E088F22@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: patrick.mourot@online.fr Subject: RE: [Sip] last draft about REFER method Date: Mon, 23 Jul 2001 18:18:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi! http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-refer-00.txt Have fun! cheers, Bernie >-----Original Message----- >From: ext patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] >Sent: 23. July 2001 18:16 >To: sip@ietf.org >Subject: [Sip] (no subject) > > >Sir, > >Where can I find the last draft talking about REFER method ?? > >TIA > >Patrick > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 11:41:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29847 for ; Mon, 23 Jul 2001 11:41:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02229; Mon, 23 Jul 2001 11:15:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02198 for ; Mon, 23 Jul 2001 11:15:44 -0400 (EDT) Received: from postfix2-2.free.fr (postfix@postfix2-2.free.fr [213.228.0.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27814 for ; Mon, 23 Jul 2001 11:14:48 -0400 (EDT) Received: from imp2-1.free.fr (imp2-1.free.fr [213.228.0.22]) by postfix2-2.free.fr (Postfix) with ESMTP id CB50B6B744 for ; Mon, 23 Jul 2001 17:15:44 +0200 (CEST) Received: (from www-data@localhost) by imp2-1.free.fr (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0-1) id f6NFFiqe017621 for sip@ietf.org; Mon, 23 Jul 2001 17:15:44 +0200 To: sip@ietf.org Message-ID: <995901343.3b5c3f9fac1cd@imp.free.fr> Date: Mon, 23 Jul 2001 17:15:43 +0200 (MEST) From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 194.133.58.200 Content-Transfer-Encoding: 8bit Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Sir, Where can I find the last draft talking about REFER method ?? TIA Patrick _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 11:44:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00126 for ; Mon, 23 Jul 2001 11:44:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01947; Mon, 23 Jul 2001 11:06:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01861 for ; Mon, 23 Jul 2001 11:06:14 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27007 for ; Mon, 23 Jul 2001 11:05:18 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6NF6DN15964; Mon, 23 Jul 2001 17:06:13 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6NF6C501651; Mon, 23 Jul 2001 18:06:12 +0300 (EET DST) Message-ID: <3B5C3D63.5217D8AF@lmf.ericsson.se> Date: Mon, 23 Jul 2001 18:06:11 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] new I-D on early media References: Content-Type: multipart/mixed; boundary="------------0CE4CE45EF0F9A53741BF436" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------0CE4CE45EF0F9A53741BF436 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I had a quick look at the draft, and here are some comments. Most of them cosmetic, but still... First, I agree that Solution 1 seems to be the way to go. It doesn't require much extensions (new methods etc), it is (in theory, at least...) backward compatible. ...and it gives us a reason to spend bandwith and CPU power on PRACK transactions :) The questions: Chapter 4.1 UAC Behaviour Q1. The text says: "If the UAS wishes to refuse the early media stream, it SHOULD set the port number for each media stream in the answer to zero" - I guess it shall be "If the UAC wishes...."? A spelling error, I assume. - Why is it "SHOULD set the port..."? Doesn't it have to be MUST to make it work? - I read about setting port numbers set to zero... Does this work with ATM too? Q2. Later, the text says: "If the UAS wishes to accept the early media stream, it generates..." Again, I guess it shall be "If the UAC wishes to accept..."? Q3. Later, the text says: "In that case, it MUST continue to be prepared to receive media according to the information in the SDP in the original INVITE" The reason for this is, of course, that a UAS may not send 1xx. Instead it sends 200, and media to the address/port given in the INVITE. However, I think it should be written that IF a UAS sends 1xx, AND the UAC sends a NEW address/port in the PRACK, that that specific UAS MUST send the early media to the address/port given in the PRACK, and nowhere else. That may sound obvious, but I think it should be there for clarification... Here we still do have a small problem, though. If multiple UAS nodes send 200, they may also start sending media at the same time. This means that the UAC may receive, even if for a short while (until the unwanted legs have been ACK/BYEed), a mix of media streams on the same port/address. I guess this is something we have to live with, though... Q4. Later, the text says that, if multiple legs are established, the UAC can choose to reject early media from one or more of them. I know it doesn't belong to this discussion, but this brings my thoughts back to the discussion we had some weeks ago about being able to CANCEL a specific call-leg. For example, if the UAC knows it will not accept a specific call-leg, should it refuse the early media, wait for the 200, and then ACK/BYE the call - instead of CANCEL it right away? Q5. If a UAC refuses to accept early media from a UAS, the UAS may choose to not accept the call setup. Should we specify (or at least recommend) which response code to use in this case? Q6. This is related to the re-INVITEs. Assume that UAC sends an INVITE, and then receives 1xx (including Contact). Now, the UAC may (for any reason) want to change the media parameters for that specific leg, so it sends a re-INVITE with the new parameters, to the address received in the Contact. Nothing strange here. However, the UAC may (for any reason) want to change the media parameters for ALL possible receivers, even if it has received 1xx from one or more servers. In this case it would send a re-INVITE, WITHOUT using any Contact, or any tag (since we want the re-INVITE to be handled/forked in the same way as the original INVITE). I guess this would not cause any major problems either, but do you think it should be mentioned in the draft? A more complicated case is when the UAC receives 1xx from a UAS. It may provide new media parameters in the PRACK, BUT again it may also want to (for any reason) send a re-INVITE to all possible receivers (ie by not using Contact and tags) - EXCEPT to the UAS it has sent the PRACK to. Again, I guess this is only one of thousands of different scenarios that we can come up with, and we can't describe them all. However, this specific case could be solved using the don't-fork-to feature (Reject-Contact header) in the caller preferences, so maybe it would be cool to include... Chapter 4.2 UAS Behaviour Q7. The text says: "The provisional response MUST contain a Require header with the "em" and "100rel". This is just a detail, but do we MUST put "em" in Require? Can't Supported be used instead? That's all for this time... Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Folks, > > I've just submitted an I-D on early media. As we agreed upon previously, the > concept of early media would be done as an extension, where it could be > handled properly. The draft proposal fixes all of the known problems with > early media, I believe, and is also nicely backwards compatible with the > existing early media approaches. > > Until it appears in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-early-media-00.txt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------0CE4CE45EF0F9A53741BF436 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------0CE4CE45EF0F9A53741BF436-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 12:46:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05430 for ; Mon, 23 Jul 2001 12:45:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04344; Mon, 23 Jul 2001 12:12:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04317 for ; Mon, 23 Jul 2001 12:12:28 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02653 for ; Mon, 23 Jul 2001 12:11:31 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NGD5I17555 for ; Mon, 23 Jul 2001 19:13:05 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 23 Jul 2001 19:12:20 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVD6XS>; Mon, 23 Jul 2001 19:12:21 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E08BB13@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: christer.holmberg@lmf.ericsson.se Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Date: Mon, 23 Jul 2001 19:11:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer! >-----Original Message----- >From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >Sent: 23. July 2001 14:14 >To: sip@ietf.org >Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt > >I'm the first to admit (I've mentioned it before) that the PRACK >mechanism is very "heavy", and what you propose has been discussed >before (I think I was even one of those who proposed it back then...), >but the argument against it was that it is against the SIP semantics, >since ACK is the ONLY method which is sent without a response - and I >think that makes very much sense. > >So, while we can (and we SHALL) come up with new cool features for SIP, >we should avoid touching the protocol core. In this case we would have >to change the semantics of a SIP transaction, since the bis specifies >how INVITEs are handled, how ACKs are handled, and how ALL >OTHER methods >(standard- or extension methods) should be handled - ie we >would have to >change the bis too. Do we want to do that? This I-D does _not_ intend to change the core specs; meaning, that it is an extension mechanism, which can be used only if all intermediate proxy servers (and the UAs) do understand the feature. If this is the case, they shall treat SPRACK similar than ACK. Or do you mean, that the RFC2543bis specs strictly forbids such kind of extensions, although it is technically feasible and backwards compatible? What is the opinion of the authors of RFC2543bis concerning this? >Also, lately we've also seen that PRACK probably will be used for more >than just acking a provisional response. The COMET draft shows one >example, and Jonathan also gave a very interesting proposal to >solve the early media issue using PRACK. Does the 200 OK of PRACK carry some relevant information in these cases? If yes, the PRACK might be more appropriate for these cases. >These were only my personal opinions, though... > >I also have a few questions on the text in the draft. > >6.2. UAS Behavior > >The third chapter says: > >"If the request did not include a Proxy-Supported header >indicating this >feature is understood by every record-route proxy, but it included a >Supported or a Require header indicating this feature, the UAS either >SHOULD send the provisional response using the reliability mechanism >defined in [6] or it SHOULD send the provisional response unreliably." > >Q1: You have a "SHOULD-OR-SHOULD" statement here. I think that >SHOULD as such confuses people enough, but now I'm really lost... :) > >Q2: You write that if SPRACK can't be used, the UAS SHOULD send the >provisional response using the mechanism defined in [6] (the PRACK >method). To me this indicates that the UAS also SHOULD support the >mechanism defined in [6]... It seems, that the relationship between s100rel and 100rel needs some more general explanations and the referred section some refinement. Thanks for your feedback. I try to explain here what is meant: - The s100rel package contains somehow the capabilities of the 100rel package. Whenever a response is to be sent reliably and s100rel can be used, then use s100rel (SPRACK); otherwise use 100rel (PRACK) - If _no_ Proxy-Supported (s100rel), but a Require (s100rel) are present , then use always 100rel (i.e. response contains "Require: 100rel" and is acknowledged by PRACK) - If _no_ Proxy-Supported (s100rel), but a Supported (s100rel) and _no_ Require (s100rel) are present, then either use 100rel or send it unreliable (as appropriate; decision by the UAS). Hope this makes things clear...:) >Regards, > >Christer Holmberg >Ericsson Finland cheers, Bernie _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 13:00:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05974 for ; Mon, 23 Jul 2001 13:00:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05011; Mon, 23 Jul 2001 12:31:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04982 for ; Mon, 23 Jul 2001 12:31:27 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04287 for ; Mon, 23 Jul 2001 12:30:30 -0400 (EDT) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Jul 2001 19:16:30 +0300 Message-ID: From: Itamar Gilad To: "'SIP list'" , "'rsparks@dynamicsoft.com'" Date: Mon, 23 Jul 2001 19:16:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Comment on draft-sip-refer-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, draft-sip-refer-00 contains the following example for Refer-To: Refer-To: sip:bob@biloxi.com?Accept-Contact=sip:bobsdesk. biloxi.com&Call-ID=55432@alicepc.atlanta.com but this is not a legal SIP URL according to bis-03 - an hvalue (part of header) can't have a '@' in it. Regards, Itamar Gilad RADVISION itamarg@radvision.com 24 Raul Wallenberg St. tel: +972 3 7659938 Building D mob: +972 56 429938 Tel-Aviv 69719 fax: +972 3 6472637 Israel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 23 16:29:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21567 for ; Mon, 23 Jul 2001 16:29:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11240; Mon, 23 Jul 2001 15:54:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11213 for ; Mon, 23 Jul 2001 15:54:40 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19465 for ; Mon, 23 Jul 2001 15:53:45 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6NJs6518465; Mon, 23 Jul 2001 15:54:06 -0400 (EDT) Received: from cisco.com (dhcp-64-102-97-124.cisco.com [64.102.97.124]) by dingdong.cisco.com (Mirapoint) with ESMTP id AFK03711 (AUTH ssh); Mon, 23 Jul 2001 15:54:10 -0400 (EDT) Message-ID: <3B5C81F1.6030408@cisco.com> Date: Mon, 23 Jul 2001 15:58:41 -0400 From: Suheel Hussain Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Billing Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I am looking for draft/information regarding billing operation in SIP; and how it works with PSTN's billing. I would appreciate your help. Thanks -- Suheel Hussain ssh@cisco.com Cisco Work # (919) 392-2312 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 03:03:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02758 for ; Tue, 24 Jul 2001 03:03:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04407; Tue, 24 Jul 2001 01:45:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04378 for ; Tue, 24 Jul 2001 01:45:05 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18021 for ; Tue, 24 Jul 2001 01:44:10 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6O5j6O23011; Tue, 24 Jul 2001 07:45:06 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6O5j5509689; Tue, 24 Jul 2001 08:45:05 +0300 (EET DST) Message-ID: <3B5D0B5D.A61F5B02@lmf.ericsson.se> Date: Tue, 24 Jul 2001 08:45:01 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: bernhard.honeisen@nokia.com CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt References: <034272783A93C944A6CA1D87FBF6F49E08BB13@esebe014.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------85ACBD35F8C29E65CD823F03" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------85ACBD35F8C29E65CD823F03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Bernhard, >>I'm the first to admit (I've mentioned it before) that the PRACK >>mechanism is very "heavy", and what you propose has been discussed >>before (I think I was even one of those who proposed it back then...), >>but the argument against it was that it is against the SIP semantics, >>since ACK is the ONLY method which is sent without a response - and I >>think that makes very much sense. >> >>So, while we can (and we SHALL) come up with new cool features for SIP, >>we should avoid touching the protocol core. In this case we would have >>to change the semantics of a SIP transaction, since the bis specifies >>how INVITEs are handled, how ACKs are handled, and how ALL >>OTHER methods (standard- or extension methods) should be handled - ie we >>would have to change the bis too. Do we want to do that? > >This I-D does _not_ intend to change the core specs; meaning, that it is an >extension mechanism, which can be used only if all intermediate proxy >servers (and the UAs) do understand the feature. If this is the case, they >shall treat SPRACK similar than ACK. > >Or do you mean, that the RFC2543bis specs strictly forbids such kind of >extensions, although it is technically feasible and backwards compatible? Well, I guess it's a question of definitions here. The core spec does define a SIP transaction, also for extension methods. One could argue that an extension is allowed to change that, since it doesn't matter as long as every node understand the extension. BUT - then we may end up in a situation when people start changing other things in the core too. At the end we may even end up having completely different protocols (well, I know it sounds a little dramatic, but you get the point, right? :) One of the nice (maybe the nicest) feature of SIP is that it allows us to define extensions, without changing the core, and if a node doesn't understand the extension it simply ignores it. Ie, I can define how many new methods I want, how many new headers I want, and how many new option tags I want, without touching the core - as long as I define them according to what the core says. Of course some extensions require support from the other nodes, but again, that is not a problem as long as I use the mechanisms defined in the core. The problem here is that first came SIP, then came the need for being able to acknowledge provisional responses... :) So, I think that many people agree (at least I do :) that PRACK is not the nicest, best and far from the most efficient way to do it, but unfortunately it's the only way SIP allows us to do it. >What is the opinion of the authors of RFC2543bis concerning this? > >>Also, lately we've also seen that PRACK probably will be used for more >>than just acking a provisional response. The COMET draft shows one >>example, and Jonathan also gave a very interesting proposal to >>solve the early media issue using PRACK. > >Does the 200 OK of PRACK carry some relevant information in these cases? >If yes, the PRACK might be more appropriate for these cases. I would say that in most cases, especially when it's used only to acknowledge a 1xx response, it does carry any relevant information. I don't think the question is about if SPRACK could be used instead of PRACK. In many cases I think it could, and what you propose has been discussed before. The issue is the core protocol. > >These were only my personal opinions, though... > > > >I also have a few questions on the text in the draft. > > > >6.2. UAS Behavior > > > >The third chapter says: > > >>"If the request did not include a Proxy-Supported header >>indicating this >>feature is understood by every record-route proxy, but it included a >>Supported or a Require header indicating this feature, the UAS either >>SHOULD send the provisional response using the reliability mechanism >>defined in [6] or it SHOULD send the provisional response unreliably." >> >>Q1: You have a "SHOULD-OR-SHOULD" statement here. I think that >>SHOULD as such confuses people enough, but now I'm really lost... :) >> >>Q2: You write that if SPRACK can't be used, the UAS SHOULD send the >>provisional response using the mechanism defined in [6] (the PRACK >>method). To me this indicates that the UAS also SHOULD support the >>mechanism defined in [6]... > >It seems, that the relationship between s100rel and 100rel needs some more >general explanations and the referred section some refinement. Thanks for >your feedback. > >I try to explain here what is meant: > >- The s100rel package contains somehow the capabilities of the 100rel >package. Whenever a response is to be sent reliably and s100rel can be used, >then use s100rel (SPRACK); otherwise use 100rel (PRACK) - >- If _no_ Proxy-Supported (s100rel), but a Require (s100rel) are present , >then use always 100rel (i.e. response contains "Require: 100rel" and is >acknowledged by PRACK) > >- If _no_ Proxy-Supported (s100rel), but a Supported (s100rel) and _no_ >Require (s100rel) are present, then either use 100rel or send it unreliable >(as appropriate; decision by the UAS). That is how I understood it too, but it was the relationship that confused me a little. IF we are going to use SPRACK, I think the whole mechanism about reliability of provisional responses has to be re-designed, because like was said earlier: in many cases there is no idea to even implement PRACK if SPRACK is used. Another question about the draft: What if we use a default outbound server, which does NOT record-route? How do we know if it supports SPRACK? I don't think one can always "assume" it does. Regards, Christer Holmberg Ericsson Finland > Hope this makes things clear...:) > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > cheers, > Bernie --------------85ACBD35F8C29E65CD823F03 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------85ACBD35F8C29E65CD823F03-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 04:39:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03996 for ; Tue, 24 Jul 2001 04:39:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06918; Tue, 24 Jul 2001 03:32:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06892 for ; Tue, 24 Jul 2001 03:32:53 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03170 for ; Tue, 24 Jul 2001 03:31:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6O7WMki028676 for ; Tue, 24 Jul 2001 03:32:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 03:32:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Tue, 24 Jul 2001 03:32:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-04 available! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I have submitted an updated version of the bis specification, draft-ietf-sip-rfc2543bis-04. This should appear in the archives later this week. In the meantime, you can pick up a copy from: http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.ps http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.pdf Some people complained about difficulties downloading the PDF version from the site, so I have also left a copy at: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.pdf http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.ps http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.txt The changes between bis-03 and bis-04 are a collection of mostly minor stuff, detailed in Appendix J. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 04:45:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03999 for ; Tue, 24 Jul 2001 04:39:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07298; Tue, 24 Jul 2001 03:53:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07267 for ; Tue, 24 Jul 2001 03:53:08 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03390 for ; Tue, 24 Jul 2001 03:52:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6O7oqki028688 for ; Tue, 24 Jul 2001 03:50:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 03:51:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Tue, 24 Jul 2001 03:51:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] update to nat traversal draft! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I've submitted an update to draft-rosenberg-sip-entfw, which discusses traversal of SIP through enterprise and residential nats. There are a LOT of differences between this version (-02) and the previous. Specifically: 1. SIP "via port" parameter defined to allow SIP-UDP traversal 2. Translate header replaces Contact cookie 3. NAT detection and allocation protocol is defined, and used between the UA and some elements deployed in the SIP provider network. This is effectively midcom without midcom compliant nats. It vastly simplifies things and also solves the case where both sides are behind a symmetric nat. 4. lots more Until the draft appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 05:13:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04536 for ; Tue, 24 Jul 2001 05:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07402; Tue, 24 Jul 2001 03:56:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07375 for ; Tue, 24 Jul 2001 03:56:35 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03415 for ; Tue, 24 Jul 2001 03:55:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6O7u2ki028703 for ; Tue, 24 Jul 2001 03:56:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 03:56:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Tue, 24 Jul 2001 03:56:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] update to session timer available! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I've submitted an update to draft-ietf-sip-session-timer. This version is substantially different from the previous. As discussed on the list, I've added the Minimum-Timer header (called Min-SE), and also took Brett's suggestion to define a refresher parameter to session expires, in order to avoid overloading Require/Supported to figure out who is refreshing the session. This made things a whole lot simpler, I think. Until the draft appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-05.txt There are still some open issues. The main one is whether or not we want to remove the usage of absolute times in Session-Expires, since they always need to be converted to delta-times anyway. Comments on that? Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 06:33:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06750 for ; Tue, 24 Jul 2001 06:33:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11124; Tue, 24 Jul 2001 06:16:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11095 for ; Tue, 24 Jul 2001 06:16:31 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05547 for ; Tue, 24 Jul 2001 06:15:32 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 03:16:07 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! Date: Tue, 24 Jul 2001 03:15:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, Very interesting draft. I have a couple of comments. It seems that in section 4.2 Contact Translation (and maybe I am being thick...) that the proxy Y is not required to Record-Route the call: "In order for this connection to be used for re-INVITEs or BYEs, the proxy needs to record route." Thus when Joe calls Bob and Proxy Y does not Record-Route then the Joe would send the ACK directly to the Translated Contact in the 200 OK from Bob. However this is not going to work for a symmetric NAT. Shouldn't there be some sort of requirement that Proxy Y must Record-Route unless Bob's NAT is known to be a cone NAT (eg indicated in Translate header)? Am I completely missing something here? Also for the symmetric RTP section: I think would be much more interoperable if we define symmetric RTP as being indicated when transport profile RTP/AVP is used _AND_ the a=direction parameter is present (rather than a new transport profile "RTP/UDP"). In this manner a UA supporting symmetric RTP and a plain vanilla UA can still communicate when NAT is not involved. Obviously it is much cleaner that a separate transport profile is used but I believe it will hamper the deployment of your suggestion. In the above suggestion, a UA not understanding symmetric RTP (ie, not understanding the direction attribute) will setup a call as normal. Additionally, the UA supporting symmetric RTP can detect that the peer does not support the extension by the lack of the a=direction attribute in the SDP answer. Simple! Regards, Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 24, 2001 8:51 AM > To: 'sip@ietf.org' > Subject: [Sip] update to nat traversal draft! > > > Folks, > > I've submitted an update to draft-rosenberg-sip-entfw, which discusses > traversal of SIP through enterprise and residential nats. > There are a LOT of > differences between this version (-02) and the previous. Specifically: > > 1. SIP "via port" parameter defined to allow SIP-UDP traversal > 2. Translate header replaces Contact cookie > 3. NAT detection and allocation protocol is defined, and used > between the UA > and some elements deployed in the SIP provider network. This > is effectively > midcom without midcom compliant nats. It vastly simplifies > things and also > solves the case where both sides are behind a symmetric nat. > 4. lots more > > Until the draft appears in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 07:59:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11541 for ; Tue, 24 Jul 2001 07:59:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14172; Tue, 24 Jul 2001 07:42:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14145 for ; Tue, 24 Jul 2001 07:42:11 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10544 for ; Tue, 24 Jul 2001 07:41:13 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6OBg7N15275 for ; Tue, 24 Jul 2001 13:42:07 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 24 13:42:06 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 13:42:06 +0200 Message-ID: From: "Salvatore Loreto (ERI)" To: "'sip@ietf.org'" Date: Tue, 24 Jul 2001 13:39:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org unscribe _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 08:20:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12601 for ; Tue, 24 Jul 2001 08:20:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14364; Tue, 24 Jul 2001 07:55:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14335 for ; Tue, 24 Jul 2001 07:55:42 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11296 for ; Tue, 24 Jul 2001 07:54:43 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 04:55:17 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! Date: Tue, 24 Jul 2001 04:55:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Perhaps I am misinterpreting the quoted statement (in original email), Jonathan? I think perhaps you might be saying that the proxy Y must always record-route - regardless of whether the proxy wants to be on the call path for re-INVITE's and BYE's. However, there doesn't seem to be any requirement for this when the NAT is known to be of the cone type. Robert. > Hi Jonathan, > > Very interesting draft. > > I have a couple of comments. It seems that in section 4.2 Contact > Translation (and maybe I am being thick...) that the proxy Y > is not required > to Record-Route the call: > > "In order for this connection to be used for re-INVITEs or > BYEs, the > proxy needs to record route." > > Thus when Joe calls Bob and Proxy Y does not Record-Route > then the Joe would > send the ACK directly to the Translated Contact in the 200 OK > from Bob. > However this is not going to work for a symmetric NAT. > Shouldn't there be > some sort of requirement that Proxy Y must Record-Route > unless Bob's NAT is > known to be a cone NAT (eg indicated in Translate header)? Am > I completely > missing something here? > > Also for the symmetric RTP section: I think would be much > more interoperable > if we define symmetric RTP as being indicated when transport > profile RTP/AVP > is used _AND_ the a=direction parameter is present (rather than a new > transport profile "RTP/UDP"). In this manner a UA supporting > symmetric RTP > and a plain vanilla UA can still communicate when NAT is not involved. > Obviously it is much cleaner that a separate transport > profile is used but I > believe it will hamper the deployment of your suggestion. > > In the above suggestion, a UA not understanding symmetric RTP (ie, not > understanding the direction attribute) will setup a call as normal. > Additionally, the UA supporting symmetric RTP can detect that > the peer does > not support the extension by the lack of the a=direction > attribute in the > SDP answer. Simple! > > Regards, > > Robert. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, July 24, 2001 8:51 AM > > To: 'sip@ietf.org' > > Subject: [Sip] update to nat traversal draft! > > > > > > Folks, > > > > I've submitted an update to draft-rosenberg-sip-entfw, > which discusses > > traversal of SIP through enterprise and residential nats. > > There are a LOT of > > differences between this version (-02) and the previous. > Specifically: > > > > 1. SIP "via port" parameter defined to allow SIP-UDP traversal > > 2. Translate header replaces Contact cookie > > 3. NAT detection and allocation protocol is defined, and used > > between the UA > > and some elements deployed in the SIP provider network. This > > is effectively > > midcom without midcom compliant nats. It vastly simplifies > > things and also > > solves the case where both sides are behind a symmetric nat. > > 4. lots more > > > > Until the draft appears in the archives, you can pick up a copy at: > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt > > > > Thanks, > > Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 09:53:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17969 for ; Tue, 24 Jul 2001 09:53:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17784; Tue, 24 Jul 2001 09:30:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17754 for ; Tue, 24 Jul 2001 09:30:31 -0400 (EDT) Received: from packer.effnet.com ([195.100.73.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16684 for ; Tue, 24 Jul 2001 09:29:33 -0400 (EDT) Received: from aniruddha (packer.effnet.com [195.100.73.130]) by packer.effnet.com (8.11.3/8.11.3) with SMTP id f6ODZIB00823; Tue, 24 Jul 2001 15:35:18 +0200 Message-ID: <01ca01c11444$b8191df0$710410ac@effnet.com> From: "Aniruddha Kulkarni" To: , Date: Tue, 24 Jul 2001 15:29:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C7_01C11455.7B3E9840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] SIP Compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01C7_01C11455.7B3E9840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RoHC works hop-to-hop, not end-to-end when there are multiple hops = between two ends. Does SIP Compression mechanisms also have this = constraint? If yes, why? Are those designed to work only on cellular = link between mobile terminal and fixed end of cellular link (hop-to-hop) = ? Why those mechanisms are not designed for end-to-end compression? = (reduce large payloads ,whatever be the link characteristics...) ---Aniruddha=20 =20 ------=_NextPart_000_01C7_01C11455.7B3E9840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RoHC works hop-to-hop, not = end-to-end when=20 there are multiple hops between two ends. Does SIP Compression = mechanisms also=20 have this constraint? If yes, why? Are those designed to work = only on=20 cellular link between mobile terminal and fixed end of cellular link=20 (hop-to-hop) ? Why those mechanisms are not designed for = end-to-end=20 compression? (reduce large payloads ,whatever be the link=20 characteristics...)
 
 
---Aniruddha 
 
 
------=_NextPart_000_01C7_01C11455.7B3E9840-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 12:47:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01148 for ; Tue, 24 Jul 2001 12:47:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23032; Tue, 24 Jul 2001 12:27:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22987 for ; Tue, 24 Jul 2001 12:27:27 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29236 for ; Tue, 24 Jul 2001 12:26:28 -0400 (EDT) From: sean.olson@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6OGRLp16226; Tue, 24 Jul 2001 11:27:21 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6OGRLn20682; Tue, 24 Jul 2001 11:27:21 -0500 (CDT) Received: from e0000865ab2db (pc050200.exu.ericsson.se [138.85.50.200]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA18987; Tue, 24 Jul 2001 11:27:21 -0500 (CDT) Reply-To: To: "'Aniruddha Kulkarni'" , , Subject: RE: [Sip] SIP Compression Date: Tue, 24 Jul 2001 11:27:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <01ca01c11444$b8191df0$710410ac@effnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA22988 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit SIP is not intended to transport large amounts of information. That plus the ratio of bandwidth used by signalling vs. the bandwidth used by the media, means that signalling compression for SIP is not in general a problem. It only really becomes a problem on low bandwidth, high latency *links* such as a cellular link where sometimes every byte counts. In short, I believe signalling compression is a hop-by-hop problem and not an end-to-end one. A hop-by-hop solution seems appropriate in this case. It should also be noted that you can always apply gzip compression to the MIME body of a SIP message to achieve some end-to-end compression. IMHO, this is not needed. I believe the compression techniques that have been described so far (ROGER, SCRIBE, EPIC, etc.) are fairly generic and would work well on a variety of link types. Some have been tailored with cellular in mind. Hopefully this addresses your concerns, Sean Olson Ericsson Inc. -----Original Message----- From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] Sent: Tuesday, July 24, 2001 8:30 AM To: rohc@cdt.luth.se; sip@ietf.org Subject: [Sip] SIP Compression RoHC works hop-to-hop, not end-to-end when there are multiple hops between two ends. Does SIP Compression mechanisms also have this constraint? If yes, why? Are those designed to work only on cellular link between mobile terminal and fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not designed for end-to-end compression? (reduce large payloads ,whatever be the link characteristics...) ---Aniruddha _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 12:51:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01410 for ; Tue, 24 Jul 2001 12:51:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23513; Tue, 24 Jul 2001 12:34:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23486 for ; Tue, 24 Jul 2001 12:34:41 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29762 for ; Tue, 24 Jul 2001 12:33:41 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6OGYw325465 for ; Tue, 24 Jul 2001 19:34:59 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 24 Jul 2001 19:34:39 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV1WM8>; Tue, 24 Jul 2001 19:34:39 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E08BB15@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: christer.holmberg@lmf.ericsson.se Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Date: Tue, 24 Jul 2001 19:34:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer >-----Original Message----- >From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >Sent: 24. July 2001 8:45 >To: bernhard.honeisen@nokia.com >Cc: sip@ietf.org >Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt > > > >Hello Bernhard, > >>>I'm the first to admit (I've mentioned it before) that the PRACK >>>mechanism is very "heavy", and what you propose has been discussed >>>before (I think I was even one of those who proposed it back >then...), >>>but the argument against it was that it is against the SIP semantics, >>>since ACK is the ONLY method which is sent without a response - and I >>>think that makes very much sense. >>> >>>So, while we can (and we SHALL) come up with new cool >features for SIP, >>>we should avoid touching the protocol core. In this case we >would have >>>to change the semantics of a SIP transaction, since the bis specifies >>>how INVITEs are handled, how ACKs are handled, and how ALL >>>OTHER methods (standard- or extension methods) should be >handled - ie we >>>would have to change the bis too. Do we want to do that? >> >>This I-D does _not_ intend to change the core specs; meaning, >that it is an >>extension mechanism, which can be used only if all intermediate proxy >>servers (and the UAs) do understand the feature. If this is >the case, they >>shall treat SPRACK similar than ACK. >> >>Or do you mean, that the RFC2543bis specs strictly forbids >such kind of >>extensions, although it is technically feasible and backwards >compatible? > >Well, I guess it's a question of definitions here. > >The core spec does define a SIP transaction, also for >extension methods. >One could argue that an extension is allowed to change that, since it >doesn't matter as long as every node understand the extension. BUT - >then we may end up in a situation when people start changing other >things in the core too. At the end we may even end up having completely >different protocols (well, I know it sounds a little dramatic, but you >get the point, right? :) > >One of the nice (maybe the nicest) feature of SIP is that it allows us >to define extensions, without changing the core, and if a node doesn't >understand the extension it simply ignores it. Ie, I can >define how many >new methods I want, how many new headers I want, and how many >new option >tags I want, without touching the core - as long as I define them >according to what the core says. Of course some extensions require >support from the other nodes, but again, that is not a problem as long >as I use the mechanisms defined in the core. > >The problem here is that first came SIP, then came the need for being >able to acknowledge provisional responses... :) So, I think that many >people agree (at least I do :) that PRACK is not the nicest, best and >far from the most efficient way to do it, but unfortunately it's the >only way SIP allows us to do it. > >>What is the opinion of the authors of RFC2543bis concerning this? >> >>>Also, lately we've also seen that PRACK probably will be >used for more >>>than just acking a provisional response. The COMET draft shows one >>>example, and Jonathan also gave a very interesting proposal to >>>solve the early media issue using PRACK. >> >>Does the 200 OK of PRACK carry some relevant information in >these cases? >>If yes, the PRACK might be more appropriate for these cases. > >I would say that in most cases, especially when it's used only to >acknowledge a 1xx response, it does carry any relevant information. > >I don't think the question is about if SPRACK could be used instead of >PRACK. In many cases I think it could, and what you propose has been >discussed before. The issue is the core protocol. > > >> >These were only my personal opinions, though... >> > >> >I also have a few questions on the text in the draft. >> > >> >6.2. UAS Behavior >> > >> >The third chapter says: >> > >>>"If the request did not include a Proxy-Supported header >>>indicating this >>>feature is understood by every record-route proxy, but it included a >>>Supported or a Require header indicating this feature, the UAS either >>>SHOULD send the provisional response using the reliability mechanism >>>defined in [6] or it SHOULD send the provisional response >unreliably." >>> >>>Q1: You have a "SHOULD-OR-SHOULD" statement here. I think that >>>SHOULD as such confuses people enough, but now I'm really lost... :) >>> >>>Q2: You write that if SPRACK can't be used, the UAS SHOULD send the >>>provisional response using the mechanism defined in [6] (the PRACK >>>method). To me this indicates that the UAS also SHOULD support the >>>mechanism defined in [6]... >> >>It seems, that the relationship between s100rel and 100rel >needs some more >>general explanations and the referred section some >refinement. Thanks for >>your feedback. >> >>I try to explain here what is meant: >> >>- The s100rel package contains somehow the capabilities of the 100rel >>package. Whenever a response is to be sent reliably and >s100rel can be used, >>then use s100rel (SPRACK); otherwise use 100rel (PRACK) >- >>- If _no_ Proxy-Supported (s100rel), but a Require (s100rel) >are present , >>then use always 100rel (i.e. response contains "Require: >100rel" and is >>acknowledged by PRACK) >> >>- If _no_ Proxy-Supported (s100rel), but a Supported >(s100rel) and _no_ >>Require (s100rel) are present, then either use 100rel or send >it unreliable >>(as appropriate; decision by the UAS). > >That is how I understood it too, but it was the relationship that >confused me a little. IF we are going to use SPRACK, I think the whole >mechanism about reliability of provisional responses has to be >re-designed, because like was said earlier: in many cases there is no >idea to even implement PRACK if SPRACK is used. The idea is a fall-back behavior: In the cases SPRACK is not possible, PRACK can be used; thus the s100rel package contains somehow the 100rel package. >Another question about the draft: What if we use a default outbound >server, which does NOT record-route? How do we know if it supports >SPRACK? I don't think one can always "assume" it does. This case should have been discussed in the I-D. It somehow got forgotten... Thanks for the reminder. The principle idea for this case is, that whoever uses an outbound proxy MUST know about its support of the s100rel. Otherwise s100rel MUST NOT be used. br, Bernie >Regards, > >Christer Holmberg >Ericsson Finland > > > > > > >> Hope this makes things clear...:) >> >> >Regards, >> > >> >Christer Holmberg >> >Ericsson Finland >> >> cheers, >> Bernie > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 12:56:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01943 for ; Tue, 24 Jul 2001 12:56:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23756; Tue, 24 Jul 2001 12:42:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23726 for ; Tue, 24 Jul 2001 12:42:23 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00398 for ; Tue, 24 Jul 2001 12:41:25 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6OFmSi16013 for ; Tue, 24 Jul 2001 10:48:29 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 24 Jul 2001 10:48:24 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 24 Jul 2001 10:48:24 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] SIP Compression Date: Tue, 24 Jul 2001 10:48:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] SIP Compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEURO5f5aSnM4A0EdWrwwAIx6S5QwAEPJjA To: , , X-OriginalArrivalTime: 24 Jul 2001 15:48:24.0350 (UTC) FILETIME=[12857BE0:01C11458] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA23728 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > RoHC works hop-to-hop, not end-to-end when there are multiple > hops between two ends. Does SIP Compression mechanisms also > have this constraint? If yes, why? I don't see the reasons for such constraint. In fact, if encryption is applied end-to-end, per-hop compression is not feasible. See http://www.ietf.org/internet-drafts/draft-le-sigcompr-requirements-00.tx t and http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-01.txt. > Are those designed to work only on cellular link between > mobile terminal and fixed end of cellular link (hop-to-hop)? No. SCRIBE and some of other schemes do not assume hop-to-hop. They can tolerate packet loss, misordering and large round trip time. > Why those mechanisms are not designed for end-to-end > compression? (reduce large payloads ,whatever be the > link characteristics...) I don't know which mechanisms you're referring to. At least SCRIBE can work as end-to-end compression. However, the open issue is whether it is needed in fixed-line network considering the benefit/cost ratio. It is clearly needed over cellular links. Br, Zhigang > ---Aniruddha _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 16:56:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22324 for ; Tue, 24 Jul 2001 16:56:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00064; Tue, 24 Jul 2001 16:09:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00035 for ; Tue, 24 Jul 2001 16:09:00 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17001 for ; Tue, 24 Jul 2001 16:08:02 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA01735; Tue, 24 Jul 2001 20:09:00 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA26145; Tue, 24 Jul 2001 20:09:00 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFW7B5T>; Tue, 24 Jul 2001 14:09:00 -0600 Message-ID: <17052388D394D411803900508BDFFAF6013DCAD3@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] bis-04 available! Date: Tue, 24 Jul 2001 14:08:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, Section 16.3 includes the following updated language in the second paragraph (thanks): The URL SHOULD NOT contain the transport parameter, but can in private networks where it is known that elements on both sides of the proxy support the specific transport. However, the following language in paragraph 4 also needs to be modified so there is no conflict: The proxy MAY modify the Record-Route value matching the one it inserted into the request. Like the URL in the request, it MUST be a SIP URL and MUST NOT contain a transport parameter. I'd also like to note that since the Record-Route may be modified, it is possible the transport could be modified, thus elements on both sides of the proxy may not need to support the specific transport as the first modified language indicates. For example, leave off the transport on the Record-Route of an Invite going into the private network so UDP defaults on the inside, and include transport=tls in the 200 OK's Record-Route when interfacing with another element over an unsecure network. This allows subsequent requests to run over the same secure connection an initial transaction ran over, without requiring the same transport on the other side of the proxy. John -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 24, 2001 1:33 AM To: 'sip@ietf.org' Subject: [Sip] bis-04 available! Folks, I have submitted an updated version of the bis specification, draft-ietf-sip-rfc2543bis-04. This should appear in the archives later this week. In the meantime, you can pick up a copy from: http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.ps http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.pdf Some people complained about difficulties downloading the PDF version from the site, so I have also left a copy at: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.pdf http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.ps http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.txt The changes between bis-03 and bis-04 are a collection of mostly minor stuff, detailed in Appendix J. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 18:19:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27978 for ; Tue, 24 Jul 2001 18:19:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03530; Tue, 24 Jul 2001 18:04:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03499 for ; Tue, 24 Jul 2001 18:04:01 -0400 (EDT) Received: from canospam.agcs.com (canospam.agcs.com [130.131.166.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27274 for ; Tue, 24 Jul 2001 18:03:02 -0400 (EDT) Received: from mkultra (mkultra.agcs.com [130.131.166.68]) by canospam.agcs.com (8.9.3/8.9.1) with SMTP id PAA03616 for ; Tue, 24 Jul 2001 15:04:01 -0700 (MST) Posted-Date: Tue, 24 Jul 2001 15:04:01 -0700 (MST) Received: FROM bootstrap.agcs.com BY mkultra ; Tue Jul 24 15:04:05 2001 -0700 Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id PAA01440 for ; Tue, 24 Jul 2001 15:03:13 -0700 (MST) Received: from agcs.com ([130.131.74.156]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA1B01 for ; Tue, 24 Jul 2001 15:03:59 -0700 Message-ID: <3B5DF0D0.1E90FAAE@agcs.com> Date: Tue, 24 Jul 2001 15:04:00 -0700 From: "Axel Christiansen" Reply-To: christia@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------2486E225B332E5B95140DB89" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------2486E225B332E5B95140DB89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe --------------2486E225B332E5B95140DB89 Content-Type: text/x-vcard; charset=us-ascii; name="christia.vcf" Content-Description: Card for Axel Christiansen Content-Disposition: attachment; filename="christia.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Christiansen;Axel tel;work:(623) 582-7718 x-mozilla-html:FALSE url:http://wwwagcs.com:8080 org:;Business Marketing adr:;;2500 West Utopia Road;Phoenix;Arizona;85027; version:2.1 email;internet:christia@agcs.com title:Senior Engineer fn:Axel Christiansen end:vcard --------------2486E225B332E5B95140DB89-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 18:34:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28750 for ; Tue, 24 Jul 2001 18:34:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03674; Tue, 24 Jul 2001 18:08:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03644 for ; Tue, 24 Jul 2001 18:08:22 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27483 for ; Tue, 24 Jul 2001 18:07:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6OM7hki002398; Tue, 24 Jul 2001 18:07:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:08:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Date: Tue, 24 Jul 2001 18:08:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, July 23, 2001 7:14 AM > To: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt > > > > Hi, > > I'm the first to admit (I've mentioned it before) that the PRACK > mechanism is very "heavy", and what you propose has been discussed > before (I think I was even one of those who proposed it back then...), > but the argument against it was that it is against the SIP semantics, > since ACK is the ONLY method which is sent without a response - and I > think that makes very much sense. > > So, while we can (and we SHALL) come up with new cool > features for SIP, > we should avoid touching the protocol core. In this case we would have > to change the semantics of a SIP transaction, since the bis specifies > how INVITEs are handled, how ACKs are handled, and how ALL > OTHER methods > (standard- or extension methods) should be handled - ie we > would have to > change the bis too. Do we want to do that? No, we don't. I think this approach is a bad idea. It has been discussed and discarded at least twice so far on the lists. Maybe third time is the charm. WHy is it really bad? Well, draft-ietf-sip-guidelines clearly describes why. THe extension mandates Proxy-Require *and* Require. According to the guidelines draft: The Proxy-Require header SHOULD be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. This means that you are going to have an exponentially increasing probability of needing to fallback to the normal PRACK behavior, and the resulting cost is that these cell phones, whom you are trying to serve, now need to implement two already-complex specifications. Now, if I ignore the fact that this extension is effectively not backwards compatible with SIP, there is another problem, which is that it really doesn't achieve any useful results. The supposed goal, as outlined in the introduction, is: The motivation for defining an alternative approach to [6] is that certain networks, e.g. cellular networks, have limited bandwidth for signalling purposes. Thus every extra message in the session initiation increases the duration of the session setup, which might cause that the session setup delay crosses the acceptable limit. This makes no sense to me. I'm assuming that the reliable provisional responses are being used to acknowledge the 1xx used for manyfolks. Once the provisional response is received, resource resveration can happen in PARALLEL with the transmission of PRACK/200, and the final response to the INVITE can also happen in parallel to that. So, call setup time is not affected. Perhaps you are concerned about overhead on the wireless link. In terms of byte savings, using something like the ROGER protocol or my UDP compression proposal, http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt, you get far, far, far better compression gains than the improvements afforded from eliminating this message. So, the SPRACK proposal: 1. necessitates Proxy-Require, which is an effective break in compatibility with the SIP protocol, 2. doesn't really help call setup times for the manyfolks flows 3. provides tiny compression compared with other alternatives. So, I do not understand why this is a good path to follow. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 18:37:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28899 for ; Tue, 24 Jul 2001 18:36:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03768; Tue, 24 Jul 2001 18:13:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03738 for ; Tue, 24 Jul 2001 18:13:17 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27683 for ; Tue, 24 Jul 2001 18:12:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6OMCYki002434; Tue, 24 Jul 2001 18:12:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:13:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Thomas'" Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] New I-D on compression of SIP Date: Tue, 24 Jul 2001 18:13:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Saturday, July 21, 2001 12:18 PM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [Sip] New I-D on compression of SIP > > > > Jonathan Rosenberg writes: > > Folks, > > > > I've just submitted a new I-D on compression of SIP > messages, particularly > > for wireless links. Until the draft appears in the > archives, you can pick up > > a copy at: > > Jonathan, > > To follow up on my passing comments, it should be > noted that IPsec already has compression > transforms which work in combination with > encryption/message integrity. I'm not sure if TLS > has this capability, but I wouldn't be surprised > (nor do I think it would be hard to add if > not). Thus, there's at least some amount of wheel > reinvention going on here. I believe that the IPSec compression mechanisms apply to each packet independently. That is, there is no carryover of compression context from one IP packet to the next. The problem is that a single SIP message only compresses a little (maybe 2:1), but when you take advantage of previous messages to build a compression context, it can be much, much bigger. Thats the idea behind my draft, and also the others in the ROHC group - ROGER, SCRIBE. So, I don't see them as solving the same problem. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 18:50:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29659 for ; Tue, 24 Jul 2001 18:50:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03920; Tue, 24 Jul 2001 18:19:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03889 for ; Tue, 24 Jul 2001 18:19:04 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27895 for ; Tue, 24 Jul 2001 18:18:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6OMIQki002458; Tue, 24 Jul 2001 18:18:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:18:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michel de Boer'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] New I-D on compression of SIP Date: Tue, 24 Jul 2001 18:18:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Michel de Boer [mailto:michelboer@lucent.com] > Sent: Thursday, July 19, 2001 3:54 AM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: Re: [Sip] New I-D on compression of SIP > > > Jonathan, > > You state that one of the ways to achieve message size reduction is to > define a binary encoding, but that this introduces interoperability > problems. > > How can a compression scheme based on dynamically constructed > codebooks > be simpler? Simpler, perhaps not (although if you're using PER or BER, its not clear to me that this is simpler, codewise). But, it totally breaks compatibility with the existing protocol. By pushing this into a transport problem, it is isolated to the two entities that need to worry about it. > In my opinion this approach is more prone to > interoperability > issues. Thats not clear at all. Either way, we would require new code in implementations. For a new binary coding, we would be back to square 1, so that everyone would have to work out the kinks in their encoder/decoders for every element in the syntax. However, with a shim, we leverage existing, mature parsers and generators. We add a layer that is not specific to SIP, so it has no syntax or anything else to get wrong. Its defined by a fairly simple set of state machines, which should not be that hard to get correct. I would argue its easier to get that right than it is to get a totally new encoding of SIP right. > Codebooks can get out of sync. Yes, and that does need to be handled in the protocol. > As codebooks are specific to a sender- > receiver pair, an entity communicating with multiple other > entities, i.e. > a proxy talking to many UA's must manage multiple codebooks. Well, the problem at hand is really a wireless phone talking to its local outbound proxy. THus, the phone has only one relationship, and the proxy has one with each phone it communicates with. This pushes the burden of compression to the elements that benefit the most from it. From this point onwards, normal SIP would be used, and so its compatible with existing proxies and UAs. > > For trouble shooting one might want to monitor a network interface and > analyze SIP messages coming in. It's impossible to read a compressed > message. The output of the decompressor would need to be monitored. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 24 23:15:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09761 for ; Tue, 24 Jul 2001 23:15:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09347; Tue, 24 Jul 2001 22:48:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09320 for ; Tue, 24 Jul 2001 22:48:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09165 for ; Tue, 24 Jul 2001 22:47:15 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6P2lYg19821; Tue, 24 Jul 2001 19:47:35 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW00484; Tue, 24 Jul 2001 19:47:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA10512; Tue, 24 Jul 2001 19:47:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15198.13121.697673.515860@thomasm-u1.cisco.com> Date: Tue, 24 Jul 2001 19:47:29 -0700 (PDT) To: Jonathan Rosenberg Cc: "'Michael Thomas'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] New I-D on compression of SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I believe that the IPSec compression mechanisms apply to each packet > independently. That is, there is no carryover of compression context from > one IP packet to the next. The problem is that a single SIP message only > compresses a little (maybe 2:1), but when you take advantage of previous > messages to build a compression context, it can be much, much bigger. Thats > the idea behind my draft, and also the others in the ROHC group - ROGER, > SCRIBE. So, I don't see them as solving the same problem. Hmm. I guess I have to wonder whether the marginal difference is actually worth much over the base Huffman encoding and whatever you manage to eek out with the dictionary across packets. It does come at the expense of quite a bit of extra shared state. If you're sold on that, maybe it would be best of all to just standardize a SIP specific dictionary :-) Not that this actually has much to do with original point... Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 02:06:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29369 for ; Wed, 25 Jul 2001 02:06:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21334; Wed, 25 Jul 2001 01:28:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21304 for ; Wed, 25 Jul 2001 01:28:14 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17730 for ; Wed, 25 Jul 2001 01:27:16 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6P5SDN24637; Wed, 25 Jul 2001 07:28:13 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6P5SD529014; Wed, 25 Jul 2001 08:28:13 +0300 (EET DST) Message-ID: <3B5E58E8.F1F32730@lmf.ericsson.se> Date: Wed, 25 Jul 2001 08:28:08 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: bernhard.honeisen@nokia.com CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt References: <034272783A93C944A6CA1D87FBF6F49E08BB15@esebe014.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------6DF019D0DC4677A1B8C5BE96" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------6DF019D0DC4677A1B8C5BE96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bernie, >>Another question about the draft: What if we use a default outbound >>server, which does NOT record-route? How do we know if it supports >>SPRACK? I don't think one can always "assume" it does. > >This case should have been discussed in the I-D. It somehow got forgotten... >Thanks for the reminder. >The principle idea for this case is, that whoever uses an outbound proxy >MUST know about its support of the s100rel. Otherwise s100rel MUST NOT be >used. I don't think it's a good approach to assume that, and the only time one really could assume that is when the user has control of the outbound proxy. Also, what stops the user from using SPRACK anyway, even if he would know the outbound proxy does NOT support it? The protocol defines ways to find out about the capabilities of nodes, and I think that those methods should be used. Regards, Christer Holmberg Ericsson Finland > > br, > Bernie > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > > > > > > > > > >> Hope this makes things clear...:) > >> > >> >Regards, > >> > > >> >Christer Holmberg > >> >Ericsson Finland > >> > >> cheers, > >> Bernie > > --------------6DF019D0DC4677A1B8C5BE96 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------6DF019D0DC4677A1B8C5BE96-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 04:20:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04373 for ; Wed, 25 Jul 2001 04:20:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23898; Wed, 25 Jul 2001 03:09:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23829 for ; Wed, 25 Jul 2001 03:09:20 -0400 (EDT) Received: from nt-mail.tlv.radvision.com ([212.143.185.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02877 for ; Wed, 25 Jul 2001 03:08:21 -0400 (EDT) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Jul 2001 10:10:04 +0300 Message-ID: From: Itamar Gilad To: "'SIP list'" Date: Wed, 25 Jul 2001 10:10:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Question on record-routing with outbound proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, reading bis-03 16.4.1 raises some questions: "16.4.1 Local outbound proxies Special considerations exist for local outbound proxies. A UA which uses a local outbound proxy will send all requests without Route headers to that proxy. Typically, this includes initial INVITE requests for a call." Q: All requests? Doesn't that break record-routing and contradict the rest of this paragraph? What am I missing? "If a local outbound proxy wishes to remain on the SIP messaging path for a call leg, it MUST record-route using the procedures above. A UA which uses a local outbound proxy, and attempts to send a subsequent request in a call leg with a route set, SHOULD use the procedures in Section 16.4." Q: does that mean circumventing the outbound proxy? It does judging from the next sentence. Using local outbound is the topic of this paragraph so I guess this sentence is redundant. "However, in some instances, a UA may not be capable of DNS, and therefore may not be able to follow those procedures. In this case, the UA MAY send the request to its local outbound proxy." In this case, it MUST NOT remove the top Route header. It sets the Request-URI to the same value it used for the initial request, and sends it to its local outbound proxy." Q: how is a UA (especially one lacking DNS capabilities) supposed to know that its outbound proxy is record-routing? The proxy may use in the Record-Route header a different address than the one the UA knows it by. Thanks, Itamar Gilad RADVISION itamarg@radvision.com 24 Raul Wallenberg St. tel: +972 3 7659938 Building D mob: +972 56 429938 Tel-Aviv 69719 fax: +972 3 6472637 Israel _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 05:18:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05641 for ; Wed, 25 Jul 2001 05:18:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26210; Wed, 25 Jul 2001 04:54:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26179 for ; Wed, 25 Jul 2001 04:54:07 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04940 for ; Wed, 25 Jul 2001 04:53:05 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 09:53:09 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DF2@RSYS002A> From: "Price, Richard" To: "'Michael Thomas'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 09:53:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Interesting. Any idea what kind of compression ratio we need to aim for, so that we know how complicated we need to make the solution? Regards, Richard P -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, July 25, 2001 3:47 AM To: Jonathan Rosenberg Cc: 'Michael Thomas'; 'sip@ietf.org'; 'rohc@cdt.luth.se' Subject: [rohc] RE: [Sip] New I-D on compression of SIP Jonathan Rosenberg writes: > I believe that the IPSec compression mechanisms apply to each packet > independently. That is, there is no carryover of compression context from > one IP packet to the next. The problem is that a single SIP message only > compresses a little (maybe 2:1), but when you take advantage of previous > messages to build a compression context, it can be much, much bigger. Thats > the idea behind my draft, and also the others in the ROHC group - ROGER, > SCRIBE. So, I don't see them as solving the same problem. Hmm. I guess I have to wonder whether the marginal difference is actually worth much over the base Huffman encoding and whatever you manage to eek out with the dictionary across packets. It does come at the expense of quite a bit of extra shared state. If you're sold on that, maybe it would be best of all to just standardize a SIP specific dictionary :-) Not that this actually has much to do with original point... Mike --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 05:19:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05652 for ; Wed, 25 Jul 2001 05:19:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25454; Wed, 25 Jul 2001 04:20:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25428 for ; Wed, 25 Jul 2001 04:20:20 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04342 for ; Wed, 25 Jul 2001 04:19:20 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6P8KIO26135; Wed, 25 Jul 2001 10:20:18 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6P8KH502919; Wed, 25 Jul 2001 11:20:17 +0300 (EET DST) Message-ID: <3B5E813C.5046A998@lmf.ericsson.se> Date: Wed, 25 Jul 2001 11:20:12 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad CC: "'SIP list'" Subject: Re: [Sip] Question on record-routing with outbound proxy References: Content-Type: multipart/mixed; boundary="------------64DD068614B6AE1903B1EEFB" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------64DD068614B6AE1903B1EEFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Itamar, A comment, and related question, to your first question: >reading bis-03 16.4.1 raises some questions: > >"16.4.1 Local outbound proxies >Special considerations exist for local outbound proxies. >A UA which uses a local outbound proxy will send all requests without Route >headers to that proxy. Typically, this includes initial INVITE requests for >a call." > >Q: All requests? Doesn't that break record-routing and contradict the rest >of this paragraph? What am I missing? Like you wrote, the text says "all requests WITHOUT Route", ie no proxy has inserted Record-Route. I do have a question related to this, though: Assume that a remote party sends an INVITE to my client. There are no proxies in the path, so there will be no Record-Route. There is, of course, the mandatory Contact header. Then my client answers, and receives ACK. Nothing strange so far. Later, my client wants to release the call, so it sends a BYE. My client is configured to use an outbound proxy, so: Q: Since there is no Route, shall it send the BYE to the outbound proxy, or directly to the remote client (defined in the Contact my client received in the INVITE)? Q: My understanding of the text is that the BYE should send it to the outbound proxy. Could someone confirm that? Q: Also, could this cause some problem if the outbound proxy is stateful, since it will receive a BYE it never received an INVITE for? Regards, Christer Holmberg Ericsson Finland >"If a local outbound proxy wishes to remain on the SIP messaging path for a >call leg, it MUST record-route using the procedures above. >A UA which uses a local outbound proxy, and attempts to send a subsequent >request in a call leg with a route set, SHOULD use the procedures in Section >16.4." > >Q: does that mean circumventing the outbound proxy? It does judging from the >next sentence. Using local outbound is the topic of this paragraph so I >guess this sentence is redundant. > > "However, in some instances, a UA may not be capable of DNS, and therefore > may not be able to follow those procedures. In this case, the UA MAY send > the request to its local outbound proxy." > In this case, it MUST NOT remove the top Route header. It sets the > Request-URI to the same value it used for the initial request, and sends it > to its local outbound proxy." > > Q: how is a UA (especially one lacking DNS capabilities) supposed to know > that its outbound proxy is record-routing? The proxy may use in the > Record-Route header a different address than the one the UA knows it by. > > Thanks, > > Itamar Gilad > RADVISION > itamarg@radvision.com 24 Raul Wallenberg St. > tel: +972 3 7659938 Building D > mob: +972 56 429938 Tel-Aviv 69719 > fax: +972 3 6472637 Israel > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------64DD068614B6AE1903B1EEFB Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------64DD068614B6AE1903B1EEFB-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09989 for ; Wed, 25 Jul 2001 07:13:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29058; Wed, 25 Jul 2001 06:41:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29030 for ; Wed, 25 Jul 2001 06:41:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08381; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Message-Id: <200107251040.GAA08381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:42 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-isup-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : ISUP to SIP Mapping Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong Filename : draft-ietf-sip-isup-02.txt Pages : 54 Date : 24-Jul-01 This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the ISDN User Part (ISUP) of SS7. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-02.txt 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-isup-02.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-isup-02.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: <20010724132829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10002 for ; Wed, 25 Jul 2001 07:13:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28714; Wed, 25 Jul 2001 06:34:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28686 for ; Wed, 25 Jul 2001 06:34:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07556; Wed, 25 Jul 2001 06:33:24 -0400 (EDT) Message-Id: <200107251033.GAA07556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:33:24 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-conferencing-models-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Models for Multi Party Conferencing in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-conferencing-models-01.txt Pages : 26 Date : 24-Jul-01 The Session Initiation Protocol (SIP) can support multi-party conferencing in many different ways. In this draft, we define the various multi-party conferencing models, and for each, discuss how they are used and then analyze their relative benefits and drawbacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt 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-rosenberg-sip-conferencing-models-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-conferencing-models-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132327.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10015 for ; Wed, 25 Jul 2001 07:13:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29097; Wed, 25 Jul 2001 06:41:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29070 for ; Wed, 25 Jul 2001 06:41:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08401; Wed, 25 Jul 2001 06:40:48 -0400 (EDT) Message-Id: <200107251040.GAA08401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:47 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-05.txt Pages : 28 Date : 24-Jul-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-05.txt 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-session-timer-05.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-session-timer-05.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: <20010724132840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10013 for ; Wed, 25 Jul 2001 07:13:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29141; Wed, 25 Jul 2001 06:41:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29113 for ; Wed, 25 Jul 2001 06:41:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08414; Wed, 25 Jul 2001 06:40:54 -0400 (EDT) Message-Id: <200107251040.GAA08414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:53 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-04.txt,.ps Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-04.txt,.ps Pages : 195 Date : 24-Jul-01 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-04.txt 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-rfc2543bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10035 for ; Wed, 25 Jul 2001 07:13:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28767; Wed, 25 Jul 2001 06:35:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28737 for ; Wed, 25 Jul 2001 06:35:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07687; Wed, 25 Jul 2001 06:34:39 -0400 (EDT) Message-Id: <200107251034.GAA07687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:34:38 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-entfw-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Friendly SIP Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-02.txt Pages : 32 Date : 24-Jul-01 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt 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-rosenberg-sip-entfw-02.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-rosenberg-sip-entfw-02.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: <20010724132442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-entfw-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 07:13:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10046 for ; Wed, 25 Jul 2001 07:13:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29191; Wed, 25 Jul 2001 06:42:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29156 for ; Wed, 25 Jul 2001 06:41:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08430; Wed, 25 Jul 2001 06:40:59 -0400 (EDT) Message-Id: <200107251040.GAA08430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:59 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-serverfeatures-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : The SIP Supported Header Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-serverfeatures-05.txt Pages : 8 Date : 24-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a client to request that a particular protocol extension be used to process the request. The server declines the request if it does not support the extension. However, there is currently no way for a server to determine which extensions are supported by the client. Knowing about client-supported extensions allows the server to tailor its response accordingly. Furthermore, SIP does not define a way for a client to query a server about the extensions it supports. This document defines a SIP extension that allows clients to indicate, in a request, the set of extensions supported. We also define a mechanism that allows clients, through an OPTIONS request, to determine the extensions supported by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-05.txt 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-serverfeatures-05.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-serverfeatures-05.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: <20010724132900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 08:38:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16134 for ; Wed, 25 Jul 2001 08:38:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01057; Wed, 25 Jul 2001 07:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01027 for ; Wed, 25 Jul 2001 07:45:29 -0400 (EDT) Received: from packer.effnet.com ([195.100.73.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12046 for ; Wed, 25 Jul 2001 07:44:30 -0400 (EDT) Received: from aniruddha (packer.effnet.com [195.100.73.130]) by packer.effnet.com (8.11.3/8.11.3) with SMTP id f6PBo3B12711; Wed, 25 Jul 2001 13:50:03 +0200 Message-ID: <023e01c114ff$31341f40$710410ac@effnet.com> From: "Aniruddha Kulkarni" To: , , References: Subject: Re: [Sip] SIP Compression Date: Wed, 25 Jul 2001 13:44:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If one has high latency link then nothing can be done about it. Compression is not a solution for that. If one has low bandwidth link and large data to send then Compression can be the solution. SIP messages take up only small portion of the available bandwidth (even on Cellular links..). Then why use compression for SIP messages? Well.. cellular links have high BER, in this situation it is advisable to have smaller packets to reduce error probability.. that is why use compression. .. correct? Still large number of connections to internet are over telephone modem links with low bandwidth, comparable with latest cellular links. Isn't it useful to have end-to-end SIP message compression in that situation? How much the SIP compression schemes are dependant on RoHC? Could they have in-built mechanism for configuration negotiation? Should they demand this facility from lower layers? It seems to me that these schemes work more at application level and should have configuration negotiation at that level only. That way they could be easily extened for use on end-to-end rather than limiting them to hop-to-hop (by depending on RoHC). ---Aniruddha ----- Original Message ----- From: To: "'Aniruddha Kulkarni'" ; ; Sent: Tuesday, July 24, 2001 6:27 PM Subject: RE: [Sip] SIP Compression > SIP is not intended to transport large amounts of information. > That plus the ratio of bandwidth used by signalling vs. > the bandwidth used by the media, means that signalling compression > for SIP is not in general a problem. It only really becomes a > problem on low bandwidth, high latency *links* such as a cellular > link where sometimes every byte counts. > > In short, I believe signalling compression is a hop-by-hop > problem and not an end-to-end one. A hop-by-hop solution seems > appropriate in this case. > > It should also be noted that you can always apply gzip compression > to the MIME body of a SIP message to achieve some end-to-end > compression. IMHO, this is not needed. > > I believe the compression techniques that have been > described so far (ROGER, SCRIBE, EPIC, etc.) are > fairly generic and would work well on a variety of > link types. Some have been tailored with cellular > in mind. > > Hopefully this addresses your concerns, > Sean Olson > Ericsson Inc. > > -----Original Message----- > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > Sent: Tuesday, July 24, 2001 8:30 AM > To: rohc@cdt.luth.se; sip@ietf.org > Subject: [Sip] SIP Compression > > RoHC works hop-to-hop, not end-to-end when there are multiple hops between two ends. > Does SIP Compression mechanisms also have this constraint? If yes, why? > Are those designed to work only on cellular link between mobile terminal and > fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not designed > for end-to-end compression? > (reduce large payloads ,whatever be the link characteristics...) > > ---Aniruddha > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 09:32:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20733 for ; Wed, 25 Jul 2001 09:32:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02856; Wed, 25 Jul 2001 08:42:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02775 for ; Wed, 25 Jul 2001 08:42:34 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16533 for ; Wed, 25 Jul 2001 08:41:34 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6PCfC511228; Wed, 25 Jul 2001 08:41:12 -0400 (EDT) Received: from cisco.com (ssh-dsl3.cisco.com [10.83.2.76]) by dingdong.cisco.com (Mirapoint) with ESMTP id AFK41118; Wed, 25 Jul 2001 08:41:16 -0400 (EDT) Message-ID: <3B5EBF7B.4010508@cisco.com> Date: Wed, 25 Jul 2001 08:45:47 -0400 From: Suheel Hussain Organization: Cisco System User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: Aniruddha Kulkarni CC: sean.olson@ericsson.com, rohc@cdt.luth.se, sip@ietf.org Subject: Re: [Sip] SIP Compression References: <023e01c114ff$31341f40$710410ac@effnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have nagging issue with SIP compression -- compressing and decompressing on each proxy server is going to slow down call processing on large networks. IMO, it (compression) is not scalable. Even end-to-end can be a problem if either (or both) UAS and UAC service a number of attached SIP-unaware systems. For instance a SIP-PSTN gateway. Aniruddha Kulkarni wrote: > If one has high latency link then nothing can be done about it. Compression > is not a solution for that. > If one has low bandwidth link and large data to send then Compression can be > the solution. > SIP messages take up only small portion of the available bandwidth (even on > Cellular links..). Then why use compression for SIP messages? Well.. > cellular links have high BER, in this situation it is advisable to have > smaller packets to reduce error probability.. that is why use compression. > ... correct? > > Still large number of connections to internet are over telephone modem links > with low bandwidth, comparable with latest cellular links. Isn't it useful > to have end-to-end SIP message compression in that situation? > > How much the SIP compression schemes are dependant on RoHC? Could they have > in-built mechanism for configuration negotiation? Should they demand this > facility from lower layers? It seems to me that these schemes work more at > application level and should have configuration negotiation at that level > only. That way they could be easily extened for use on end-to-end rather > than limiting them to hop-to-hop (by depending on RoHC). > > ---Aniruddha > > ----- Original Message ----- > From: > To: "'Aniruddha Kulkarni'" ; > ; > Sent: Tuesday, July 24, 2001 6:27 PM > Subject: RE: [Sip] SIP Compression > > > >> SIP is not intended to transport large amounts of information. >> That plus the ratio of bandwidth used by signalling vs. >> the bandwidth used by the media, means that signalling compression >> for SIP is not in general a problem. It only really becomes a >> problem on low bandwidth, high latency *links* such as a cellular >> link where sometimes every byte counts. >> >> In short, I believe signalling compression is a hop-by-hop >> problem and not an end-to-end one. A hop-by-hop solution seems >> appropriate in this case. >> >> It should also be noted that you can always apply gzip compression >> to the MIME body of a SIP message to achieve some end-to-end >> compression. IMHO, this is not needed. >> >> I believe the compression techniques that have been >> described so far (ROGER, SCRIBE, EPIC, etc.) are >> fairly generic and would work well on a variety of >> link types. Some have been tailored with cellular >> in mind. >> >> Hopefully this addresses your concerns, >> Sean Olson >> Ericsson Inc. >> >> -----Original Message----- >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] >> Sent: Tuesday, July 24, 2001 8:30 AM >> To: rohc@cdt.luth.se; sip@ietf.org >> Subject: [Sip] SIP Compression >> >> RoHC works hop-to-hop, not end-to-end when there are multiple hops between > > two ends. > >> Does SIP Compression mechanisms also have this constraint? If yes, why? >> Are those designed to work only on cellular link between mobile terminal > > and > >> fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not > > designed > >> for end-to-end compression? >> (reduce large payloads ,whatever be the link characteristics...) >> >> ---Aniruddha >> > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Suheel Hussain ssh@cisco.com Cisco Work # (919) 392-2312 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 11:00:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28504 for ; Wed, 25 Jul 2001 11:00:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06027; Wed, 25 Jul 2001 10:27:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05998 for ; Wed, 25 Jul 2001 10:27:00 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25070 for ; Wed, 25 Jul 2001 10:25:59 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PERG301839 for ; Wed, 25 Jul 2001 17:27:16 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 17:26:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVF3LD>; Wed, 25 Jul 2001 17:26:56 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E107EAE@esebe014.NOE.Nokia.com> To: ssh@cisco.com, aniruddha.kulkarni@effnet.com Cc: sean.olson@ericsson.com, rohc@cdt.luth.se, sip@ietf.org Subject: RE: [Sip] SIP Compression Date: Wed, 25 Jul 2001 17:26:42 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, > -----Original Message----- > From: ext Suheel Hussain [mailto:ssh@cisco.com] > Sent: 25 July, 2001 15:46 > To: Aniruddha Kulkarni > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > Subject: Re: [Sip] SIP Compression > > > I have nagging issue with SIP compression -- compressing and > decompressing on > each proxy server is going to slow down call processing on > large networks. > IMO, it (compression) is not scalable. > Well, obviously you would only compress/decompress where it makes sense. This would usually be between UA in a cellular host and its outbound proxy. There you may only have a few kilobits of capacity available (and during the actual voice call even less), so it is feasible to trade between transmission delay and processing complexity. So it is a classical optimization problem with two constraints. Between proxies, where you (should) have enoungh capacity, compression will probably just slow down things. > Even end-to-end can be a problem if either (or both) UAS and > UAC service a > number of attached SIP-unaware systems. For instance a > SIP-PSTN gateway. > Again, using compression between gateways/controllers probably does not make sense as the capacity limitations shouldn't be a problem. Regards, Markus > Aniruddha Kulkarni wrote: > > > If one has high latency link then nothing can be done about > it. Compression > > is not a solution for that. > > If one has low bandwidth link and large data to send then > Compression can be > > the solution. > > SIP messages take up only small portion of the available > bandwidth (even on > > Cellular links..). Then why use compression for SIP messages? Well.. > > cellular links have high BER, in this situation it is > advisable to have > > smaller packets to reduce error probability.. that is why > use compression. > > ... correct? > > > > Still large number of connections to internet are over > telephone modem links > > with low bandwidth, comparable with latest cellular links. > Isn't it useful > > to have end-to-end SIP message compression in that situation? > > > > How much the SIP compression schemes are dependant on RoHC? > Could they have > > in-built mechanism for configuration negotiation? Should > they demand this > > facility from lower layers? It seems to me that these > schemes work more at > > application level and should have configuration negotiation > at that level > > only. That way they could be easily extened for use on > end-to-end rather > > than limiting them to hop-to-hop (by depending on RoHC). > > > > ---Aniruddha > > > > ----- Original Message ----- > > From: > > To: "'Aniruddha Kulkarni'" ; > > ; > > Sent: Tuesday, July 24, 2001 6:27 PM > > Subject: RE: [Sip] SIP Compression > > > > > > > >> SIP is not intended to transport large amounts of information. > >> That plus the ratio of bandwidth used by signalling vs. > >> the bandwidth used by the media, means that signalling compression > >> for SIP is not in general a problem. It only really becomes a > >> problem on low bandwidth, high latency *links* such as a cellular > >> link where sometimes every byte counts. > >> > >> In short, I believe signalling compression is a hop-by-hop > >> problem and not an end-to-end one. A hop-by-hop solution seems > >> appropriate in this case. > >> > >> It should also be noted that you can always apply gzip compression > >> to the MIME body of a SIP message to achieve some end-to-end > >> compression. IMHO, this is not needed. > >> > >> I believe the compression techniques that have been > >> described so far (ROGER, SCRIBE, EPIC, etc.) are > >> fairly generic and would work well on a variety of > >> link types. Some have been tailored with cellular > >> in mind. > >> > >> Hopefully this addresses your concerns, > >> Sean Olson > >> Ericsson Inc. > >> > >> -----Original Message----- > >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > >> Sent: Tuesday, July 24, 2001 8:30 AM > >> To: rohc@cdt.luth.se; sip@ietf.org > >> Subject: [Sip] SIP Compression > >> > >> RoHC works hop-to-hop, not end-to-end when there are > multiple hops between > > > > two ends. > > > >> Does SIP Compression mechanisms also have this constraint? > If yes, why? > >> Are those designed to work only on cellular link between > mobile terminal > > > > and > > > >> fixed end of cellular link (hop-to-hop) ? Why those > mechanisms are not > > > > designed > > > >> for end-to-end compression? > >> (reduce large payloads ,whatever be the link characteristics...) > >> > >> ---Aniruddha > >> > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > -- > > Suheel Hussain > ssh@cisco.com > Cisco Work # (919) 392-2312 > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 11:04:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28875 for ; Wed, 25 Jul 2001 11:04:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06745; Wed, 25 Jul 2001 10:39:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06714 for ; Wed, 25 Jul 2001 10:39:02 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26345 for ; Wed, 25 Jul 2001 10:38:01 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6PEZek08885 for ; Wed, 25 Jul 2001 09:35:40 -0500 Message-ID: <003d01c11517$77e98bb0$55fa403f@blazer> From: "Dean Willis" To: References: <76C92FBBFB58D411AE760090271ED4186F9DF2@RSYS002A> Subject: Re: [rohc] RE: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 09:38:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We can derive targets from an understanding of the constraints. Assume a 9.6kbps single-channel GPRS link. Assume that approximately 5kbps of that is used by a half-rate AMR (Alternative Minimum Rate) codec. That gives us roughly 4.6kbps available for processing signaling, such as a re-INVITE, BYE, or new INVITE arriving. If we have a 1000-byte (8000 bit) messgae over that link, it takes just under TWO SECONDS (8000/4600) to serialize. That's clearly too long, given that there might be three messages (or more, with "manyfolks" QoS) involved in a call setup. I haven't seen a hard design goal for wireless, but I'd guess that a transaction time of less than 1.5s would be a minimal goal. That means we need to serialize in less than 500ms. This sets a target compressed message size of (X/4600)=0.5, or 2300 bits, call it 250 bytes. In wireline environments, I've seen goals as low as 100ms for three-message setup. To reach that over GPRS in the above scenario, we'd need to shrink average message size to (X/4600)=0.035, or about 20 bytes. Oddly enough, this would be roughly equivalent to current GSM signaling. SIP INVITES in the Call Flows draft run from 300 to 600 bytes. I doubt they're representative of real uses, especially with all the additional stuff people want to put into signaling (cookies, state, cell-IDs, auth-tokens, blah blah blah). The three syntactic dictionary transforms (ROGER, SCRIBE, and Rosenburg) we've seen published are getting on the order of 6 or 8 to 1 compressions, so they're producing INVITES in the 50 byte range, probably approaching 100 bytes with "real world" messages. This might be good enough for general use. The best work I've seen so far with LZ-based algorithms provides roughly 3-1 compression, which might possibly be good enough if one is very terse with one's messages. -- Dean ----- Original Message ----- From: "Price, Richard" To: "'Michael Thomas'" ; "Jonathan Rosenberg" Cc: ; Sent: Wednesday, July 25, 2001 3:53 AM Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP > Interesting. Any idea what kind of compression ratio we need to aim for, so > that we know how complicated we need to make the solution? > > Regards, > > Richard P > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, July 25, 2001 3:47 AM > To: Jonathan Rosenberg > Cc: 'Michael Thomas'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [rohc] RE: [Sip] New I-D on compression of SIP > > > Jonathan Rosenberg writes: > > I believe that the IPSec compression mechanisms apply to each packet > > independently. That is, there is no carryover of compression context from > > one IP packet to the next. The problem is that a single SIP message only > > compresses a little (maybe 2:1), but when you take advantage of previous > > messages to build a compression context, it can be much, much bigger. Thats > > the idea behind my draft, and also the others in the ROHC group - ROGER, > > SCRIBE. So, I don't see them as solving the same problem. > > Hmm. I guess I have to wonder whether the marginal > difference is actually worth much over the base > Huffman encoding and whatever you manage to eek > out with the dictionary across packets. It does > come at the expense of quite a bit of extra shared > state. If you're sold on that, maybe it would be > best of all to just standardize a SIP specific > dictionary :-) > > Not that this actually has much to do with > original point... > > Mike > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 11:25:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00845 for ; Wed, 25 Jul 2001 11:25:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05970; Wed, 25 Jul 2001 10:26:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05939 for ; Wed, 25 Jul 2001 10:25:58 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24993 for ; Wed, 25 Jul 2001 10:24:57 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6PEPpN03294; Wed, 25 Jul 2001 16:25:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6PEPm510671; Wed, 25 Jul 2001 17:25:48 +0300 (EET DST) Message-ID: <3B5ED6EA.D02AAC00@lmf.ericsson.se> Date: Wed, 25 Jul 2001 17:25:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Michel de Boer'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: Re: [Sip] New I-D on compression of SIP References: Content-Type: multipart/mixed; boundary="------------5D16A7CCE57EB82AF4D66BB0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------5D16A7CCE57EB82AF4D66BB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, A few comments from me. First, my personal opinion about the binary talk: let's skip the binary talk. If we start talking about it, we will argue about it for at least 6 months (I think the people who have been involved in the MEGACO work know what I'm talking about...) Then, IF we would decide to also go binary, experience (read: MEGACO) has shown that it's not that easy to define text- and binary rules that "match" 100%. Ok, SIP would probably be a little easier than Megaco, since we don't have wildcard values etc, but still. Then we would also have the encoding negotiation problem, and the issue about which nodes MUST/SHALL/SHOULD support what... And, which has been mentioned also by others, that we really don't transport that much information in SIP, so would the gain (not very much, I'd say) be worth the pain (very much, I'd say)? Compression is more "flexible". For most networks/architectures I don't think it will provide very much, but if peope want to use it they are free to do so - but it would not affect the core protocol. Then, if we assume that we need compression, we have the other questions, which I think are more important to discuss: 1. Hop-to-hop vs end-to-end 2. Do we compress the whole message, or only parts of it (the message body, for example) 3. Compression negotiation a) Do we use an external negotiation mechanism, and negotiate before we start the SIP session. Since the proxies in many cases also must be involved in this negotiation we would probably need some kind of "centralized" function for this. b) Do we send the initial INVITE uncompressed (or partly compressed) with a Supported/Require/Proxy-Require header listing the supported compression algorithms. And again, if the proxies must support the compression, there must be a way for them to indicate it (can be done for example either by using Proxy-Require, or some Record-Route parameter) c) Do we use "manual" configuration, either by hand or by using some of the SIP extensions that have been defined for remote configuration. My thoughts... Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Michel de Boer [mailto:michelboer@lucent.com] > > Sent: Thursday, July 19, 2001 3:54 AM > > To: Jonathan Rosenberg > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > Jonathan, > > > > You state that one of the ways to achieve message size reduction is to > > define a binary encoding, but that this introduces interoperability > > problems. > > > > How can a compression scheme based on dynamically constructed > > codebooks > > be simpler? > > Simpler, perhaps not (although if you're using PER or BER, its not clear to > me that this is simpler, codewise). But, it totally breaks compatibility > with the existing protocol. By pushing this into a transport problem, it is > isolated to the two entities that need to worry about it. > > > In my opinion this approach is more prone to > > interoperability > > issues. > > Thats not clear at all. Either way, we would require new code in > implementations. For a new binary coding, we would be back to square 1, so > that everyone would have to work out the kinks in their encoder/decoders for > every element in the syntax. However, with a shim, we leverage existing, > mature parsers and generators. We add a layer that is not specific to SIP, > so it has no syntax or anything else to get wrong. Its defined by a fairly > simple set of state machines, which should not be that hard to get correct. > I would argue its easier to get that right than it is to get a totally new > encoding of SIP right. > > > Codebooks can get out of sync. > > Yes, and that does need to be handled in the protocol. > > > As codebooks are specific to a sender- > > receiver pair, an entity communicating with multiple other > > entities, i.e. > > a proxy talking to many UA's must manage multiple codebooks. > > Well, the problem at hand is really a wireless phone talking to its local > outbound proxy. THus, the phone has only one relationship, and the proxy has > one with each phone it communicates with. This pushes the burden of > compression to the elements that benefit the most from it. From this point > onwards, normal SIP would be used, and so its compatible with existing > proxies and UAs. > > > > > For trouble shooting one might want to monitor a network interface and > > analyze SIP messages coming in. It's impossible to read a compressed > > message. > > The output of the decompressor would need to be monitored. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------5D16A7CCE57EB82AF4D66BB0 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------5D16A7CCE57EB82AF4D66BB0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 12:08:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05438 for ; Wed, 25 Jul 2001 12:08:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06976; Wed, 25 Jul 2001 10:42:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06945 for ; Wed, 25 Jul 2001 10:42:00 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26668 for ; Wed, 25 Jul 2001 10:41:00 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6PEcUk08897; Wed, 25 Jul 2001 09:38:30 -0500 Message-ID: <004301c11517$dd68f980$55fa403f@blazer> From: "Dean Willis" To: "Aniruddha Kulkarni" , , , References: <023e01c114ff$31341f40$710410ac@effnet.com> Subject: Re: [Sip] SIP Compression Date: Wed, 25 Jul 2001 09:41:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Actually, it's the serialization latency that seems to cause problems. How long does it a take a 1KB packet to get through a 4.6kbps link? What are the impacts of this to a user who's trying to set up a four-way bridge call? -- Dean ----- Original Message ----- From: "Aniruddha Kulkarni" To: ; ; Sent: Wednesday, July 25, 2001 6:44 AM Subject: Re: [Sip] SIP Compression > If one has high latency link then nothing can be done about it. Compression > is not a solution for that. > If one has low bandwidth link and large data to send then Compression can be > the solution. > SIP messages take up only small portion of the available bandwidth (even on > Cellular links..). Then why use compression for SIP messages? Well.. > cellular links have high BER, in this situation it is advisable to have > smaller packets to reduce error probability.. that is why use compression. > .. correct? > > Still large number of connections to internet are over telephone modem links > with low bandwidth, comparable with latest cellular links. Isn't it useful > to have end-to-end SIP message compression in that situation? > > How much the SIP compression schemes are dependant on RoHC? Could they have > in-built mechanism for configuration negotiation? Should they demand this > facility from lower layers? It seems to me that these schemes work more at > application level and should have configuration negotiation at that level > only. That way they could be easily extened for use on end-to-end rather > than limiting them to hop-to-hop (by depending on RoHC). > > ---Aniruddha > > ----- Original Message ----- > From: > To: "'Aniruddha Kulkarni'" ; > ; > Sent: Tuesday, July 24, 2001 6:27 PM > Subject: RE: [Sip] SIP Compression > > > > SIP is not intended to transport large amounts of information. > > That plus the ratio of bandwidth used by signalling vs. > > the bandwidth used by the media, means that signalling compression > > for SIP is not in general a problem. It only really becomes a > > problem on low bandwidth, high latency *links* such as a cellular > > link where sometimes every byte counts. > > > > In short, I believe signalling compression is a hop-by-hop > > problem and not an end-to-end one. A hop-by-hop solution seems > > appropriate in this case. > > > > It should also be noted that you can always apply gzip compression > > to the MIME body of a SIP message to achieve some end-to-end > > compression. IMHO, this is not needed. > > > > I believe the compression techniques that have been > > described so far (ROGER, SCRIBE, EPIC, etc.) are > > fairly generic and would work well on a variety of > > link types. Some have been tailored with cellular > > in mind. > > > > Hopefully this addresses your concerns, > > Sean Olson > > Ericsson Inc. > > > > -----Original Message----- > > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > Sent: Tuesday, July 24, 2001 8:30 AM > > To: rohc@cdt.luth.se; sip@ietf.org > > Subject: [Sip] SIP Compression > > > > RoHC works hop-to-hop, not end-to-end when there are multiple hops between > two ends. > > Does SIP Compression mechanisms also have this constraint? If yes, why? > > Are those designed to work only on cellular link between mobile terminal > and > > fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not > designed > > for end-to-end compression? > > (reduce large payloads ,whatever be the link characteristics...) > > > > ---Aniruddha > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 12:47:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09536 for ; Wed, 25 Jul 2001 12:47:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09574; Wed, 25 Jul 2001 11:55:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09545 for ; Wed, 25 Jul 2001 11:55:00 -0400 (EDT) Received: from packer.effnet.com ([195.100.73.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03777 for ; Wed, 25 Jul 2001 11:53:58 -0400 (EDT) Received: from aniruddha (packer.effnet.com [195.100.73.130]) by packer.effnet.com (8.11.3/8.11.3) with SMTP id f6PFxMB15194; Wed, 25 Jul 2001 17:59:22 +0200 Message-ID: <02f801c11522$065a3110$710410ac@effnet.com> From: "Aniruddha Kulkarni" To: , Cc: , , References: <034272783A93C944A6CA1D87FBF6F49E107EAE@esebe014.NOE.Nokia.com> Subject: Re: [rohc] RE: [Sip] SIP Compression Date: Wed, 25 Jul 2001 17:54:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit end-to-end compression seems more efficient as it doesn't depend on link characterictics of link between each hop. A payload compression scheme should be designed considering worst link characteristics that a packet may encounter in it's path.. cellular link is a good example for this between two hops. The gain obtained on those poor links can be carried over to better links without any loss. end-to-end scheme becomes more attractive when two disjoint hop-to-hop links are of poor characteristics. The processing time on hops could be a issue in hop-to-hop schemes. An intermediate hop serving multiple connections, if under load, could affect all connected entities.e.g. a base station serving multiple phones. (Particularly in payload compression schemes an intermediate hop need not decompress at all..) In end-to-end scheme, there is no such problem, resulting in a better overall performance. Definitely, this is not applicable in header compression schemes but for completely different reason, header required for routing. There hop-to-hop is the best scheme regardless of processing time issue on base station or any other benefits of end-to-end compression. ---Aniruddha ----- Original Message ----- From: To: ; Cc: ; ; Sent: Wednesday, July 25, 2001 4:26 PM Subject: [rohc] RE: [Sip] SIP Compression > Hi, > > > -----Original Message----- > > From: ext Suheel Hussain [mailto:ssh@cisco.com] > > Sent: 25 July, 2001 15:46 > > To: Aniruddha Kulkarni > > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > > Subject: Re: [Sip] SIP Compression > > > > > > I have nagging issue with SIP compression -- compressing and > > decompressing on > > each proxy server is going to slow down call processing on > > large networks. > > IMO, it (compression) is not scalable. > > > > Well, obviously you would only compress/decompress where it makes sense. > This would usually be between UA in a cellular host and its outbound proxy. > There you may only have a few kilobits of capacity available (and during the > actual voice call even less), so it is feasible to trade between > transmission delay and processing complexity. So it is a classical > optimization problem with two constraints. Between proxies, where you > (should) have enoungh capacity, compression will probably just slow down > things. > > > Even end-to-end can be a problem if either (or both) UAS and > > UAC service a > > number of attached SIP-unaware systems. For instance a > > SIP-PSTN gateway. > > > > Again, using compression between gateways/controllers probably does not make > sense as the capacity limitations shouldn't be a problem. > > Regards, > Markus > > > Aniruddha Kulkarni wrote: > > > > > If one has high latency link then nothing can be done about > > it. Compression > > > is not a solution for that. > > > If one has low bandwidth link and large data to send then > > Compression can be > > > the solution. > > > SIP messages take up only small portion of the available > > bandwidth (even on > > > Cellular links..). Then why use compression for SIP messages? Well.. > > > cellular links have high BER, in this situation it is > > advisable to have > > > smaller packets to reduce error probability.. that is why > > use compression. > > > ... correct? > > > > > > Still large number of connections to internet are over > > telephone modem links > > > with low bandwidth, comparable with latest cellular links. > > Isn't it useful > > > to have end-to-end SIP message compression in that situation? > > > > > > How much the SIP compression schemes are dependant on RoHC? > > Could they have > > > in-built mechanism for configuration negotiation? Should > > they demand this > > > facility from lower layers? It seems to me that these > > schemes work more at > > > application level and should have configuration negotiation > > at that level > > > only. That way they could be easily extened for use on > > end-to-end rather > > > than limiting them to hop-to-hop (by depending on RoHC). > > > > > > ---Aniruddha > > > > > > ----- Original Message ----- > > > From: > > > To: "'Aniruddha Kulkarni'" ; > > > ; > > > Sent: Tuesday, July 24, 2001 6:27 PM > > > Subject: RE: [Sip] SIP Compression > > > > > > > > > > > >> SIP is not intended to transport large amounts of information. > > >> That plus the ratio of bandwidth used by signalling vs. > > >> the bandwidth used by the media, means that signalling compression > > >> for SIP is not in general a problem. It only really becomes a > > >> problem on low bandwidth, high latency *links* such as a cellular > > >> link where sometimes every byte counts. > > >> > > >> In short, I believe signalling compression is a hop-by-hop > > >> problem and not an end-to-end one. A hop-by-hop solution seems > > >> appropriate in this case. > > >> > > >> It should also be noted that you can always apply gzip compression > > >> to the MIME body of a SIP message to achieve some end-to-end > > >> compression. IMHO, this is not needed. > > >> > > >> I believe the compression techniques that have been > > >> described so far (ROGER, SCRIBE, EPIC, etc.) are > > >> fairly generic and would work well on a variety of > > >> link types. Some have been tailored with cellular > > >> in mind. > > >> > > >> Hopefully this addresses your concerns, > > >> Sean Olson > > >> Ericsson Inc. > > >> > > >> -----Original Message----- > > >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > >> Sent: Tuesday, July 24, 2001 8:30 AM > > >> To: rohc@cdt.luth.se; sip@ietf.org > > >> Subject: [Sip] SIP Compression > > >> > > >> RoHC works hop-to-hop, not end-to-end when there are > > multiple hops between > > > > > > two ends. > > > > > >> Does SIP Compression mechanisms also have this constraint? > > If yes, why? > > >> Are those designed to work only on cellular link between > > mobile terminal > > > > > > and > > > > > >> fixed end of cellular link (hop-to-hop) ? Why those > > mechanisms are not > > > > > > designed > > > > > >> for end-to-end compression? > > >> (reduce large payloads ,whatever be the link characteristics...) > > >> > > >> ---Aniruddha > > >> > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > > > > Suheel Hussain > > ssh@cisco.com > > Cisco Work # (919) 392-2312 > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 12:47:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09548 for ; Wed, 25 Jul 2001 12:47:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10790; Wed, 25 Jul 2001 12:19:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10759 for ; Wed, 25 Jul 2001 12:19:43 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06445 for ; Wed, 25 Jul 2001 12:18:42 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA07392; Wed, 25 Jul 2001 18:19:28 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA16655; Wed, 25 Jul 2001 18:19:29 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 18:19:32 +0200 Message-ID: <5316E8083EC4D411957F0008C71EEE3473A956@MCHH227E> From: Euchner Martin To: "'Michael Thomas'" , Jonathan Rosenberg , Euchner Martin Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] New I-D on compression of SIP - security issues Date: Wed, 25 Jul 2001 18:19:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Security experts, my understanding of draft SIP udpcomp is, that the compression occurs on lower protocol layers (as indicated in chapter 2). However, I do not see how this would make sense when assuming that the SIP message to be compressed has been integrity protected and/or possibly encrypted on a SIP application protocol layer above the compression scheme. It is well known that once a message has been encrypted there is no way for compression afterwards; thus, compression must come before encryption. My recommendation is, that the SIP compression scheme be applied before any SIP message security processing takes place. Ignoring encryption for the moment, how would the UDPcompression scheme perform, when SIP messages were cryptographically integrity protected with a message-dependant hash-code? I could easily imagine, that the piece of hash-code couldn't be compressed significantly. If the hash-code negatively impacts the compression performance, then it might at least be wise to skip and not compress the hash-codes. There is also question how the compression-protocol with transmission of the context and tokens relates to security? I would rather assume, that at least the WRITE entries deserve the same protection as the SIP message does. To conclude, I really doubt the statement in section 7, that the compression protocol would not introduce any additional security considerations but see much reasons to further investigate the mentioned issues. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Saturday, July 21, 2001 6:18 PM To: Jonathan Rosenberg Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' Subject: [Sip] New I-D on compression of SIP Jonathan Rosenberg writes: > Folks, > > I've just submitted a new I-D on compression of SIP messages, particularly > for wireless links. Until the draft appears in the archives, you can pick up > a copy at: Jonathan, To follow up on my passing comments, it should be noted that IPsec already has compression transforms which work in combination with encryption/message integrity. I'm not sure if TLS has this capability, but I wouldn't be surprised (nor do I think it would be hard to add if not). Thus, there's at least some amount of wheel reinvention going on here. That said, it may be interesting to consider taking the same tack as IPsec compression for SIP security which has the same problem as all encryption/compression schemes which is that you must compress before encrypting to do anything useful. Thus, it would be natural for secure SIP headers and bodies (attachments, as I propose) to allow compression transforms as well. The synergy between our two drafts, I think, may lie in something that I've been toying with: the ability to have a complete SIP application layer security scheme which not only deals with the problem which is clearly in the SIP domain (crypto for parts of the SIP payload), but could also be used to provide hop-by-hop encryption/authentication as well negating the need to require a base level secure transport mechanism (eg, IPsec, TLS). I think this is possible by extending my current proposal to insert a shim layer much like you propose in this draft here. I haven't included this in the current draft (mostly because it's not a baked idea), but it would make sense to my mind that if we allow compression, we ought to fold it into the security framework mainly because of the compress-then-encrypt problem. Mike _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 13:17:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12716 for ; Wed, 25 Jul 2001 13:17:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11497; Wed, 25 Jul 2001 12:34:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11466 for ; Wed, 25 Jul 2001 12:34:38 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08124 for ; Wed, 25 Jul 2001 12:33:36 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 16:58:28 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DF7@RSYS002A> From: "Price, Richard" To: "'Christer Holmberg'" , Jonathan Rosenberg Cc: "'Michel de Boer'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 16:58:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Is compression so different from binary encoding? Our own EPIC scheme uses the BNF description of a protocol to "learn" a set of binary encodings for the protocol. The compressor then replaces each text string with its equivalent binary encoding. It is feasible to write a SIP implementation that uses these binary encodings directly, missing out the text-based version of the message altogether. This is not a change to the core protocol, but rather a combined SIP stack/SIP compressor. Normally this would be a big amount of effort for very little gain. However it certainly solves the concerns about processing requirements (as it doesn't have any!) Regards, Richard P -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, July 25, 2001 3:26 PM To: Jonathan Rosenberg Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' Subject: [rohc] Re: [Sip] New I-D on compression of SIP Hi, A few comments from me. First, my personal opinion about the binary talk: let's skip the binary talk. If we start talking about it, we will argue about it for at least 6 months (I think the people who have been involved in the MEGACO work know what I'm talking about...) Then, IF we would decide to also go binary, experience (read: MEGACO) has shown that it's not that easy to define text- and binary rules that "match" 100%. Ok, SIP would probably be a little easier than Megaco, since we don't have wildcard values etc, but still. Then we would also have the encoding negotiation problem, and the issue about which nodes MUST/SHALL/SHOULD support what... And, which has been mentioned also by others, that we really don't transport that much information in SIP, so would the gain (not very much, I'd say) be worth the pain (very much, I'd say)? Compression is more "flexible". For most networks/architectures I don't think it will provide very much, but if peope want to use it they are free to do so - but it would not affect the core protocol. Then, if we assume that we need compression, we have the other questions, which I think are more important to discuss: 1. Hop-to-hop vs end-to-end 2. Do we compress the whole message, or only parts of it (the message body, for example) 3. Compression negotiation a) Do we use an external negotiation mechanism, and negotiate before we start the SIP session. Since the proxies in many cases also must be involved in this negotiation we would probably need some kind of "centralized" function for this. b) Do we send the initial INVITE uncompressed (or partly compressed) with a Supported/Require/Proxy-Require header listing the supported compression algorithms. And again, if the proxies must support the compression, there must be a way for them to indicate it (can be done for example either by using Proxy-Require, or some Record-Route parameter) c) Do we use "manual" configuration, either by hand or by using some of the SIP extensions that have been defined for remote configuration. My thoughts... Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Michel de Boer [mailto:michelboer@lucent.com] > > Sent: Thursday, July 19, 2001 3:54 AM > > To: Jonathan Rosenberg > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > Jonathan, > > > > You state that one of the ways to achieve message size reduction is to > > define a binary encoding, but that this introduces interoperability > > problems. > > > > How can a compression scheme based on dynamically constructed > > codebooks > > be simpler? > > Simpler, perhaps not (although if you're using PER or BER, its not clear to > me that this is simpler, codewise). But, it totally breaks compatibility > with the existing protocol. By pushing this into a transport problem, it is > isolated to the two entities that need to worry about it. > > > In my opinion this approach is more prone to > > interoperability > > issues. > > Thats not clear at all. Either way, we would require new code in > implementations. For a new binary coding, we would be back to square 1, so > that everyone would have to work out the kinks in their encoder/decoders for > every element in the syntax. However, with a shim, we leverage existing, > mature parsers and generators. We add a layer that is not specific to SIP, > so it has no syntax or anything else to get wrong. Its defined by a fairly > simple set of state machines, which should not be that hard to get correct. > I would argue its easier to get that right than it is to get a totally new > encoding of SIP right. > > > Codebooks can get out of sync. > > Yes, and that does need to be handled in the protocol. > > > As codebooks are specific to a sender- > > receiver pair, an entity communicating with multiple other > > entities, i.e. > > a proxy talking to many UA's must manage multiple codebooks. > > Well, the problem at hand is really a wireless phone talking to its local > outbound proxy. THus, the phone has only one relationship, and the proxy has > one with each phone it communicates with. This pushes the burden of > compression to the elements that benefit the most from it. From this point > onwards, normal SIP would be used, and so its compatible with existing > proxies and UAs. > > > > > For trouble shooting one might want to monitor a network interface and > > analyze SIP messages coming in. It's impossible to read a compressed > > message. > > The output of the decompressor would need to be monitored. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 13:17:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12756 for ; Wed, 25 Jul 2001 13:17:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09739; Wed, 25 Jul 2001 11:58:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09286 for ; Wed, 25 Jul 2001 11:44:35 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02689 for ; Wed, 25 Jul 2001 11:43:27 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA25305 for ; Wed, 25 Jul 2001 10:44:36 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 25 Jul 2001 10:35:54 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 10:41:52 -0500 Message-ID: From: "Peter Barany" To: "'Aniruddha Kulkarni'" , "sean.olson" , rohc , sip Subject: RE: [rohc] Re: [Sip] SIP Compression Date: Wed, 25 Jul 2001 10:41:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11520.524B2E00" X-Orig: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11520.524B2E00 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11520.524B2E00" ------_=_NextPart_001_01C11520.524B2E00 Content-Type: text/plain; charset="iso-8859-1" Hello colleagues, We submitted a contribution to 3GPP TSG GERAN WG1 and SA WG2 about one year ago discussing this subject. I attach it as a reference (GP-000508). This contribution was one of the reasons that some sort of SIP compression was deemed necessary for UMTS (both GERAN and UTRAN). A snapshot of the results presented in this contribution can also be found in "draft-hannu-rohc-signaling-cellular-01.txt", I believe. For those who do not have time to wade through the details of the contribution, I summarize some key points below: (1) Typical post-dial delay (on average) for a GSM circuit-switched call setup is around 3.5 to 4 seconds. This has proven to be acceptable to a customer. Anything "consistently" beyond that number becomes questionable/unacceptable in terms of quality of service. (2) The analysis in contribution GP-000508 shows that (with an average compression of 25% to 35% for individual SIP request methods and response codes accompanied by TCP/IP or UDP/IP header compression), this post-dial delay number of 3.5 to 4 seconds can only be achieved/approached with the least robust channel coding schemes (i.e., the least amount of coding ... including up to no coding at all). This analysis was done for GERAN (GPRS/EGPRS connected to the UMTS Core Network). Similar results can be shown for UTRAN (i.e., W-CDMA). Also, even if the customer is willing to accept longer post-dial delays, we submitted an additional contribution to 3GPP illustrating that the as the duration of calls becomes shorter on average, the number of calls that can be supported per busy hour in a cell decreases rapidly vs. GSM circuit-switched as the post-dial delay increases. Therefore, a greater SIP compression ratio is required (via some form of delta-compression as discussed, for example, in ROGER (see draft-hannu-rohc-roger-01.txt). (3) The open issue is where to place the compressor/decompressor pair and how to negotiate the SIP compression/decompression scheme. The compressor/decompressor scheme can be place either in (1) the mobile station/client and the SIP proxy server; or (2) the mobile station/client and the radio network controller. NOTE: The terms mobile station and radio network controller can be exchanged with link layer compression or node-to-node compression for those who do not like the idea of a "cellular specific" argument. In the case of (2), encryption (among other things) becomes an issue. Therefore, if possible, solution (1) would be preferred. If solution (1) is agreed upon, then perhaps a new layer between SIP and TCP and/or UDP is a viable approach to designing the negotiation mechanism (e.g., something similar to what was done for https via SSL/TLS). The Internet draft "draft-rosenberg-rohc-sip-udpcomp-00.txt" is a start in this direction (to some degree) but it lacks the signaling necessary for context update, context feedback, and context repair at this point in time. Regards, Peter Barany IP Multimedia Standards and Research Nortel Networks +1-972-685-2471 (Office) +1-972-684-3775 (Fax)] +1-972-467-8346 (Mobile) -----Original Message----- From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] Sent: Wednesday, July 25, 2001 6:45 AM To: sean.olson; rohc; sip Subject: [rohc] Re: [Sip] SIP Compression If one has high latency link then nothing can be done about it. Compression is not a solution for that. If one has low bandwidth link and large data to send then Compression can be the solution. SIP messages take up only small portion of the available bandwidth (even on Cellular links..). Then why use compression for SIP messages? Well.. cellular links have high BER, in this situation it is advisable to have smaller packets to reduce error probability.. that is why use compression. .. correct? Still large number of connections to internet are over telephone modem links with low bandwidth, comparable with latest cellular links. Isn't it useful to have end-to-end SIP message compression in that situation? How much the SIP compression schemes are dependant on RoHC? Could they have in-built mechanism for configuration negotiation? Should they demand this facility from lower layers? It seems to me that these schemes work more at application level and should have configuration negotiation at that level only. That way they could be easily extened for use on end-to-end rather than limiting them to hop-to-hop (by depending on RoHC). ---Aniruddha ----- Original Message ----- From: To: "'Aniruddha Kulkarni'" ; ; Sent: Tuesday, July 24, 2001 6:27 PM Subject: RE: [Sip] SIP Compression > SIP is not intended to transport large amounts of information. > That plus the ratio of bandwidth used by signalling vs. > the bandwidth used by the media, means that signalling compression > for SIP is not in general a problem. It only really becomes a > problem on low bandwidth, high latency *links* such as a cellular > link where sometimes every byte counts. > > In short, I believe signalling compression is a hop-by-hop > problem and not an end-to-end one. A hop-by-hop solution seems > appropriate in this case. > > It should also be noted that you can always apply gzip compression > to the MIME body of a SIP message to achieve some end-to-end > compression. IMHO, this is not needed. > > I believe the compression techniques that have been > described so far (ROGER, SCRIBE, EPIC, etc.) are > fairly generic and would work well on a variety of > link types. Some have been tailored with cellular > in mind. > > Hopefully this addresses your concerns, > Sean Olson > Ericsson Inc. > > -----Original Message----- > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > Sent: Tuesday, July 24, 2001 8:30 AM > To: rohc@cdt.luth.se; sip@ietf.org > Subject: [Sip] SIP Compression > > RoHC works hop-to-hop, not end-to-end when there are multiple hops between two ends. > Does SIP Compression mechanisms also have this constraint? If yes, why? > Are those designed to work only on cellular link between mobile terminal and > fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not designed > for end-to-end compression? > (reduce large payloads ,whatever be the link characteristics...) > > ---Aniruddha > --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ ------_=_NextPart_001_01C11520.524B2E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] Re: [Sip] SIP Compression

Hello colleagues,

We submitted a contribution to 3GPP TSG GERAN WG1 and = SA WG2 about one year ago discussing this subject. I attach it as a = reference (GP-000508). This contribution was one of the reasons that = some sort of SIP compression was deemed necessary for UMTS (both GERAN = and UTRAN). A snapshot of the results presented in this contribution = can also be found in = "draft-hannu-rohc-signaling-cellular-01.txt", I = believe.

For those who do not have time to wade through the = details of the contribution, I summarize some key points below:

(1) Typical post-dial delay (on average) for a GSM = circuit-switched call setup is around 3.5 to 4 seconds. This has proven = to be acceptable to a customer. Anything "consistently" = beyond that number becomes questionable/unacceptable in terms of = quality of service.

(2) The analysis in contribution GP-000508 shows that = (with an average compression of 25% to 35% for individual SIP request = methods and response codes accompanied by TCP/IP or UDP/IP header = compression), this post-dial delay number of 3.5 to 4 seconds can only = be achieved/approached with the least robust channel coding schemes = (i.e., the least amount of coding ... including up to no coding at = all). This analysis was done for GERAN (GPRS/EGPRS connected to the = UMTS Core Network). Similar results can be shown for UTRAN (i.e., = W-CDMA). Also, even if the customer is willing to accept longer = post-dial delays, we submitted an additional contribution to 3GPP = illustrating that the as the duration of calls becomes shorter on = average, the number of calls that can be supported per busy hour in a = cell decreases rapidly vs. GSM circuit-switched as the post-dial delay = increases. Therefore, a greater SIP compression ratio is required (via = some form of delta-compression as discussed, for example, in ROGER (see = draft-hannu-rohc-roger-01.txt).

(3) The open issue is where to place the = compressor/decompressor pair and how to negotiate the SIP = compression/decompression scheme. The compressor/decompressor scheme = can be place either in (1) the mobile station/client and the SIP proxy = server; or (2) the mobile station/client and the radio network = controller. NOTE: The terms mobile station and radio network controller = can be exchanged with link layer compression or node-to-node = compression for those who do not like the idea of a "cellular = specific" argument.

In the case of (2), encryption (among other things) = becomes an issue. Therefore, if possible, solution (1) would be = preferred. If solution (1) is agreed upon, then perhaps a new layer = between SIP and TCP and/or UDP is a viable approach to designing the = negotiation mechanism (e.g., something similar to what was done for = https via SSL/TLS). The Internet draft = "draft-rosenberg-rohc-sip-udpcomp-00.txt" is a start in this = direction (to some degree) but it lacks the signaling necessary for = context update, context feedback, and context repair at this point in = time.

Regards,

Peter Barany
IP Multimedia Standards and Research
Nortel Networks
+1-972-685-2471 (Office)
+1-972-684-3775 (Fax)]
+1-972-467-8346 (Mobile)

-----Original Message-----
From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@= effnet.com]
Sent: Wednesday, July 25, 2001 6:45 AM
To: sean.olson; rohc; sip
Subject: [rohc] Re: [Sip] SIP Compression


If one has high latency link then nothing can be done = about it. Compression
is not a solution for that.
If one has low bandwidth link and large data to send = then Compression can be
the solution.
SIP messages take up only small portion of the = available bandwidth (even on
Cellular links..). Then why use compression for SIP = messages? Well..
cellular links have high BER, in this situation it = is advisable to have
smaller packets to reduce error probability.. that = is why use compression.
.. correct?

Still large number of connections to internet are = over telephone modem links
with low bandwidth, comparable with latest cellular = links. Isn't it useful
to have end-to-end SIP message compression in that = situation?

How much the SIP compression schemes are dependant on = RoHC? Could they have
in-built mechanism for configuration negotiation? = Should they demand this
facility from lower layers? It seems to me that = these schemes work more at
application level and should have configuration = negotiation at that level
only. That way they could be easily extened for use = on end-to-end rather
than limiting them to hop-to-hop (by depending on = RoHC).

---Aniruddha

----- Original Message -----
From: <sean.olson@ericsson.com>
To: "'Aniruddha Kulkarni'" = <aniruddha.kulkarni@effnet.com>;
<rohc@cdt.luth.se>; = <sip@ietf.org>
Sent: Tuesday, July 24, 2001 6:27 PM
Subject: RE: [Sip] SIP Compression


> SIP is not intended to transport large amounts = of information.
> That plus the ratio of bandwidth used by = signalling vs.
> the bandwidth used by the media, means that = signalling compression
> for SIP is not in general a problem. It only = really becomes a
> problem on low bandwidth, high latency *links* = such as a cellular
> link where sometimes every byte counts.
>
> In short, I believe signalling compression is a = hop-by-hop
> problem and not an end-to-end one. A hop-by-hop = solution seems
> appropriate in this case.
>
> It should also be noted that you can always = apply gzip compression
> to the MIME body of a SIP message to achieve = some end-to-end
> compression. IMHO, this is not needed.
>
> I believe the compression techniques that have = been
> described so far (ROGER, SCRIBE, EPIC, etc.) = are
> fairly generic and would work well on a variety = of
> link types. Some have been tailored with = cellular
> in mind.
>
> Hopefully this addresses your concerns,
> Sean Olson
> Ericsson Inc.
>
> -----Original Message-----
> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@= effnet.com]
> Sent: Tuesday, July 24, 2001 8:30 AM
> To: rohc@cdt.luth.se; sip@ietf.org
> Subject: [Sip] SIP Compression
>
> RoHC works hop-to-hop, not end-to-end when = there are multiple hops between
two ends.
> Does SIP Compression mechanisms also have this = constraint? If yes, why?
> Are those designed to work only on cellular = link between mobile terminal
and
> fixed end of cellular link (hop-to-hop) ? Why = those mechanisms are not
designed
>  for end-to-end compression?
> (reduce large payloads ,whatever be the link = characteristics...)
>
> ---Aniruddha
>

---
Mailing list for Robust Header Compression WG
Archive: http://www.cdt.luth.se/rohc/

  ------_=_NextPart_001_01C11520.524B2E00-- ------_=_NextPart_000_01C11520.524B2E00 Content-Type: application/zip; name="GP-000508.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="GP-000508.zip" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UEsDBBQAAAAIAFtlYiksgZacY6YBAACUBQANAAAAR1AtMDAwNTA4LmRvY+xbS4wjx3nmxkrGdNx5 WbLhxEgKygOkxeFOkxzOQ5FtDskZMR7OMCRHsi0JRrNZM9Nakk31Y2bHwh5zzSlAzgmQQwBfctFV aztGDjnE5wABkouBIEEuyS2GN9//V1V38zE7uysbySEt7bDZXfXX/35V8Uf/8Ov//Bd/85v/klu6 vpL7VO6nT/K5X8o8o/sf/oL+8mu53N/h/h5uf/rkyRN69DG+P8a/7+Hf9/HvB/j3t/j35P+v/7PX v//V93If5PIv5XKf/o2PE8niwpPf+WEu9yu50fuj96PXotdyK1f+pc/nXj34VO7zjXv8788fq+e/ tTRuoj+fPPnV5Nlt9+Z6j/++r0HRZ/aerr/88urnyxkIH3359s9dfP4HPt/F5x+Bstan0/f//cV7 uR9Ba/+xlst9C+pdq+dyBTx/t67eL39+fQcWgHGdvVzuz/D9n/B5jM/HgEPG8v0v3uNxz/L5e/j8 +y/dy/0XHn382/dy38X3H+P5K7nVy9Bd3F/zEtfRDguR8cuOM58/1uv+9dfU92X+GvrMRd//Laf4 kp23/EnwH7+k4PzkMykcg6/5/livv3wty2sZr+VPQ8/jDD3f+MUUn3uHudz+l3K5/4SP+sEXcrnz P8jl/vClFJ8Xvcx6hp4/rULuePS17ZOPftJ6fG+Zjn/9Cubg/UdfuJf7jPGi/+tX9ajXE8PBkThq 9xsn4ncr+aPe5tbW1vbW7i+f+EEQOZP3ZUkMruVYzvKNCzkbO6ITyanYKddKYrdsl7fLdau+aW+J E/9KTkcyEBUAsCxr4MeBK/cFXgSRnIgTGV37wYNQWPpqiKY/nTuBF/ozcYC3Us4shUjPcR/IaHNw 7UXupRyLpjOZiIGM4rk4C73ZhRh0epYzG4ujQVc0vcCNvaeN7neOq5vNZsnim263pJ70+yVBQFrD Rs/qy6uy2CrXgNhnrc+J4WlTvOuLV+3N6qviZTvfmUWBP47dyPNn+c+JXgOItg/Ft4e+W9vb2dmt 1+26ePdS3Hu5+opVyR97YST8c9FwA392Mw1vmbKTTKnmhzdzz3Umd5I0kB/EcubKW0DuKpA1gCzb +a4MQ+dCioH3HSnaYeRNnadQsKfmbtNc0ODcQJpVMQyc21arbKkZ9VesWkIAZPPs+FZsBWEXEICv gdHvN6Eds5lkhrOUOjGouJg5E5Jo5t0zrVLJrFJJWd3rD0Qjihz38i4AVQVgjwCksuoFYGhwI3qt HqEUyYcRRB55V45G7akwawqmvUVAU/71NpuD5qFoeaELkwL0O8BsazA2gdleEEO/fdQZDNv9u0DU syDqLyhJrcx2hYDsPJ/qVbTa2szgHWhC/7h5v9toioOJ7z5YBiLO/UB0m4NNWwwvAz++uORve/ui 07uq3bKE1u7Kllqi8gmWqK9foqrNoVKlJXafxYKqWv8rMNjtPHTIncQhlg9Z5/vS9adT8rqE0i1e pKqVuwK7ref78lwGJKXbRlfT0a80er32SavzDdHID7/Z6zQbx8r9dPrNs85wc/B2Z9h8s90SeHEs Bu3hWQ9///isfdJsW8ncg/xx45vQsaqAixXkXRsnLVjwelDd9mAArAb7GaAprGYCa9hvNNvi8LQv XhyzVr4/eCsDvZ3vtZo9WOsZAe42hgNGtc1+ANogWo1hQ5yddIZQ/W+1VZj6rJX1/VYvkFeeH4cC pqkEBTcfXXqhcOEAAm8Us/a8Y78nxrDgOAzhvr2ZGMvI8SYYKfH83MhIjFTc4+dTbTEhNDFk/XNE lIkKro4KoYkKLtlmyLYZattktUmnkQWvG1W48r5TLvHryE9HXXkOJtPXeeA/vMH4AGQWy0IcApsr xGqiPJAOQnZYYqTvWskzvBiLmR8Jx3X9eBYxdTT93J9M/Gty6Zr6EI+dSMwk6ANqI6wQOLNw6kUR npBD5HmOFwB0JINzh8i5vvTgw52A13PGY4+FgPk0llALCB/E5KmMLv2xsq5AhnPQISG5sQyL+9ZS 1EkwKsjyBbi19LqvQOK5M/Z8ZDBYPlCusiRk5JaL4p3Ke2Wr5QWYQU5gFkLuK2BPGoNE9DD3ORIi TnFg+zD8peiSLKoXqGIBUvIMVGLt1B95E2hSpByH4imxh8e6ztwZTSSm1zD9RF6LceCcR8/IKIN3 87TbHpZED4b69ZKwd6uwwMGgc4r0rX961Md9guX2eyXxTp3+7OgF+8Pe/bNW7z5WvJTOGGwJ5NS/ giLRgqA8jIJ4SQzv7GLycMXUHGjGdB6FJG4H5haGLHUPuaUbKeuUwN1oBS2xoDwGPrR8MJeud076 PLkpAaMLJxiTLAje7OfNJiSjvMjz2e6FE8lr5+ap9ivAMmcS+ngKToDwMfFRLrIRY/zgwpnB+cCD hNoymSta4SviwrsCYY6Y6PTW0eltZlA1cXvhC7ivDKDaWkC3MoXcMrna88CfkscpZkBtG8JZcxYi bLAYYTOT6lARDB0vEBwk0RUjG/M5JnrkxhtQEZUktIn1V94YxhfP5yh92LdBSIHnTMrWcmFgUQmW z+erAYoZOZOBSj56ThDhS3jpzZFk+heBM7UaR803MbLhuqTiR3AnkWheOvBHE+ugye8OAt8Zuw6W IH8R+JN0wKBJ7x1o50A5BTNkIgPrYDgwb9lNudIjR6tHWjSVchNjQFZTPSE5aChW80QNgo/RlZ7V 7KtRAUiHb+tDYgGA9Y8PVx+LY28mxSG8vkXZr4E+YAVOqDmMZyoKU8mGMcuuFRKZQE0SFlrt1lEb 49ozsMGFdrScyIG/jnR8PZr4IyhV+8qfsBFYnApkxiuRTHRBqj09IQWpW4eHxDWKjIdxABdBDIvH N9Yhs+IQMgMvYqqJVVmbz8MM7hNKGpAWpeHX0dGAZh5pi+asZKCUCEX0WFoKufxTkcISNEQRNrgJ qVjnVFZFBJTc03imeRRabw6HxMc3b+YyGFJ8SVgJrYt8F4LtEANR/wKIzozbEwmLiaxOT72Bbs+A RzLjuNFr4QUk+sCQaN6xACxWgHwqccI433XICP3gxuoesQJ05RjuzHBjRQW6R28vD7K6BIkp9aIb AYhQMEa1OzAvEv3Hs2bmITslLi3JQQbWyQFrGPFdHKwq1imhfDrX9qBKtny+x16X7i1mQT6lG74M xaI3IxLxkt72fBhqC25BtOQE2HOI4DlwZSpS9U1IabgPZv71RI41QRhKBt8H0+DvNJeNsVN3g1+S YnSSQKfLEaQ5+eQtFuA+TZZZyHNW3xs777N+aZ2LR6HSsOxsZBg0wkwMJFTzLc06oyIDzTDWWmI6 sWzQYi8G+UATJj60owXpguvUAFnyZ4MWLTIA1QS3JYm786U1OtkhnRmc1zIWgx0akXQVtLnsWMMm TR2qxFPNNwgkk8+apFNnM/KUocOYocyLVAponTF+ZwjArPLkwDNT2aT4ZfuD2Jsz386GpPSAqm0w MbdDvrOs520QkSsQcShVOgRaKTIxAsr5eQiHoaEd4WyoRzkZXZ+wylwiHQjlFTudMB7xQzzRyZJJ s2k5pQ4a2C36Jwqkn0VxqwJiQL+YQRZ5FtJVL7zUEXsiKVAFPN1N8vG0lnJmArbNg03JgvAXJjXH ONZRljIYziYWEF6n1UBp0E1xMjE+pDL3XHukxWIOIZUxwMoa+l3BShQoqmUJN5kEFkmS4OwaXbVE N1kCGRPyDZW/mIEEVGMy6OLWS+COxegGDIBrSrPAhMKRRPZHq0xVrkgyE2tcqyh0u1mcxxJKAq28 JOwmvqZvmo4nVELpxgHBcUiJIl1Dy1R9DhOeIjCRKQDZeEZlwjqQOlFL38VzyudmFyXR6Q46VCE4 7qVq9gKe58OrJGMo5fMRqZdwyog1RYEqKCcGprNIS64khrQCSuKJWV2tA/5i0LkeZhSMmJhNmxYY 2WyuZ6Qu5vzAu6D4QZ6KVoBZTc13TokTOyFwJc4/VaSmIjJU+UGosAsvKanIVD4NzO92+V2zmaEd eTNpoGcUTmsa8mBkeiXUKx4nPqzxsLmZNjHSfq6wkHhDvCnkzJIHDEPIhy58+sVCC8DoLuYRFyNP JiqidV5jQ9SQeaRugDsHoW4dJByhimcgpXhnj4pQe4v/2vy38h47BtWf4V5N6nrxv9k7ELfvHaRC K1uH3kUMoho2sUwXCA9RHngTVB1RwJnnC3R1Cks6IMfFsnVLh9UaUnEPn2cnRcmBXVvA5yBxLYrs cKnWfRaiF/s1ZBmxbnVl20KfhEIF2SNTALBIAb+FwWVLbfVw5Z+RYOLqSE2lNyutdNpEAYBGNxBM MYkQz42968y0vpEQoG1CcCM2YJx8wSIRtvKqGgfnoTeNp4u4XMO1QOsmN0rBTUoMJ1sUa1LwUBQ6 7SIzn1omIDQgLoXCtuuKJiDSUYaTqd/gaoosSJPAisIp4LdD5eCoU5CCo7YEypMw2nQp7BoSDclT ZyyXtGcdZfspSkzMa6Jq7+DvV82zJj2rLz4DUm8Ie2t7K30IerjyJby460ptC+IXsEHigvxbWwH8 n0eS4aYjBDb3kceREFDvj9ht6t6tShROE/KvkA+R/N70rynlKSVKMY8DAJFpwzekak8Jc2Fpwkn1 SEnqiZ1ubBzL2QX8eUFp2wau7kZz43RjozOdUh0DrjZCSslIthu7oLpgk/bsER8+3KPu0aON+kZ1 Y6PZNQWf6QhuEOcKlZXhWxv2xkZjIWYlU+w9el2jOfYezbFrmLT3aM0EVYZgcZqA9b057IkE3qUC iapKcBGYbeG/NW8RiCK5UcHLKq9m02pVLGZjMU5bN2qEv3pbLyb3tSoTY2+VRL36aKO2sb08jEn+ anpbqa6/t3fX328v3zLwamZm5varC7eEGGjYZqUFIRzZkeW7CEGgHvTaq/iuw10Bqu5pOKkSJJyt b9hkBQUlrGolAyp7v1W8ZdBWUXO8ulV/tLFdS4btmtXrlZWVldS0UBsTyc0slmJtiSNqkarNwCrg STXhiYrMT5lVW5HXCrSd2iK0bDnMkIHf0I/guTY+3NkmtQKRzFJ7R91ozwIQ2hXDwrtZz8tWfqfb X0ixAOLkdNjeFx8+LImbR4QsErJyiRxg+VHyVnTxJnHlr8PhvJF1xq/D97yReOKytbBpqGK5aC5G u+ZSOmGmRDTlxYPYJw7Bw6Xi6pOEUiQmnN+qKmXi+w84740Y6LDVbYhzbrDNuMGGYHF4UkxTkbFE USu5czBSsXSRR2l/e986PKF9Eqq/XNVcMM394n4+XyvV7S0aojPM/Txf26Xqbt369tMvy2olO316 nhBiZ6duDTg0RUvsoo5HhjJwvVau29tiitKktDKavpOLDl6Axwug76vlCoSZWjqEQlbL27tUE4mC 40ax2hCxK1v3K/XbJiEjbcXs9Z1nxsSkQu/7XHqZMjDpyNBeDzWKaeuPC3vuEelqKh2mkFFbRnGQ bKOxcWzbm9N4glKMxmDmsX/BzDLCXsgH3uJk4K1Ox3TvNX7zOS0D9Hh9SjngoUZOiDpyfnkTZgGG C8r1Vj5/iBnwPQP+e6C+NPUzgna/Jgpbf8Keb9Cg7039wAIe+bwas0uPdjJj9AO2OfmQ9je4TWUg ZmBNpWN2AD225SQVinjDDFxEMUxfzv04MBRy5QnivYDNwaPEkkGGivu0oxZItSESqL1a0P1qGI8M H17VYsJyXlZpeQH2Uq4fqD0zTh0zU3nDKqLmDGKOQ7vnHkyUNJe3dyQd2PEpo99PvF08hyY8KGkS odpKKV9Puz7+9YyG6BFVo7YaS6pWZ7pxculxhamySxAG+mJtr66Kx5m9vhtXcZKsd0HROucqd5QP HYqkStVHlEPrbVkDTDXoFrdsmZ9pEiapWycn5wpIurjylbS1pbLghG4xoS0nYyhkHdzWk2kXjPkH xgaqbi4lEleQ0kMKWEFl9tr5ztR2BXcFp1TBoyCgqoH7H7QDxwcXDI6MguLkFJIkyDHzi0Cd0w4t Ad5HpltUYtKSVhqoq0mzpMFdWb7K16cxlOEiIGcfvM7mW0DiE8bn557rEWMYvSnCJbFqEc0sbKCk Gz0ZxzKnZC6kyvJ+2m8yJHGhlGXr5HbXQj6lg1KzLGnrVpt0asy0W3niR1JxmWCNIJ+nAcz4KqrQ UuNhnc0emSARgrJFR2hQSd5Wqtvl6i77djjynnFqIzobxSWPvVsTI+oZFypVUy8T/y/UrqWKtCrK 2kyBsvNMw2eYhOEKB4ik18iNA5qSMj4yXdKFpq7qY1JvKRS0y0StwrepZM6W/JoyTOhsMq1FVtUo PUyiXRYfJjExpaSDiIIjDmgJwouakYsvuDQOVdMSsxvjMTlfZEVyMqaCjXjDm/nJltXKG10Idma8 vUEbiMtD6BTPbKHk10M0cUk+Y85cAUjaJi4udumMwATyqRiuT397Q1S29C3X/VeON+F0k03DMIqk 8dTFdI/htq6FLquzDQVkZgGV7EgHdExYXoDoz3a9k8RuTonai6aWz5HMsms9p1BBkd4R0P04gAtR Sl1I3KR86Mq5Dhum/6G2YTTuJSwvdf/nYHexC1dMu1bkIVNhl9ZE6qTxculfK6en2ZBkaj/D7DDj oxXFqWUmR7DOpukhmqz7Mp0XGqO360zHIWkJFWj/Enq+rvGRDqITDxi0pihNxxySB6VBujxdfWNq xpUX3JJeKSgXUUjGBqqVtPYwmnYgzPP0AOk1ijSeY7Ynokve2+j6YaLCY9r4hRDYA6pKJUxPJC1J 4o6wtBqhOejpoKaqMzgAbs05Uz6FR1hQdEwyPBMUn0nohF4hJZDGmZWZruK+BZdtOBZmz85ltj2W +liGeAsJWgEekUuOIsclagbW62VdtlgnJnAnC6xvcyUQMXEVYn2vDPfIABeQvaUD9knQW980ezH0 bmmxJcC27TXAMjF+EdqCxxIF9myUzy56vWsnTEN11mtzTV18IZYsdszuRl8Y/NdIf6VrloC7o1BP L2t4OmwcE9r21k65vqPWMgks2SLtlboRhTpllCbjvm8KCs0sU27cV4WJfuefn8PZ6k3IJJhfOLQx 8TRLWkgPOfZRt+upZvyMJrx+wTVdGK68VqT+4t2mtIXFcXh9o4vopi48VphAlqUM7aN4fAFWav/4 M3dsaUdfUl2VUQfYB1Lcsm0LzpXT+sYZ+XEkqvbv/7wiczk5A3LLLzMsfZRdH5Gw9/b2gFiJeOpQ lRhKSh3TzVLiqdkZTlNLaCesh+yoO9iM/M2DweC+0Q516iIwhzb4pEZm8xVcIDVO2H7LeW3g4we0 m09GZDJ9JI0OsfNMGQzZb1Kz07t0JJkiuSd13HUop3M/oD1u9UOOQzq4UBgeHBaX2rVWQ+ApSyrT tUmRT4LwtU/JZ7LzDCSz3aB45iVVMwAkWEG2x8dN+nUB9YeQqfLpPMZ8pUekqyGDTlKULrKX4RCh fqAq7V6LWjMOn5BOO1yqBUrrm1+06KqNWmc3rOUZGAZH2vQ3CEQJC/nogirVqfHC9SP0P2miLCny oly0BsEA1S8dAqnzJrXyEnbRyul+LM66Sj/FcNIOP/w4YpyBm6kasnOXgF86V9S4QGkYxnw47jye UMmRhao7wxCl9PgUGksczpZSJVM7+epHFWKNZS11bMA2HqNOmyhy9HQ+wu/qI/xUjDJmjvqlGFVE 8Z06Tw7Zd9044L4IORpndqN+JqEaLk+z2oUTEmXdflY/tTQU0a82VcoaSBiCKFB3h6oMJy1Disr/ ng1pYkzH1+YTLJk5tGKOZqghri6Al0aV1i29/IsFjQr7kTupa2bNeKTOlTwHS1O/+sK/O7T0aRZn WStoEV5R9UA5iva63c3W/7D3LfBxVXX+N31kEsqA8hKQ1UuskizJMPfOO13ENEnbQPMwSQtSapkk k2baJBMyCW1w2RXlqeL6QF1X/cj6d11dZYVVEXn4FldhBf8r4AsWXRTUXZ5ioQW639/vPO65d2aS SR9Qd532e3PPuef8zut3fuec33nlJJeQQ27CyFbS19ayRinFVNbksCYeJXIffzRPvbRgMJSYrpHx HFcfCsFInaxUqsAmZUtDOodZo3k0uMZWQ2WnwmKWQDGU2ZdUgXRJK1ejltE4EXvwgFOfb/dnuFfU 10Ahsv5I567qDFWbvwtlLZcj8wkVRNmy9nLfrbSUyHPsZYtkH6qRQfWyTk1xkTzZZJSP65VPufC9 vK5yo+y8tSi3Mzc8i2jJ/bEjen+s5uHp3NZ8kVbgsipbbIQRW2CCVUWJXpIsRtSUiDZKTTbJQ7y7 yyuGWIViKEvNS2gZHo95eVi1ZzGxTD0I2jOAdNMWiqJsZ7JSIXk6OgaQoXKcEshQVjDSyssseetY 105bmqjjj+HSJPWqp5U2qyS7pfLBbiTFlt6tE4nrdTHDxraiJnuTQ5vMFtzcPG/RV1+wlZjEK7l4 hZIrSaeuRZucGK8UpHToYot7xVbRp7+/XrIZmzUyvi/+XWXcL9xBcRweFzMZBRuDfOZZ2mdQoKk5 0RWVuWFT74ZmzuR+SMEJjaSqlyJmiPo7opLr/r6k7i0VnydKPBsmC4P79ZLZaINUTq/+axgsNKh9 faOst6ap0+q2zZUUcRP3VGUkJ4hFad6F+ih5zpL8JFgFjM4DJvSvR8SUcC5LU8FFtWRA0PLYIFGB DXyJL1NdE165V3C60BiNSz1XcVeC3QiPYsueTHSLYnUSCC00gzji1wUGZlGGaTKMPomBgtjlxdoV mv5hhatdFBFQ87wY8ajxAWnY88P5qSwtL9zkJDYjz8Suu0ndX6exkBrdyRXAg5AgILGho68ZQ3M5 b06aTprkpN7xhFqMLBodKj8iyzTgS87/TNCaeF6FTSJ4KscTMBw8kyGNO5wU5iSn5irv/0A+dvR5 SzrVbgU9fJFr/JHc7ARpOSDQsuPUs946Zqu5X148qHqhFHkSZ0mVI1pNS4McFG2B1pnOskKf9lWd 5kQcbw3kHFK+E75Tm+XYb1jvFyGNEALrGui1nWgynhRlsmFwTUtakCWKm5w0C6EM+aetUyJYtQgc IbMv2l1nNw6rzXWiZWi2aTUMqkRupEmUjhjz8C4OpBj1k6ZG5UQDV6EcKFF5ghpaiB053iNBiR7J jXLgxDJiAYRKImpQrtiqq7hZtSN2UBlb9FYMcxXmaoDhFtgVgnyimXpP+dE5oaTXieQ6XmRqfnWs nxyIXJibU5w5ZeynMucJi3J000BNHf438LxWwwQ4ckSPiPPjcw06GewAya9EaGi2CNdEZKSQE9yT 2wnByCshOHtdFpSemA3IQ5+aT/nQ40XesYC4ITUtD7ZcmJfTYnpTry332nOG6imHsnKXNyVz3vKm s8AObRXbmLdvlmaYJ7hzoiW5vwRsUmBsLUyTwkR2yPLTVCKR8OHhfl/wIbW7IxTq6tnYNdgZkmKQ Wn8pmCKhEOJF6/2IHTgdIuN1uDQtBwHKBOB69Zs6Q4OaT0w67W097Z3rQ+20qoA0atlpNH8ikrro 4ay3b7Crt2cg5O2QzHmNiNT/QBqFQkrkh/pVQ6ibUNl26X0oUrVGkaAM18kRqj0hu5DFLcNqOWAR TrlEtFP0yvJcGCYb63qlljO6snYG+SlMmx1naeplJIcc4BKaC3WKFSkmE4dCzs6dIWO+OTseGmTl UbMtM6lZtLD5opzqhNMd2ekRUl8g0FnOGxdEBoTCJdR7VigUg7k/p9VloW5ULm8sT2vKSqqb2A0f CsXhtV1ka256ujAdWp0dUekjXRCtjgG7XcQTygVaNDFL6iOqg4pEgmIjOkaChGmQCnfVLBGZIYQg 99MrEkmQkJtpR7P5cTBDaDVCsEkpPbeD1ETNtr+yk15GfhAkZF3SJWT2dtSGkaKdRBdE7tZImsrx QNeknCZdNAqDhhK+kst9ESXBEzsO+jkIpAKeHM9vF9JroSRxvGlmynfaCsVdHgqyg0c48rQETaXC SQnNdhXlMVD1yQu6uxmkx11YJaQXOnakzPEiPjs6JQjCYqvUzSIRB+PIEZDd54NGRDM+uW/nflSq I9kimiTBAK3hMkNcsWtVql4C6qP59EXES9yfHBK85A1xnbJD3FWVAjf2DfrUI5UDcBcXgFYgV1Jj VAwotriA5Kh6pIzuxQxiIWUAL8+rFIYaVqqerDkEnCclibIhSQ3JGimzzK07Q3RSyMycWmIjuGjE 1jOrZaImtPU8vcx5PaK3pUMk0DpDvUCvkaYZWqZZTUabKosFVLbVbYGxQkHMWUTC3rAymfWPK8uJ usbJAg+JwEIkWYdRobYW5PCxyUds6EASGz6QxEYOJLHcfhM7fP5NlHZcHnnDjKGGcnq7SBXNU6Pg 5ckRPW1DgtHbvBnySXKkJleyS8yJyF5uqH91KOlGQ6F0RLSfsgfZRwfEUI8L3xNRfM9ERDNLFm4C Fk48QrMsdu9ZdiN/aaJPMXLrJCMcpVa7r21wHRiYVE4YK7OLjGs30ol6TSHHTfNrkiKUiqhJ2kBD E25Ey9KqNLs5f4MSDjYooQGKXyqBbmM0UqaZ4+8O4ug65T57O5TIHVFBUjrUVM8CMTMauDCdnjGl okPBpVSWoFeyMZAlDrJR5UncyxM3s+hsjLmLDyYWWyDru3nYvEB2x9KReXsQOuNjSFUjDE3zOi8p iLi7YEGUiWewGOJIqxg2Kb6PZzw25i+cVXHi8ESM6kTU7hdjFeb8GNnHg3UhkalYF5Ix9UnTTcK/ 8k30khkjaV5nJrxOdGbay2ZjKlq9p5LMTDm6yKsJzyUvbrVeSkKTu+iQ+ERCCC8ts8IJN56RTCnl mrSPOynJoaa9GvnEI/NstZtHbpuroXxdRrHYvn91US5ztqdJSz6W3zo2DsjRy9Zp0hRPGxoi3TXV q1Pyo6KbSso+bxwYCe/H2aNonUSqE2jQfWsSRNpZNSLWbvlWxJRZrTR/DkU4ODO/I/bZsrhEbuGr 7GJzF1/qQ7QjMYrZnpvMX8Tp8r6sPzeVUjpX7c9L2NCLlzCvvQyk7eCkbPilKbKDXF4jL1l5HeSE 5Q7V4qqQpIXSM3oIF9TikrQfEjSp8yN58CXo1IXJeSVo8qAwbvLgS1CdsIoS9ACnLbBtvX12eloq eHfQ1ktWj/KaPG+XUXaBlcT7NKSzK+/xCeiPIrZWDxSz23NiN1d2fK5IC2bRJTqlaGqYKs6klFF4 BhNSLhE8d+ctXzxNTsiJbc7oFg+2r5NTiVxRjMii32Mug/a3h6SUoVcxtUOHXQc/IGtijtz1RRHl Wk+uEwHbpNbIqc1uPAmjz2tupTPu7LTwFGYyajvZKuE/Lo1hjkgjPwdyF/TMTvAR3GKqoUltRwv7 F7ijP1pUjLO1oMuNPjEhPoRuFZnVSk28zvk23czKld2+HKqUMZGyJ/Z0xmxzPXqnyHlVeXk5oVGD PbmGXHZdfWJNG7GJtw9Y8UcpO9kNSsngNNh6UXwiaxa4Tw2xo5zwrooJknrv36keQ5xuJxUbRHw7 CEsWbINtzcjSuSKCa4tqXYlcN8XLcZt8/e6IXDLPZTVDdc+/2B6kGomX1BaYqHydb68RjwX6hMJV rVwS255lnaaKRZbTOVrbTE6IwSiHmNN8mb2DdrXOcJmpTXdqxTEXgV8i84Sz3H5DbgKL+6sc4QRS 04osSETiqEKccjfl+jM0Eu7ytKCxCopj1nHS/EdxDKNPQ8V5QDdLBMXdYvYZBnZZyE0VvMPC2Ech c1Rtp2DVKolmobinO2S46CbVDTMiD31HJZaNlMpzOV9tt/eYFW2BTRuVyrXqBshuNAR8U2lueMV/ qt2YzLwWHKFzANUiFcnQa0Qd95YC46aGxExLalhO15OMEFxfnB2fEbJduidGT8B9YhgYAVDNE6PN iKOggV5KuEIahZZAME1jpS1L4UaKKJ1xRenjp8vPGD/j/EzwM8nPFD/T/Mwo5UEiG0JCnWgoGUkn oqGEfMZi0VA8kuang2eM7WORJL8nSHOjxnTwT+ZkJJEin+QiEXHZZ8qhp5shP6kU+8wE/efgM5nh kDPKP0JmnzEOLZPxfMY5FnFH+0+hExvIxZkqMg8cXjL4CB9+KJTHEPLT4fJwOD9inBOUN/FInPMm 6nB+cH7GOYdiKS8/R6gkuQwy7N9JcUlEOT8zRn6yf2Fj+h+Fn5QRcpL9x1JeyMmM59Pl8mDNnSyP of0vD0OL/9IXSDIbSnPyUSzM5g5nbpIzJyOKhbMybbB50svQJBUoVYEkPxPsOsFZGY8k+Blln0nO 3HgmyODD+5GhavRVZn6kff6rcMrcA6EXpnirGEjc0XRfbgfTkEsEeMDi3ZMT3uRsrh8cKQzb4vKz aCxpN5S7nMyu/nIyDm5xl5PNc9YmrMTtZC46WupetcC1auiBBS5zc5rtttmttDTaTbcM5KZmxPVs sKYNN5HwJndzPflphifbJZnq2A00T65XUA6YayYR9EZa0YCqFYk22+ZOKNCKmbTAMtG03SCPVq90 DLSPOm3Tn9ZXB+goFO0WOq8dfcyYFz5Efkn48c31/Wva0emOJvAtYq9GbykHqusj9rl0vCzyDZa5 6SIFhdd1uemLCsL2zOwEbb9t6FebGvvLnFhOB0CDLxGdjeLeH9vRhxRnS3PKyO5MJoX4JTZ7B+Xz 6pmWfG5mtGUiOzmHIdX2YksxP9UyLWPQEnUiMztnmu2zI3Z3dro4Bp5pts+iSZuJ7Hbw5NhkFjHu xNc83d/QbK/FN1r8Qu5WU0KLZNtN3icRJK2shPeBGdSPIXD9JH3tiNi900RnTcRumxyhEyspx7pF MONjhWb7zIjdlwe302U/fRGU3PiO7GRujj+syfHqdKbTeWGWnCCIs3J8UlgbiBT4zOUz6Q2EkRfI 7nWIxPDY7PhFGGZN5jj7OwqThQspGg2UQVu9Pld/mZPBub/e1YccPnN2MqcYOVk+cylLnWh0Ojfe EnVFhs4fG7AALbYTR1wjBn1lTuLnoUJpFFLlozA9Ouwm4rGhfFGXKfJ3XZZW2M6VRqCTzYUCl6k/ rg0Is3W+deMNXnUXUUr7pFrCcZE+b/WNnA3qN1bftJurb0h0bizQvuBe6vVL0TeA4qLxEzE8KWBI mtFBrVOQ9nxxjPAi5gmbtNxyFiO33GbvLkm6WVLLq8zm+s7Bga5mFqxRCBnImI781jy1Nu3gu9nx LHq3kAvD5iUX6lT/xr4xkhfuqU2r7MVIpga7UYeHdokOj/ZHw3lRoqHWfPUHLmTwyl/H0xHxdIIi OVVRJHsbHGXYq2x1yUibOKEd1DUZpu4efIHvBSkSFJMMPeCCodHNydgN/s1EVXHZQJt99lpXVxYn 3uKkNYs5cTNZ6Dm6SBZqS7e3c6Kxq7vJuCNARdeV0WU/HN2EbJJQ/w9qre+mBc2qHdShxtyUP9SN 1NINF4a4BWwY6DDolts+QeJkajo/ToTTRDgpCUeTaW5h+TwqXhaMKK9FGzNX5NfuwtbZcU7kmmlk 0dx25CU3vXSfUcv6HMlZvm9mpux9M8hQtXmCRGx2cpaWj8hW1EmpZj6V4XbrTcilXHYWJHm7RDNt aWeKgdszSJrr/RV+upy4tEpcPL5ouhtQxdVWTzOM3uGZguwBJCmMjI99E9E42Jc6g2v4pEjuNZ5q d06O0PbmTurxosPRUIZxK7K41+mIt3gs7UJe9edGxqmxRY8iNyR6BojfeH4KXaMZYWoj9vLuOSSt FsQJ7BEI2GtdYbYowtxRKIzASxudFJ1JYFTqXSJpe7tBq72jxFvN1UZK7sD5X0py6Dl8apUO0PH5 6njevg77dON+IvOenlV0Y8HpvgsbVtGdBKeXuwhjFUX49Mq3mkTCYeP8/UonnpXNOLl6oijnj1Y7 rXb7uraens71dj9dejkwaKzmnaRzLOk+tNGI10I1heu7B8T0BF0gVpCHtRdoVi6rT8iw+SCq1hX1 dM7fivq0HcHPdsL1TtTZSb/6zgmqGJPDYtUzPjhR8YHzaDrX4jtxY5U92L7utDWsgszz+Rq0g2ZF fT1ZrzOs9Y4xPUiUS+rhFkVp93S2d9HhgxRjRCeKYCng+UL1kZcKPlBTARTpWopyZJ2FyJ5aQh5k lQZxPvLoioq8apss7hCq9KksLVZaUR+Ninys51fO63q6roKCz12biWSyp6Eor+WiJCeiOOop/2XB 9BqXg3ANoBiJ3Kd9bLkc79NA7SkEHJaJvN7PUJL1svh4B/AIazRZ2ym3BiotuLeAl/XHpZlfOYAI HZI8SRNBXB4ix3yJUzN/lEbeuD4ymx1/Fa/MD6zc5bsUuKwQdL5oHglKUdJbetQ5IKggJF6MAPRO Jp019cyPgaIVEU5whJ2SCPMk0cGLriZfGlmOKWJcIbKKHdcHb80pIVS5vJhMtEoyZeuc4uXeGblX T3GW2L1RlrUkhzDr+pls/rBQW1hs9NJpJNwNl4f0ZMX9acy2akaOeQHJGBcz8MVxpF+cKbJCUNoZ 3Vkv58K4G7WKj9mhI3q8KhdRbndG60UEoly3BV0xdeiLgyAiP4hTwuSMsEmWIofU0x7Mcumgas7Z iQZFzN6IncJiFXxESDqKTP367g3+Q5JE1rorpBuKd3+OF+ELbdroLB+wzVJPuIg69fIVD1l53azM bQqjgv+IdDoU5sX6ttNaL/elqcnmYs7kB4woW8V1TiM5cZ3TAF9ipBdwq2OsBroHMPIc8N1+pD56 pyU225ph5ceiOFfBdlvru0bFpk7fqn09Rc+3ZklG43Nm5TwZqWl8Zwwrgtl9pEib3cvRG2qtZ/Un Bu50Ih2HS9VzKOedYTVWImDwn07djNiBuBBbmTExqpE4XUHEAnxUmOZNC7IX4lJxdHd2dLUhTm0D A11re7o7e6roinR1dpk7De2cKKcQrX63T7O1ZjbUx4pcvIjOdmicV8aHQqH1rt1XzM2OFORJuqUW 3aGNIduhK1acaCQRcSNOJsQ/OlVWM0GofL+PfTunuXBewQGIuoLewPb8lHeQb9DoESIvsYgjPJW9 70UxMm8CYI80N2BagkRcEOgjOzr50Xjzh0VpdpMh8+fdpshH09BU4Oo1Ibu8tUHNVuQSQ4KQOtXV GDeWtwONmBGfhIo8C6tyPub5FCTmJrKCnNpc7PFNqU13wDNNCNFvMM+TyG0jF2Z52sZvVIWgfMWl L6nnaNNXvpWzCa2H55aMGWNR+qn20ADdN0EhIcBcwNQbGgzENS1C7WqjYcUMjSvRuAWNFNdoi+Nj eVH8YTt8uK60MQwduu2Bzv6NXe2dC4wePO3LvlfZ9arK6hFTudo3UlL7boOXqfKfF1P3bpPZoWte mYuTVBWbMevdhGnp1Tt4V8cl8peg2QwzgVBj0ps+rXV7zjseppK1IiLO9VN/xI/pOioDun0SvsQY ssGDFPPh8WyxOJGd3u692a6fYtJHUdxeODNXamaarsHXjsybdAvKM8/3eOgXSOMLc+NgaXvQJ45p oQd7UmwZb7XbNgyuQ/PR1d5G+/APYdYUUvEAMGeZhqHCRV2LYtFF85qIx8LcNjBFnRb0NkbtAgmd UotgE+RE0uXSxcaId/QK+iU9HbLJJj70f7AbN3SjvIepm4Mi4xaKNT/KoknVNpGJbnSh4MBqPSRn SULHW7hn0Of/qAjKpIcPl3yaKMOnA329PQOd/9cZVV4QtxhOrURDFJcyGuXGBOM+BlElJdKCFtZH dGGamg18PNCY24kypEGd5i034pdYSTSkXX3rOvu7etba3b0dnbRXrZvY9UXo/x4SnVghUfwXAC6m Dxs4wnwgN8PXy5lklV1p1zbji4Mu5qC51KMT9RVjqlwx9q3vHKxUof/Xl6PYDriIgnRSqpfQqS4z VxZdqtsgapkdEx1Ube3rQKCXKgsl3Yoe6uCGvtIiCJ5iWfB0VOqMmaYDWFBa8rJGeFhMAVQSuTb6 RtSCVSd1eTopK+Za1F3REEcVrH20RempIued0j6xKxxXFrwdLaHV7RjyT+Vopapmj/6ghd1OQxGv 1xaPuCLQaDwkdwLzAR+iTXJK7TgmquCTBp1EZTJuOTK985Fx2kNrssPsspEPkGPFCuvAx+XYukm7 8Gi5LRjZalKOoJXo4KJmbRkGZXN0r1JLqRWdehgxSbnU0ZdnIWqSQtIkOtk/htfC++r2jhILOsI7 YuZWnOjJrpgkl2JqyYBnHT/TpqropRUv0IHgVTBDbwVmwHB2fWGH2I/hvbHG1hcHhwLk1dozeVnW XTqr0vtNKkgLCVu3nwnrCK3Lbx2T0fFeS+OTKIlOXscmuf+0Soh1hjZg1NlCJ3Abb0YtiSXM5AjW Tq0JDQzYF4rVa8arPytUNGImASE22pxQ+/qufp6JIEZipUzQAjLDHvTlpuMIPU2bK1znJy9UOpKg uZxnoXJC9Wxv90RCPlcMmbOydrv5RSXDTINUFjkdWhLYKxvb21cPNK0sKxvOgOPGrNADjZSRJ6bY ICmy2qPbGHRdMYAeOjOsSGtV89nxJi9CfpnktYsZdFba1q+nA7PaOzs7qMvyIow6Dt22j2M25d23 vNhWUMqCrqBw6DqQTeC8bdeBbwIrMluAq5xOKks+N8aQAGWsFJm4mQmi62iofOi8BVpyHVT92EL3 M4/qx4m2mrMHh9ooysYPnEQcaJNSbh5n9HOq7IsHyZoEvEG2nhygdqJ0gGUSse2SHrpBUg65zIVe Yo6tnN4eDOinTIJ0DR+vLV0329lRGifTxKgZDCv5pVq+r0CLHNTA0G8qjXiQiita8WgitGZa6KrA UXk6+dEI2f+JSaAFEUwfb3FibhnCjlDJJtEa5agBkcn3m8x5B/LbS1RlZFP+fCyhLxusaJnMtkO8 jpCnko2pAl+8Ub8p2hPaof9knmA2yeCSsRCP32Q4XFi6aHl2KJAMVv8qB43qBYMJ22kKBiJ6Hai2 KgjTubtwMBXoxcrSi+0zvXhZevF9ppcoSy+xz/SSZekl95leqiy91D7TS5ell95Xesl4leKmhCYJ K3FyWFXyRoSW9FUA6d0XdynWKlSCIFkx3Eq5pVN7zWVm+8ijrsJUh2nsVznO1c0EBmMbK5PXcnLQ yZTISXkNzv4KSnQtFtVqBAsy0G6YsQoE6HXRDyDfzBeeCK7TyJ1hGYqeHpnnk85E2S5Qic8TmiO6 Ba6zHww1D3nJUZmWsvrTcnbB3CvXCgsta9QJbVzbPmCDOWlbPK8SkD0Ziup833Qg6+fh4bgrSj4a E+1jSz+tjBDv/FraBPpoxluEPmDedjIrwtC9TifY6zy0lL4Ud9VDmlf5ayR00R1Ptb7DI1Gu61le J2zSsavpeyLZ7bS82HspJREstlhgqOCi0NZ39g+WHfkqTfBMIbjyydQN/x8ZGqvrkBc3Jn6JxpEL K7QcwQm28pfw8wWtaunt6elsL1kv8CeuMLmiXZxy/UfBFPF2FV06qUOowkssTBYxacjOS7zD8CIV 46QCL2tpJMk1VYeCcPVMGuBRtXTAiXtM2tZ+Vk/v2es7O9a+KOsGDnmGNO/lXBxzhg/3Lgv2NtUM 6gPFBhe7IUmUVnvwksMDdOlxmY1I8xwYY7fxifM6hW3yvNNFB7vDdxo93wasF8rnJ2bHszNqEfIM LSmUWxt9J67TPjJxh7w/K+QlBuKIbO90MONqkVZ597WoskW7cU0PXSRKx0NAFE9MFZs9UczdfWNN vd0or/FssWlTob7I83R7ZFzeRjpe2MqZoTrojbTI+bS2tXjwKurT1rThqUMklYqISbM92AXJb7Bs l2ZZOO/rsBvL97noOgNxJxL97R5Eksy+TxHfuzrtSaQZX8ya2ylqrrwOYYZvyJHVXt8I7CBarnAw GLP56g3KtCx4IMvn4A86rYNuK741Drriu7zBMUptnJvweTU/JaJNZgGK4uP14mrB+Wlp80YEkZ8y XsHDkBbNgqUXioPfxguF7bxTROz+GuzobivDLLY+uXckRxdZKW6dKWHGbFGyYLE1vKaH2GsaAlVx htzZ0dRaXx9vTjpRcjIsBFBrPf8SzbF0cqHb4sPhjvyolLnSH3qsqVRS3qs7E8gu2tBhpAw1PR5J Ogk+06y5xPVM6UlTizlQyyN9mgiukWImgqbz3dQJUpFwuHtAH+VWVPWsKbTaZ6sqXBMG8j2t0Wg0 niR9/QbIDMdunuZtGIMDjdEmqkz0Z2qkcRoVJEzHqLRG061ulBlpC/K+OazeGk+3U2PN0baxplUk wxVl1yXKI0Q5u3V+ym60Neba+YmJLdlisTk8ld26BUNP0I2ONclwSHrBIj3WHENY+J/np0sOEAfE YxSfO9tgBwdOHH/T9A1iYkt25EKixcQgsbfwDgzYUHxVbBNJnQ/FkeHhscbeJo5xrKlZR3hiQkY4 EnVbUS7DE1toubDMDWEAWYcjjTH6lu25OVheoBJCYfOKXZdtKAGuTIn8mqdEx9nOcWPxRDKV9udq Kh7TuSriGdXxtEsj2uo4NvzZdLuSjGaZeIFBOLNVkJm21e0dnWvCQYsxI8PS0cwiMqzVTVCGyWig iIt4IshMtGNNR2ZN1J/IdDxRRSINxsxQGjllpLHYMjwxIhPKRlQrSl3eiH2GFAYc+6oCcGNc3F4A hYlVXnQzSXdhYsPDmhhcgxpX9uYw3US7ZTg7RXyDQhfsIDlieGTL1JahYVER+Fs6k8kk404gvzKZ 9Lz5lQ7EIJrk/EI12ELTrV5SEk40uricjzN3sXZBZrtXWaOIcZy5HCmLEr9zqqYKO8gpJQoc1azD joGYzMbR7LAUGPFy4VJP2gy3MAEeplxE8ycrupE9iVgsHhGJKiXsz5o4JSgGwjTcNrIllsy0VksB o1cnzg3RKs9/OrlA0vwxcNj/FnSjKRK6D1uu21raqNgHuMtqnpjaFqHtJ9rYYfOxBtwN6Vd75Kfn OW9pU3yzuPluhLvhW+WpJBO57KQ8DWCS+kbjUuEoD+PUF/hRI/bGwoA62pJ6X0Vb3hwoTxvKjegN gLY+wgfd1+msOAwHiYrY+p4AcSOod4887cnVV7CKuzWzaqjlXc3K+SW6Vl58cnysLvWKxAr6UUWY LgIxgiwWpsbyRV7RTHu45RW7GOkV1WGTM+qm4Gneask5wZvThwoz4shc9EHoWAnqinDWyPs56RMd QUXf6K+4IZY/B5JYHM5NZqfzBX0bl93hHyIRKfN+MHm8r3FzbocTKe+ChzQ7Cr6PRV4XNE5bEnlX 7lR2ZkxyJkV82uMdnWJxpjJo8Q0sfJ4C3auiCcIpHWWTvzA3Pid6tUVxDrN3c9xQjrJeR9gtSeGo PvVDByTpmwmVF7v4vuvUHq5cxRagbsbepB6T1M3vXl5y1UfZiHuLyhxhWxozOkk4EmZ7NY4Rp0OV XEVE3khXw257h7aRLinoJkQHJdIjSbMxYlWY44Zc5W1dYUqZaZbL3kibWIuhNP6F+gqoyHN2B3gv 1MuTPKjrjcPqhtri7BC69GK11ILfEfgknXA1SBcGI/0qUGVNpxGFYkn6H2rrYBPHQd6AknHpsh4l S4l3u43sYtFTkpM6+90Fst9XdNVnP3k7mNnPDtrFxaMw05U7B7ZEZubGcyIoOvTGNotgTX58RheL iqAoCvQx6BIkXRZupbLw1xjv1G5bnIJNh44L1Zg4K6GTL+XrX9/OyaNzfGb4qoJwmFyynqmvqyMU 4q8h3a52gheYHotI7yRzoUVORGJujK4p89NQ+iU5sGVyQbqupFtyRnqAspoLbRc3Qw+g6Z7IhSgd HKNZSgdnTGhNdiI/PocQGnl/VtE7bdR1Q+0heeYo2Hx1SJ48GkuF2kLy/NF4XLlJhBJJ5SYZSsWV m1TI3el9AcfsTKbVtwxMwqVMHuSWl+OBmKqjy5Kkowgf3de2FoV2jHNs2DO4ZHhxf9affn/6/en3 p9//2t8yy9oEnAdcCFwMHL/csk4ATgEagRSQBvqBAWAQ2ABsBLYB24HLgMuBK4ArgauA24CvAj8G fgL8FPgZ8HPgfuBZYDdwTK1lHQscB7wCOB44FWgG1gBrgXVAF3AmcBYwAUwCVwJXAe8A3gm8C7ga +HfgR8CjwGPA48ATwJPAMSGEB5wGWM8//bz1OP97RPx5UPz5MT3u+cE93/7BPfTvZnrA5l+k9aeF dUl2Hr2k7pKl2x5dYlm1dTUb6mom1lnLjmS7C7SdcPP7GtONsNvhswsv3UYkpWkZPSxBa7el3Anz xQGzpc31msaRibpL2s883uo9c4n1RmAZGc6g8l8LnBvggx3ATmAOuAh4C/CXkj/eB9wGPA6soPID jgWOWy5452zgHbKMT5DlRWXyvJlRlQ27KhqeNg2//WMxPGIafl2d4T8qGnzOQiut8O111hJ76Y0n W4dZNa+xrJqNlnXYy6ylK2uOGnncqsH32iUrjr3mRHyBB5RI+PblVs2GhrdZNUda1okvZvk/BcRR 564C7gaOrrOsc4APAM8Am+ot693AD4G9wF8chvoN3Av8Gnj1CsuygZOBBuA1wErgdUAMOBLdtRxw O7D8CKQD+AKwBwmdfrllvR24Dvge8Fug7ihw3vPEe3vM37O7du16+mn8599TTz29a9cT+vfYb379 4I/v/tev32Z96frPfurv4bduyUar9sq9e/eKt8/ot+/ot8fo7cglNcj+uhqrvuYwLora4nN79x5Z ez2edXvJFtlpHVl78vPKvJTN52vzEjZ/Q5uJymG1r3hBmkHxKQR0mBeOtXTJicAxwGuBlcBrgI0A OGQJsuWMg10uz5jsemANT1Q0+Jw9VtHwsGm4fx8M91XnrLKfH1oL/2pP5Dr84Mu+frJVi6JcaYmK fRi/H3nptctffun5u4VdnfH96E8+bpFECL1WyIjrl5GMCEiMV1AbGAUcwAViwBiQB94OXApcBlwB XAl8Hrge+D5wB3An8APgLuBJ4CkgDJ45AjgSeDlwFJAC0kA/MAAMAhuBs4EZYBb4G+A9wHuB9wPX APcBPwaeBJ4Cfg/8AdgFtIIXVwEbgI3A2cCbgHOBCWASuBK4CngH8C7gasnLTz/6O/r3C/HnPvHn 38Sfb4k/XxF/Pi/+/IP48xF6yFZ+IFTagt9bW2r3pjJ21AcK2m0pY/fLZaV2uTJ2jyw17URfwd9/ EO62+9xZp1NeXA/cANwB3An8G3AXcDfwAPAfwLPAbmAP8DzwgpQF4CGu66MnI7+BAvBXwCXAFUCx AfwD3LkSfTLg98BzwDWvtazDG8ErQBuwGvh43LKuBZ4AngRen4CAAt4DvBe4H3gAeGMSfAR8FPgY sCSNdgb40Bss62+BDwOfAJ4GUqvBd0AGWA28pR3tGHAxcDngdiINu60nd1v077f85xHr59Y9+HcH mu6f32F9t+Tfd6wb78CHG/D9E3c8Yp20dFvxFRY6VojamZzfY5S99csmKYvRA0u+nG3h7vt1Fd0t TdZdUlu/rcb64uPW0cqN4eBwZUcW1nHozZVxZC2FvegDdtf5+4R3a271+oTWG/an7TwFSANnAW8G ZoAPAF8BfgG8/GiUIbDxaMpi4/eUafjl/hp81HwGX6APHsKGB6ozBH/UAUB/D8Vx2OusFWvQx7j0 yiVHjYzV1FjHfHInBH2oBu9XLqm1IIE8e2tZjTRZJyy2HPPAu4HPA/8O1ByD+g+8HtgI7ACuAD4I 3ArcDfwGeB545bGQ2cA6YBOwE3g3cDNwH/AH4LjjwI/AIDAHvBu4Gdjzhyf+6+Ff3v/je/7/XXd+ 7/Zvff22m7n/9dEPf/D977n6HVdceslfvWXn7HRhPI9e0EO79+5dXvssP1+1h55n8PM8fv4lPz/C z5v4+RA/d/PzFc/R88/5mebn2fyc5edV/PwE9dioX3fjc6qH93P99jv9tke/nfS8eovT2/LanueJ zgX8/Dg/v8XPh/hZ/wI9T+JnnJ9Zfr73BRnuV15Q9O7Xby/ot2N0v/MU/daq387Sb9vw1vRSlWmV Y8F9Mew5oIaDGNGXxCB+NEok6fFnqn7dD+wFjkdD9hfAucAO4F3A54DrgAeAUzCQ/O+T0P7+mWV9 FbgXuPNVpe3/X5/8EqXPpyN43DT8Zh8MD1X8cr9p8OmB7jYNt1f8Uvo7rNlavtKqXYmuOwbVwHEr a2h8jrE8vYXOsRw1qiezIdORzmVLlEyvIOvrTmSHeizB5X/cwSr7t8o+4NuBy2Rf8ErgY8AXAYw+ rJuArwB3Av8J/Ap47tk/PPX4f//24V/+9L4f/fAH3/zarV+6/jOfvPYj11x9+dsu3lmc3JY7fxOi Xb+0ZvlhtT+DxBZvT+q35RC6oaU1tbXPKZs6/XaYfjtZvyWl+xT+Hr6k2WLLDElubVrlM51OJuH3 9dLvGZraG0wqvZ7LPrY/R9if8xy3AU+yTH8EQvi4JUus5TW1jz0LcjU8cF9B73Cziduwr/Pzcm4b 7oJ7U5NAOoE6jPJrbxc+fv0sudrDz+PZX5Kf5/KzyM8P8PMmPK3X7E9ZPQw8AuwFlqCPvwy4xTYY +kaTu6+rznDLtw3DP5lfqjTccmtVzuYhsA8x8P2Wippbx9W5fF1uZ4tXrKxZ8sFxa/m9x6OWWuVQ d+951rJr9q6sf/Bll5/Q3KBCqK3x/91nu6MrlePxwAmAA8SABJAGMkAf0A8MAhuBs4ECcEGDN967 HHgXcAPwBaDnNRj4AFuALDAMfBD4EPBPwOeA3dzHe+AnP7rr+7d/49YvX/+5f/zExz74vquvfPtf XTQ7tX10aPM5quYfs1vVuFN2izrYqG026bfN+m2LfitI91PaZoWWHWH95uq39B7hPrPHqMFn7dE1 u1u77NVvW6WfMfazUfjZ5vkZ1y4n9dtl0s/l2uYq/fZO/Xa1fvsH6f5T2uZm/XarfvuafrtXur9P 2/yEItRwMMr6Ocv43fRWw+D7UqXhpp1VOfMZvmQabjIFQpUEPmcablq5tIKzyob6c0gTZ7bXSzda h1DNlzLqmGrr5jPAy1ZiLAi8FjgFaAJOBZqBBJACMsDQymAR2kYs9okHHtlfAuNVOZuHwM+rclbZ oH6HVvkfuy9lOwxsByaAAnA9cAPwHeC7wPeAO1Z6Or/7gV8DT60U+j/S/X0C6H2dZS0/xbIagTOA 3U/zGJ/k/3cg///lus988uN/94H3vuuKt108NzM6fP7mc0X8l9eOc9/pb/jZuZeeT+L5StGPOuFJ 3Y/iKZIVZFEH2V37/Wcg8kgK3vGMkoI/1m+/0G+/029PPiOk5lPa5mn9tku/Pavfws8K90c8q1sF /fZG/Tag3zZJ9+dpm8v02xX67Sr99j7p/v3a5gP67UP67cP67Trp/p+1ze367Sjq/zXsa3nekjYY 6ybL+FVpuMWskftCYObaqpyp3wGod2CxvcH6tFg7We8Olf5fuNq6uQU4H9gJ9DVCDjTNKy1Nw6dN w/8zDR+taPjbfTC8zzRcZRp8pBf81anxM82g8Rh6uWUdeekblvD7UvEeHGXr0feRquE/4tK7l9Ds nJqN2ynG6ftR8suWilJT2B87yYdHVCrbjwPfAk6IWNbbHIz7Y+gbxJGVwG3Ao8ARCctaBZwHXA1c B/wU2AP0JCFLgA8DtwCPAEel0LYAN2Qs64fAY63oe55uWbuA+jMs66wzxBwOzd/Q3M1RbWL+RukE HvrFAz8zFMBf/uIN//zZT1/7sb/70DVXXvbWt0yMceHRWPg/SccpW4Nbnwm0BmTBrcGU0JjibfoF Hjt/1RuLf3q3Nxand3y9mfXDH2YN8De55XkwMBanXuLy2olH6dvb+Pk5fv6En3v4+drH6LmGnx/m 5838fJifocfpmebnm/h5OT8/xc/7+PkMP2NP0PMf+XnU7+n5ll30/CHH8ml+uhzXDtYbmNrkBD83 UKIbX4yy/oNZu3yGynPzlQ2/Mw0P/1F++YVp+Jlp8KV0np+WSI+XkU7nL60gperI1q4xbI5fbF2k edQs8N7VYi6V5lFvArZ1YAzYIeZT453zzfdVaXi04pfK2lqfH9/M2Y9Mw3dNQ+VwvmYavlzRWZUR 5V+dJRZmqfyvM1S6XB6Hn+h34Glr6/mLz27FiVYZl8uZZqBVqjT/d+xiyjQL/DXw52sxLgA2ALPA 6HrLGgN2AG8FLgGuBD4KfAz4e+D7wB3AXcBDwK+A/1pP83qP/OrB+3965/e+/Y0vXP/ZT0OWs6Z3 prBtNHveOQMy30SPdUrqbi7QupvL9ds75Ld3apsv6reb5LevaJt/028/kt/u2U26mg1CV/PAbtb4 StN/C/n/2G4l82XLcp4xzkAdtFaQhZCu3KqkRKvyS89H3+89H8vIRx9L7uRe6SO9l3084PlY+7Tn g5qXFWSxvPYzLMEfUiH9WoR0txHSLs/fEg5pF7lF23iraPXw9lW8vZrKNibL93RZtqfK8k0A3+pG uQG/BB4Fcr0YJwCXbEBbAbwduBr4AXAXcDfwU+CVGy3rJODPgFOAMSAPbANmgC8BNwJfBr4BvOVs y/oksOU8y9oKDGy2rEFgA/Bm4FvAvwJ3AfcCvwf2AEe8GUwMNANPPPwr615A/Psu3r4O3AB8Ang/ 8C7YX4a/b5f/1I/WXoSXbrv4Yrlapj6w2uKkpdv2XlBx5Qa+fm7LfF9rNlT8ilCPWqtDhdsvJ+aj NHdq5fUjibpLyq0bga8PvrqSL/dg1esV3YG1u0+aBl9r6FvRWtlP5SWxpmrGb/jmlGHwyXOf4Zvm eGUeZ2PVOTOHG5Wd0U/2wk+oekxQZy15YOmN4YtOWrqhdA7QkPwVRifB9sc6TpXV4cAxQBxIAK8H 8sA2YAq4BvgA8BHgm91CLiiZsAtY0QMawMuAVwF9wBuBDcBm4HwgC+SAC4CPAB8FrgWuAx7oEfr/ R/7zgZ/ec/ed3/3mV2+58fOflvqft/4Pe2cCV1Wxx/GBC7gCihuhPsBK3zMtc0ErM2176uu1mGWm iQtqLmAuueSCKQpqpZVbKoTmVZ8LqKXmmrmV5paFllsoiLsisegr9P3mnDn/M+fCheO9l3zwYfh8 5fefO+d47p35z/zPzNzDmBFDwvuFhYr5H7XnXkazLutIbRTzNZsoJ5VUOqlMUYrP5dD8/M2bND/P aI7EQ8yfeFJOc1LPkWonSrW/JY0h3W7JY0jfW3T2ocraXN6ZnE2ktovXvqWcc6Qui9euUE4NGsuC xFgWTDltSLUTr7WnnH7K/E9R1f25xVIzPyu3eYNxTg7MCii20lwx2Y8LKCYbv9gtZljUNxibqrrp hv3/x2DIKcC0v5dnllruW8p09W75N9Xjy0serM0pON6LsGqO+OlvIAWkg2DEAnVAXdAMhL2kxggT wdIOGBNaS+/bcN9jMAzBeuoVe8XsG6kVpSr5fztGNgx3IgdYAcnQh+et95FMXVESte9Qm2I17rY+ 94F/IixfBip3RJwAjoPxr6kxIY8HD4h4kMeCAa+rsSCPA/uKOJDHgF+JGJDHf26I+yygZid1nx/G gF/5NM+ebesTlnwRP3/urBkfTp00IfK9EcMGDezH93+IKDfhrB7l4tNiFXiGp1dHZYYkLl1Ex/Hp SnS8UMm9rOVeVXOvqTMuN0Tu4zeU3CeUeZVJWm60mhuj5B7Rcn9Wc5OU3NEZ/LscyXylwduNvsvx 7O+abVHsVWS7K7ZPpmbzVlXea5pm47wJyr3BEWVWJz1H7b1v5FBfT6PZI6SaiHGtKeX0JjWE1HBR agQf8O7/K+r0ptyqDbMijhiGsxkMQ397vLgUMxiGYcYm2Y3i9LhP2wns7WZyJ7A/rx9+7zURzBL3 YFaQCNaC9WADOASOgKPgGEgGKeA8uMD9FtwGcAxmAbVBEKgPmoEQ8AqIAJFgIogGMeBz8AX4M+va ebj+z4d/2PPt1q+/TFhujZ8/h+//iLTd/xF2W2vNo2+rrXkM5YwnFUVqFqm1pA6IIw9Szq+kUkil keJLOLy82x0tx5NUWVI1RalalBNE6n5SDUSphpTzKKmmpF4Qpf5NOa+Q6kiqmygVekfaexZx5460 Z228wYpRZxn4zjNWpyjq39Dw7U/kGsKwfW0lwzBBZ9/YN95UMeMxz5oqZjxmoKliBsOx5MhYvsOt vfemau0D8909mncPmtH/qzrjr0vAnv3S5e+U34tJI76tFFA5cgKDMWmMqWIGQ0sOfeqsjnyUpalb gQdWZB7qgRMC2geWQxxeTf0R9d7C9BU8L12BlO5wn7ZJBeb5avW4FHwHfgAHwEFwGXh1ZswH+IFq oDpoBJqAVqAdaA/CQF8wGIwBY8EcMA9YwWqwBuwHp8A1kAGyQQ7wf1Ps/0uh/X9rE/j+j9l8/8e4 UcMG9e/do6v+DtS+r2Ku2vd552q9YWVS1UjVJdWcVAdx5KuU041UP1IDSU0W5aMp5xNSC0h9Tmqj KL+JcnaTOkzqJ1JXRflrlHODVBapXFL+NC41E+NYCOW0INWSVFdR6i3K6c4ngus4W/ep8mTXGbmN 2TdS5e1gJo+xbyyTd9U7cgLXpr/ch50ZM5ivK/z3tDwGGJYzTRqn5Sp05ASf+EstypETGAzb1O5u tmzo/bt8irvumPPJyzNeBJu+LnvjDqsk97+1QCAIAi+DjuB10AkMA5PALPAZWABiwVKwHCSARLAD 7AZ7QbI8B2j4vox9I1mevzd7jFz7Jo8p4GxyJGrymB1yhGjyGCk55LtqGwh05NByR71E/Vcvinrf B46DU+AMOAuugOvgd5AJynTBrSrwAb4goIu2//M07f/k4/98jP8xE8eNUm8A5Q9NHcUyxb72LNrX fovUn6R8xTd1KtE3daqSqmH4VhAvVYdy6pL6B6nHRKnHKacVqTakOopSr1FOZ1JdSfURpfpSTn9S EaTGkZpOaqU4chXlJJL6klSKKJVKOedJKV9UreNMfdUGwaAOqA8agkdBY9AehIJeoA/oC1K7S9V3 Rq5L+0aq7I1mj5G90ewxL5gqZjymtalixmPk+V+TxxhPkMmMyanxP8CReowEsWAh+AIsBpvAIfAT OAqOgatd+KYItBdQGfiB+0AAeBg8D7p1Vdf8a7xl8H/b+H/EkPC3e4VK8b+n12KxomWlFa2tpJJI XSR1Sd7hcYMvfvGjM+j1TFI3SVWnHqSB6GcaUk4jUk1JtSMVKsp3p5yepPqQiiK1QJSPpZx4UotJ bST1oyh/xPANH1X9SuqMKHWWctJIXVS+/+Pq+jRsAzZpnJHjR4dOIC8YOXKCZU3ddMNqt5h9A0ms yP/19/AOeb7oNarY+uCrYs8N30/zMPAKxYHgJDgN1nVnbAOY1MPmEzBMqWyUja9kI1E2/mP3lS9k Y55szJANwy5vwyuGY8ayfFLFBnyjtjpl5ht12F2dJBuJtyxPpJXPp5SYVaOptpFiD+Zhd6P+yrAX z6LtuSuHUVTZG55uoR3mDrcavq/bNpnJE/Xvc7d1Hg3e6MlYZzALzAERvRh7B7QPY+xfoDNo1Qc2 6As+BFv6IT4cgBgTY3ML8BboBcJAb5B5/cr51N+OJ/G5/y0bV1xfcn5h3Ixpk98fM2r40IG9u3ft pFy1iGHEatgFWg27liPNfVe5Ke+8eOimMts9+SZfR5uu7OHbliv2wvHHbah74dxoV5w3Kf6VIm2l sU/SHVppLIMLqcAzPL18tR14F9WjoHaoR1mYp7vXcr7fz13ae75cWdP75r/8qAbMa8YfylFQn5Dq /qemepJ6LFdTT5Dyva2pyuruv4vatVxWbX4hir2LX1F19Yr4thFxRRW4DuZ13lDUe3OwACwGK8Ba cBAkgQvgumgbZUT7qAyGg9FgApgMFoMVYBvYLdrQKdGOzoMX0I46gi4gFIwFUWAOiOuutrX1or1t Bw+ivdUHj4Jm4FXQCfQHET3UNjlZtMsZIAvkAg+0y7KgLqgPngRtQKeeavvlbXc2uHntCrskfk4l Hd63Q/xsvqLrtYm6XiblJ7GFqFRvS/9ze/V9g5b+D2zDpZZ9nz9eyUPZPVjJ0n/Rai1PyUEpNyuV 8sHvEP1xTqyC9GynspTrK+Xyk/hb+leao5xD2tqnnJ3vZrS3GxBX+8g0vehTrvTpbLmDuSQbKbJh 2Ovxq2wYtkPstvuK4WzbZWOdbKywayyUDcPZ7BtxLE8SO3ICRHcvPVuD8grdrS2t6truBa+gfZOI n0rPz3dMMazq2B3Z8o5bfrNFfccDT9R3eVAZ+IMQ8CR4GXTqpbaJQaJdjAKnQRq4CjJ78StAPAga gCagXZjafj57G+MxWID2EgsS0GYSBxjHAT4GzAcnwTlQKxy+D7qC3mARWAK+B7+DLPBQBGMDwbtg JVgHroAs0HgQY4+DziAKTAZbQC7wegfvCzwPJoJPQb+hjO0Zhg99DO6FwHNgApgIokDW9Uup4ufU CV1nsWPsJ7D/BNN+9rHr+eh97HuwDZFROUv/SSmKB/rBR5+uz+SH8jILMrj/GvcfK8+F25zOtOfD ce9GH7LwGPUhFULy6zPkniS/3oC1y28sHgAGgxFgLJgIpoDpYJaopwXAClaANWAD2DqwoMfvJCVL xhH5FZPGIXPFTBqrlOffiLTcbjGThiGJO4Fg0zGdPys/885+i2+ZDuVnef9SqWbVbjUWBqTWrhcs 7/CqeTcLjWWZOz9jvWD9mSP5rg9Xcba+d4K94BBIAicG6j58GdwAOSAXWOCz5YAvqAZqhut+/t+s 9ItK/Ld/9/bN69fwR3/MnTl96qTxo4cPHti3Z7fO9OmqEd8jIgZsRDFgCKmWpJ4m1ZbUi6Q6knqT VHdSfUgNEv/XO5QznNQYUhNIxZD6iNRMUvNIxZNakiPNTSTmiLmJ1fT6elJbSO0g9T2pgznSjuaf +XnU/ONUIplUGn852JV1+BB4FDQHT4JnQDvwUrhjd+UG47jsr06frXhejpZc0bOo/n9fYfX2GugS ro7DCWB1uDoGXw1Xx+HMcHUs/gO4YdwtA7xBFXAfCAQPRqhjdQPQDDwB2oB/gn9HKL5/Oe3MyWNH Du7dtXV9In+s4xzl3m/EULg+3/WlJ7XtemRrrbg8qUqkqmdL3hSYLbwpiF6vS6oBqcakWpBqlS15 07PZ5E3tqcTLpF4n1Slb7S3eyJaeGNQtW7knFdbEbPkOdX62dscZS+q6dtXpdN5sUn+ScidvLkvK h1RVUgGkgkjV5f4f5Mo6LshbpPSDXeN72dhu17AmS4YjfrTIXLHCHVFN6ijt4Phs81Q/ETv4BOTd 5q/fM7jO//0K881XQWcQCnqDARF6zD0avA+iwYfgU/AZ+BxYwYoINS6333Eek18pwo7TsOn+3vfj BTmKdDlyEpGg6yJLtf79XVXH/N5rM/gWfAcOgJ/Ar+A3cA5cjlDvz9qI+7Jx4t5Mif2STxz9cf93 O7R9v7M/VmK/IeF9Qg39P/WhBzLlHjUjU+5Ry2dp/WholuhHu2dp/V4fUgNJDSE1Mkvq88dlUZ8f RSWmkppBajapz7PU3j+ecpaQWklqLamvSW0jtYvUPlKHSR0l9Zv4v5IpJ02++iv61WdQiZukbvOX g5ytu0ni3vqDQS5o/bfMFbNvGPoTw2himE3aatdYlCwZZvv/Ytbzy98a8rOtw0/AXBAHFoPlYDVY L+ZPtoI9YD84An4Bp0EquATSQTZvC4P0uZaKwA/4g7+BB0B90AiEgJbviOd7q33ATv7or2VfxH02 c7oSBPKl3zz3f9UytXZck1QwqXqkGpJqQuoxUk+Reo7Ui5mqV71EOa+R6kKqB6m+pMJJDSU1ilQk qUmZUnz6UabooabT67NIzSe1kNRSUqsyJW//MpO8fSOV+IbUblJ7xPv7jh8Q/FfUeRE6vI33S4On /SH/rzKOORtayKlo5pSYf0E+yedI54PN3D+B12DUL2g3hLG9Q/Q503bvMnYSrBrOWJMRrv4YDfcO h2XDcO+wy+4rhsVok8Yac8XsG1Iq48d8o952qxw197ayelyekS19E8POE1ry+76vC+O/qs7U8wnw GC52Jag0CveQ4EdQ/z3GEkGZ0YglQQp4dow+n86/pBExlrFBYDW4DOqNY6w1WA+8IxF/gu0gdjxj L76P6wJPT0AsCq6CiImM5YCaUfh/wWQQDSpNYqwHWAOaTUZbBsPBe+Aj8DlYBhLBerABfA32guPg JDgNzoCzIAWkgmvgOkgHN0AG+B24RaOPAwHgj5vpV5UvNYmFozOUUpQnVuTd/nmCJ3bqmJKSflSS /EtpPu4NlR7e3eIG7a9oi3sIs/D1bvcaoDrwM/x9Mf44mrzPJ/NQcn1E/+/L+/8Orq5Hw+40g3H9 nhuG5zHZ/0LmT7Jh6EkMx+xlRZTcGth8wxMe71WDaSuA6Xmf4mHsOzx5f8OUaX7mUV1bIcy/16kS NUatv8Sxqp9oPqG1f62tB6F9B4M24GnQD/QHw8EIEA8Wgg3ga5AEjoJzIA1cAVfB/TEYa0AzEAJ6 gz5gGHgXrAVfgp1gF7gO0sEdwLf7PAjqgmYgBISB3mAYeBfMBwvACrAS/AySQCr4x1RcM9j1AT6k DxkLn85YAhj+Md432ADOgTTg9QnaPXgYPAKeAC1BGOgNRoMxYDVYA74B28FFcAncAq0+xX0SiASr QAI4CA6BbJADWA7LSM9gjvyof6fUzqvinMpKoXEPgWG5MbQo+95kuVWXAGOnbHzrrEHJLYTVRoPk Twxtdds3KsLjgTAvNze3B5V/6yr/1lP+/XsYf3Kn954KzNLa8+XyrYNwcKDhSO7Td3M0q+7KMTJX fld/yMZNlxpxKyVjvvyK00Zca1PFLA2V6KmzTRwmP2BVpuzRGOY1805L95e8e/qXqz0zqEpd5rXM XTsb7eT0qlLBXN5Sj7x50yx58yI9bfMs/sqVY4xR7k78zMY2taLVMcCRCH7RFlPFnL1FunfJyXag 1Y1c5+bylnrkzZtmyZsX6WmbJ1pwBblu+fheBzwGWoGnQOtofcx/BnQAPUAv0DtajwMGgIFgKBgG 3o3WY4OR4EMwDywAcdF6vLAIJIKvwDqwPlqPITaCneAAOAR+jNbjimPgF3AWpIDUaD3WOA8ugIvg Ergcrccf14AHYomaoDYIjNFjkgdBXdAYNAFNpTilOfgXCAU9QC8pdukL3gaDwRAwNEaPZ4aDj8FK kABWx+gxzldgHdgOvo3hf4X4lvgLxEX1i9e8eh+h3lOwnmbq3RrF9GRYO3PaaBvPbFLx9aViOBqw so76tWu78UVNTRX7fx0himMcoLZZbzN9tHUZ05OL/b8rs0nF97Mshj0XK+voGOxi/x9pqlgJ9f97 UfOa/5uJp6ytmZ5c7P+1mE0qHf+lqzSX58z472i87GL/P2mqWOn4b5Pn/PjvzL2PtS3Tk2v7Bet2 U8UcMVyfivH472PmHtbakunJxf2/YWKPp9L+X7pKc3nO9P93O0exI0Zdm3Fx//+sqWKl/b9NnvP9 v1ynfL1tNzgGLoLL4GqMvgZ3A2Twuge54DbQ1uXcQCUQCILB/dJaXT3wd9AYNAFNpfW75qAd6ALe At2lNb0+oC8YDIaAoVP0db6RYDKYCWaDz6boa3+xIA4sA/8By6fo64GrwBbwAzgADk3R1wiPgmPg DDgLUqao64bnQBq4AC6By1PUtcSGoA3oALqAnqCfWGMcACLBbDAXzAMLQCyIA+umunC+D1WQk5Vx jadbGUrCL75zIECZ5fNQpvrU/QKBxvm/bmbq3bqa6cnF/X9rZpNK7/+lqzSX58z9v6N+7eL+f66p YiW0/78XNa/1/2b66KK8/9/CbFJp/Cddpbk8Z+I/R8dgF/t/a1PFSuM/mzzn4z8z8ZR1AdNT6fhf osZ/R+NlF/v/YlPFSsd/l9W85v9m7n2KcvxntslFnyUl6XMrOE//LPU8/bPU8/TPUkvFefx35t7W sN8vw66RLhvXZCNNNgx7sB0xxu+XDMOpDYZNKoa1VjGA7/n0C2txR7l2/duBZZjhBXWXX6DY+33Y vXJUo1xp7zfeFPMpbI5iE9gMtoCtU23+PqdJI1beP+TICewb9zIVR3+3bSEV8qvjbeAbcBCcAr+B MyAFpIJzIA1cBdfAdZAOboAM4DmNMT9QFVQH/uA+EADqgQagIXgY8IfRNQKPgjbgFfAqeA10Am+A zuBN0AuEgd6gD+gL3gaRYDaYC+aBBSAWxAErWAlWgQSQCFaDNWAt2Ay2gK1gG/gGbAeHwGmQDFJB GjgPLoAMcBvcAewDOBJwBxbgAbyBD/AFlUBl4AfqgMagKWgBWoInQSvwFGgLcpH+yM0tyl9M3QOo zAr2Kqy+rfLMTKyknTeKe7L1peIY/5cpzKet8s680vqXk4vrXzutXNfm8pwZDwrrt63xTE+l9S+n EuH/hY3N1q5MT6X1L6cS4f+FxV/WeKan0vqXU4nw/8JibMPen9L6l1OJ8P/C7qOsvzA9lda/nEqE /xd2r2x9gemptP7lVCL835n5kCIcG6zxpord02ZXEvzfp7B5Lf7Mb0ql/i+nEuH/zsxdFqX/y1sO S/2/4Dxn/D+/Oej/sXcfgE1UfwDHX3ehlK3sDSp7L8UBIggOHOwhe4Ms2VsqspeAIHsEyh6y9ygI imwZCsiWbVkdIOX/vaRpXtqmd00Dbe9/v/qxfZdLGvK737v37tJcDdTERy82x8k9dFH/0fP9MWqh PtqiPTqjK7qhO3pgIAZhMIZgKL4dY/lspQM4h7sIwTN4jrV85pI3sqIkSqMsKuJNvIUvUA/10QAN 0QiN0RH9MACD8C2GIQDfYQzGYhzGYwImIhDrsRGbsRXbsB2/4giO4hiO4wRO4jbcx/Hc4Y2U8EMq ZEBWZEN25EBO5EJuFEQhFEYRFEUxvIvP8AVqoz4aoOE487mfaGdrRLi2UzpavykpV94HHnX+p4Va zk2ThS2M+pdDF/M/tbq2e++PkX85dNH/a+27TUIKu2uhyW8OFXJvkfBGUorY3lvjbfe5i8nwnWsi hdp+2SR/jrJR/3Ko1X8qci1Tyb+8iZiDXFt/jnvZYs+Yy0Z7xFw22EteZv7ZJyFjL7vPhXLttmGa q2m1RN3sXJx/pTaVm+W+Psb+2oX7f3P+U6uNoY33fzgMF+dfecjo+bf+qriXObf/t9S/2jwpORyI SaTQQ/37qM2Fjfd/OAxd1L/a8Q7TRWELI/9y6KL+1Y5pGed/HYYu6j8hxy2N8z/Jf/wvH39uhFZo jTZo+2JznNxDF/XvKO/t0B59MBbjMRFTMBU/4gCO4ThO4CT+wBn8g/8QAffx/KORAimRBflRAK/h dbyBguMt1+Tohu8wFXOwCCsir9WxCnvxJ87hAi7jCq7iKcQEIdzgDg94wgsZkQ8F8DoKowiKohjK ohzKowIq4k18gaZojpZojTZoi2/QF/3QHwMwEIMwFauxFuuwARuxCXtxaILl733k0zShMc8BPY52 Eud+tLtYvt2PbeEzJcWRnwKknPfxcW8adS0h8/mfpmq5Nm0StjDqXw5djP/U6tkk/zG9xsRO0bZa cgufpvb51kX/r9Znm44KWxj1L4cu6l9tv2waIGxh5F8OF+ff0y1m/SvLlIh72WLPmMtGe8RcNthL XmbJv9axl3H+N97nf52sf+/IHMm1HvcyW/3bltnq37bMVv9RvyeF2rjaOP/rMF7Q+V+51q25i3uZ 7fyvXP8xl9nO/9rqX23u5Pgc70S5oeP8a/60lWQ5/lObH5vmClsY9S+HLsZ/asdAjPP/DkMX9a92 nMu0TtjCcS6d2Rkkk3hZ/b81J3HXuqvrX+1YpnH+32Hoov7VjlebbghbGPmXQxf1H9s5id9xGEeU /LcStjDyL4cu6j96vo/iBG7Bg726F1IgFfyRGvlRHCVQEqVQGmXQC/0wDnMQiFXYgI3YhP04j79x CddwHf8gAh6TmJPAC97wgS8y4TW8gUIohuIogZKogIp4E2+hEt7G5/gKzdACrdAabdADfdAX/dAf AzAQkxGIpViO1ViDtfgZ27AdO7ATu7Abx3AJV3ANN3ELt3EHIQhF2KTY/+brsTme3jdHwr4pKY68 1oePe+ao84C2839qOTc9ErYw6l8OXfT/anVtfP6jw9DF8T+tfbfG4//TXdpIkuGRWU/H/7Xsl03b hC1c/Pnv8uFlcyTDUZSDz39PDvXv6+y4y8XXf5irabXkcv2HZLDnt17/QcsY2u4YsIvrX77whzmS 72uZHOd/vs7OkVxc//JRxv+7+lceIpH2Wf5a5rt27wFwcf3Lby83x//t/t/6aPKztP4c97IEzP98 nT2e4eL6D9S0mrH/d1nmrfUf17GpcDyZJBL3+k9OvpbmrVuJlzCLSs77fznPT/HOD0JUQV20RVf0 xiAMxhCMgwmLsQQrsBKrsB+/4RB+x2EcwVH8jXsIxgOEIBRhCIfy5j83uMMDnvBCVryOgiiMoiiG 4qiEyqiC91EVH+BDNEB7dEQX9EQv9MYQjMQojMYYjMU4TMA/uI3nSDtFiCzIjdfxBgqiHD7BZ/gS 9dEADdENvdAbfdAX/dAfk/A0XIQ+NEcCrvocGhwcfCc4ODzYHLZvQjnqW0e69nP0Y79R139uktC8 hwkpQuTGQ5c2pm+TGlPlWxLc0BzJd57v8JhVGi21a/ceQBf3/3NFtDDmf9KzFJER97KE9P/O9s0u Hv+V0bSaMf+Ltizh8z8lx9Z9rXW/at2HWveXYyL3h9b9oLL/uzJDiPwzmTPM5vXGM5ScI0QpNEQj jMBIzMJsHMFR3MO/KDhXiEJoiEYYgZGYi3m4hMsIxxOUmydEeTRAQ0zDdBzAQTxDBArTxRRBK7RG fwzAOqzHbzgEzwWML5AN2VEbddARnbAQJmzFNjzCY/gtJK2oig/QCI0xDdNxEL/C3cRri9zIg8Zo gkEYjNVYgwM4iKdRX+Hmr6cu/1LCo6zvUN9aNYX4HC20jLNM8uzMxf1/YxEtjPm/9CytP8e9LCHz f2fH0S7u/4M0rWbM/12WeWv/r2VOZJKL1Jj/62r+n9A5r938z/Fk8J62ht2Fmh2vNkbuLjQ+9DCH DSIFSczv5ppP8x2T35pNJV5cNsNiLvOpE/dfqMcy/9Ny3MIukzPlyeBk+RbHDbsHcNxI0uGyT3tO vO0jlq3cN/pxqSVYjlVYB9MdYQuNb+zSuFUkq4jltXPxFmHNkpx9bcu0jgLCYi7ziS3n67EBG7ED O7ELu7EHe3EQp3AW53ABf+Mi7uIBHuIRHiME4fCfKkRO5EF+vIbX8QYKojTKoCzKoTzexKdohpZo h6/RBV3RDf3QHwMwEIMwFFOwGEuxCuuxARuxCbuxB3sRhH04gFt4iBA8xXOIH5nTwQP+SI00SIt0 yIjX8Q4qoxo+xif4FHXRDM3RAi3RCm3RB+N+fPnX/1bLtzN//2fUf/IZMajVtOkbYQsj/7rr/9X6 bbu5n5F/3dW/2r7ZJE+1jPzrrv7Vxl927/0w8q+7+lcbY5suClsY+ddd/avNo5z5/F8j/8mn/tXm ykb9W0Kv9a92PMSof0votf7VjnkZx38todf6VzuuaaoqbGHkX3f1r3bs2hQsbGHkX3f1r3Z+wjj+ Zwm91n9s56AmYipmKvm/Kmxh5F939R8937MwW8k7VmIVVmMN1mI9fsF5XMQ13MYd3MVjROA5xDQh 3OAOL2RFYRRDSZRGGZRFObyHyqiC91EV1fE5mqMV2qMLuqIbhmI0xmAsxmE8JmEmlmMV1mELtmIb fsdpnMFZ/Im/cAEP4TmdFwcpkQr+SI00yIKsyIbsyIHcKIxKeBdVUQM18REaoTXaoC3aoT06oTdG YPT02D4PyuXfhHz+Vy3nptrCFkb9667/V6trZz7/0ch/8un/1fpuU31hCyP/uqt/tf2z6YCwhZF/ 3dW/2hjMOP9rCb3Wv9o425kLsRr5Tz71rzaXcub6X0b+k0/9q82Xjfq3hF7rX+2YiGmIsIWRf93V v9pxL2P8bwm91r/asU1j/G8Jvda/2vFrjdd/MvKfTOtf7RyFMf63hF7r39F5qAmYYtR/VOi1/uVc T8WPCMRa/Ix1WI8N2Iy9+B1H8Qf+wjmcxwXcwE3cwm3cwb94gjQ/CZEemZAdOZATuVAQhVAYRVAU JVAZX6AO6qMhGqExmqAd2qMDOqITumAwxmMSpuBHTMN0/AQTFmExArEEy7ENp3AWF3ARl3AZV3AX 9/AvgnEfj+A9g38f0iMTsiMHcuJNVMUHqIYPUQMfoy26ogf6zFDO/77o07/PhHz+Vy3vpiHCFkb9 667/V6ttZ67/Y+Q/+fT/av23Mf+zhF7rX20fbfz9ryX0Wv9q4zCj/i2h1/pXG2ubNglbGPnXXf2r zaeMv/+xhF7rX23ObJz/tYRe61/tuIhR/5bQa/2rHfsy/v7fEnqtf7Xjm8b43xJ6rX+1Y9jG/t8S up3/q5ynMPJvCb3Wf1znogYq+T8pbGHkX3f1b83zIAzGj5iH+ViAhco2gEUInGG57s8/eIpUM4V4 BdmRb6blekAFUAo18DFqoTbqoC46ozt64Bv0RC/0xjiYEIhlWI01WIufsQVbsQ3bsQM7cQTn8Dcu 4yqu4ToeIgzheIKn+A/PkZatNg/y43UURCEURhGUQ3lUQEW8ibfxOVqiDTqiG7qjB77BQAzCYAzB UARgGpZiBdZiEzZjC7Yi6jQtTzee53Q1flNSbr0GoPn8bwvV3M8Utpgl/ZzwRnIPXfT/8alvk5Bi tsOGvMVo3Rck/V1G9GzHvJaGi/r/qJD6+riX2fp/2zJb/29bFhZzWcqE9Nsv8Nyg3SUnXfvQzsWL 3P9nLfBy6n94zPVSq+1/jc9/s8SLz781J3KutS3TOv4bHnM9H7UxlqmMsIWRf73Vv4/aONqZ8Z+R /+RT/2pzJePz3yyh1/pXmw8b7/+whF7rX+2Yh3H+xxJ6rX+141rG+V9L6LX+1Y5dGp//bgm91r+S 47iOTxv1bwm91n/0cxBB2If9+MWo/6jQa/3HlvMD+A0ncR4XcQ23cBt3cBehCEM4nuApIpBuNnMI vI4iKIbiKIGSeAuV8Dbewbuogi/RAq3RHh3RCZ3xNfqgL/qhPwZgILZhF07iGu7hMf7DM0Qg1Rwh 8qEgiqIkSqE0aqIe6qMBGqIRGqMj+mEIAjACIzEKo/ETZmAmZmE25mAtdmIfDuIIjuIYLuA27syJ 9/VeRfhjczy9bw7Vb0qK3YsK5VSfj3tm83e7839N1fJtGiNsYdS/7vp/tZo25n+W0Gv/r9Zvm44K Wxj51139q+2bjfq3hF7rX238ZXz+iyX0Wv9qY2xn6l9jI7mHLupf6zzK8Xu/5BPEYrpLG0kyPDKb s+3C93/Z139USLUe9zKt7/8aHnO9FAmZI685KT3SSvlhE9xYs1DTas40Xl54FDVvKZ/I24VHGbfI /Jd3r+m/7tW82dxzhecX3gvcvdmOFEqYv5PrmMs6pIi57GvPmMsuesRcFuoVY1nq+B7rWCOfD3Zt YprV1rRatGRqfHWVVaO/ujGXdUgRc9nXnjGXXfSIuSzUK/qy+OXfeq+oHEnP0LbM9gxty2zP0LbM 9gxty2zPMGqZX3yPX/0npHDcWCl/bLDG+2hsNBsgt5J0dSX9bdMvtmOSd3EP/yIYHnOFyIJcyIeC c12d05Xyu0xd+9CJGUk///5a810IhfEB6qE+GqAhGqExOqAPBuFbjMBIjMJozMJszMFczMNC7MRh nMSfuITLuIKrCEEowhCOJ3gGv3lC5EchFEc5lEcFVEVd1EN9NEBDNEE3DMcYTMI0TMdPWIt92I9f cAAHcQgXcBv3EYJniMBzZJovxBsoiEIojCIojg/wBeqjCVqhNdqgLfqgL54+DX9qjhf2TQjLZz9a zwmIFvHN7Rr5Pf8u3v87MbTQ0f5fuUf0ZxhzmYv3UH7xrVetHXozTas5tf/3dJObSTj/STnz1v2/ s32wi/f/zTStptP9fyLm3z+++9M1j6R/n4v7f/lUs+v6/yeJ/Ron6flffMdIWgtabrm4/98lt7Tn X8SS/+jLlPxHX6bkP/oyJf/Rl4V5xVim8blFrS89t5jLXsz8z9lxr4v7f/lI4v9R//8kWuXHzL9t mVz5MfNvWyZXvnVZmFf0Zdb+P75zmBd5/O+qptWc6/+VVROpxpLwHkr4aZmX9kN/DJivvaAba1rN qf5f3kySdP6TwdjEL3p+B2MK5iMQK7AO67EBG3EAB/ErfsMhHME1PEAYnsFzgRBe8IYPMiMLsiIb siMXyqIKPsQnqI06qIt6aIf26ICO6IQu+A6TMA2zsBAmLMJibMJmbMFWbMNO/IHLuIG7eITHCEEo fBcKkQIp4YdUSIMCKIUKeBtV8QGqoTrqowEaohEaoym6YzjGYCKmYTp+wnrsxy8LE+f4j7M5d/H+ /8V1F4kZSb/+/eNbv2vk3tfF+395I/h/mv8l4h7KL759staCljcTF+//5c0kSec/Ocz/nN3Purj/ f3GbS2JG0s+/f3zHTGuc6KSN+V/Snf/FdxystaDlzcTF/b+8mRjzPyczb+3/nZ3buLj/f3GbS2JG Mhj/x3ee+iLP/wRpWs0Y/0dflpDxv/XYwwEcxK/4HZcQjBA8hbtJCA9TUhjQNesjt4zxv3OZt/b/ 8cm9J1IhB3IiF3IjD/KjPGqgFuqgMZrgK7RHfwzAQAzCYHyLCZiNhViC1ViDtfgZ+7Afv+AADuIQ biAUz+CxiHEK/JAK/siF3MiDvMiH11ARtVAHDdEcLdASgzABEzEJP2AyfsRS7EAQDuIojuE47uE5 xGIh3OAOD3gjDyqhCqrjU9TCZ2iMr9FlceIc/3M2ry7e/wdrWk2n+39l1USqf//41uiaEcIWLt7/ y+8ZN+Z/L2f+F99+V2tBN9O0mlP7f183uWnM/5zKvHX/7+y+1MX9fzNNq+m0/0/E/Psr+bfm2jpG so6HrGMf6zjHOqaxjl+6oTtWYCWO4hhSBwqRBgXwGr5BT4zFOPyK33AfpZcI0QPfYCmW4QROwmMp YxNkRhZ8hI/RAR0xDuOxCBF4d5kQGVcwRoFplRDXEbRaiAxrhLiyXoireIYMG4QojCIYhuEovVGI MjiLc2i1SYjW2IHdyLuZ1wZfoyvu4T4qbhHiLWzARvhvFSItPsMXmIhJ+AOn8Teexvsr3PwVIh6I 8HviZhxf4UL41qrpIT6H8HnLd2jnD1N4eqfo4CbWBQvP92tm5lUt6zuUdQTrMJSL77h4jVxcyWj/ n4g1lqTn//Gd62jt0OXDRC7e/8ubSRLKf0iC5/9R938J7/y17v+dnb+6eP9fwk3Lajrd/yur2m9L rq78EEdzE39HxyK6Svv3nhiBn7DGiTfpa+3/5YMAyW/+5/A1Tso9lF9cuZ6LRYtt47tV2IrfcRhH FtvGfCdxQ+kX4B6oXFjYNg5Mi3TIi3zIL40NC+IDNEdbdJbGi73QG6MwGmOkMeREzMJ6bMXuQNu4 8hD+xD38i+BAy1jzAR4GWsac5fERGqM1Oknj0J4Yhp8wFwulsely7MVRHMNxabz6B67iIcLxTBrD esEbr+BVZJLGtQk4qCdCH5oj7pVE9M9+jDr+1yy+edbaocvdhIv3/2FyK+nsY0Ni7GOTcuVH7f9f QO26eGzQWNNqTj10JTctqzk97Ej6+6aM8e1r17QStnDx/t+JU8tJuv6Tw/4/vvtPrZU1U9NqTvX/ wi6M/t+pzFv7f1eOiex2zCFy46FLG6ZzUmO+fEuCG6aFmlazD/U6r5LpRLZWuR/HI9thsWR7YizZ 1rbM4WfWpY/vWNap3ewuTas5vZtNsqFxi1BWtWbMukXEXBYWS980MZa+Sdsya/1rmZ9kRTG8hcr4 YKnlWPwaJz6wTWNjzSFNqznTeHkRv35BuYd9Hcc2CrRtBbZlE2MZBWpcljqu/CrnWj5BQ7RFO7Rf ajv/0gk9MQgBGLHUdk5mAiZiARbCtNRynmYxApdazte4L+OVwesogfJ4Z5nlPM57+ASt0BYd0AVd 0Q0jMBbjMB4TMBGTsAS7sBf78RsO4Xccxh84hdM4g7P4E1cQjIcIQRjC8QQ+y4VIBX+kRhqkRQZk RwG8gaIohdIog7J4F++hMqrgfVRDA3Rarsz/45rgPzJHeAK+Kdk2X+1BxJz/xzfPawYIW7h4/D9B 02rax/9JpI9NwuMC4Rff2tW6y2+mabUXO/5P7Pwn5Z7fuv9PaH/seMx/16WNH4I0rWbXGKGtYR8p rR/07u2Sz/bO8NrL+WzvwV7Rl6Uwfzy53b8i5vg/jdo+1RQgbCFP6uNoTNTWSC4R6xYRy6ubDLcR 4aM2bjLdEbYw8v8C82/NiZxrbcu0Xv9hsFeMZT5qY2NTGWELI/+6q3+1+Y9piLCFkX/d1b/aHNfU WNjCyL/u6l/tOIbd9R+N/Ouu/tWOVZneE7Yw8q+7+o/teGQXfINey6Nd/9HIv+7qP3q+e6MP+mIY AvAdhuN7jMJkzMY8LMIKrMQqrMZWbMN27MBO7Fpu+duMzCiCt1ENn6D2CsvfbNRFS/TDQAzBdxiO 7zEbC7AQJizCYgRiJ07hLM7hEi7jCq7iNu7gLu7hXwQjDF4rSQr84I/USIPsyIO8yIf8KIA3UBJv 4m1UQXV8iBqoidqog7qoh/pohK8xFAEYidEYg7ErzdeCdnTV57iuCR2Pb0rK7a7/3EIt50b/r+/+ X62uTXJmjfzrrv9X67tNVYUtNOZfYyNZh17qX+v+2SSkcHz9zx9c2kgyoelciovqPyqkWo97mdbr f9rqPypSJGTsZZLPybl235CUTjvpef+fWm0MbZz/0ff+X22eZJz/0ff4X20ubBogbGHkX3f1r3a8 wzj/o+/6VzumZZz/0Xf9qx23NI7/6bv+1Y5NG+d/9F3/8vmHcZiG6fgJM4z6V0LX9e8o7zMxB6ux G0E4iCM4imM4jnM4jwv4GxdxBWHwXyVEWryCbMiOHMiJN1AQhVAYRVAcFfE+quEjfIEvURt10BTN 0Bwt0BKtVlk+720JtuMwTuMCrq2yfA7cP3gEv9WMd5EOryITMqM4yqAsyqE8KqAiPkNbdEBndEcP fIOeGICBGITBGIKhmIL5MCEQS7EMy7EZO7ATu7B7tfn8X7xO58X/tKCScvvzf2q5Nvp/fff/avVs 9P/67v/V+mxTsLCFkX/d1b/aftmof33Xv9rYy3j/h77rX2187Uz9a2wk69BL/WudQxnv/9Dn+z8S Mj823v+R/N//oXacw3j/h773/2rHsoz3f+h7/K92vNK0XNjCyL/u6l/tmLTx/g9917+S4z3Yu9py nZySa4V48LMQ59axFl5dz3gP5VEL/8VyDZ2G6BJ5LZ0AfBd5TZ11OIDTCEPGjULk32i71k5rDMQY zMWOyOvv/Im/Iq/Dk3oT90EFfLbJdl2eqVgWeX2endgVeZ2eh/DfbLteT+3Nlmv2dNlsuW7PPKzD 0c2Wa/j8i+DNlmv55NtiuZ7Pm5HX9OmMACySru9zDf9FXucnNdJEXu/nnchr/nweed2fIdK1f3ZF Xv/nVOQ1gFpvEyLiv/9EVIQ9iggODrsbcTfYHHcjLN/CLAvuRt3IT2HmG81Ny81Rt1oWBd+9G3Fb eLhnivzENx/3fuZPevNxzxf5Pav8SfBNEpJ/uzmh4w9LnaGt8WNCG+McNoaKuCJVVmkWRwX77/d2 v5h2Vx4q1Tq/y7AwmFvbuQmqKk3Ae+72Mz+PInQQyXP+l/pF1vED+TedaeVma/wh32LX+F1u7JMb Z7a52xp2tzh+NGcae+TGmZnSL3XtQ9vCw7zh+Ar7zVD4ZLXbGj36mZdmibaVefKyxsb3lK9wn/z8 YtoieUWqfFHbsbA+5gS3DWzhr76s/jZU/geff0N6Vf+UbzntRMPuAc53kjYzx/exezr2DzBGegCN z83+Aco4egZx/FIhvSCOf0/kNmDZXpzaEqJtUyLLy9oXSns7IeQP+hf35cbpN6QXz+4Wxw9w+pGm +zhu2D+DZtKjOb5PHP8EX01Px/4+npruI5zJeeTW4qA3URuntEVflN1BX4A2GI5MO4X4BLXwDZZh xc7odZ4x/rV0Xm4clhu75cYWbY31cmOF3FgsNzTex/Fq1vDKJFIHKGME8+DBQ5keWLt0r/qiZH43 85Fi++PGqWz3Sd8qWFhHGzyab6ZoSyy5TMCeIHr9Z3Amx8eRapcQuVEcJVAW5VEBVfElaqMOGqIp mqEdOuJrdEEf9McgDMZojMV4TMBMbMM5nMddBOMhHsGNrcJztzKR4R+KNEiHDMiIbMiJvMiHzzEa c7ASq7AOG7ARe3EcJ3ASZ3EBf+Mf3MJd3EMonuAZIpCS/XsqpEYaZEdO5EFeFMOn+Bpd0BO90RfK W7Oe8v+n5m+hoY+t/6l7pmn1yM99zhQ5+q9vniOI5sr1SNtF5l/JfevI/HfdYcn9p5H5bxCZ/+WR 28DGyG2geGTOv4zMtZJn6+uuvN5FIl/vlZGv7/HI11V5Tefw716EVdiE88i0V4jMeA3FUQGN0Bgd 8D0mYD3aBPE64kdMw2zMwVzMw3wsDLKcp1iG5ViBlVilnLsIFTcunBO/Ywdi+wrdslGsXW7+Hy3T fNMs0/zIb74lamYTnT8UnsJT+Un4e3TgIYXycx1fN7+yvkOtF1mNutqq8Oz8YSpP4VNWuS5rKs/s Hh26PebljbyVe7XzdVMu2Pq18qjcmuG+w1uVq7hmsN4m3cC9frvl8F5puJdyEdhaNd25mTHHO66s Z7u+324vdsVh40BuqbFNvsWucaCr1Ijj0UpIDbsHcHyfeZWkhuNnYNewi6ya++GUwmPy8+x+C18t kjdGp5/RMjTPJj+YRxk39X49ux/9un8mZWcT6yPGtU8S6V9GP3z1PenVOiP9HEfjalVNq9nfRx55 a72PfHxT630+07Sa/X3kLVPjfWILR9uNc1uhyKx1P7lfrpJN8jOSTxDYN3rIjQ5yo5XcsHs0u0Z8 QtrKU9gVgzJ2EhU0vzrVpFeH8Iw6jmoLLcsc5imuSnX6WVojxvEdtWUpXsQY6Gpu6VfFURJyn/6r fItdw3HlOL7PKnlr1Vhtq97TtJr9fRz2UpHhXFXGsY24eL+RMSFj1n4IwPcYhdGYhhmYvccyvnN8 Fa8zHzu6JY77yD281vsU0bSa/X3kvGq9j7xX0Hqf90R8w6WjDZFJax6VcfpSrNxjGa/LY/U8KBA5 Zi+CoigWOX63jt1bo33kGL4/BmAgBiEA32H4Xsv4Xhnbb8AhXMQ/uIGbeICHeIQneIbnEEFMq5EC fkiF9HgFmZAZOZEH+ZAfhVAUxVEC5VARb6ESqqA6aqAmPkMd1EN9fIWWaB1kmYtMDbLMRZQ5h3Wu ocwzVmMN1iLnPiFyIeLJkydRwsJCHjyIUL5CrD9YG3zXKCzMfLJIOTtk3lC83LMKfzd3N2XWlyXq nI8y67POApXzP/HNrd2w/prDht04YIHcmCU37E4ATXPY+Ca7o1u0Rz5r3YjabsJ9anZhvh5LCeF+ 9Xl6r/X+wruYV/QTNcJ7gW/0ZR5ZzHWjvPtPDyMOP2fr9Yav9KvtUm93zO6Q3DgoNxxvO6YPHd0y zuEv7S1vIXa32EWm6BuB76mswu3qcyX/x/yj8i4s37WtHXUvV21hlrOJbGFx/37rs7TfMrXdJ+q7 vzN9r+Pc35AbV+TGRbnhOPd2jYXyyE/jfRIrKsWS/DjPAVP1V5/n8F7sVzKd/DjxHcHbthYt+Y+x /aVy5b50r5yvXfKzddyYnyzvYx8545v7lLbcW7KW0K0n3vM+a6R/UWMg5dir47NnF+RX1vFq9vep oGm1xLmP3DghN+zezxAkHIdvVpHttWb58rtnDgh7niXAzW584RdtfFGJHfg6F2x34lUlTwuCLGPW 6GPVn7EO67EBG7EJm7EFW7EN27EDO7ELu7EHexGEfdiPX3AgSDnBIUW43AiWG45XMxqaG7FsV0q/ 75GVbaudm8iu5OMgfsVvOITfcRhHcBTHcBwncBJ/4BRO4wzO4k/8hXM4jwv4GxdxCZdxBVdxLchy visqjMbLa9hC2Q5yKLm4jn9wAzdxC7dxB3dxD/8iGPfxAA/xCI8RglCEIRxP8BT/KXlGBJ5DedeW G9z3GalItIYtzPlXcuEBT3jBGz7wRQqkhB9SwR+pkQZpkQ7pkQEZ8QpeRSZkRhZkRTZkR459luMf RhoSI90xQsl/duvxKPudhhE6DmlcKdyUMZ+SfyP+L8Mttyj+RW6Ra/XR4rlXX3w7z2pfn7zIN2Gu V34UWK32AEYk7xiIqqprxR2+Rw/e6hu+5XC6Md+KpeKjJX7uwvxWE5EaTUVt0UW0FGVERVGerwqi HF8lkYi/vLxIxF+uHF9ItF9eUSTaLy8llKM+ifbLS4pE/OWlRCL+8tIiEX+58vfjifbLy4pE/OWJ 2MOVSswerlRi9nClErOHK52YPVzpxOzhSidmD1fa3MN18lV+eavIh3G3e9D3ct0uus19u/3CWCKN 8AxW3jq21jNlsPI73TyF+e+/3xd+wZn50bOyMmke6pZOiLQ7+TGteO5meXZpgz0tDzGklPAJPucj hIen10dzAzZcdA+4GDqlfMTpT/s8F5t8LNPuieYzqDtFszzZglezLPqa7XILUZdn24aVT/EPD8og xLRhn4hp17uJQawvIvrM/H165zEZPsg8pG3vDXc7/XV+w+mv9hXuV/jVm803d90ztHGqUb0D0m7y uFfhnY/zT926feuFXzZ89dv3I0dmbTkmoE/Q+MGvRaT9JGNlr4opLu3NPOi9PWk8DtTIfSBXi+BM hdJXzvj39PMh/U5P7VX+gy4zDn7a9u/pfUMHzpneu83U9/NW6bMjUx6fDlUePajc79C9yieONtmU 9sH8npWqvJ29yj+tAz4NS7did37fH4Z8f8NtwdXP6+adm7bhXxv69RSzto27frycx4SGC1d8uHPm 8HU/1MgTtCBbnxYzMkf0HTNJ/JB+QrahKYsc+8374L7Qrrf7/NTj4YylX/X0m5ChQooypzp6jy1/ RhQKqbyvx9znvQdNDv2vSKWmqW+mX/Xu4i3nhm87f6Oj9/yiRy4Fjk27ZW/bb45+VPFolnnTp1Vv OaDwu/tzPW57a0GNx3177Zzd2SfPqYEbera40bptv259+/VK1+RI5e5d3u42u832hVP+LVD9WYbH u1qHHjrY78inZzsdKbd5ysaDp/rnHPZVQ7fvB6UdkGvGzfC8c4J65h/5OGu51z6Zcehk2rVbWm2b eLvOoTf8W45pM7FJ/e96tZlYtkJo0ZTt5xzLc8Kjc8X8lca+2+vO9Xd3T284vW7+Tc+n7D0YZvro TOZreac0e+IzrVPZZY+vNWnSvZ53tXXl3lm4aHK5njOOz848qv0NrwWvbL0/+7tGC47c2tz+zuFh 13tcjAj4cn+94GETOgbW+/OvGVOuByxa0uRmnypf/vlHpo2BS8qM2rUp1dxqIQtCfZ9+dylTQNOA t7sEDO7Xvujkm293q1ZrQMhX7cqk3rU3Z4l7g+Zt+qVz35zjJ6bbPb56wMiI9df6rsv6ekDJQVUD 9z/17Jjz7itfdZu5f/HDSg0P7LlWf2C5n5+47y52dPqjkZWW9Q68WfTg2k45Wz9vt6Nx/xMNunjW /mjXsvFnD515mnLn33VrhfxV8+xbNQ+feVK5WM0L6xv8HDqis8fmPJXqlexfvFXIhVb90xSeMKPe mQuflZicvfaJpRW33k4/Oo9XgwabOtUa4P/aHJ+CKYd/meNKt+aTqod1G3/j1M3uh3oVWz245ZxO s0ZGTOt04pVxPjOX3V38oEOD9Uu+P/to9fnqgR//80WBlbtHzXe7k67Iey0rFj3crOipCqsXpOxe sdgXW6ecqrqx4Zl8za8Pa12tRsm/fhz1Vr3KC5blXpfjePZjhwI37c/QLU+eFks+P/Zh3hYpr2Y9 WLZF59oz8w2uUKzCm4XLFbo1ffuMg9/M8+7+8PaUaw0r5RjvX6jo/eart6ztVWGRqd/J5gMrBWS+ VHnYAxH2pm/r5leaevxWvdn1xaETCjw/0vbJgKrVgvdOGL2u6M3PcgeZWmzvkGHM0Usr7hcrm2H8 rSpHB2cYs0eMqZS1S4cG/24p9vmioe/k3Nu3W8GmG1tc+WHl1stiTxPfc02nt8hbo9eoXxbOKjC9 Qt6BxS54b853fEK7sSPHXq7bPkPFWoX2BRW5PuyHqws/PJ1j7JWPd4kuf8waOur+0V37m68sv/zL tOm2Xz45t5nIfv87v3mDh3w7o1jpjOcmHd4SMuHnlV9kvFPAp3GKCX99NKhHgwUXvzwdePI6KUr5 aslc2bsP31c998a5gx6MSVvnp78m19l7/8KmV4edPZv78oXS3+b8csa0xiP+R9tbANbRK+mCjmPH zMwxx8xMMfsYY2ammJkpZmbmxMzMzAwxM8MxMx/DOvf/583svTvz5s3u2lYfqVSqkvt0d32lktT9 IT+3Sqv6XX+J35rRqytdSajXkK8Vmh+6qkZAPqTMezGopNUsi8DnOBh6NW0+lTyHNKztOU+HzOPL 3RX32pVzjNrkTokvVkm8Urd4yvpAIGTZHbd1HLL3miEdOsv1rp0pZMxvYt6Td6xo++u6aO44RvFI THACVWn9xo3vvEacUII/NyJzyljOfNpZ7jLSqw0Qg9c1LdN+/FKg+Ogr1auYPsJTIbj1qghwwasc frLeSbC0bqzWrKBs3ZtujUSzFxgSHcarYaPOTi6FZhgvx058ynL/RgK+piigXulIIcXo9ubGS3cr p07YK91b1CZ5IbfNlCj9naoeEYO0Zn4RZhazTpaJ4hDgD72SrIk8teA6xrgkl5MlrDCrGDYsb5YP /DQUKRk3iBvPPkk5bTodGyZ6Q2Gy88Mz/vdUZ9FXERsbiwmYQxMSd8N+Q3eNDpkC9nLgbnbfW9A8 OpgDNuwpo4c9P0ud/ZXx+Qf7Jc2wef/dFBe8IQIyH4/yKfdFHmqCe60ixnInnU4JM6sUTfMPuI/Z Kj+vU7Js3LJRiEZy2WpV1afn8ilmnIbGdPJD15zsRykDs/Lorw+vV1YKJEJjP2QTIT1IxipEqj4M PHzQZVvfqhUbYd6YjErUqTeobvB105v1QJUrzGNF1wWPYrF/W/jBjSW4EexKbVsNBdYEw2sJwdHw MCpg6jnfue422ji5y2U4tHGgVNJRuciVm75kL544I9iJSr+RwxgOQftoXDClMibY+a1gu13DMmZi TXspd3P5ZJWPS0Wa90NDx9lrvjkfz0ZAorPltR7vXKEzDV+ofr5DcUfDRF+pBqnzISUd8U5Afsrk KJ6X07PJ6qDV5uhl5OuamerwuewG4WSmcoXDXY3lllHDQ6JHcGE0T3KFIJ3oRvlFK+/EQsjLKpO4 MRcoExRv96mUuA683NdItpT7Fao52kOlJEElTr8wWT2cYJR7GdNfhTWVVHDo6NjY+5bZC4W7x33P 1VtsUKq4jjuAVdv6mcbg1eVx1WLbxRMWxmTvDVyrR1Gb79N/hTXUsFvAQ/5bWEMI7N+xBvjfWEPx HWsQvmc/fOhE+YM4/gj6zxHHh78RRyHkH8ShmMqw1llPEe5ILax6Kwcu8AbmD/kX4nhB/qPzL8Th 8U77Z05E9P874iCF+wtxHBjwggHe+f+BONS0pfGV0fkdzifG1tRNfKusAVTOAYn0W4XTRAD2APRf xQMnI53fjz7mf6QNNA4sjyxGGkjmP/jIZOb5Gyoy0mwaKxdABD8vFmkm/VwuUbbcR0nEikmKW6bC ez8BDwfqfTXyn9jdX8/0OOPayLjOdDgvg7AGKzEHo3YE66SuZvuy9w3h2PWDUhfjB+xksI478FmP H5XIqNISm2QnNdmz4ZT0Rb7dEjaVSBXlXV5ahUia0a/oaskmUhZCsD+6qNdK4rcr7UGhchLNP+GR /b4/x1W7DTWxSj8URbQdezeMBZIm55EaWORvePujBHCGwnUKPd+7frZ65Z4QCDjlMRh3oG20K1ts OPphYR3bFA32SoH46bg4IOXDWT5EEiCFNp6P0JQvr4wyR3fp98fPYzbfTdnpRTfjpm2jmOBMwUFH VrbTrEZotNIm6ommNIhpjcbDFurzVbpzsNW0Hr0id+vTYfVtESo9EsFU6LxycNXPdKEzYpiF87Dq Eg6JE7ALnzApcdNzJSGlPib08Dd8lZmtjb6dGreJhWn3767uYltoIszXLRochnBS4dJwPHlb7ovf NQYM+e1Z0xNfgAJOtA3m0o+Tdv2ExbAjJlKuxfp4DW8mJyIGwLyr677ceZjMDwA18s2n0ETWw14+ nJLah58NyK/4qhh+4SeIzGR2z3HYV+vBzsCLHI9OdxCENjB5+hzQTmRz7AItzobctRLdudzHCe0h qmu4EmepScbAawUu99Er8qxbnnGaTW/TYiJaNoU4lyYWmyCd9WmcUi79OhS3jtDPpG4ldP5ue9xK U0II3PAr72W3/hRUYIIAQuJMIfOlVV4G1vBsQB9nDnkte2BsnjWpu8oNT71Y+bSXOiCyAy1xLMPs 97NGPEhjuUSaf3Qweq8nGriGETEKT8CWw3QjiefuP1iRMgQRMLCxJlLeI2/Daek4OWAwhHKdxxSD LZOCHW7o6uADZeUDJYLuCp/WH9Jo+TqpjMMvrKR8cIP25aEprp2ZjO9EKYhSrVVBdiWx3KkrVsrE m3wtX4vyVJKcQCVs1FP0Uet2aKpujIE9TIU9I2kDbem3c9PcQSof2mhiNk98rtTV8ZJDnYXlWAQl 7vXkVAw2JMSVo9KSPWuUfrNvK0S/V8mEMjQl6gmil26nsIPddonO8RPUXsURR/gqAv+v5FuGYUgV allH6HOX3+llWQ7behbUGGmRrxKNl0NajiS4vXW8MABry0GI7KFVZHZ6ddKHncZcjC81Jvjoarq/ PrhYsRcszrWhhJUDH2uN8T86I3a/huJdFtoTW6rPMQzbVEnZ0zdoGU2OKn5xifWixRpMcriSeoKr cJEcSIoJ6SKqUFYZXLL/8lGzhTR9SAFbVXIQvbQAfhS0xqOtyDz4KzbjZ/w09DAl4jyMFTEQZtzJ iKVT5SIvKdqUdStVNx8LJpuQexmKD7JDCm3pNCuuoih/Wyn16016XcHVOTst+wXjjT7NbK/UOuDw Q7tSkeOK3CR05MfBTySZIWGNnse990UugHrnRI2kdv4vZrdbUDUFZ6YWR/NPm0Pkx8JwpSaF3yoC vXIxVYmSZonm8Eb83TIZnbdHf4m/DD/ZN711vtpX3aXBHTmwHuvM8PGgZbNf5mkM6aCJpOpNzFhQ JxcwZZAuzscmVVr35t+0U0xM1NA8qSdZVKrP6po0ylvLC0yE7Ux/Bn3zkfYq7aOMR5rNLo8HgN4e jewl9MpN585aHarzfxBQJtItuWSOodhbiZQI7VoHhqB35bhChca0+BYC0fbh+xRc4m58Jtl1Nd+s dgJ/hAHfwEs28VZJ/wtH1foLKnkneMT/sfH4+C/GwxLtj/H4CPZfGQ/wv41H5D/c1R9UdNSGbPM0 ZdDDzi37OANvYGZ/u6vcWH90/mU89N9p/8zpTAAG9mf1y5+5hZ7vhmYG6Z1HwgiM81oTjOHf3FV1 D0t0Uew353uTc+u75fJvNLZHVpuMUFQI+eiXfmS3n0VYF6aDBVkpoLQ389pLXcQ/9D9EV4LJeyLH fi6ns/lGwx8qhoAqOoWN4fd5Sz+H7AmKLK4oEKIzdc2iciGpVZt+RJudhQc07tn56N354myiCsbx 40ae6QeaCRho7cegVQ1s7ibsK5jkT0TNKvBSKTBvJd/bTUx6a+LtJRmTUc71bTAG1qDjI8mt35Ap YwO0/YYq8jzYAuYaitaQn3tEzTZTULOKTaSoGu1/QEFYoowxQROGuUJWV6eJ8ypo6Wx3pQl/EeoT m2R2+HRbRuTsic7gWdnz8/icSZUzUk5ph7t3OhxYc2hBWxVLCUMrBpbcz/opV/nrGNgOOcpdKaJd 51Nk2hmS+ouojs4BHtSP1nO8NePtOC56feQJRHakk3q4UaQKP0XcAEsa5Gq8u+KPdhJuHutC8JM8 Vasmww5YxAZYh3WnbjRsTW7+Grdt8dx9mbMdQFneSlHis26uThL1cGch9xQyslyorXnLIUckcaKk OkTmW7JLUC8DoCqh7YvVoF1S3CcqB0zhX3KGEh56pB4EDvnm9jpfMKbbp3PR9d2ohH+9CPT6XbSO jNNyvipYe5Cezzn0V2lldyD8ZFouoayv6hAqjW4UM4i5o0y/xndndS4Xwu6XQolV1eMKXGeoQB/Q K7d3D5yfnUeNpJsxEUV7ykmYTwnpiwu/FQEDT0GTJA4xxnmNvP4837Y56IOTpXzlDubZdpPWATGT /P3DpDfT2CVEDxuCYLmJPPUyIeBQY62Mmw49Ov8mkYrhCVGI6x5v9xWHQuWpOj9DlybQPKo2Ipe6 NtCUbJBFY/kz89nxrXjS8bs1MecnuQbuoAwRcmmblLbCERAIK5+LVj/i95amwyvcO0/T0OW2T3+l ixc8ipxmiiL4jpUvsKJ0jlOczk/e8bVmjkep7ip0E56w+3pbnzmK6iQqzNIs0eJ2K0YlPYQ+dCBm z+RgYXluVnnkEWG7m7Y9480bAaJC0KteQaIja/Y+qW5eHfrW6qu43M6Ur8Fjkpr8BkVLOj55K4D+ loDUYqj0u0uEp+hJ8Tmb/eraXgoNlqQXmhsE3y4gtTypQLri9xHp+BRnTYuEHEV9642EkNwNVcXy LrXe1RGQ6S5V9XkhZmHAHp9uV8oNYt48bvggTq2UUMqMoljwbHColEUG3YzXrOB6z40lq7Sm2rpJ rqHHAas4Tk4oMSMcqMiocCbSqviNYWUndUSXc1uE6CaibtThx+A95yHyiFo583itYNX8z8KkRoR+ e4rKk4nbdPxdvGMrV2/kwln/37z0NNXrkMAMO/uJVJr58r7DZX/n8t2YGZ0yH1vvU04KcTj8Y1zT RpRjqsAop9fUSyfgznMzflhjQ/0BVXvaBp/YhLF4B20Nz54O/oEV/NNoktqq8HYFO67LngGTWLbL qWgrdrnDkmH1cP5vyIk5yIkIqMxzvNTqo7eRCO+o3nNuUhZZKKMBI03epFn9h9WDHStLmRiBhTWJ YQZ6QwaOKavAY4KEphXl7Yl+J0mC8/VgZ6pbjnQtIqf6IsEFHI0vFYVX2DZOkfLWxvXFGBpffpmW m03L5XgPzFhUbi2wOmd/s4S8oiU8/wy1IU+D31Z8ll94qJMW7l/rSHAq1lp7w1g/2C3lWNsy5dWi hy+9gx/iWLdtWH+kz8nIZpMZWLoG97iJN3lJl9dJfdIu/+NXGCsHpRp9kyIcg41Z6ubptY3t2eno h3hm56DHSnEOYuxsgzYrtTI1eUEoBCpKCYnhfL94o4wayFPZuMAwPgzXRMSnVNDXbmdhQcK90Bvm LZoeM+GTIKGtiPGY+vZvv1yELA78jo0oWf12HjPvOHEYTnDmktJ+35PBqk2vifGeC7Y75bZ20h5a w3HlPEOI2x+dQbSVWoq1ol0UyqzdfpkBoDlhWY6rDO/cUyHAcNQunxa1PoSpVXDwvY2vEGYz33O7 rRgWncDkK7Y5J46Lc6AgdZGji3rYvYH2aetDX8xZUuQw3oTT+ZDgRzg/1ieVJ7eGWxw6ZI1Cjioq 86L6eBQMN+qV06NYRZKp2ElipkaXhAwrsgxk7WWkakH6wvM/q8tR+WA63DHHB5Om694Ex3tVhvSl yQg4D1xdVfPTmjvWuNTCdLxqD2F1ABTXBsI4YqoHbpeujE7exDHur14E6GtJ4DRzhvPdaxs4s36n meAdU3a6dT42ie8vjWbXSt8m9lIzdEZcNV/8/Ax7GxMtFOEycezQ4ZAEZTQC55ehSvslul9DnwDU ByZTC+wu0weyr2oRxl2ad8+eMaGMf5ZWvN1CXv14fVEVdoQjik7fAhdYMiSi3L3wE8EBt4cFBYOn bIv7M68KCbR4OFy4ReTPq0peB+SFNvymIJWiXCQbmAVNmEG4C6Z76pDtxSDl4YR1WKbeirfRgc3K hNROX122VFfy9VeGg8l7yx24/xwifKaYpegC7/w/HsuG+Jex7D+E/xwcfPwbHCjC/QEHPk7Dp2ZI PVoUWvpJ9HsMEm9gDHB/gQNtoj/a/gIHlO+0f+bEJ31v/8448M4l/A4OZP94onE6YENyemC37/35 Aw7q0+BsleZwBie9ztbb700MZcAoEUOHSCmQP/+QZO2OkUFWQWUn/skSiTtG/cWNVZAR1i9EbIBS eZAbPte5DzwxDBaDpuOIpoMnP8Kq30AQgkgt7wE84XXSxeW6+9O4iYwLMBm0seGV4UAEzGj1yIWW gj6Nig+4CJ0S6kDu/8by5VNIritMLD2raIiq/uh0YBGEiiWMAN2vbcW3FK7MCPqavpsRsxlmEaA3 k6Q1y8eA1cceD0gDKajvVMRKdt94vNNx+SENKfyTpgNJvyEIdcDrlVbmWDNzHdF1X/txx1U0FVU3 mnQuEmKrFaNVoLPQSyR7UPehsHWQN89D96+UCpcIylawf2EX/7VXe9OY8NOcJmi7/JQOTVczspyu Reeynm3LwP0hhev5Kum3mS5tM0RiluCoybSGC8FtUhuNjjqTl6xhHV0hc8vnwpbm6g5ARKRV/8/D V6KltAzVn/A/i8P44kx/MtpGMwvG1lqMkpKga4qF0uUSciQOUl5+98xdGZGk63i7bOeTPxyeHQqd +55OMenlZJwKHQ59YFXu/GSZP3JSqtFcrUFXSDcvXVJMK1hO1l6+kPajvEhFd+FYa3mbbJZmWrgd dUWE7sgVpuHl+OcCBSqQofv5mNGneXs8WnfDpOe23OW0mmiGOI06iSp8zngk7+aBf6By9KEDZEie qhQ3Xb4ruUbjVrC+Eld6229en+U+7CMuX/7lcCNpYYFc98rZoqNljRrQvCtu+zgpBojW5+5QJa90 2C85zqimSvb0+t2KyM1IMFcal/yJQTH507UivRtxw+0HXJDJiUOit2c41/ScLqFmS2j5iLcBo3tm OoZ4pzpOUacwp/vqcUnu8dHXF3C/F4XdfFsb5JPA/QMhvKJsuapOwkf3JlWYO/GY6K5ARxiQRWxl IIil+1Vz12ZrgoXsBEg6GewRpeeD/Ph5tbkgwIvGnmY1G/oOFHvfm3kaX2UjZO0HIu1+ddid3Bp4 Ij+pFOlAPYPxe9HZbbfNpYUBjcYyBIM+dr+S7kZvBkGRnZgST/ppile9IT8KN2lp9rwa7IZvERIv 2oivI3Isxm5qzThtRX73Z3IWyYjpWB+eJZ0gPF2kuRZR3Q0FHfl875yRqtMgT+1YxsvnuOGUzC50 12QyLO+TKEmexKxJ1s1dKx5qUHR1FpQ9eK4x+zXMZqzMMlLqIEp/FsksgrK+02f7PN6zYXfjxlow HAUxXnSrP/bMh3ip5R89EF3fBpVpsCNIudEU84V92xv56nOTzzLqHRKpAPy9lN/Lt91ftm+wEouV gjofXai6+ZG4kKwLyfXfvlzl2iJAgMB3wZuiX1Dv8GI4usYpFrFIsHq8juKrNkLaUKzpu1+ld1m2 OhjJTzhIbYIsiBexiLG6CRjJTho/2/imi1cxCNL7gjSSq3w+PEI2WUDfocVS9hBMk53oinnjWBN3 d4A3g59BKfd0oDWjWcN0e8NeoXMmfmFH1Vxn72dcTqweYDdOitUYnYmEyuB6OuNvlRrJuatVnkT8 /TLtWvmipKyUoBp+Vm7Kud5uxiEl/yYNHz+5BeaUwteYvpIQ45bO3PuMh8K8w/8zaOwHd28ZxeKG nyfcqi70XQEms4xVkDqgSjeoDf6Mzq+9JFhaOVtflniRQVAHfAFQ9fbhEaoJVrjHm/hKqCkZ5i44 BqlbhvX9GhDs+HQG6feyMKTbm/jwfgkRT/qvCFUJ/PAEqxhi0N/wWwVvTNV7g7zCsjXVQL1ziAX2 WJEt+oQ9U2npf+3xZr+ybHo/pdGxAkE0VeQneDF4m4Tki+ci6zDJQAkhE4PW1ENa1mzHgjSWTEuW emdFI/oFIkZ6gHmfZMEafJ6zYeo9zRXPQ4q8TmsxffRs0oL0+bz9wK85V8MoS4HhhizRxfD2xXYE Tmksdb7GrDnZrPplHL05FDeVVSRhwk+NvUlVuuFtmBVZetnRGUiNNJ/1Ownd+LQS9ARQ3chWCaV6 Xu12B7f2kU8GP0f7gsYY9Dth3NC03u8A2t3azded+Cof3EezJl2Uk0lBfqizzoKAl9qhyR5tmars H7wfzvCEe15Fd7G2lmHujIeMbYOdYECqMbq+miJV2QG8MGdFFPpv3FfHthzIJ71D+pyRem8Naabt 5YhV1iSLqsSq3Y8hvDTVtycKiA88CTNl2pKJiRrHS6e6m2365r4d5nwfi24jbhM/WS65i3mUF9bR evoxia+XkzekGI1wBo40DTZyfo5WPNs147pFQCifamjYUnfESiH+pGimnmKyk3nJIsl10JogCaM8 75ioILJjvJGwHTk982LMKsmx6e0mqyir6GXIWpjSoONXfp9LmhxOJmAcgkKV6EidWDeliy8hbG4d 2jA/aWHdXrVZsz/AYm92rF5dU1Pls76e+Pn+rDHrwx3Ji/oxh9c8nsegqVqX/N4ljmLIcXGNicju 0XcLkJ3qrG1JfSNWMxVBdnxxXlSXkXJDxqqE8eHsVcY27bJ7bErAOt8cqUBIQxvlheoeloSVgwZs lMDTkrZp070psZ2Rui+LfcnpS41T8Nr1UI0CzApNIrcHFkrDzis6m2V2zvzSLQQIFHPuvyJYNTnb 41ygYrqAcnIu1oF35uX3AnBf5AdU1jKQLG6EelKuekB4LECvVMibLqCe2Ih2YFjTdK8z9zYYzy+h +HlB2UOttkJ49GI1IOhm8iXq+ZBeRdraoJ5g+CyqPDvdGfm9GOz221ainHSKvxJWrMZVdSI+cjcl Q99tEPtAqeLGVOn+aAM7c/N7UR3S7cZYQb2zGrKynUQ+6RR5RbVuI9XfiFiFv0fv9ia64m+yqwh4 UR5S7eZ7v98gHtGapsxQ71Q/6364x+725riybkIRBCzK4h9e+XMsE3QfOnvbFmUuSzTOqKOvGr7N H5ZmDYO8SLYtXYzw8FkGjlNLcq3oxmWspvo6zPAjUZtvJsRk84kuJT1Xl8TJ92Xx5FUUVVCIEieG whJZMiTwM+POBXc5Wq046UZ/+ys18d1/Pu2WbuQras4NleY4Qyo0bgmeYb0H+L2Q7Ira7kDfia9J 3xeVNsuhnNh87fhgzdutIzx/4T0QW9UJ80jRZODXPnkIfMJf81pPujm+Go1N7k1EPbEywjvL/xHw cjrU2JuIduI/JNi08G43MIZoNinQTuTE+HHOZDoDXtqH7ntkyBfvxc+Q7ivkel69d0FbJBAg2l3a pvL3e4x6V9m2HgJkaeQJ5bDxbrWIhLyhz0j8Xg7FfO4de203FshfWp/Nd+dsnSBA+kO9m87fUe8s Yhd65tBOrmOvt5yLUe+OYxd6RWHuSGPFe07lyV7W+giNKmt6m2UADvfUwBa+28+hVtusjsQy3+Pd UmQfQoEQYo1ACGHP8iNkXfkeB/AdcSnZCga4EqzWzG0unkddM4832rmT/tqmkCu6OdH1Y/GDYWOA JB/+yzSeqxyX5SipJppVJpEVHUqgQQhn+uvdmQ5rkaz0ObrFzFPJoIsByBxiT1Hj5q7H4+zB4c5R VeP8jvVypKzrSG6TLKVpYSV5/iXU8wRWeUe1CIeHPTv/8I7Cxb7RtP/SwWeb9El2Gcq33FpKQS7l rVMOSmzmkkZW03TknC1/HTtlxtNN1lLJMmQivIF9wiyMHZ3cUyqei1S/bCzfw9rtXFvoft1f8RkR JU+jXJLmctTYpB44mzTYkY/+0lcpPHz7YRUrbyZWptCBpA+zJDSnxN98eWVfFE9U0YDn7LWTbLAj 6m0DzS2N9ertIznkHjk/7H8O8XMpm/Hbwdv+jyE+5L9A/D+Rm/8c4kP8DfErYP5A/NW2t+8otViE x+TdS34pA+NvYGEwf0H8rzR/tP0F8f3eaf/M2UMABubxzuH2zqzyDu/v4MHAXBUMwIr4xMG+vfP/ gfjlqf8G8QWc78+CYFAouLUZfzPGSYNDoAAkApFjca/BaLlJc5EJg1Tj0QOwq8jYvrpifM9gYlmO LR6TgMI/gJ+fTvCDpsM8CFEpdoSnk61Cg8NMwYW98elYG4dK14uzYr8efTm3Oc+6XvO4z/A4ryDB J65TkYOWMoJ+lADvHf+JTWa9RSwiMdtVphSQgoO6naY75PIbl7381/YSn7yDAI52XtihaH//8PYD eSz5ivSn+I+jortbYgvOZnTvQF+0tVYGYdJPPl7a4rCH4Rs4MdGni2KaRFxJ7/r5+4WfUXk0H5Tw 3UwlHeHML9s+2WREYVU8iCYvJBseEwklW1Q9s7Z4ESzSsiwvfCPWnPi2y4+63WleFhSi/K0WuZdV uezKvl55Hcfn5IXk7IWajsGpgRTCaWOphaB8NK8lgd4pKEEi07+aF0TnZK5NLaViX2+0R/qW6fS9 /az5W/iNFrjsfTHw3KJ5mfVUpIfvrS/kpm3p4c5wph54K1bRsM4ZbzsZXC4xSVnFu1GYtdFoX39f 7gBz7zkaemPZGjtpce4xv6ol4/CWaDuJBCLlw9J7vOe/zTifnKN4ekuyncScT/VNXNCHJ5wx5MOb LdXy9YiKzFwZ/CkrhfaS8z224JAEULwQn0DhhSlfOfiMuUtn60O8CDXrzveT/ZAF+i5yKNKWCPWE oFzHpY6iPUBv48cqmEuYns3BbcsvjsNotJPjmONNWeQTjFwd1QgKL+pub4Qr3CZDCBDeEMcmrDQM CHcXt4kUAmQT0+kLyiLX7wR3g1w9h75Tja3s2XuHospDyradxIu6Yh3w9zGk+p3oblSrH/y8eOx5 tKJo9HV9tT40Zuv5oDySaDXI9XjzX3k2tUOA4IawNpmf30FWDLDrlGKxkaSxJxJaYnFSLAuhMVzP B/ERf/UlK08n2pMQg3sh3ywNe5tg1qJd5gnZpsEbhH1obdk3MH+a/aDklcQvZzFV4dJBMy8JNnrc mGn1gKLe+5Mlj3Th52WC9DFinku7F03N/vwilYy0blNTG7WWUgeJVovjZa2U7X5InYGYuON9+fAC c6JgnZL8ox6tePOhexTJ/eQBU+rWtF9PsfEMnOSMKPfEwTCJuFH4ZZMsdqgxe5aoxrccuqLM0Qc3 kh+SHAbcyxFu20FU2/u5FddfM12my64R05DQKMcnLkMsu17YP+v/OeccsXrnn3lsO++lFjlIOHpk SBahYj7ainuh3mnGNHZhoJ7Ex8Rvvm5K/uV0ROoJILt9Xs3G/wuJefjpCWC7Ma5mW8GATHZNmpj9 XryG7ru9jACLnVHP3KvxECDiIeFNfjbyExeS8wCPND0BeDfsVa53FIx1Rd+0BAFCGSLd1HjHdWtD rX9gIksMyyb9u7XxiL3vGadcNCU17dVWIj+5Jz0PLv28CPwM7KqnQb2DikHqeonhNBuY/KgsGe8W bT9bpvBqRcGOxLpz/exgmCTgTXhgrXVnUob4s/ooTfWl5mWKK3WLST1XxDKjYEb3+eDkBf+irXmN 4X48gnzytci9e3oksHQEGCUebvY5cFm2nzky694Z8cKw1CfSgEMf0bXrzA1RQn65DD2/1z3oe62B N9QVYtMk9N3HWXaLH8v6fKJVG2FtGGdofu2F9epZ8/rjZIs2IuvQLkF650dWSaUuavkQIKeh9+sZ 7UQmd5w5ErE0RE83Wgvp/kO3DtvKu+WrIiRd7Ax4Rl2183uR2U23VXw36lixugEe0Xobvqu+neKW 7+UY3R88IlWdQZ4I9JOxVZViFUE8ElVvuI8WTZfvsId519j2/B0VCb3CWpe9X9IoVyR/gPU/UFKC bo/3hyvwpkaYO93PPh+ScWKqssN5sc6SIUDXQ8CtaT5AOoYAFPx9z53GeQ3bKo8BOTsUfsO+2UZ9 iw4cGTeUyMCRXPnBo7vlW2allZILAdb1MZMKVjNf9NycTkXrskcXgdRuCxNDDOQqzwcYUP2QxdYA 2omTEcHZT92eV+Pd5K0r6Dv2GgSXIUr9zg9uH1dJITw6x2zPm1Hv0mM5emWIF4NjhG0HCWBAVkMr m++ngpKUstdL7/2KJOboxkA5gSJG8uOxer+mwp6ptai6X3V2PbYmUlDvKok7P3HE6xGJIfZ6GUgs dvo+f1pVhACx7rI2Tb475xyxGwEeQXrZURmI983vvgLmlabtJMqJOEl0ACiYWr8Tyg1pldfPC9Me UyudRL8TyY1olQQ8O7WpukWEafXDCLZL6FVG+qKajL3PJp0L9dOpZ6aQ4a0DEMtbfecAiqU3t6am R0669ToiM2KKu2Mh15GkZSV8P6xbnsiHFMPlrXLgrCfyoIHgEqMZtCoe8WAVvkbj2Ck+/4jIdXp2 SH8u6Rht9JvQbRqYZk+YLo9cQZvdWVXS0lbjae3a33MEuVUTATCOL9DzMTLszBOr5OsQXiCINbW3 yf99K8Fs0qQ0ZkMa2nrauU7wyGbuP50ze2eeFLUabXV66U3beg0tcle9VMq3O01IrYQEnXj3LTTF c8GqdaVBa1ojgcDch4DFpy4nvuS5orHue1wKheRX3VJqFs0EYXcfZYwQlTlBuiSMJIy9X9QA3WPz Ks0EldrOY8n840ChWeW4b9rBczPWkXF7NzbaLU+89ZyPU4B+ckf0a9QWQ2h5C7zZ/qgMm5ERmuRk 1f1QeYMUbPE3UEu56jPbyEzH60vf0dGH7Oc+WXpqtFjDizfLw0nPl+p8i1mMbkxjxZ+dDazoL3UE cENHYWZXY8LKV03OLpbnzirFA2wbMo6KIVhJd9utaTC/PB2Evsy0oSbsuqwrNn5u7KKjXASSAntf BuN3XZoX+I+X9s3PBa/LVNd32p09TwXETsvddzlymXOBy3jtMVMHCGz8ZEJiwHux7pgtiGBccgjQ p91PTYoiQyGV7XwPRUxsrIvfkV5rB8/hWp/XA5cp9fIN2qoKse4HEXQC1zbnlgtDYFuveWr0Aq0g LE4HYe6chpxsKUNgeTruwrsznQWLljuwMwzu6++Mi7ww6XkotgIFuPkW+OlnTyLgyl3oIcnHZcc6 w5/ptci7vcGvIJposvKWQitfDG2iakdW9j1PCOzdS9pBpWCvViLWK05sIrlKIf6s8+jKBBoNqFiU 4f1xQ+7P4+YLurw2PquPcMVtX38PvSEZIMC7a6L85+hxkwqNifwj+Uew/83P/1eTnUeR/6DHbwJ1 0/nV5dSrWTi3ZDYos29ghch/oUfQn1UYf6PH7HfaP3P+eO8EyTuHxzvz9ns9PgYY2NC6KRh2sxuY 1Z/B4j8DxOlwjujKaYPHU9rK2trah3npFyEx/MhBjEJkvBCkvX6AUnhUcMFlKD8mM6FrCSFCEQqj r74sVZ+w0J1F96AdfsROxdp5yThCYSB+obF3XBja/h7V9CkSLosRHAbJ+O3+WHaDIhrgYtkyKXB7 W2mzBlo7X3+y5uPO0UODcLv6LPgtsBrcg1yo8xtqgHePchtENxX8p2IUyC2aws+rv8X1PL7BREpK PMxyiAQhV0NT9ZystvE2XniHM4bNHQbZ448GbkohJc4XJ3yW6OF6XOY29pSERuFIrIEOAsOSODEO PFGI5EyhFV4+dB808zVGIbjgbDK1L4Iye9AKJ+jsw/r4VJUF24NR3E7RsCDBtFgqFZeIvWJle4AX O1KoRgHAMShPwVzmUSvwsqGqa0T2rj+ng0O0ZBD37NXtRsU88o1M/Dm/ptSAdFp/aF61W+BsGrjk m/8KK1fRucxS6mgmCDNAqxae2EC3NjvQMYoMmlIRil6EjpjHMMvq6uhY4VEcgklEETbOs2ig5SfI tUvXoslCXQFtrK9UaEQPkJLuxoobGArQcGimUIwFGNweLcxrXCJw6ehwCelk5uNenw9NZkJUphjc WtRo0PBbRTbqZn+LdOmqTG2/oZnUoaGv6h9lMB2qJGAP7Lcwcva+O40P+IU9CMhTa0/fLMJYWNoh qG8sHjh0MdrQEXGgde70tirFIFJ6pxYqY9a3FeXOM02edgEXfvfACTFO1gPJVGg83o9STbq4DcLG gEXyWSmPAH6vZY/pLKllj6JADYUi8mrF0fQ8vdGVn9mr1XVtoiXJDRJYa1MNq2shrqjm/dzibbVT +sHSLP2UVak1X/bd7KfVadazkc8fWxPNx0azIy1ZYVJbQbkdO5xWVRCDhwBLuUFWWTy62+mdJJsc wsIoujcVmIZnHss3joIkIuWjfPHEAZ3Gtm9wDW3wK/eG5m6hKgx0U4h3LcadhJbNECuTBuZcPxek PrT/WqDbsIDQ9B4Kqd+DinA//JB7TyfH4U83yWQYeSddq5Nmdse/zAUG+j3dvkjooOtBqwOT7SPa UPFTxTmvUN/pnuuYnAGQ4IUM3DFmMMN4KIF+xcWeid4UELtgwmQoHtj25/TBiTgkeeiH9o6fkypp ePo88QYx4Ej47AnRKX8ZR41O1Peow1hQu2lK+sA4J0Wt/C6qtTtl4kd26KYwK4NZ9b4/5wbMwCz8 On63opWOQvU4lF0HQUQxTBuVX+GBjsKvs/f6TwOOqM9GEOcW93H7K+8CNLtTOsDeSPxa4RkOvXvf G7x3AeIhFDpr8yLOE/FdoxhjwaeLIGhrjvY8z5n3+g8Rh4YX0aRNaZvk4xIXghmVHw2fkJ97oel5 2vPMZN8bkOpJi3dFi1yU6km7kL3/DxZo7XnCm8EkD8aMBSdk7wxhZAyH2hcupK402DMCzZ7IQGV6 hsPKTZ/ITYEfTGtHd4IZDA4egNvN27PNy4WOrFF5oj25HQdMzL29Lw85Y9FXZ1HH2kJf18lnhwoB vhd23GrwQ/79uG4oodcEVS4/vKS2PWPQY6AAbFfgqMDJHm/MEwtU4MfdH7xfK2KJSOxe0U8KuzrI 7LIsYYaGk3DdCEOv6aoaf3jJbvMO48bEl7FdeZFNcHSvQ9wJkE3IkH9Ol4zkDe5zIzjhrpKTyDg2 /zo/h+uGGXp9W7Xg7yWyrTUFXpMzNxSa92OVv4PbiwEOZlnWrVqFnvI7l32Zoc4PcCjGeYwiy7J8 IJNuWaaoZs0exvRSVfR4VXo3s5V0BlYv/acV8e02GGe0lGKWzNNZSmEia/Ui3TiEl+9jXmnBkia5 tky4PPii2ZhHFr/nVUazARY9x4NUi4VdzCfvzbvpwT1i+x5VqzrB4+EL2JKivFAjGmkdIrnD9cZq +5YLPX4PkaN34Fm8Wc0jWrxNWW3V6x7W3U2yfdJY2/9qYYSu8Y2+zdnQhrjNpbUSsF9Z5rZIM/xc HF95yibi8hJDugBQzG+sWGptZbndzEwVuHc1HaATu2sQrRNzipo0JyrvJMksPDA2cS3Yn0jlXqHJ g7NuUwygfU/SbTxZ1+KKHuBzZ3GDIWXS9ZQClEi3zYEoDzwkA6Xp0Xs4T4XTNvWu2msQHvzqr+ED 7vxPLTeewZ6CoEe+zoU4q7H40duHu2evR9HMW88xp0O3lj2eF+D9M49UGFevgl7f7+vcFfcTt/Y9 HP9bT8ugwp9F35N81IuAZosFcDvf8U4xzlh3f3pLcLqQQI2rtkwKzstyfVnJKOI1kVaqGBecp3eI YcvwZ8fl+MJStSC2451/jG8UyQyVT80yXj/v0Rp+ymYXQdHw8qVhQzOb9aRqINBAs8FIFGtKJoq4 5/7XsSbKhJCIhryHTvMZUxTNPXYwOuWh68PILgvIbo8FRLwHgwp00J+EdIjntJmNpol8IjYWOGya tttzF/eRpZqOpjo/UOWOFJGjWdBCxy76VDlLFJ0jF/jkWf8tu6IgZr/0OUK/Y9kovcKa0k4HvhWb NrHPrZZd12q+oPT8vZYA5PgVr4D+934RVF29eZnXk6qnN4wXlXi3UjmQH8OCzrx6vqggTqMp2jx8 uYy9hAeQwRDUjm0JHXrNIhnuLmam5BLPyRCoDcse0feobhHuPr9cdEZup/OhFfxEDBUIpKM7cpPK faJEBc5VlXZbk9h5y1vLM4xEHo2STVjoLfyIJLZ7zZ3Nef3CVlIZy6kL6YGx6IoKJLFEKdMx2vZE OGHTa4zjbOxp8NNGTdHgjnzE2GI4QtzCuw37LX5sNtY6QVZJ4xUxmtRyNl9YwQxAvy98mZ/hHs3h MHVlpoyA2Y9xdL83UZbM4UZSF5hLnXx8DQv7agYzn8tKjHG+q7NwnOMeTB3shFnadjW9bT/LB35M WcpEruRzvjDlNJJspyY+M5d+kz/PZ8fjAhv1265UaFJ7YNAuYICGbvkW+5ePYsdsxSR0PXXytm3U fRu3LrfhC2sJjd+B+FDhKm0NShryIIq78GXIgmHAU4ns5VPEt/qn0ZQKAe4Ky8mta5QmlY9r5sdu xis0dWYekGvOSbOYHS5c0pYzQaEt5Ql9j9aLrd0TMZxEJPVmwmRrDSl9j7KLPN1pgIzCESuNkrKV MECGTXA7QVlon1tYvoxU9UGDECpwRc/mIw9gu62yXubYYs7q+p0nsB3jBA4VSJ8v40DVcuqNCkzX t/nEI7jNK2g1g6q0tk9q14FyJ1b1CRXoXC5Ta9FClzpb4KS1tLr8RTOVYnl12efe3hiU3qCRVtaO 35jLzDnzVvRCVO8jFURpM59wYta9Yw8xEVkrMTUxyqxkT7S/k3twMfVlf8+mDqFh4/vkImIMe8B5 bGO39cd0S8NtT66TPT0QICPb3wvR8udEXfc80xnVU2uD+QuMZpiOUfgtrT0MdfOPDqVf1YHuk14a FUhzycc7ty95v7ZAD0C97I/p30232/CduRbTySY09Rp/cCEU/HIf5E8d+PhEQirMgSB4vqal8b1V /O0bTcj1S/hlg+nBq+h+0W+jnAycNc+jZTnAPU5/A9SOZ+OW4cqMYyMxC4uzAA+ffv9P3tDwMWNs Xufc6kKumq7vVQyMiMtQsbg9k9Yd9RyLnfVEdeef7Tqg70iquskm5I4R7maeBEHyCv7tO/hcBTaN ycfip4M3UndqwBcS9KGvwjTySw7yN2apOia0M0CcXoDxFlBKYHEkgsjyOgJLIkO1uwIc7/2LUqZh 0ah3G2BSSJ2qliMyQ4uQLF98kFgxf3/caj884+JqRPp12t6sFlKXzxVNp0XE5qmc5S6b15XIDPCj Amn0KsFGyey81c3Y6GlkBmje7yn9Bb9IUjvvuWVzrXp2HJsYTh+IO1K9xhjOZP1RPRv1FE5dKA+C xUqJjNIq5apGY4oJjq51MPbAvmaCBoKTn33vJnoRr7uNbAJNj/JHOyXzuwm/M6kqJpvQrtLWwy2u n0k53l4ZkOq5D6Jf3zzQrvCY986uVtTFbcSPk+bqs37zn/Acw8/cwuEzTzAdqLvDjyMcoVDXNoo9 mLTEWkGantPnJi/a4rzebaYiH6DlXnWVmKxS7adbgSK9SPDKFkPBdvAi+W3y9jVcFcIZJ1rK45Rn x/kMPeLH6APe+MxY9QIlOIZYKbIHBLdJx1zTAXdUhKrVp3P4+4THpJSXcfIC84LYp+DsfZ/zAxvv 82/jfGQTo3rJvvnxnG+tUxvPrb/SfMjsdGBaUS0hQq/h7l73IVvNO0S2n/UXkfwj3x9NgHMbnWnl 6w1ARmVAO6olbeh1tuXLeLZlySN36PVclaq/zGc7+u6krvXZ99MI50G3KIIKhLWEtOwc6Xt0Xzzu pojnXNA/1tOlkX4Zj0o9T7CfvpwMm+HNl2Y21D5l33HgGnhiuguv/TLgWX9V0qzx2M7le0Md/cES 5kSGBg1ooV8JmS6xreVb/uO0kdGug/DOvWqYbMJpkXvxQ2roNfeikx7XO4hYpFjUDw29lqni8F0D bPPCOKMu+oRJZ9j4tkOe0KMCh6viuyfgpCudceNV9PMfIy78lqgzDuykWyZENjgpUpwGttWySETt xDy6F4XlYpkHjV1N9iaHR2Gzp6Lg1nQlzpQJYV+P7KN2NK84bEZOeNStUtvHzLvLHlsMG7u3Uzv0 AGZOoqmdtq6wNTithvHkeds2uOvV+/fUDvmsXdUM1o982HP1Ued+cjk2HYTyL8tMQhG6Sg5jJsTr 8gTnSmXZ6W+ojUUmMYWNlPCoUFVFUZMXq9oNZN9qFuPRvtxjqbibJGMlKNFeJDeKc4VnTZAHL0wb tbwlBZXjTUn+KnQprjtdrf3+PEzmc0eGj2KtFzuaGZe9l6qghqOm8+3wfhcEJyUVBjui6nplf+U3 +Uv826j6riBzPyuO/Yz2YN3vtGwxF9jW1lKsSNXi3cRtT1Ejdb7WurzpN9t803d7n9iZY//AaU7O dbM7TeAelCp7Tx5vyEmz6DvZ++Gty5vg5OS1sSQzG+Mc9cyePubMXqyCim7LPsm2gjYuidMn2l50 WsL03H6vu0/9SGgWpfLRhVT0rjMDaeTk0XY/ICIKzSbAVMWaPdvr7XsHZC0YD9bxOHY0mZwYpWwi qDdNnvALYoLeNIZbRWaAY1YyvrtYJibu7Z2uqCMfnsfOuNrVfmjfZL4geGsyIdMlHwFQ994hsz/X xaH2eKrSea28TJobv3Hqjfz2Sinuc+3b4mgbJFf7zy/fwvSwnmioeRsf4UZe9lBwOl4aP3RjFwae PUN1AkA46qa2jHAtNcbOSQL5OSTftGpmdVER7VT60CIAa33MDRKItpVJ67JPZBOlO7bJVNOViWKB JEuiJ+5o2ZszOQgVgJu6L5y0Ahz73aYM4xVa7ndx55Vl1Llla7cOOWf2+5izazEhtRbo2CnoUhOe kuZSY7V15HcJLA50L3FH3+gX7EmY5h1eN7rj6+mheTw3w/pblZOA2ueAyVb3q7OQuvVb7BGC2HWH /qO1T57sq91vSSNvUG94U0utg3nyZ6Q9X1zk1r0+c67hyZ991A9qpTxv0fF54O5r66TlOnxACXj7 yUUuOb35jIGR+JovBMirPElOynzT5bhyOn27ryGSGel7I4rdmro/R/ivhlY0Gf4nQyvg/zK08t9b 1aWL8GdoZQ5JugPd4XgHL7AesF116PUGxoPw19DKktgfbX8NrbC80/6ZM40RDOwz2F9DK5vIYGCW 6H8NrSw6OYF9+LMb+Ktrxlwaki36HMHgxmtzu0DzyhqPQd6nYQxSMUjqX19hDL9wIRcoQQMQ6xgl pRGhAyDsiZ8tRjoFYaFJwEk0xKhUinPqktjlcYxplad/YeKXL8Ziwn5pwMbO+/q4cA46pTiH1juL MuRuT7c5a8z2Aq3bbIBe1jvWIvtWI6juXYzGhmGx3x5+VaR1c9dIPTCa1Hwewg+t7kyPUC5g8YZI tJWHwdHkWNllJ6EeNSLvhYObWQINLvG1yeL3fXo8Srm9XMznUwpjSvUq19Ip9KPrpThUkjTW+YQl 8bzzY3qXSyGGttKT5CKquEeBnIi3IWqsavInXMOx3ab3SUrCxGRC9bW9lMxz0Vmck8pbLEHfg772 CR9q4qTS9Z61QvtsP/8y9Yx9nSXRuIYAnTjNWPCGA5NH3yD1r2mcJjcYc77MkXUR8fI2o0StpW1a muIU1NBPweImEOElhQkq1ZqnGvg3Hs+49ZdefHlRNzQ7EQ/Qu+6sbrQ7rb3+4jWCzjjD9KS6d6Og QisbT93iZEQAHXDDvkHVgo8wuq1BPNOY/060V9gSGw+G/Gjum3h7nQwgUZV/pdSkpNpV4vLC07U/ sUj3ccLdLJN0zvs0Hze4qzIW8MTGW65D7VI4wjBzZ+GvufMyx6eE38KQvRZlN0ZJfqRNpNtex0g3 196Qad7mI3HQYR9W3feCe1SRTGhf0LIwz+VWiTGwZmEFbEZYXA/C1OmzceO2yIx3LX+eYaYsLgfu 9Zyfho2x14i5kXpwtu9Ja+zHJbE4LtGZzcY5io7SGJXuFe6KaOqQc4yU7j5odsyHOLIf5ed3KE2K dd5ToVPl4kQnAGAGhzfG3A8FSecuQWRzampafktfiFju62s7TjnpVMrtNIopuGVHZ8XcUtM8A57V ajV08siXr3jL5bMKyTeuXJPn7OtpppIom3H3ABW7mvTXanSq7qhWbn6F8lmbgI69KZ3SPbt1EU3C HauEQdd4G7cU63qtHMrlK+h2ecJflBv2H7osvpvVtY+Ej/dflx9XLs6zzY6w8OGp3lctfQmWiEMN gjgvDZBw6AYOXFjpaWF1MfRd6JiHsIojCPu9wUYc0z4sYb8SiIew9qIEQWyADzjBPivBd2rCxeZo YKN6smAvwFygMT0jmoYoncIL+3WCDTjBP6vBd45jkMg4BxJ3Z0PtcMN6swaZNgvnwZwxkj1MdjUh +hNFbaVmIRePoQVB+OBGHIM9+GJ7O2iE3Nj+kYmAvWC6md1/gbiObBbBAQ/zCoG9wH/hxbR6ESiR 66UvcbGnp0Xk64PeO3ODXKyGJOzH8GFn+WMHZRBPJLJZwHsvdSEG6vE8XeBVx5DNUnCCILKRBurh PFXhOyEG2PqIgiAq74MleLpdBi4c9LR+fX3XqPJZZPlDB2lQ9qcd3N/E8DD87cIhdQSeHvACMANz Anzw6m7z9msq2xP7hymM1IzBSkI+c6LsujQ+QPPjm+Zlhtt7iWMN0Bv4CZyef6aW36QvH9SJdtym qX42JN7BNqrnpxMcPZt4CAFIEPpiuzV9d25Vrp5NHITABxCEmgBS8uYft9BbHPUZ+8RQr32mCSIb 3oN58ZisO7qHH3Z+ZpT8AWIRrUuHFMYb+06/6oyfvvsPomuXRn0GO/moJ5tpkbnO3EG4HF0f+Wra ruSj43IgzzfFpBt8ilQ1pB5YTYQ9mGJjhOWFl1rsA2hZTMsVPMxh+JL6JBK3iadnA8YjhNoW7zm1 AGC/tY/bPNavhOKRQG3LtZ9akGe6tSPrXujRgWvIJnNtcZ9Krkh7UovbLNWrBAclkDUdNh2wEBS8 ggEuMKpUf3hJo66Wds9Lt/Mc5lSepqyW305hWci+WFtlV7YzNT9JOhesi3fOqW5FmpJb8DUv4t7H w413TPNsa3y8XnbgC/dKb/M0jgW1E3bnbMsHutFCbTh6etRa0yKNNBnI4L/Bghw25Llncrr7c91r s5QMmeuNv1kJ32R7PErsRlSWZaFk4lK1ssQbG+gimo/3bFh6sqC11XLuptMxXFrrX0aIP7e7T4Mg yxfsQeshOnR3TskKC6WVIH7T4rM5qETwPeLHvYRbc0y3pw7PxZbe81AdOrrKIkRMEUkLErYcm1p9 498qNivnpY+EcuGZRf34e+i9N8NhpPUzhZ+E5xQLVMTMSde+WQTx5bRfcmRrjFOQz8tdz54tkxj7 Z5R4t4S3Wavwxz467K6uJnnjqqlghoqdnhmoHlfyHlVa3jiqwLozpD9j/xqRhFL7mDsVBqOsSKJc 350j4WjupMwqVJ1ofG/QcRo8Z41Zjf+s08qxonPObugR0LPI/Lor0nzXHrcT5pFPVyb26KuV26dD HN2YpKhp+vrrinpPPgGPGosmVCdStTceF10Hqf0XxfYat1vk088WMavJ1qkj9gSN3CiV49ndCikL gqBjnFszNuXYFGGUTVvPomnamVJxRiU0qvJICDgoDJLYEnNSFgtRfBOFtstnQCNQnKa2rG0EYN8A H4OEMqgDJTCYM1R3GPu9nOCWC91MdR40/uheqWiH8X1UcVWq8vu5evvN2psog9NnorYJVQL6I3Ia wfjxvmyDQebgW8cjYXGS6teUpxLDmLuS3HY1ht+vuynB9pDLO1EiLHaIsPsGX0x7MtUnRNrCzXMz bEpyM07dGrVPdzLC7VfmDid2me06S0stfrE4LQTw4m4YTpzB+ngkr7SK234TlckrY1dTUNTAICAq PsSER0CKKipO+SYf+JvGJrSR90ZDqi/fMDEWwJRkrItRFjKWaz9vTuxvPxLWZ7R9oXN17b1Aydzp vgtPpJYRfKxiJUowGbwtoe6k7GY2XrY4NiSyMq8x0uJt3PfQxUK2MnGDf8UJ/DRGp6kFpcxv/vzE XX83MV/6HfFW28BhVEMudn5jLaGGTVHu6gLyXiV0ntmL8WyOpYSapoSiEQGMaZsrL2J+bpxj8OtV 7slF0fTb5Bdx3pa4hy+NmR4Py7s/RtOIHVZDx/jglINB0TW9a+urtZr8J+74e86jS2cipgOFVS8p gxqlngeAvtbBvfKszqryrLu2lUEV9yzBZq+Tj3KeLLmr83Dqrvp7YxK6gstddTKqbQgdq8ENqXc2 543TWQCQ8Mg68X21wTKPxs49VTKUXSpGX7cCz8BoJ5NBLUP4oiPPdYWLyUsDRv86EdejT16CSiKU xUHFJkoLQchyecHKktUaUt3qvZ0x+Zz5h/qWmdE6Hj39PeUnCWNRR4M8Xmx8XW20siwNTaZ8A3b2 4xKaEZIGlrsS2pWswDKQnIXzNl8iIEsddFWs1XBqFdXu1Ay83N9nqGrv0zvhgljmyn0BGmuq+1cn suGYSiCUT2Z4SCCIIRUPF5HCvMKeqHZ1UMB4J6/qrZJz4LCRdev6vaAu2sVtaid+yi2dNlKKhdiA 8EBb7JTwc5HHi6A3j2cKJXtwqMr+CPIjczUV959amjKKoIR5pT0x7UaMhegUtWC0nkqLeM371HtE edlWlu28qpZ7yvhkJoc7XB6kw4o5KjC7IbGkPOXOf635knDrWbAR6cofr3+TD2QJ/CgVdLXsrrNw ncq9c3zsyj/DPo1F0iPTtcRtCDd2R+rVzN6lVRHJKkCC8N1LM24fX6+ASzytn6w7uUsHvCGYrGmG rcuxRSyNVMKPwa8d2pIDYNvP16W0SjquT9YN7M1CaggneyBfTO4Kcm2CqAzWRmqIJ3vgWgR2CZm9 2x8/PjhLKMDFTJWcP8KFPQw/wZ1j1SlZt1wPP8z8xiD5A+viTBcuwI+j1/pTKwCIq9cwnof4BF+r QWTu/NuGKX40D9+hqkMzG2chHvjAUlx5yc0ncOY0GTmUVxihuD5rPG22s7Bw+dxkRZFIGr8+AOkE z3yY9RWUqlQk5SvUvnROAig/h7x/yuvS0a31oQJcoC6S6+nEbRJ55HcNrpu8wcZtInV5g42Rwbya paE/sJYvdYaRPagtGnZPA/zO7yV8X7JM3jTiNnf0oj8eS6A+/9SExXfkAC3EQzAEayPOv39pKMno nNvmdzafYfhR7kSqPgMuGDIVNqVMa31IAReSi4l6S2TdndN5XaoatW9ecejf0wEyy/Q+ic4DG3lO CGQtkjoRpyQRt54RL612EW6ZDdzfCumgbz6XW99eRhg6bUYYCurRAC6Wqkz9996NdGUFYoYqFoS3 MOozZZUP+HwwGaf/eBcuOn03VpcOWJI4qlZguV87uQPM65cT8e4rgF+rXmvXemwThC6sB5XaB4At Q2P363CTii4TxeDiYheapfomtoWli3QFfyvB5f1CcqoyVdaabGp6+VI5MDJlree1UuHB2TL9LT+h k8CD7Bslz0u6YttT2r6ASGmlTjNHjur9w7n01kp1lq+P1uDR8VE1jUHKJAPQKN49vbpxCAmQ1Io+ GTYvVlBVsuhxthPnnPi2G/2i9Zr99uxULfTcGcHjrVP6X8zD/J+6e/D/4u7Bg/131mHjwf5x96iG p7nYMr2Ublz22HxMFD6/gd3/PQ9zSOmPtr/cvfN32j9z/qT8z9299r/nYfZr+NiiqxL4gJxtbM5N 6YfZnkNkKojnwmUMJaC/a+RW/dZjCXheHoAlHdiN4/rscrgGiboDM/IzUM0777NEYXleuazpSUhU RPwUfE7+R8eqr8YZaYLLU6++pLAzzMu/wzbu19pXxivXT29pPa6HT73vWs9BXude66CORqyoReit SSCaATkSqvMuOD/VfszjLjt+gGsIUgpxVAwHX4DlHeodhIbEd8Et86wBWiGxz4F55dXFw1KyupSJ ZdKuIWWOVsRH+gtlp99FocnPrxRHd7eoxQ3bvpMjU/oiI59UgeE7hlxvpcavD4HKxX+w+DoI9h3F Q2ogSG5yIyK9Qlpb3tSkoV7xyyT0ZbVkK1qwAeiGqgcl63jwl7Fgneoywh3Il2dKZLbNSvhk4sS3 zbKaNkFJW1HeRZjg810DtL9bsazOewrv1lTo7sn9yK2617/OLmAvHlnA3DsHhCQrSlXrmS0Av0Su lW7u73AE4lYTFtWEO/LpNyYqjxvlm/SasTuOcFhkH5ZfivJPvERKzQrIryy1FaLFKoYXhdR02Jgl AD6afUqJNK8nnyAA1mIkSoUf6aoZWHhZGBKI9OuxV3BbZPBYDjtrYVX3uYeUcvU24RLYVYwmlTfx amhNLorM69yPll8JO+3qHAxyBywdJLVsryKKN2ha4UtpKTIIzAbishAtmGtmgErYVsqdF0c0yqlO VdL5J/k+Lgx298ptto5KxTmg0iQShHIBJOal/M493CTFhrEJyPHaQtPI9uNEEMjH40OymnCy7r/N XRObz19DE+SSsnpNOtxKyMtmrJyO3L2f4HDx/Dq0goTIAif7fjQg4fhwg3d2H2q6xooee4l/qseZ vEB7dgdl0UudHOOKXG8PNgEms+oQh+jctexUGfB0G3uN3uSsWVOBL5i8NotD0tAxN6EZKNt65Fa7 VgYkBGGfVpueNa8Vu7+mzZQBnSaYWiZSm4GfGo+ax63mrzXusbWPJ1avYT97f8parlfOsqPtyNby wWkP/0aNd5gfs4YxiZ2Igl8J5uiNw0Da8KFzvIsIKmrr46YA48WcXwQ2KvqPiTd8zqD7Hz6TXT4D JKQNGu+UTgj8XplNG9wHkAgOCgbGOwEavxdh0wb7QU7dWGSxBMzxFXITu+KDz3gXQ5xRHwXgw8Gz /DsB3GeuC2vFSCRa5p0w08XUhvC88qnjNz0p9ynsV6DPuxDNrk7jTSCXUd+nYPDfj/5dTFqfXmt8 J11GQpxkIX9eg3wNXT8+cMB7RkmJ1bW+90TgA34v+SYDjmuwplhdy3tPzsGjtsAvsODb2MTFysbl wbg70TiDHLqyWS7axMVYXd+b+OBxBrF0ZTNdNPoaFk0qg3ETTSaiFP4QMN60+TD4GUgFlkk0Fo9C 6StgtvmGgN+LdfUu9R44GmK3OYjwzNPFxLupDHbEKbVrtW6k45P45vtbfJIs+6kKvuQsJSp/lWnP PD9kGd4QQHOvgpzk8SbtZk2coayq+pDQMd79m2JjRI/sN851vSi30NTZ1z655yrD2ziNB/of0e7a cKaBeej8kLb12JMvedidcKZG547bVAOu5o+DnOxIT3jJjfNP8wGtfmv+HQWJMoGb1UkJuY3uEb6P prEJpNnNg6TP+jdfgoWru76OLaC6lgkgRybOfdeRvKxMnt1MJXrFzD13VP3C0HObrTfFBs+EDucA RBqNeL5ETd0lKoj3FBIMXZcZe3BW+iKnMhPY49JtzZa5qVhs7+4I9TkOwMgPrqbPhLam7964J79l LVVysBw4qYnop916oUtcy6RISx8nSRccYFnO/bJ47kGLFQBe8Ixb8FwRpfbjcKxwuKvIXaCkjbWY rQAyl515Sodw4EJuNCBwTn5mlTUyVTPdRQ0IWNu2TdI8bHOVtMrPd8lJvGIKkjyupEVtUKhjwA/7 ZF7l9fxAFXTtKL7t3bQFqX/+oQxr/PvLzyppLVJ6NEWzdkFLLBdfbX9OXVYe1OCuKtgWe7AenLq0 UHpqfoOX+osQNmXHnR6FY/YqPKyn8tTIvsCkbA25C/HvDax3n+9sUi/EW0LMLAH9N7uKZxZmCV4W pN1ZetB1C6KO/V5qr5c5T+YfxmqQa1UEFX69RtS5Eg20SKlNTlKyXCsaiOSNKC7hYagGfvTLmyQw Tt0vbN88YI1RRhSiB457vpUeRh89KdYzxqoeus6xMO8gbCrdyqj+rm6DAclMJpa1c2j5WVUTuySq QZiW+07YFpWS5jgDCpOmPNQZID9q7xVhdc5LKnrkO2o0VErdae+HNUMZ8sRq2hh3fnUMaPGMjarQ W7y//SpOhhxqzt+e5gx3sRrNVEJNPzFUyl0Qdo0ZYilNfnR2jCjuudWhVsXxgNC0jIro/Knuq8ns XLiVYshUkUUHd5tiiejBQkWBWDqgDI5x3sott0nzuhYbZIeiocJJ+klAZzL/6Ga/MkWJClEj2sTq 9Yl14E31GMK4E0uZofSiXg+J4fwEXiS3A8McRLFfhisssGAwWl2tUbb2+OVUzc9uSAFlch5jNHdK T66IA1mS3sRiKno5yMmh7Pt4OXuQpWqx3HLCPD9FJu5qINsiXTMX+7mSj4rFsPoyffyd/Ib4m3bJ zqJlgfOouNU1Ce21/grcQ6sOXLpbiz/fS2yUGiP+tLvSnKVQaz6AoJCHQ2Bince3zsWvWzEula3b Wf8rtwxUnpKFX+3N6PR99xktH1mqdjUvwsLK5zwgcY6qpUmORxK/aat0Vm1+2Bnskj4PrLPq0Lll arma97lrsuQdnfq8WV/H17lD4CsRd/v3N4V5J409ziTIzIJObhw72k01pOGt9Y5xX7Wfn0wJ2RzQ U9Rq36ArorlmvY588E1Y73jd1qYkdV3yptVYvAarsU7SDhkITMTBVmayA2dvOXljgMxoazru4+oM Wg4FYdaJm/anYK3KPUQZqZE/0Cb2tkejdI24gMqcb75cNoC9zBG3fOxBQtMPk+gc5MDiFRFml3kp 03tODwvEVhc1Gm2BCQ2LeQO6qKb1PNpgBnXeUUQJa1bLH2OnPjXtoFRHtvXLtein/V2as4/gxygF LR1q6gqa3ooe2ZRdvY2rASef/BWtWXZcChmP+MXF14oHzi1ueM5e9O5x+Q7ZeVpP/I/7CW85Dj5E px6IFW1zyaHLlRzQx+FOfqhqlTDIGjNJtp+U2fIDJZbtLfQvtiLtIp+hWfIqdbtC2yDkuzO8XLal e1MDl6JP1+rS6m32tLbV5mXb0mWLvJ5aD29mBTyij/hGj5zD3atMYR4RBvrlNaa5sSMh3QFDRQ3H VUKpj2+WA4ZHb53VRAyuu29QXHAfGxRR/7+HqnD/AlXhwP47uwL0ovyBqkemtdEQ2eu8cpH1y4/e WIVvYNkof0FVB90/2v6CqsnvtH/mPBL4z6Gq8Z93Gv5j0ieSI/pc+yDwbbWZp7W2FQYagvHbFQQs OmPoV80Aa9r6L3p6ho+6EsjgocRxn5ny4lROAHOwV7xFX74U20JYoJeAJ2kozWbkVh6VKuvmfdHA QBb0B/fb9wI2Dq8bw1iyV8Blx294Mzucn683OwDPZEikksiKdXVoAdJH9M2VYA8MvbEtADpXQJzu SEBxEvkhXydZYp7UGY4jRC4peltr0dzzjwgKYwlFCum0BPp2T2nco6TQ+DzecwWqq+1ycQduyTj0 wyZ351Tqda5yisyoaTJNIdgA0LSveHESC1VN4qS/z71FCOtSeASpqbOVlaBuW2V36NsAByYJBtr5 5Bcr8mZThCTS8ieNqeHmwlurlyjpQdPvuYmC9pGrjbcnQ0xWpjTlplJTqitLJbv9CzNMGyiVQyi4 9V320T+XZw4X6R3nS5KGYkuX4xIL0JMnNOO49NcjUx+N8x0qkqf3JKi4E51PePObN/BIXHIrYTV2 dXy3Vr+ZSJw19qpqke7VE5I2EuZm3M6dZj+sY+fODxGNWJ3aWFh51LuQkbay5a6HeZxeUwbkXU6z fV4q8/61MCRXUjwyspI2J09td9U0jCZGSpNsdI1rNT90f1A8cYxAbYd/1VIQ7yZzMTskqlJyddW4 X7/OvPqKi5+G//T4nQpuwY411tK5eR330SVL6X7ZmvryyO5XNtYUthR/pa4a2xUty1y7c/Th3XIe 4r3GM28j4Xm2CEL6Zf0X7bAJgHXxWamV7HTOqcFDWj71tJhZYY18Wub6fFxDc155YFk9hb953GTx Y7Rk3n69ZA3bRv6J0pkCt871Y4WETaHYqz/HXO0UnE6i2Eh9HI8CJgWf7B3IYrdYtmTwHJfabnqX KiVSzHCf/02byCfTu1K0YoaabunYMb1BsVnm+Bla3VrEXMeMTPMa1rCwpufAc3yhWmLcmHYpDasm c0Ro/jENzi1vHzXLcvz6UdaY//y9fjk2zceKUvPa0aOQee3Mc3zHKzat8CGu3C3HppB5auExzefT 1I+0Civtvf71cNOc48rFZYSEo/XDlwtHJJALNbGQSu/Xh9FZZDuW53GmVwBnss1mZ+hlsjlxjgbc x63sHw5ckD7UA28SSCgcR/qfn7O3tDoC3pgH3n5Do0hFMCK/onAmT24JRF8mpxDnjMF/3CIKcuAC 9yEbePsRGCJKCx/gAz2x9/m5G9unGoNkX/Ndwkdb+jffN7mIyU3inJhg34v7nuY2pDfviM4hNBIT j56vD61bWnfd5+GXZs4hKdbvDKVbWuu+PpQDPOvIduUc8AGdHyf2ZB44DNsGsUgoQO8NuDmTF7Z0 oy8L0EgouN81SHImq27pRl6WCIhE3L8LqLelj7yIZOqAnDDW+gwfUAkTENJ+4WH4bMaZ/I3xvQwb FMJ34WHwDMOZPDrzLm+kDrkaz9slwibI4dHOHVvkrLYB2LC81fqo30bkH2xDh7haENb66Hlv469U wC5RfwSTQ+sugJg0OtttX64BgO7EuFRpMhF6+CCZyv21WHkUZouDdB3eJQGZX4pOsXZWoz4BuYPQ jm9VX+iBXyN1WbxUOfyd5fM62D0TsSdDu/Rp/kLJNfTWArEO1P0HYk+XXOlT69kSh3cKiQ5cYzZy R7h6gTOTxVxqwIUFcqWvBUkAUhUzW5f5XJZI6rKzF5eXbqJ71fiRQoP0abd3MUXL/mll2kBpacJg 4kqOqfb3OfTHhGfXHrlh33mFiPnCsPVft0maT7brwmtSctUnUsFGQRQ6Xv3oxQKv+Tu6UaySuJQI vZ2784E2JbUPX5yopeZaGOOA2bNsEVdjsvyTDvNITUo22xU0A8YEheQdoH1GmfTeFvNoZI2bwwai S+8mKVqsLVOSLJh7RmJPtG0KzsjW7xrPBwoPcnXqq6VUnj49UxgbBVRfjCgQs0JHXqd82ce3G3Mr bpcptu++R52TeGNVZA+KPpiFFHZbkQX44F2u2FKGrkyazahmYdV5gqxPaSY9yx1cpEPvLEBOTtxy p65P1c4chZcJ12uDMxCOQUGwAo5kh9QvJ8q/PK4bymFvHVQCH+/I3dsdQgk96ldBHC1wlPX1XXyt 5XJE9gOHILt5YcQZnoXCKO+x4t/7IO71Qjqsk5nPt4ed9cGe1o9LzcLMlfgeTnXiLEXiPMvpO1Nj 6bdDEvwFlITDj3eEfBvWv7mqKVuSngtNo1/l5Py9eYg9P2yDcxIRP694Rr+y2/zGC+Fzf5bw9ls4 1O8Q9vHzSahaWEm3exYzGihm47Z32cerfcDOpYkl0j7vMN3DO1c3jPCA3gKSZMEt+CO/CifZeA4N YE8iP4p5pjvXEg7gO+dXp699J1sp2Nh5af8uBYO4ayJuMkUxO/fdkTIth8tbjx2HKCVygFvowS0E 2H1LEvC2+J2Znx03EiHgoj8kfOsJuYdoPj2i1z1XXg5aN6wJnT4c+bVo3gh/DjdyPOBiL2R06xNy D0epjFjt8ndL8oBKES0YjhTk14Bpo4xvuJGfhB6o+5Rte6G35EZlBsyapxZloXX9mz7RByN3iJoz a+SJ7TBOOU6wCZDM4ZXmc0SQxhk5W9+5ShOZ2iwUZJqKWQPcxc4ka8UZXjqb0w3vjIWZg5EI0rjs PFeepzqdKHACfS5rJcRHosdk2b5sjHcKyNx/ZKQJTeUnHWaTLWBKND0kp9LcEXHflPVCyyXEvny5 6ZJPyC4hXLS2VHI+kHP+TrBySXhggZ9vl8Z3BTr03ch5Vrrtkpi5q+SwBlyyJKT65Jp+n/hWJkUR Ga6eCG9euAf0CJroMWLE78cfDMsb4X0L6+M1FbWfpWJcWIHcX6KJa9jpw90V5FnICN8hrKNBmyC5 XBoXI0YiKbU3wtELzcZfWIIaOz5ZGFvv8z2wnqDM+rhPmbUwBgWzhUWiA72QjPyq6N31nNBpwi+H z7hjOtDuGa4+tsF0bx9PvlIgyqnHWSSof0vwfQahzW+tC1jjKyLqOHjYpNwdpemwlBtwIYXCEIgn BO0Tp1wVb0kPgpLv3l654QbBlBqFLx6frOet3GCvC0T7q/ywpLFLp061Vq4xYU/5ndtqQCm9xq3P Xvsfvi68Fqfl7yYrMFsWyAtde8g9jQctczkctYXvBJSFnkiyAFWUUtvJ7/Q9lSJtqGeFARcUBmhn 6nOiD9x9TraGMFt8IXy2kzT0PRu+D4hNNNBbBH2Iq1I14RelKJVBrXHI/Ah2uFoxv8sfLLLoO0ec JUzVWnh/H62ivco7VL0EXDqOZF3ENtP18orKbWbov3/rkdjUmXyNLt4qlewChfbX4ZXZ0W8pNK0K odordPc9tU9fknoZOLJlluL54rZICyzlR4MLG/YwefoV5q6Ai/B75Ne5CXxTpDiIhi/G5o/5xVaP 5klUlBtXDzhnxG1vAmOWUraaWv1ok7aa5OE2icyuLPqi95dQQ5hEn00v7IUexkM4egnIAyYVaLPy jS4UhB7c+25tg2G2QEWY57kmFwZCDwghHF1e0tAbUrWuDHT+k6QBusGuBKtQARdrTuEuCywP+EIP 9SELPaeUAecGam3hsd2mqD2Vgm2fKkKR+fU0ePVMLooDLlxIOtDO6IRcGWqbko1tifQvH3AmTAwf wTF32UGMW/BYPuNYOz9Evxw06ulCVTzKnPB7o3kkCIivYo1fkm3H2xq+P0qTSXRg7zmEHnZContv t+nvM2cK4F8/dcYuXMPrDMdbKaLAPn6iFTU2zuqzaslCutKaFPfIIvkk6tNxQ7Utt1XDR9/DINKG bI1H/EwZIuALt0jvz3tpZX9CMknCM7izWFDoIJdDOo9JvrGcVaNOVQO6Vz2GLg91qAk2kh0hwsMl ykz+NEXplwFXVr8yWZuBdemjnk+1fkvYyzFT4SIrW3JVx+dwYt/B2N9aLPMsV5eeFp9ewtu42O/s b+o2chXh2XFiLSDqAc+1MUMonPgiZhTty9394km17PM6mXzp4sCvsBqhWQbteE3RkV64DHVafKfp /IMT++XQJh74c23XbVRHGFoA7VK6iT7gAvQo6CHgA+e1a/87qjPd5YLyBOeZzwPq3i0+81fB5o/Y 76NOXyyloJZZM1U9Cq8NbHDlCV5gbvlLl1snqe/WZaAF8C4tm8KhtzZM59bv1atdoORPI21m6DGv Jgw4XF2qodAail9iuQd4wnX1kwtdGYq61yU9BN87rhOz4xXqdR/bAnmOZ8eWnFsq9oiqO2e/f5lY q7j+IYDyyQNivGBwwTLryvo/PC23LjMZZd3woLdKkVW7EUgDBMo9PAtvFddPAy7YQiw27aG3NFmj K0V59rzSkDsw7ehWJYRcMaph7yOOSJ4l+2i2vCWhbUjYt7KUtQIqhbWgOJKQ1/0XP963nZA8E4Sc /2j1Q14XPOl6hI5m8J4F7b3dvooqeHq7FVU65L5CnuPmT60n1ADtjWZ1j7yi7cces+7e5l0nJYaj n+489EIrO9+szsPQz99exhrD797sgxGH8XkEn+GtlBQEhNODfL/5gS5TSAErXsMnbwTOKo9ntaqP Bue7d3dvZ41YIJOtJtBpUADpF/5Wri+7aEb1EOqyTqiTuHAnvhPgrenxAPiIV/Yp4smvwJjC9NpY 5A4IOxgtAaGHyYevQJb18SUpeMft87DkB6wO0bboa9Tsg3db1sz5E9eq+Kt+tvNPmX7PRsWxRm6v kLUpfCTN1szeeZXCLOQOdDsqLUziZ/mGFa6RBm4G1NZ3SDBqma/Y87rdNoZItlYAtVp9FP1sfSjp s82OUQ3ugzJ6fU8Gm9PZfxurvvk2NHZdSRmg+8P1gxYF8TNxbpfP0NC1DVkAg6AW+EI08itLe9db ahZwQwS6E/vSoOk14EL3O+QrQx3vG6bQA2wfhq0/9FanAtyzbrHb6yD0VjKxzieOBORXi/yut/o4 4IYYdCf+pX2TpdCDzR74W6N91huV0ANGiGpX5OcAVWQaW2b5zejO/ZLVlU71luXKkbnXifEzSs/r E5wOY6pXmI3wDqu6pwmCpLET7y1113zFEaRHlTzXW7b+JdHSytWt4tG67Df+/IlHh7DslPGJQcc1 B4ZT6YJLl+cd12yCmLwVJml2SNSNy9a8ni76YuafQ/SBUxu9+L6uEKuwQg+FyAKQ93TEng0K2EMq 1B/f4Wkj8fqnezbi52/1jIxK5fC0pAE+8JeGtrooPUjTsB/960a+QhI/Y/ZpbnZ8DjivxPr0dJzo 2x9wkY5s4weKQO7Ilsc+MFX6JAm9xUGyDu0Sgsw/QwtvlJboCxlwcYxSGQwKQe6gpIG/MUr0lQrp +fpMkN0/D2muDvgcHonoeBWFFLHLAn5LtX7vzVQVzW+8u6/HhlZLY7tF4Psgr+5L0eY75UqTlo4l zUvt07u7aaOmcSEqFPXacI7TZ7p59f5EtBHyRFt1CLigRMkOOO7V3tXzrNQdE/9UyoWkM7Yhs3h8 adUCEygtrOkdPKJz+DXdesupW/OhZZNGRJtVvF8RS4n32K+TLEDX1xVydTTgYoPkFbOi8VTBRTbd fdnDb/Sk1Y/vNEcPKKZgZ9v0IuALUmxwQMMBkPq95WQmrq4aiSmAcCagnyWXdnzojVnsyHqJPpFk 09nXdo6qZYfDOYFDTgw8PVzVNXUyuu2tw5WtVtZ65N3e3UqE6zaLvwlBvDvdtbkLKxzUVrgTR4c8 XhO31jTEU2rOPoqVUtwDLPZZKG+qTFhjXCd4qa8/+Jj5mjM4FtdmgJtlCHeV0zxpDiDSLbULal1O zmFZA7I2e5se06vaboHFG+kOSwkTM3X517arhmrGNDHRqFmGw+wJBOnOORfTZWXg6E1ZGXecmcvI jdJyeR0omSeHbaafXPl0b/kW/LFhYyZncG3KXuNSkYfssDIhsuyLF6UqXXGKKrU2EQ971LAYjw8O EYgbxHC4phuqOvwmsEYoSev9X2w0+T8dUvqfriM++0f0U5MD/lR1Bsx69G5z6VZEVfcNbAT2ryEl Yfs/rH8NKfW80/6Zk5v8Px9Sivl7o8nxf5vseta+0vr+y9PLxt23LRMSV/1DklpNw29Hoco/0ncX l04DYTiQbJcIAAFB8gYhhk3wKnlQRIqoxl3wUeHnwBTi2FdR8cypKMTF2DD/CAXRvhCfkN/noNO9 dQqX4bX8qUOmjZUN77u1P5Nd773PT1ED3bAdeFP7U9JlDLYdIB0zMfVUq0cfGDGN9GP6YQ2JIHBK 4Zgu4ai3ClCpJyoiYmNFOEf180X7+4mdb/Bb5WdDiaqpXh/Hng6qp7kTDaSNtaPWnbhtMUNikRO3 xwaRwQGeGTGq2mUBw1fFukYE8PZqWpekBsfJS9WYu9ttCAK8vnD1xEm2L1QZ5+IsrwGGxmVeG1ta 4Y8jxjn7TEXdgYaNy2j+ohh9Y4v1iIl8vdxzpotev7I2avk7VQ9d6XWQDHf5dVp5MJPF7Khg7PgL NOyslaGiZmKRl8TqFdeK1rGOCIJJrSYtmvbc+CZnr7nXiyt2/O/bRGp5K6eZb9ukj5WSzfzvtfYa eDlaWG61js+ULNbey780s45vpPkmp3jmuJ42+ZIfaSfvQcy3vKMLxRNXCOvXjr1XWuZGR4+yuYrt M9htwBUw515FdVoetazMXWX0mCwPk3KvOwdu84twzYEr/AxRv8wSgAI+isQVDGJ8HbpnceQ5FNoT 4bMHHsMmhRlT9Nc4ASSKG7qHRnZv/xkyOluxz8Nv4BQ3GA+q7K8s42T1399bCvjDeH14DYyMtk/N E1OFiPOkTPltupm99CDRCEg7jvoaZ/MuEuIZDa9zwDBu35UkZlfOD8YL4jU2EnhAUSz0rsPmIxo3 jPf0QOVNWh6o7V0knZ7QuX+nzU6vJ4VZEgM4oOOD9AHngx0e0oOMQqoAOOD1S8pvns3zxaYFRgC5 GETcMwrjr8aujRo71S6yNZyQr3GV4GjuH58R8FwgZKZv9N77xJXyu3SzcvnBmPGXmarI5+GVCkaA eFf04oMoIzELzbtEvSQAN4T30EDnJ7Q0Xtp3Qhdj/A3zwyj7K3nKbwZhlKE0U8nKetbMRyvdl2Co 3RKr7Dmutm8E5XVU9vnnl9uDlzlWdMlEpQHxd0SE8n72YiEjrwHe9a81yvZek0G+ifOz4po9olOQ W6mRt3sIJ8BqjTq1eUmd9CZ2leawKGoSLFChXUvBem/f3lClaRVVNbNkWcTycUpZfSP3coKi5MY8 xXWWrEiHmgipUrVDurpRzaHlpwQzpUaelYSXqF9hI0ThRw4l1UYaAHniHNQR1goh1fTpM/yjpvUC 3ELiChz/iNKhlQIl9yDqCj3aikJegzk6HMOkFEW4pfqDQSGFgqnI+0YqmnZhrwWdAlwfnvEMDYAh 7XWT9X0dlY8twq22hUtoq8qzwEY9ii+7cblPkem+fqf/mQYOmks5+07RK4Gl4hkivJOudQ5uuJQk EwtcbP9T9ofhrMAR22pCUH9uxm2Y6skULKyOKbP4/VruODv7xdKAAn9GHXFHMPfeRpfcY/IV5fPo z0g7HchWWEsIwFW0F97jYIfxs1ncbn2VRbe91+gvGbvXYhe0t9nWjPPPgHWw1g8n3HG7wBuZ54yO jPNp1a/pO204ziyLt2TDrbzpbsmmkO9s/ER3nlXVWYm/kzjfBtoDfXZ0hu9jyHQhPFAWOeN21yro 2lbq484d+OD5CIFI3d7QlrwA+0/pvu0/YQAdQisjqt9LH0Sm5zmBVVyLUrLEw6q9OggqEnGrp5ZA a6C5dwxc/eCjxqJFtzUp4AyNfVE/OGY3mqvhchDf4kFpuoETqQfRL1M1sOEyiy9EdoGgTIoOeHrk vp7/mnm/lnxTdlB8R9kptPygxTuXqxA52vjBK+vH7OrD94Z9MqDmzfWRUfl5xslluicFkRPt70HO M5kH5bfWFD4qF6a15NPrE3xnlsPdH+lfoCydLOcqgthq6zh5eTTW8a0QORIbVRoDcunK92qPzTVK chM5ck++Yxo80iK92UvMq7N3VPpmBp9begJ3ePCc+Zde9uKU+BSs1ZqNAYxu1tXWIV5Ak0k68Qi2 55DqSNBHIYttw+EAK79yUoA39B0xo9w3iavhKkr/cdJyALZHJfaeZ0V1VqcBWVS7Et1q+LU+ttpk DlvnwpPPsjM5r5WNKuV34BJEOTBLjW9dMWo0tbtiFvGnFhYoM4m6ZZf01mLs2PrVsSfKs8pi4pZ1 vSTjfGpl5LITGy9ruunnr4oCfWts//OgoYRtPG/FCPn46Et0AzS7DGw8OcxaMX32AxHu/c3Wc2gp yigLqigfTjj0S5Wbu+9u5ANtS4vflFmAvvtX82kDQaGsE9eGO88mV9lo4aTBYu3Gha0qYev8mzXu oDia+HX+rqjWnCM71ZL1im+dTlbizbC3ogub7h7px2JAxeV14jOrxmNM0Zu7ADxRGw5a7KJGUR8k Lxusb/hzFXJLcqBDq4w5jjlRzVzaNe/GCozpgzHSfB5UbttXbu68j9WyV/BtFvbkRg2nJVtLFc6t 5xQ4lxxMpPrREKBkErJ/rEc9Iwfww959qfo8fHEzbqk+0nr2cexwWAGWd1hVWXUE3gUZGP2zx+v7 nKY7heEr4/FvzVlEvrmU7MKOinOxZrej3KfNgWeF9hiBEze7oYHnL7gWpnzadfZyTWaWnNOsv0Pe ftlrxnrfRietOG+2gX0sJbikvTKenkyfZd6gUtmXmpssXILYoE/gGd8HfVqYzPVkychtf8Pf9vZe bVX55U14v3NfmzhH7/oy8iasAiKdcNGfZIcbgTFKm6OvNhwgdx5IKYEmCO+00Qb3gFnUj9vd6H5F PGFXlrgKrMLyIyADeH+4g6wSer83yqs0u3VIAN6Ed25VoVoSVxSLMnoMMWQCcCDaRdfCmF2nquOu u1gygY8g+EVOGYkr88U5PQ+JuOwgL1zLMimJqz8z8wjIhgUCXogXb62Jh8+DvQQW6eN2KfWywVon SMke+arOP6wIxj3zLZ777h0JxW1AguirCgFxnXAg7SoUHeJhKf1kP753BqtFG3+EexjAn7XcZZlk j+lVGxCjd3AAb6gTni72eDIfhDsLPSyJwYiOUiLFO1yeRYA/le9XT45TpE9hkfFiyW+VA3qqIpcC lgZJSpAek3GvWYbOeIMRawM4OxZxET7SmylMFLYDrj/IHv8xPzQuYbECGNkuBmHluh5z2oIP/ckE Ug43+WPoqeRclpeE3JuvQ+/oIp3YEdBElRYvmsNzvbajk7xt/DTzDbR/8cNOHukxGnGJR4/Gn383 uzgUXjK01RUW1aVpWbKADUE5cvw2QdJK3YP1VN7BUq6Xz40tvab42xZY6XfuWJmcIdkHZTokFUd9 USe33ozvxtiXAXjpGhZHFphblt6GMqKsd31ZWB7rE6TZbgmj5WpCIiKsgQlT5RaP1fjZC8BU/jXg 7S4fazQW3jWBg9fhPfJ84IczYfa1YCR8Hi/u2s5siTt2kkcvwibvY4KDck/O9uNyWhu6SbnqM3Kb e0LDzJaNN0uB1vB1pryNM4sIpEWkpbN8MRFA45oXSODRNcYH5zNzvyibxH1wdfIXWFFlBylCS7PI +dpPINmvbVRSz1KkoMJ7XYrQZD3E7TfI0rbq5Jr/YqkZMicUmQa4xv/xHpD/06VmJP9YaoaTSk2Y fxc91TL0SMNoK5TwBvYK/xf67v7zcte/0fef/R3/mXOf69/7pIX1LgsJDIwTKRxMQkcdrO/P9Mc/ cw/TbL7jAQkG5QoFXFpmhsMsRfXPWIvRipzwKONo3/TXJAAtVQpWVwluLKd4HHZoU2S4drjmX8JR vjMxuXqhNGBdpiOM6CQUOLKEpOFALIV36xj5tlHRxsgbMKK5xt/lrHC3tXpkAc+aN86tGxQTl9T4 37KAoFWvjslztywPTyBaj9/mOR85tCAxJbau4AslbQ1pdlNrKw3ETe4PORafcP4p2tCQV9+FOO+X L8YDDh1r2kBdMbo5y9C+07sTB85EazayF6DtVxzO9GfL+9o1//noQ58XzWe9BRG09VuYm+N+mvrm 8J57kdz2XP4PyE8BTa+tP7VQgsbuRq7h4ByAwMDkAHl9kTdCtk7AClNt0OfnCd5WOfTsCnp6rcxO Mi0KK5DWKtPEgdepACYS1HEPFP/rMuJTuilAPina6+PTFM118qRue4z3/m1/6TXcZAHVaFEMq0/W tIDD/mWIdwZ6TcEdmjZPEdF4p9fdtibQPHmy0Me2xP6EJ9HC0OxIYtWSVFbTXfAt67cP5e2k6bjE gCUw4Nxwg/jloOd5tfmRBu6weRQ4nahISXOnHHFkSsA0KaeRVrUclkr3rGFDbFTfVZpBzxt6zLHb EgN7t3Ibuxnfyo/KqlWpPVAxON4CcvIiexDVJoLxVq8QqJwNzB5+sc+MXFmpmXp1Oc49fMIzyzSe vTFW4szxQVRwsRmt8b55UZUlpOl0ZbaadRNk8BrOkztiC3VpNFYWcH8xeDlJhzvkOFKdnr1E2eKa qSUtQALo/+B20mTHHqUsFb921wwKFzv3tss+K3XSlz5slKNMaPfi/nUyWIg20u3J/YsxG9br9jBN BYtfHnQ6Y+hkk01YCro8rHZnfM+MFRroeuESFsEJTD2dzshY2WRbm79XFjgzvmfGCqs7nmaj5gIr kW5WCg0/eoAcLfUE+AnwOFPkBj+lyOV3PLESVcL5hNyuFEJVt3u5I69EyyEZQF0fCkY8sq6rZif8 arGlWrfJxtzxANVhb0TLhV/6P9Zhm/LL3MwVIqE5EfPP2mQrCHuAEnCXo+WKf/k/JuAa8MvczRWy DLf8lnxX2hra7tWSvhgt54L2Ltba75F1Tjz74YV0Eo990l3bc8bUEuH6KZWEtQadcZmQAb/wvoX2 1WU4IvmKteL3w/n4DEb0dXVa8wtdxGV1kUnfVbznSaM8i8q2oUBYarUfiqHqo9Zq0wgV/VWhICnz hOi6JHYsKtaj5DTOUk5dPOYcZj4dgcu0tfyywhSgVdQMjpxf7Pu1omfENPeR/DIJUW7doHhzKVld vFbA7yuyAOeIcGQNHoU7tGWq8JITyrrAuPiGPx8ASqslue+PNPQgKivvBJ4ZuLTrsNHXTpHIIQis R7OxJUNjga3dyhRbzGborV3SgFo97amWt3T+67AByxwnSQ2IlxZZQPhP3QWcQ06i3DwtigrFaSp6 IQnKZmgy7cI8cnpwwALKITc5nYYqK/7PvFVlRKgziIhFpe4CfETkEc9fElS9rOsIPJWWnBdwc27G vR+EOAdEofVjw5GF+IWg4bQCkK9QhFKAJAGMNlOs2FsBMjPQv8syv3A91QhSnXJafDS1Iv0KisMz jQQbWxYDM7Hyj0tqgv6TvTMmBQPVoPxQb5UBwK22NcuAmM9DvGSCVDtkQEyTohIC73IHxaEJiIgd PQN+X/4p6AlY53qXQVARcEgp+fkgcraXQYwyR3ytkUSOU/aLKUMNMEr8TFYKQaxODj1MLSihAiNU g0m6M6BHI/EUeT6qEnOj6XvciJljQdzyLwepwC8EHK8KxMyvV3r0MoEHtIbj+fq4wbXS1BCmqUrQ E8zFyBnGCsSco3lCtkmAwE3aeFjBESVoBXYc8kYDDmFXQqugVeAUBYklSc+/HE6+9ZCIz1weDEaJ CzgjG0PJ/+tBOSdBNL2AurkSU3nYq75I0vXvZPufpkW9vNW166AA1XAEmEpMPNQMJ3YyzmNLCdv5 pZjNslribnVTYb/aiSAI00wEmLudIAgQE6liCxWohIVZi475H4lsdCiGllS4JgJ++J8LmgVGhoHy 9EGq4cY4lZijIdY4U3SkLcYijREHSShrzDmaYo7vxOApux0bcecNgbOhM9AgAc45kYtRm89q7OWr nfjAvxGa3glb74Sgd8LSukBcg2lPgsvIfhoM2jpTVeH/+pghMPKNnno0iYuWX3+/N9pWteekU27O 0LGI69C0IM6ITHts3zjRGu6jdy3TExr6bs8o8unQM+ve84xneWt5dY/gRL21xybYExXp+nGDO1oQ fzKcrdZBWyctAADcn7J6YJw9z1DZdofqBPWZx16Z30Jsmd/9iDpknAlGU5QRRpP/GHUMa+nX6TLw 9xpwgCo2VXI3TRhIx03UboOm8otrZVvOZvtVGPj9CA3sKk3l52kMyLNEVeRDWBJt+U2dZinAYPPJ KfWZYX1pU/Rchd+guWr3e36zeln5Qu2U2rbMGYNTpRUWv1QbMmquAnzwqEzSrBk+S3ntPXfEr2Kq zPt3SumupcYv/SuNbapj3B2Xwb7zwLI0jUs0e9w3hJ0HLFN3oJmX2opa/W/SuCj0GoTLXDN0G9qI 6GbmN3rwYXsUiaTwrzVaEHF7JDG0WL5G70+CUdHP6u9VKjjq3gnhUzy/UIlyXYTIV3yVJVU3SWKs MabKSVqURRrDDlRQ1qhzNPcOsm7ermqXS4d9RIxu8P2afhta212bIe0J/v3HNScsexujyLer9G/Z dn7OfoFuV9SXqQMEN1nQxjnHJV8MS+VzBjuq9IG46ZEqkL6AIR4oeBIbzRWOIxe4fbNGDMJB8cQV WSd9yhVbJyWR838AftWdvyZgXtiY8SakaF33M0RoKvQSZtt5pEL2QWd6w2JE3BkvwiGi8XuQGIsA UhJYDPOdCgSfvBVULVZ+2hrzkuPJZDwXp3hUA1Z5cdzldayGdaTRihpP6kykANMi4jj6JBh0y7XT 5AQczPRfT2qjCGWPsgshrzqWza7phlDOEBjHLc143YnxGSvdTx6+3Polft/X5DLsByhdpYfIKzhS PerPfqGSjsqNmxx3YYYV1boaFRYDeKPqdjdCjaMmXz/PeU5nTO7Mr/NZJuE3sr1Voli22Yy+Pq1G 4OmKUPplYYynAnVV6ARd0+Zv0k8RQ522+LLtWL/oIG9cu80hppx6siWgvFI8z1DCBcE2OHAOLXPh 3yhUo2o6CZuU4NUkhyUulgAxCtx1Lv9B1DUuAZX8g2iBq6g906ZU1qeCgMQ4d/HjH0TniOJlJgYM mmrla7uCtGiPYrXQcoWgFEmcqz+tb/X9ivmlXYvVYBTpQmk5CtgaV5sqh3rioB0MAUbNTOXNe5/k u1fVUNWtpS2smwWVGDmSRJLwZtI0rZExxiLJY/cG6vaT8EQg/9+wczLENFt/KzPzG7UkNa/Rm/UF GtTO1w2YkHjSc4rPsSYFW8g38tIeLWnO6BHO/10ko04JZovc29KYpUMKhd3XlzF0a8J0GhXO8XNT m1EjrBBdu4op+n/F7rQlHVc8QVZ99H02ZUktNLOdeXz9useCnlpdFdvpYYhmGI4koo1u5HMvUVjZ XnCO6ihS7FFCdrHsY7uSGEHhkZfUbcf7MS8MKoWa8EIBxymjRFSq/qBYQ6REPOkotvAIRSETkXnu 8GfySNGO0lq1kguvsksMNYpBiciQlPGsXcl6tdK5a8m6YIkc3VxhVolc7JFxaLFOUts/pJNK3b6L IM3jJmGZQ1n6B3+FZslxVsmxRL1xcQOvsqaEMiKLMtdJPvMRp/JxkvmaYn2UUi+sIgKNDnVulOJc lRKCnPLH4ga6uYZCc7xiampFZSWGRPnBYnP1kqTCkkClYmjFfBKdEiWIkrSkksNicxLlQQUnXmUx AqAlb3n3UMYnTX5cmSmP0Fz5+6RODI53LY20c3Ryc3RS5HfG0cOOfhe6J2x7k1v/RbwEmVMG/3/i sX38F4/tv/fWTvl/vJhLOU49xwSOTvVicNHV3zDt+g2M7u8XczmE/9H2l8dG/k77Z05Cpn/v0x+P bRTuL49tk0UM7PrveEm/hvZ3vCWcdlwz1lwe+bKhJAzlcmoruCXX2gZxgddfZsNxlsLJRSHUTnDp yZZ5Mj0UKqG1+gi/UD5wkDBofmFN4K2vutFfCrBEMMjPh5gOnu5gJWeAQ8gLwIYArw/salgr53Hw YXXp4FFcCU1aViPM9pjM5AJmgVhYEH9CC3W73JPk5XgNvSqUZ4f0RIOP7O9TwKqL//qa8KwCDku1 lP88xRkLryGO43cOZ2nd8lZjgZNHHsZzygW0ZWk3/z4/aXQwOVC8W5iebX1W5z32dLwxApUugvtk BlZdqUqfwecWlfm2BwYO+/GL9cvEDtx3vzrVisqyDF5t8cocM1ZjL7l4m2XniNmvB4b2dz9y2r5p azerCUQnma18QHI5YXnSBUUnAOp9+aFDFhpmNnKS4Geu5PXGuLlVdPm9LqXv+jlUGOZV70xTk8wS yAR0G/jvY3eojjlDO2SbstVW7Y6LXieKHWwWJuizJ7zfJIz3eRKl+mkdyGSXQ2qTEDU2rufP826b sz9zTU/86hL35ZufSn0a1njpkbzbtafT5LJv2tbqr3Oap7L3Xp5+rirHNttaUIHb0ocjGT3tqW3y lrH5GcFtvlA4a+riJVmvLdBK20pI6dR4/JTw1FYhV6ybcAxl+7G9NHrEid/a5sgZtGElbYpnY0JH N9OXbFa38IRverY+63R84DGIOJmgy5VRf4xfJ6lLfhSvInO0JrNWFbXOucB5Oy95Nz4QSOvgCdsu wrsi5SmRw7Q/K7M2r8av5bVUt1yjXedx/+jVYsP6DSV6uVDY1SIbcev0wRH6fKxQOAWUQFQsl5yD cBPKZJ6dha0JuulbjJKTi8h8vOnb5McQO1J0L/P1xieol1vI1QQ58rUQZFeIu+zP3H65L+ZUyD4b wD2wMMy9MzOxtMg2GWjYmRlbnPBMw9nhT3xvyrf+tTM6cvndQyv/46FFvXtoPH88NBArh0L2hcjH zOj3Ds09zPOXDzTuzJh7mr5nmuWuSW8PnXN8t9Fy76hYquvlUkNPHxJSF1PlUmHOZnokvLizLH86 G8zyr0lZns609zl7tiS/V96jrhb2ozyRrQuEuZPulqkmNILflf8yyzTDEk4jbj1tfqZdObZ/Psft lqLoZer1EZdVTcGort2949BFr16Tx2PBEjnhaIVRQa0mGoBOamTyTmToPy3VQo8RiFwZyvjRllkV G/fDk+pQjD1lOfBXCUJBA+uxSmv3bBKsdT2etFUHmYFSefMXA+nyUkJFTWSmAmdnjSbJEmfBr0Ua 8jDKmujIJfOCI4IlznZFJfh55tfkjcv2MSXjDE1zSf5K5a79e58VLWThTLmxnXTtuB4W1tiZGT4L hDZ7lOHncffTFHDDgQs5hUHPpRLpTLlfpH+wFxUVn+JW1AB7aZlIwPzaWeGQ70AykAAL0DKVxIIM oNZGRi5yzKSig4FWaqGn0jaVhOulkQxOmXYTl+fue3Ls2FVIQ6zmJ9huQ2iWmyEuUJLQ54YAsRL4 eaUhyueTf/B9/xTMP0RWSkPs5m8fSdgPVN8zP1AZapaM8lIOVvVmu4mGzp7htO/9Aa1MSaKUGfLN iURoLvR/FfYvSjy0MhmD3H91Bqzq3AkZE5B8U5dTmI9PuCUz5gP8x6yo8UiAnZK8WWeol/r7cS/Q u7Tom7Zo4BE1tZKq/K+WMNg5ZaWiihwhJwyMkj9V6cU0mBl28yrtC6MNR+06Dcpu7ZalV+5LKnu3 NeUjx8aaie8VsP8hHZUl151KpxxqOzoa9yjZoJQRpzLOaUJYSFCMqYy1hVQ/mgj2paz7hTC193AO B5id08NCK/MwfLZtHwvYck+F4Tkm51vBVdREdXeJLB7HWjVfSFl+ztA8xVW02BeVztJe6LF11oab wZ+Egc74u9C75BRJNQ73XgZpFVcZ3PWue/h7L3rY/EYaPZYQoD1HeIqb9sauIH1h1GICxU135NUR BR1L6CpozKUoEHcrj3vYfJtru/+kLLOOp8Tm9l7YXP9Z0t0uqOwvWYq7+k4rqisRzFdGOEPglj7M iFmP2udT4Um7Vzv9fvVP6d1tYOVU4cHFLyVAiJqL+jRoLmtqHggBdDyvTptpfy8l/52CYSYObcv2 HTlVHLilbWWDX9JmttTGDxm76SqUmlq/H17JFuWP8vxKQlSd/d+lD4ocDFq3X4N5fvkiugh9BCx9 VWCPSUAgM/6/ZxUCqFgKISNOAyRJBpyFyAd986GVk7GQi6ypwOfoRH+25EMrNaL7HiWRfFtTgCjR DOM8yrrlEkHszHrmzJGa1C6C0z5LYsx2JmWEWoMeE+QAd/idmHEkKetEXtgSp6g9XFyxq6RqX8ID XthHyT7Z4xNWeQi6fPPOprnr4rffg7pISKuKiuKgz+JN1i6Y7HwgpWcOX5Lr3j7RLr6Whud/yTmX 8Qk69FB8upHyPLsV5ZvMcXhBeL6G1v54VcG2+ek1SH9nvwe/i+iUxBVlXndF5qLNY7zJ99Daw06w j39DuIaHwaATlxIUFRdCIBOzVhe+kk2GXXxflpXBqCPnHeW0QTgR60Ds34FQyOd5efLoftd/TXOr CNJuT6/jjyZ5sn798hgdTbVl5ZJQd0PkSWFA2t+8TetDOiGVs4tgpM/PkOjZNEo/zDCUQXRCQS6a eo3j9mZEPwEg71wVlpS0t9ggpCTfP6kywqIBkFuKlw+Ava4A/JDu/d8qYy3edFHejln8VnQTCn/o KA9FXFfq0wXo6LH5563B5Puuwy2K74zg7LX/0D1FNgPSbOE/4T2ZfhVnh2tgKb5yplAWwGSwU1tw nGgpAFW7hvZy/+A6BrszvEQNdtrYLAMFEYUnc5ZJyU+0oN/+ISYS7pTdpPyD2Mo00YJ3/YeoHO2g wnc2uE2OCCdni5l18Y/WPN3qjWjetDo96jKBpqSB7TWXcDLiMpAmucUXlnlVquxf4P5/y+6w5jis NRkY7DKtPHcvIyw7bTY/lCX2eFLETUICv6Bd48/DV+Jjlt2kYe//7uMNZuulCU6AdPhukNWbtpUo POLHxco0qT9+MUJs3I2flgKsMnHdi6nRQ5QZc1BjabOXUGcMptjnKsPR4cqjTRH+W5wC5tivUDdE iyBVRCq4/yh28etgfIYTL1VtloGHyQ65rLtT0vrMQQCUVCO2MwEKVxJv7tddAlEoGJ+iiyQiam86 gQQ1cb8MJ7KDwZrjJvVzJPVzUM16stolsmm/sDdta1R6PbdR+VONCvl8LvFxLMNxbB93if28/Fy0 8YJdrTWCeqOneiOZCsmYemgV0WjFjok2YQ09qIZeqmxQeN5Qd94w9DZtQL3S7B+inEyHWnZGW0ir 744y6lXvDZecVstohOcxdOcxQuuZjKweatjJVLh61PdCiErxfctuiS3Wkt/VRJ+hBw15w2t6m6+F zyRlG5y/Y3sf7jZdYBnaJ9NMxmc1Z4LLs023c3VOpF9v4HMfofgv/38Iyfyfvnn330Iy+v8IycAo Y92tnophWVvf1VMibeu/gfH9vfufUvIfbX8BfLZ32j9zsnP/e5/+OSTz8e/d//5XSIYy0/HvkIy1 cvHMtyP2KHL1196W2DhH/Xzcv0IyDPJoU2TU/w8hmYD/EJJx/PeQTO39P4dk+vv437JA/C7ZG+cg 3km++ceAqs8PUNmYEIAhmAEBwBsR5lKs3OraGgb4k3xXYaqAaPb3BhERn41jQKd3AvMO18ZZxTXH Du3cSWjf6euJBWeitWnAzVvwR8mNpV1ga/Y54c1zyutKZz+SswzrFl/217d2x3x+D3nXz7gvBNcw P35T9t1mQ+6FMerdqVaMj49nVcIwwPX2xLyyWXrHdhju4/hd8Fwf8ct7NnALuNQ7A5qkn+6ajQab cu7bO8kJk3D/hGTWEZ/i/wrJeD1NldaPAit1JIheLp/nllcdzEaYacnG3+QONxz2L2P+Cskoaq9U Es2tc3lcnjrcjgJnBDiVuV7XRuqnWMclVk9IZT3c5d9wF3wobs8nU2MjliZhNgY7hJ+mApdPmpcT m29O9hwOR4rjMUD0QbeliKkLlHyRml79Y4Te5ffIde6byhO0vIB5myEEYnKv1LLzQljh6e7SmFxl 7DjUJ/kX5tKepYH8xoqD9bJMqfTmYCfGDPflsajTlbwLBI1wYrOvAjXUw2H2dTEDt/63biMR/MIW zGQ4c79oVeQz4XUwIsOEp1WVp7ASgi5YmlUxjBx6rJYO3jwitxx3IusmmC1NzNU4c3zOCxNb6Eaf pu51+dzanqeH6+wmwt2PRym8FATilTYbynDdWhc5QftaT5EDiazlazEXbal7pCaEcUJE49dWS3q0 2WWEo8deOOqsRxd71466VtC5kpXXjkJLPHKUCS+7hwH2VbyZ39SyYPnGZ9jKiT1L7rjloufa/y/2 zgMgp+9//Le9pKWkQTtNaQ+VdiLtTXto702REBFRESkamqJllGwZpZBKKLtSFCWlof/73qd8evQ8 xufz/f5+3+/v7/K6z3POue/3Pffc93mfcc99Gvpk3WGUubiYqr7ZJfVN4aPmFfSf5eKzNtQ2Nhv6 DqzoePj5QP6Rx1cGQ8xcIjnee2Yql23/MHzRvvttxLPOSOXOs1kruAdUrDOTRspWpEYdzre9wDvB 29q3QjXh/VEYM8B5Nd45RkYxgnCfZ2bKlu0BIp19K+7eHGls3rhRPfLw3iXiRkOBafkfM7veXtPW SmD4pGxUuKV2KIXjkVGmKRlVvZnX5jee2fmRygd8qN9rwwUtKwvP7BeEXEXv3PrmrX3cG8/yHZEv R06s8H90oTf0o2FW2fuGPqtd925pXu6JLpHSzAq1mRjgZV52/5zmq0sKy6wOvXYJDfZev3QQe6Tz 6rtHOuFfNj49V79KcjA/hl+6TqdzLfZIx/bBovZjlSxsLZR5EnsUPRWW+npeX1VzZUPixt33uoS/ sOdxv3FJOXP55tL3t6TCD8aHZSQy2mbG30sKYtL01rsTo6niaZI6GX/GOOhB2rePtEuvyrMeBIWv +3ypQGng3Lup1Q9tssqn8pcLa7UbKX5REcrQkdRUpFsXH8BWomI7HFvv0a2s6RJfSd1bbbAq8Vhp 8e6QlL0mDy4YQlD4PDUvdzdffMjuRMYHzAu35BanpOxlfJAdqreVxEBZvuFGP+XuR65b9qryHykL HG+kInvi1K06jzLmuPKQOjtPCJyoZ5T6uFgA9sRlfWYio7KaZs9g63qFRR3n1p9y36wcduF1gYvM Sm6V/hL46LN+7fKozNBA+YqOI/cRkp5H7ojymUWbQ30ocUFDA1v2RV3OuUmRersfJl8aMrS9uWIh b+hr/vikvZhqONkr/tNJRwrQ/6w7HwS+OsE3qfS8wU1HtF6K9LYos0Cx/r4SPo3yXeT4gce7d3PG +u58uOeUmx1fqFhAqDd/tXz23J35PtC5jFXg1TKGrvvm+3ZfuiC3d7snV6N0IU+Gm6mGYn1uXEDa KooX4gdor9oIscanFPLkrqHgdUs0CSoOFUvovmfJ2HRcQrtNM2TuLi/kRtz64lI9+prFcu/47khm z915JZiy+R72urUpr2D7U6tdXtSnFrQw2osU8Z4zNdcKgMjnBib0V1KzOeLEdOTI0QNKF3jvDnE+ lPgi1Vki3mpXFSOMjzQD6mzorizykCD3yJgVoVy6zZG7TfN00qL0B4aPw48mvzBIxuC10d3uumjR fjdX/bTvAu18gpxv3FN0Fp1akChtL8LG1MGXbacdkpjgx3Rfgq9aR/tsQg9EsuW8qnuW9u6i/9P9 HSN77KQ7FfxuRzw7J/hq06u03TMRARBxDSLmQUR5rb/AJqMdIgO5d+W4hS7kOC779nHiQqSabveR QDXdSKgmg0FG5s1Oph2rJElH9jQ7nfPPmA86Qh51KuwvPmn2mNmqI9TAbqmyZ5uI7/Ge3PX5lRPc p3bsTATDfqpQuuPFxUDVed2tw1IZdm3XAvzWM4BsFHvjSZttQUHjdSUvL2o1ivarvC6JC79lQ3GK D3uio3/YgsfTckvut8BbZv43EzW55wb2HVwwwj24Hw5eTdvJu0wkYMeF3MvDQau2qLwWpOjfd5Dx 7X7Stnr061mRt+zdHb43NuX6ifXzh9pd+Y4tc9HNq8zY6mE+kqycU7334SJWlCRgLFx329ejJsdj Pcx7ni1itQydDqrsPmAnpiwaQ9tbMCpSkHO1pfInyC7kDXn1dH033weRpQu3GGn89fSG0IMdO3fX p/q2SffyjzEvyTHSEFQhq08pvazD8+0Z3syDvYb7qm+fvfSobNs/lXCrp4Jq/zbuNIl+GneqL47T /9285v7Pp0p/qV4VwTxZ1kMfaTn+bGD1R1aeAamjzbdU1nhwWHksO7HsQNPmRzdXdIm7b2RekD9A 155Fd8Vo860ardiHsHvNwvO1IutUrwy3dHNs9uSKNZkWutxil4UfK1jIqJmSftRjGhpA8mgY/XXu RjDV7XB2X+EQUCKQtWFKyfXrDYGmmzEt/o1PBdXClJ3U9uz+WNbvNG7zbtVQkNiYbfmCVNXijOWn 5Ji498+3sbhoe8l89ZJaWSuV8Yycq6smxz23XBgIe7xRxTchum+1TDRHoj01Z/KDW9dvSd2l8L7f oBCoO8Rf8EaBKSfv0BItCfXdHBLbAp8ObvuyWPe41C7bmMhbG24bLTCuDx+7m8Z3ceulw1mSfcNa EgPc8naKmVNt1PKdz9wubXKq2xOrLRx3Z1dXw9CyPnGNiLTMtwrj3IycV8fVXhU4XOC5ODCkrOL4 eShEin/CcDTfiG0e67vu09fHlMQjC60TT1bzyrTQt6++YevTQkdrVnssAos8Jd2yqQWLlNtTWOpp L9rqXEw5fsjrdBMaaSFcZ3700MFdVY+KbDMKvQKXsXqXWdxBzETIsAPV1ki17KCBSKciiuRIF4Pg obpNOmxs2j17poOUJhr+4gkNnGaHjygk0Ea5aLh2Hnrw9IKG+T1OOr6hupSuLvrsuE5rxnSFE7IK /oysn+ribl1Ynnc+cmvBMQU27a49InfvcmpT1JbxSPuv8fTr5BHFU52x8Na6tmWtclfczjDJ2Ug1 bmlzrmhNQR/qSCjqtch1XUstOMKQWB3dx/HJab2L2rqd1V/2FRxj6OMYemHw8O4ObYpN1m2HGKyy /dQERHuuVddtPMccOsRrorGkdVp2J+3Y6dLlS0q1Ozbqm9/bEbrnS4Bgb5dWdpxaiXfDDjEThSXM rHiqOa+mC5gdXeXcUlawvKKM7UmtdOhA5IvQhaklYruDR28VYw90+O9cfsGg0zqkdb+4e4d+6J0m 8/wJe9FXXPm9SXnVrwqrt5p/RMxukGFRXp2md6OLupJ7k/OiXhdGxZvnC55Qlogs3B2cUVST1lua 3ytpKhi3JpU6CosKl2ipySwKT+6VWT2cnt8rkxsleN38VPwF8zqltS16ab38Ri16+qHa7kX85Qfv KN4srPYrLI0uKuVv2Z73+IO5L4+FUoP5m9NYkm2VeXFmkUUuh/khL+OPpou6FS0MV7d8MpdL9mo2 9Y0qkk8uypa20BnGUnxXt3w2r0oWZXUqMr++OnXXSot606oVFhK5vbZFpfmgTonTyFNKuvhK5l4d s082L60f1nb739wDObZL603L703LY44uv+mqrDG6bNfmfq7jP3iiM6RwgMuO1O7f/neYZ57oMGFP dPaNLpVGdlQoFlJWcTPnDZ2eQt5PvwGjk4eeDTfgewNx3x8pOeuJTgHo+gSn7bm1C3n0XBep+PZE x2iD3W3uTAV/3djMo7ImXEpsNaX79+h/Pm3TlyV4X8vae7m5Il/Ik9PbuA4LhcnLJi1UkVvPHcJI x6lpGyX1iZFaIj4kUIPqymHVUccgu0cHnIKpryyQoK7MX0C7RfZ54xF1o6GuEXtfYVsvly9fogeO pA+Mbxpyz/Wgu8FUPhVEyrurkWcksTxL0VKPrbOjQyeem6mPcWqPREPT7pexzcv0fMJkb3+Uae0v nVo2UsTUuf8y1Xv6sQ8yW0sTyrMEIjWmlg96jbT0a5xSv/p1jCGmvD7vuLqdfsym0xtf3TFsn4pm k15gu/RKTHcGbVBE9MIuK8vSdVl6A8cCZesu3vxydsM49SXS44adNds+Fu5Vszuveqng8RnSp4HR 85aMN5XUnNudOVoXdu9ZddqqwjeLxmhUDh+5FDr5WfhtxaXJd58n7tR4Frpx7RnMuvZuWFF9scvN nB7Zbknp/uVhslM7ihViY9/Xnex767Ap4uNklsM6iXMTAi6KF+j1zsjevvjM+ZJee/HKtYNhX+se K91JUku/FOQbEym46U1r1acbDMULqXLYPWqTPn6lGJA4dZL/wrYBazqmUxRH34S/CF2Xxev2SXhC qBRGd96jzy0U+YtPb99bkcN51py1VFIiprqhXClW4m6tQl9ARm1mV/+8IJVd0uVs3hG7uSNTzXWU jqy+NpY+rNRwP+vO4RKns8qmiVbml7af3lV3Um7CxSJkd9p98cjmO4XRV7gCn5xcdnT1Moncduq6 81qvehijVYXEZPWc3/UsDG4ZWbbR2LCmbU15xUBAS05PfEhM0u5zMR3rqsdqUj9dfRBk2/pOcTys Q/X68N7BL71jKnrrfBcWLak96OZ7vv/810vn1VW7mmiUxWOF3nZ+XfNgclRmFUNXk4DF19fbe5va kqXHnDZ8XfFsh3rTyJumIbKxoadDwurmsf269RtkpMVjF+t9/twd6Kr+dUUSV0PWTaY3Rk4FX9cl lbEKgsbW7OjxCraOvere97d+qWCz+LpgR2/T+YhFk0Ly4rFszpDI+GSvOl0ZJDKafV3D0LLkdYqJ pJp47J2PtZMiN0deGSnFSMXeCXxj5Fnw1UcmNkFGPJbLwx9Q/6rYeGUikOuNUWTB1xVcTgP827ua KjaNDvk4fF2hcky9aUWsqNYnvVijwr49Q/YeJaf2jYctrw+lfb0i7Elmo2Fkjc2WS6cp7FPO8X+M ZT5bs07npnKKSyT3+IqXzu37k9bvCiopcPFw4ao/f4jjzf1zKnd2bd/YlOxJ/+VOYHL29o3LX+pZ 5j0uz/eyKJJY+6Wl1KDqhsilxxZ58qdcNH3PZLuY+mrczH2ckbSqyuzV46XbHu/fTl2lJrjOV0Mr /jFJuWSL5QqLPlPf0h6rGsmWrl0xVX2mJ9VehuZZcn6sDlV/ueRjdRX7cNuOYe4hb+uDysNMdEcj 15O1pTczHpfp3rPhZtRmSvu9BmuW3uUM7Ug2GNJdH57yIC5pVV77lgfchZXZvJqeq7TiH3jSK3k9 9KdaCoeEai+9G81v4FhYKWuccrn8RF62kSdp/eG0CQMWa9G7fewlnqR0eW70y1PLL+45LHTapplc PlXodKHslruHGw3yzhcG0tfEU+WYP3JyTtrIdomnN/PEPv+CndShynwP3yYY5/NrHk3ayMB4fK1e fHWJQu9203zB4i0Ly57VUzYysixPldtcTmncitzhWGlDttQbcaM/VkKSUpVa/jaQniW02bs9LbTe M9SbLNT3WCn9w6ot1fLGbZS9j1eu5yyAyPWFpfuWNFRIzrdfVqMYUfvO+Zx92PJ1y2rYSw+un9dW L7m9z23hkVkwtK6+H/YgLUqMbP0qux4Jdm/9B2xRdHUc+yvzOkuSbo8brrqZ23khaVXt4xVOkzcn Hu8/c95eyDe4ds3jrqj0Sqq+vJ6TQi1sVb2tuY/XdZ46I9TSNRhTJVdouSTwLptI6YaE8/atPsG1 Je1dtVXuR0ZaD/t22nmfQSOHOh+bK1cNl3tSDcw7HPah8ZjntaMazduL9VmW+pLmGR6rpEmR3/JA yPgxuYGKQWHasyTuCzI9j66obE2iD6fk5uyfp3zmPER0RbWX3T2qcVMeIo9VusAloV9VC0Ns6/2W uZ74rOnutczxxGfSbx8MDQ8XHypUlTKLhvDlNYZMhZarA3aRNz1cQJNZKELq4bXrkIycTsPEiYR0 h9aK5GcLlg8d4XO3MLve4L/r0JeTYkcf25oIByw0x+jysv0Jj/f3GjwusLv+lKIq4TydF4mbxLES ipSqzeVsxq2kd2xX2tAt9SZx4zRIlz8g79oRpMN9oObYy8tb6Asl83lPVNMf8yMreIL0ym+e/nrv YW2/B6N/86W9EyupRxt0zt2z8vNUOaR2S2PJ62MMQfeo1g5vMdv03HyJYsvM11jqtW+zWi/Mn5p/ lFf47VTMxWKrlSuCVXVuyLQ5SHZcDJLZtHrj5zy1Tk0Rgcw9yoNfup4PSQ0dWPaxZIiZtUn5hrDD mIe9equHzcu1U8snt39Q2XTmnR2J2omRwkSP1c2UF9lfRFzc8Lw7h6upqI97Z+LRMDfbm/ZBJa+v XXyzVZIt9N2Wa+EPLvapvZlSNH3eVlsqfMTHryNHoPKqcKRDrKucUq/F6Oc9N758ar+R+qV4YKxI 5Y69Ef9Hn6+ysftj1kVrbko4G7I3bLSiSzMmymvdWE7jxsYsvq5EpYAu5tiYNDHDLTIeXw7krFsc ZD8o0067Ykgi9vB++p5uktikfXfnjy1K9bgYsE5PrK6mMvpT28SlaNFOvw9TcsEdUzKmsbUvz40L RjwqEO0KzzjYaUF9dL/V4wsdy9fpPpnoYZe0eXLciiWm6/2tVZ+4zk9NvS5vCOt3bmlcz1Vn6kFZ sijbWkZgd17jPGsX87K6Deyrjy46HbW4eOGdXpLWNqYbY8rMcJisQnYm531jhWyhvqA1ZZI3r1r3 NmwOlSy17n7pJB7qflkzyZlXGJRs8Pxo/eR4ie9WiypzeaENxvKZj8gtJGQ4LVa7ucRRummdbvAx l0jdQ8ORQn9FusKkKmqx2FLOODf3HK9CnzX3jvlQp6XTn5DtPc+0j/6t7kPXb5F7ivLKl2tsLee1 dpcvSrtTR05/Z7tjenuB7ZMZBZv3XZhyXUp77slEYktbLeWnbRcuklqXL9uaelx0h90WpQtNpU3G MjsWFQWdYz2kdUU6+BAufoE4RD4estbAffuWfCtFV1WBNGhpR8Jh8dRrJy9z0aalX5tnofSUtuG4 Y7qS686ABWJLd8S5dUlpnVW1NJ5PUd/gtEiVy6RkB/++0B3V4fKh7vvs+YKtVzpQnqZ2OdfWc8tB zyBtZ8bZhOQWt9VVF3y2VV2YZ713RWuOcSv/5ajesszt5ZmkrU4l1jsC2etr65oOf7SWOV6y6LLt sHXx8RKLy7Yj1n3HS0IvP/5orXK8hPuywaNdqaevWffLxbSW3DxM73aX1PKai5ymDf1lr+iSsKXF 9Nbr97bQu4WSiK1aILbqqvUq53KvxcVsd4pILJtd5LRsDC/3RpSsXVpMZq26t4XO7XzbqMcIuVzy gYc+X+ZHL5O0vai11W7tjYGIgTZW72YX3+3l8qpsi+9Es93Q6rnUuOFGYdwPnsgMKdgK/p0OOuWc Djol8iu/ejg4D+2gb1NXzlXYSBqieyl14etdL/2nkMbpl2S6TqNnw3XQ6yDu+yOFZj2RQTvot6hw HfR7eeuQlG8vyRht4LRafPNZw4X0MldhXy49yeyWIi+D5jzDnNi0EGuDo8wF+trG4RR0arKGGdBB X52x56xaD88uWuUUrhCxFImUMxFXqDR0mIYXk26TeHLAKXrpFXHRHp7TtxdX3+iIC++aXFT7ZdJd PqzIzVd8b6zMM4WhL19jBmojM+/rxzO+GmWJP/R60cuY9EYj7YN2hy9eumRUUKFTxf/ubOlbn6aU r1bjFauutRucHpV5/PUidNILVrUy7937mPPotVPzlK+GxTh/8v+cJRzbORU5dfqmeu/EsP/kk03b dfs3aG+sDRl6nNf3cqLJm5zRy/Xxl6M70/RTqsKdAt3ePOBMfC0ivdo9Y8Dm890nMSncGrcOvnt3 uDTffpPHm9aX+33s6AJuqrqMVi3zlqjVvzi8/olTbLE4zZWgvSte+hx1uPCx7qTCgXz72O7Wl3cq Vl2RXn3iUZNJ9xD5k8zAM/m3Vp1YH1R58+jJG+r2F7/uEGvzu5A80VG/0CHizcv3GcV7lXYt9eYX tTVQfLZX5VJ+htHiyP1VQ8nNjcs9+u7eWG3F5l8qsKzj3P4Lo4PtiTnFh0Ibla81NoXujfZVvWM7 WtMc96bqWNGE5IrdfUOV+p1tsTv7GA6knokZLVnBX/6g1UjRrs3vVsk6e/uo8RNmxYlW+8UXSi0T zmg60HDShNsoOV/H7/HY7oo3bpZCb82Fdg7RDIWm6MQKBj1s7fChYVt2O4Yyw6lfX/tV0odmmeHi U5tpTVomupefmNyTczTkTC5DW5o/j3v/jWWn0hZV6Dfed7ClCMpQMuoIE6vPP1BvdaCRtUH6rMdt pu6hc7c+Ryq/8LFoytr04upqjwP9y2k8BswaNN5e1ms0KSU75eBwcaLVYLB38G7urSma7id3HzK9 eM7PZ9VdWB/24l1xU/7RM0/XcHEnqpPdzLrZEPjlgNSSd0ZXVySo0wwFfBVY89bIveTrRifW2wE+ X5+qb1YfYXjdNKk1FvxsSFjFMtY2LHmj5576rJrWrZPnvbmvw5cXE+e9V8UGuQx7OF1NP/ku8Evz GVD4RC1B3Xc84Gul71ujmJKvGUkLbnuzvBrs7r0OgsqBjLGla7kas4pZHmSdLxvTytbZv3N3fZbz 6ytfF/BTfcxnV8pQv5HwKV/KMvYMV+yGkHVftXMYPgtzqCao3+95MbFTN0/9RtnY0MfcCt1FR9RH 5j9vqiX7Ejyw7+vToQmRPfeXhNYWDeo+svH3zmIJFznsnrFiMLv/jOpBpVcdTwZH927nbGIN5lvM +jHWeCQkfTdH3yE/8fXmLgO24mlmLnJHbjzwW2N/P5GlnzU15VZZAqfI0uQBG4FT2mp7q5MzmCP9 HyyxWViis9dz/emuplGbNgrvMykfy0rpLFO915d3tRxytDjXWiX4pKlKUp/OIP5AowjT2t4cx1wb waur9JJ9NWwHE85QeAoNCHew5b41NbnuRqduOtXi5+1w5IHqoi+XBx3en3FsEGNqPGTGl2FSa9t4 yOSUOi1/xvJXkStOxurrDssKOmdI0w0qnQy+s+bM8/ruSsnBwteett0ZgoJXleCEwXDCxnQrvpsr u04MD5B8qZyvlB96K3JtUONd0bLD/XUGi+TCUspSaPnTgpWbnO13BlRnML8Igdy9fUidX7802YWJ /UWIJy64OtqqVugtbY7PyZ3i7rSRDmxtrmy153y0XJcX12mfWiET5GK4jy2VWlhiKdOhm3Ip2H/u z7fhg17jsJJM8fWIxc0X2Ztyot5w8u0FnUMFuopHOV6EeMU3F6In2hL5dCX6/91q5Tzh4WHBjgE3 h9jDV6kF+vjL1fi+2yUuilvzNnb51m7Du24NzyPrl0YmLton6b6y+hDJW2fK3O8DpeJvwcfJR0yt 3mpS6ZNw/uXud7FMi6hsJDgDUkS+h/+OdLY4/53qXPG7ostXbG+lB5jWc99vmbPTu+cmk7MuVDPo Ec1tJ0Jv0lCZzBdwC9OWkYrz2LWFaYXZvHkzKBLleiGPRb/0qwVNCwJ3eexS3Ma/NuMqk/DaFwks +QHXd5opvrwuwhX4ckHX8rVOi18t6Crje2uQU1xqrGhmvjRDRDShJO7W3B3vraA7CQ+ORZzYYLzC TJZxPdl9uTk7qwcik6dWb23btZ7jguU70+85h8+D+7bJWb5LPVfzFx0/dneL3EPje+5DNkveG98b jLZbxFJpIye0ITWK3fScLRcKbesF5i3FN3i3vbq7L8kycWKC5kBFV2qD0Jrl5e6TJTRmDUt0zksn 3VK0Xia0xv4SheDVPoVT2s+j7istQ2PO2a85FFB7SOqFsqjTVZMqUZHUYeeWefasVnefWwSymlga nhMtPRxgsU4nxULb5tuuPSXFoEMePaQZjlUwvCDqBwc9lX1RdM7zKkTGB7vOwBIoz+RhFNAoIvdE Zuu4R9O8/ixVlpGmzJ3w/fpkhcfVr+0yTlPv0k/Hfl7zSD1a6B0kf25af7vIvN9Pf+op/dusmoKg cJOppzqTwQst+iWLnq43P49F6cJ/s7Rj5v33zdgu9q2yGS0VdrvSLvMTKoR6aO9YtIlHtJlVPF9v RJ/cwmgzZ1clYBNluXNnTeYFDpZw1S/JZBIaB0349pVu67FNmLXLu6f6burJlOcm5S8LE7O76Z5u M3xr6f76qlDRVkNzqiMF8+WTzY7cKjR8/VAoyItFqWpnxmPttb5JV0SGb1+/1rPwXeTY1uFnzw6Y ylx+ZjF28Abs3g+eXN12QGE0ePGXpTuu08TmLxXtfLdIdXyLUeSoneOlM0+qx9nYY+/kqD374qB6 9sWrieDPbSl7pt5W+k/ENn697PoqlqTuoDhbk7vGhM6RG81fozd3vzNjeafOayP3mSWRtevhI4V3 2UMXH+24f7+2YnftXfvLDWXnPzupnneJVf5y2FBLZkJApU1QWPjmhXnPqs9UHlpRVVke8cXGISwf 2t/4S81h+2u3hGlGhg9Qe7+Vq7nWWXzHbdTWN62F9NmQZLSL0JFr0V7v1if7RM1/r3Sjc/8t1+AN TUY+RtUJcs9OK1A9iNyYydAuMxQSVelh8C5yWa+yrWgmycdnFWddVystmoodXjeyaf2Xtibx/pjA o/PLiyqYuoUHlmqavtTfWqWSs/A22xPl0kt5vtsWG7ZnCpcI3960P/RrkMXpo2mSTzzfOome98g9 nG8qZ3TNPKhJX87FoGX3ohP7o3WLtuRzxBdR6g9vE7RwsIbD9AKvfX56Wqvj9HEvJ80iNqGr6PGh ynwW+fyYEj6TQr77UqlPc8wT8x/TWviStBQJebvcpC3a8ySpu5ijZI+FYWtdEqs55zoKbxeLA1Vl LhQtlFZXHlu3UGaKFsifo22tmxagL42rerHvcSYnSRXv09PHDYiIufq+s9aoumJxWt6ySsIIdwS/ XgJ77GdxZqnHG9+c6168tVHnQjBFwfXzm72a9oc+OrO19wNZ96gqXeuLTMG+075ULbxWV5SfVrhy n3l/TPm1qPWO6NbLZhRzYucXvj/PZLzjKj1n0axD00quneE237GOou9eYUKB+YzYmRUWxtxBrCXX +L5EmBapZV4vonjC3f4602TY1GSH0qDN5l3KtCPscoP5t8/KstvcX1rQYiTbPihsa12fxdMSntlb Y9wSrh9qfrAoJ+rQHdW6U4dHzIeOF0XmVr8v9NtR5MffUp1vy2Bxkr/lTP7j+Ra+/C2VvBbNutih yt2FjduKGnlbDufb0lmc5G3Znv+Y2sKXx+KZ2bCWxabcXSaFu+AWRe92sPhs/sbYYlFhb2bR4qIi foubZqGaFty5HBFFGgVem80DzYpeumMqiyKKDAqK4szpjVqoLeT2FfUVVh8vkjSlV22RMpfTLooX tKARW5N6+lhRb2HR8SJRUzlVCxnzFu2izPzebUVPXSZyPs7fNbHZ1v70s4UjzHRhAfUfE+D0oTfN OmgsOj6aj1m3HjLVuxWLqNw8hVz54SOSPdx/ZwRGNWcEBkOhH4zAyKdHYMuxRyR+aVZl7zrqKygu Fzh0XryfNoXQT7/0suEiejbcCIwC4r4/csN3j0iWUuJGYIdWr0KaZz0igRFYjMxQpuseboVALqWE O8WVNIE2h235b3Nwp5nmU4s6J3f4kG7nkjd8JytwBh2BKfXw0G4zTlMdZVtqR93+koL7uu7r51ry ZzWNtncx7rZZcO+K8JJ523wuj2Pjr9r0qtQNNpz1r/y7omWejYx3TmTKyhuT8vYtucnE1yM7eJF6 ctWhoHqpkc+fGU/YPVK8HnNk++3P89JZypZQSlTLNX5oruu0/7BsoEBDnvlmzavQJibX7dxM+eqr JvoePaNyGKjt7BsevfbpVOyRppFDsp8Wku08ZeT37FzQ6owpLTKSbZQcxy9x18T7yHc2PB0cTO0L 7tkku1337Qj7eJfLEnc9nsrGRr9DXdELL9pelDnLc1Ne8+nHRvZN71fXbWrWaSJra+3zt6g/d698 Z+dxu+4utlPPvvDJfPxiFd6Vpn6LWsJlQ8LkvOY2F5/oFD+G4wd216w8r/e29WlWaefYqyrOxDaZ heqqU/c9uge6VGP2S/vIb5fQ5ch/NvDgmdanVH7hR4rPmgOT7p1c1lW67khNbcb58giJ4K/NFd01 Vst1m5TvNDZFDoy5cLvzT6zRS/jCX1ByjM7/5Zhs2P2su2cDJw2Lyr0+26c2Z4sWdy2vDnUxsXzT ++DqwbOelt2lbtYSjuuT7rfBwMsvacc9EZMjFsEpfl9SU3UOB0hHqTrVbl80JmaSY9FcnHbv5UKl Ao1TUuECTgF6o28XjV/14OEVPTLF5fH0mXE/T8d+tafWtg9lg5d1qknkXNdxmzgjsm8kPfgR59nq EKEK2azjVlJ1Txdr7ejpMzF5Hxyx2W+y/2n7Xnc1pSMfkxblRz/zmG9AdTFfL3L+xhjvt7133zRM PHi/u2Bq+dh7i959AR+4TYqDHzXLB3++usNGOc1q54uLo83Hv3IJTw56ZLwbaFJUSlB/lasQW7fz 0823xepGzpKP+4+oq1B98Ohe+fXdp56mpAGj0lNfn+6t2aDauiw288bnkW6bdzxfVyQOdzVVHPok /MwqVpLhnh/rwEH14o+TkzZ7llzPaonw/1pSl6e+7eJYsNCLbPV5n+qzvmyZnExfopigPkRW+0VG nWcyvbdY/VZY8oGeg+p+zrGxT69rTASy1H55JZSrfuPiWIXG5JWwSxNl7ycny95vHXV5UvvF5cmD JWdPfV3BlTtgMtbV1EUy0b5in/oR1bGKt+NmvTnqveMWFv5xR4dLP7JH+utUrBHWU5OvLcvPWBXr W//RQZyhqSZyyxPSqYWf13YrirYKLE4LtXjXx35tUDRMpPF0yY7bYmMRl2uy98dxrYrQN9Gwl849 xrPXl+G22C2FrRquhhtCNxl6a3o7SReEGm64m5qxuVXuuEVLlVAVm/maDRYhJxfRfTxWKne8soBn 3duUuIA8EtY1nms1zj2QLBdMSduoY6dZaEYt2sFsUCFo9Two3iHgg9fZ3Ut2hhjxMThfKe5g5qCj vSrXxRrvbX4qzTvkYd9Z3qtyyhdv8neFFxzJ590SmKpk3MR0oDgk6MZKVb01JkZ5a/mF2mxMGUsr 4ITdcMKjFBRKpKIKzhfJ7+itKQi+Hq9cb+pRVpwvHqJ8Q3Olh03vp0Cl7ffSzZYnP7ld+rncuFeU 2srWnLGgskREwtugXmiNr41ZlNHSUKGbC97tb6812EnvEvFmZE1mW0ncB+Uiaqt8vnVHdwWEil5t Kby1mv5Fr3l8cf2YVce+3pQSuQYKmR63ayu28ZKmysm60RvaaJm13kuZ9bUqr7xwOcWrUDPvdrbQ 4JTqKrlQX8P1dmZtrQ/xv65KLK7vrh4S99w2ciuXtZP/QBo+b79o7F1je1pPSOIR/wG2d8mrip/w f2kXNfUtLC7ie9ilMVBAXXVeU/LYGb6Hgypp1+MfZ+yiqTJYLMr2bj8rXdjtXfdsjRkfCYqxXXhm XuJ38HX3KZqTFHnlcsdbblNUtca3lohZkdPs3KpmUxERk0h7dcgOjhb2Znt3QI7u8+3DFOOud+Mm c9yv1HiZFZmPuTbTOtDLnvzQstLMrL3yudcxzyvY14fm8nKphoZu2NewXAPBs9xiG+XulV21IuNe 7UAfIn6Oo8c6ACJAxOXK4vYyx73vrE/rhcke5Tb0oA0+ambgbqa4MeZEwOjEGqdNMSdOq6mbWWdl iczrFlZVOYR+etBe+5J+NSDmhFRGlkWhxSo/1h1NTaLzs7IWUN0+6ayoXsze2CS6Hb4eevrtg/Wk s/X9anMbDjOpTS1mN8eK8pOcRkpcHqn2sYc1KW/vqJgb9KEJ1XlTZMdeGmWLcrg87URJnoi35x38 r76F4ionHJ1bzIyXl/WKhHA/YuvlotjSe0Yu9Mnhal/DjjMn/OzMzp4sfGL5sPZt97xLgrGcXMLW 4+u21ewTuiqR36d5+DJXLk2DBvYRImp4zCzktaL2MTNP0qMGLD3mh1fmP3j9/qipenIky1fl9LqF t2Nj1UosN6vn1GqPyjx+tqzjfJBYxS31Z/uXOB1f8LLJ1PejdsV4+sKJkET1yYtGekOZMUNGZx82 VX21yrL6OD5x9rVeQ//Q86MDZ1+TOEV0koxq7n5h077MZ8uQRWjhMWcWMvEcHdboG6cLS3ZNXpdU VM9zfta+OE2s8NHBd1lrg/of2eW67Wgszne232YxQq7Spu6pmjTaUhvs4iQpU3Z6Rfjw1pVu4KtX Xc96leVq1LFXZOpUQMKeTymy7RWv1zkFmap1p0VfdDei4VY49f789cy9SkmN6Y5G28sFNzWJXcw/ tvczS7Tt/lCu2KZ9j4YUX3yxJB2oydzv78OwrJoxy21qoXnG/tEp78aoqeMCU1F3AwYSh9YYmx3o 8Lb/osf7KVPxgfOrpMOSjx3t9O4eqdN9ff/Q+1U31x7jTsmJjRRXbNxklhT8bLfzbdX1rbJpJZ5c N/ZHV5eY8NnkCOwSHAmx4c5q2ekaKtt64JCr6k6dsteLb+w5N6C74sEeRdf1i/eV1JOZiJ/Pr1c+ sK9EZufStKfNbrx25fu4QUlK5WjJHv1WSseT7NKcMgLinE0Suy3nHdrDquXusj3ebWuFo7zlvPQ9 i5jT6Bvj2q2XK6uJiXNmUFSUOd/yadh32ieArYHSgmOkg/r29gD++TY4Hfjpdbt4K5ZrXS2/YiPF KVa3vYm2ntLjis9rJuaRLJs4zX75/ILuzuWPz++LLWVMU1zoeJc5/VrHPS61YzebmA9ds+ELPsd5 WKsxTilDUHpHzXGl1+IQ+eCjjRPu27fkXINXFzl5lRb4Xedd3RWgILsjgyJYcbXr/HCt4Fs2Ujtk mc64bnuzr8JxvsdtNAu8Hle4qnteHHNV5Xpo03e9puK2ascn5+RrK8Z447eJXFPR1fmqHNG8+Vb5 Fg3LJYuCXuvpPry1V7aVLmuYb/+wpgv9kf1yPrplF1ziSjyz5LhvH261Dt/U2qHfun5PVVdFK5+N N4d3vYevTvkZ2dYEQRt+ywX1KkK3RMdLggSKS8r6v5REJ5dEcxS/qOBILtle5zVeEiZQfLJsv3X5 fsVdb7hZXC02Wgrut7hvLZdlkejaImvZ7CHHb2O4p+WjzVF9Sz2XvATXPH1UpWKNh+xrvi38p5rD X2x8PZyQbLYzdOpotev70ZKj+q1JTdLjg5k6g4xjDLq7HwRc+A/4nTGK6Q68OPZSi0xc99vK3cdH LjtvVS715H4+hVBPv9Qicgc9G64Dj0Dc90d+/cHvjDV+e4TisMGujfvmqVLBjuLoUDedM9lS4Ycf 0jw8t8dlsuou9lKL4OLBFDeW94lHCnZuYN6jSC+XcoO98hD7BbX497wx7cc+HZfNO6LxsIHn1mLK 6FukkSIl+5icqVkiDozc8+XurB3JCB44f+lZbcXRInGhz8MjGQPnR4ZULg2pKKdt1NRnpAzLZIrf vI91dyzJZKy+q5VaoIeH3oc+q5gs968LNmW3M7NRUTqsntdjtcqsaSwsLOPSolrzYIHsJ6/aRwKU O6L0x6a2xrh98Hk5dLQp/PMT9aKpz/4fr3GzGEa0Cd+LXbbes8F+wVq5PR+TRslX9rA4jzVdCNJh l795pLQJfaeFbhmdy9WCr3LuMcllOe4MGqNHI8OzlqrZHc2qsUV/ZsxlfF22y9P74+2xfIvnyW5j 2DRR8X5EuGl/rnjWKOVwsdkw9k6L6sjYRMvY0xcL3BaxMHdNeXwasBmKMr+0lnpR83hhP/eDU73+ WbWjrefr3gwVLsks4Jq0f2OrpMPPLHMz4X6y/cNLQp+yaCbHncxWHXnFNbTppcoxh/UFTZnFDumr 79qrHSzKULQvy3Jec6mvIDJW+kG8nOVDrhebNsUfkyMdCNJ94Zkdo+VHe3vlpRw1joixgr2UuwsU JF8V3Gy4GL1nbMPzet1Nsh8sdCYp8kQm1vVbPWyvrpXgfBV7SSnN62LyA5u6hnO7aXZ8GtCSrT7r ZnNp7ErhK718B+VM6bELBWcv+jwQ/pQpEHbWzeJS1KTz0LsjwYUKh61MZV/mXB1yb5ifHqhPvVXW 9Kzb1sCxiGH9tUvqE7KX1ziorR1pOWFsPsad73KnP1D5xDvBtTdTJm+8PXT1ZcqAd0app+ELs6pn gVEl/Yvzb/bav/xk3eGQsbhYfO22i3WerqdFJsz7wjP8vGpuvj1x5qBix8PPC/OPcCSalZ0K7NU+ clWBapw7P2crpPY8t38ZEhIQG6isfOulea93Rm/ZiQ87Nlx69YmnOjpjsfYIcz7VfTivRsqNwqdt iiLXDF+YljwLPLz3/eL8L4/sX8oueeKQ0eUivpZl055mvY8nGDn7wzP2X6u5KaJ04aCi4I6Rhfmv pRKbXR1ehSjfX/D4Y8zNt34bRxQ79gwIrg1/NZ7Y3KGY2Gy+5NX1rCWRnfsi2/peHlF7teFQ88CC E3finrHXZCzJPxWa/jX89kPhIHOrgq/RQ2HbuE7JNbzyv3jLm+nuvSCzC5+fJBSmRr6/aWJWP/Q4 dv6hx+eOlwlPNe/7+NptbaSY31LBtV9srxb6mHauSvQ+MJhWd/TCkZSz5kGDfqadG9Pblg4onjLp ZAZIT5nYJ/mabVSry9wvEp8mvAX91aQNIs1k8WF3sg8v5qn8sv9AWNTme2x1RyshUt7qtZzmkfo9 geFRJi7hzncc+LZLXxFRT1T28InaHJCmuC2ADRikfSFubVQp/8E3azLFqYjpAemhNjld2q7QPclp kXv2s0XsaRRTcPBOCd1vRt1Hnr+yVe6O7esFt6q3W+tNpFT5yOwZpfGWVH/ryP2RpfXp9QUtWuYD 2zIq5F5O5fVu7GRST7/PnM9oYM+borOWN4UCiAQuaC4dYnvDl5Nx2pNNxC0m+/WxdbkpZxrrjsnY PpdTznn6TsL0waq1W87X6K9anaGpn5hBGhx+n6E7mClZ7XjuxvcRLy+9Opu13/PZvhcH1I8PHXq1 QHrvBc2eiG33PtIef8WqeVMsPsmKmvsUY3XG8MNUJO+Vl47gB49LMmmplyvnsepb0qwsN0D2W5Du K2He7JqKCBST89gIIrdFSfRb3V3X1W6gunXhY3D7/H2R9cFDrbohvtptc3a3efJetTpI6xevuW/j tl/D1u2EdaqTy73hm8nCW+ODoag80s0cj66idPqOF73eyxtFjuSzhpw6cfJYtJwvhdNf8N5hy/b5 tntnekez88TbqAb3Nhf5GsmKdh3c/4z11//a2aQu9bjSVWjQX6NrEfRMroi5c5qnRBBY75F7wCVj e/ieUJoBjj7mErWf4Zn+wLDd6Gjai9JkDF4b2+2unov257npp30XaGcWFAvKPyK4aIBjtXSnXBpj B3O2nWbI6gQ/mvsSvNWC2mfjeyCSLedV67O0dzGZT/d3NB2wk1Yz8rs9uuK84Kuh12m7Z0dcg4h5 RtZ25ZsyBfiP0pg4+00psvBd1wmoU2bJFjbAfdwhPXV/l8xt75Rzt7xTFP0PZNAkfzn6coH0JZYM 0qYDHprxZ26JfI7c/9R364O0c186jlV+iTsQtvVBl/DRSk7edQ4KmqPa55nihkP5yfv6dKkzlypo nr7oF++4qYP6ylg1JMjlGJv2a6ebPG1qXHRj8l2GyYd2pRzHB7tJIUyx332B/mGT55HSOSshZpUM 7QojSRlTya0HWUcqhspfxoTZW35oj7S54tHtRpF19CBrBEQ8b49cVCYp9uHdhd3WB5m895annZ94 L9JfXJV/7lRrZpyVt9EV+P685bHZB6/3IgFVnxecs42mXXdSlaK0NZPUytswr3Ld/DbzkRZbsw4I 3SiuOvGSq7QwoKrV/NA1OdauAMNtEHUVjbL3Fl13klv3znsKbtZLHL0Foy3GettqvH6G/JoeoXP5 jdtfFB/3Yb/IcWc7r438vNvlTvpp9FrlPuz73a7tE+fc7touJVC/nbedlv/V57FUqU1y5i/lxrwK XPUctz14o0Tx4CRPNav22bgeS8YO2mw7jRAxro7mrycvnqg9PKpnrTtguG+pT8WGwBYXzjdX5O9s 9U2herLUlMD/TQkLpkrrmkf3avvdqng89bWBRZ3MZuh2k2fOlnMxodWRoZ+de6Uj9ybU0rtaLn91 NJt9ckXy5EWmjTsSNp7p2cvxxYcpckdCrH9PcVTTjodj0Y+XabqfzArKTBjwfGZ6u9OYfOza6S8L t9wmvWfHZLbMENkka/A1xpRyrJbshF9tkXHB1z5ea4p+T+FX7jrLPtqOHCtMD/3g6RIsNuiVvSBZ 1UPZt9NbWlNNSdd9zOuVqerw07zzY+3XkmzW9jwzon0d7CN810gvKShrXnND8p1kOl4tEcM9e/ea +LVmp2e1iqQJm9T7X9VdfXydroT6rkMS5/m8vlydKNG9mKIncUnZ8czuV8Kj/fvu7xdzbnK4G34s mOJd5Mix9v1n7b46FD8a5ZIcf09npvCVKYva3VK2uOlSiX3cB/H3So5JKuLy20Y21rXsi9DY2NTd 8sQ/aWjY0Xb0yAejLHF2ScXGKwhnt+Pl+hu2Pm306ef9btlLtjrX2Bsf6qO4gUVuSj3fX4xFlno2 hBoOBZWxPZGTvrWOfysWqWzS1atdu67kRliLS4PF3sjz1onvTbenr170GT1w2CTjvNqu6PPWdMES CeIK7rK4XxyLow520XA9vzzn/BvKwCtPrRlt/Bo2+J3XWCelwKadximD/oTYwoY9FMlv6nZ3pXFe p/gnhysu22erICAveyXvccJhcfZNz2utWw7ftxa8OhInV3S8bMW6PefeOGk0dW6nHDo9HeQNvLLC Z4M4gxW/X6T+OikGTo76ay0JdouZFzZc2143GCD3Mm3HdYp/dDhtPktDqPKW9Xp8um4uEmGf78hG N9GdOn/OtcPp04tUs510fOadbG77XmTt9HndpH0qWV2rlIWsIdT5cr3bp8BqtdPrlkRUq60sPZR1 3jlm2cH7N98ePrtuKLM08nXUhvOLo6oX87XdRoKPzos4v1ttbRt3fejN5lCq8y81unZR1a7TXZLf x10/nAT711Gu5xdHVi/mbRNjDq7li8QOv5nW52LUdvNWqL57qVb5wfqeVyHrz65rU13fluzdHOQb VS2f7K18fV0zL3Zi24p13pmlcq85TA55a38MWrQpo1Snvqrnra12qXBa3878PpogC/OuogJ7yZy9 zS1n1vkaWXGe3+/UZbC9dt1tqZAqcav65hbN0tI3vVHVu9UavVbkaLhZbuVfslPgrfdOfqaR5Ess MmOK68+Kt0kYtUnUC35+s/v2xrgPDvcjehVe/wf84hjl9NjNHHv4ssaYLYyJ0ax3H4tfuHPVS8kp RGr64cubNvRsuLHbUoj7/kjxH/zi2OdvD1+wsZtadetkTvBJ62QJscMKhr2Unk8ffm5ZUu/ejv5G NDP9crfOY5Gr+OVoDEuY8o9vP52wmS35ID0lPb8RZ4pqvJCrTIKBG/mDHeW14vzLtlFIa85zJ/Xd uvJs1VC/amzI3pjuzva15u5Ob8dUulVGYp59aVzS0YfQ8soO9i+ON69cqKReNMlpOmqysv3pU22N 8aXs1AeMBI/t22/yhqHr42jCphSB0c7LXV3PHdZKHKjUDjyrOsK1dc0pjupJlUUTByKlv77tyj+i cnJJ2dTY2cGvQsnbY9hWvutOHfJYm6FTc/uLw3yeY1Kbsz97UGbpseTWOoe6vbleKBrFeveY57ic ln3le+rCLfd2vH5HohN5/EJ10PGo+RLNZ8gW9yt6fLr0eYnIAS/62iWMp3zzs7LTBJoHNRwb1JRt 16uFvgjpRX9yzNzqc96htEULhC85nHk2sv+V57hiEvqTY4+eBo4XjDXervC3ahTPMtg0FeD5WSUv cUikSz+lkslNgvu0A8W4jN+lAX79w5XBUh80HM9uCqmOyjZVvbRfuWzdqtT5S0TPWy13yQo9nJF1 xrznLCuvxMRjP42+szzllOsj2NpOccilmO94P1Y59q7UqDipzyPNrS0ntz9sfZZlVtuw53Bi0Cb1 0uNZHNeCju59wrm9+Wu4t0zh4yMidvXzPrpRvi97djO9RmHeNbWxzvtaFTes5udlKFO9e2C1c+zc +gNR4dek3ucoNLauvVi1P6oiTO0GV5buMqamz4xLXm7YrRR6LUCWjSHV4cy7M1wLj3ZuisnqPyKX cu3a57c8nY/zt0aoqHFfVxl6y9Ol5ra9t/lGAP0m5/lP8oW7WtVUl5991cwS7AFfzhu1Hx+TlbPU Up/P8CTf+8XJTdVsnUlGbVdB0vbQeApnkVE4v9ynqjKncVmVM1VGFS5PPnqG+Xio3U0KzBrUGi7k OHl8Lz+cU8PVO2ux9plXzVtvNW6MYnyhdpehRXiFiVZ39rXPnnLVVUbF99+PVnJ0pBsVm/SbORWo dSS1GIc4P1ITFD7zWUSpjDtrP4vKkIjSlU227EVGN1/KPdxF/yQ/ugwytPBJktEI+kNm9rvHKxW1 s64P7M3uZFTqc3tzcvNQy73yJtk7+6LueUarydz8XM01VbP2Q9yNgIYPe2+9LU9LOMrrECujxPSE NUzK2+R6TE2i4xDf52vUV6T5Pn/xi7urxH5pUD1JxUptGY//TS6BZTwOuxj4+tYMaDq0KTcfyeJ8 WNP4qWtoa1RbemfDhYTltcF8dZ+6dHa/vbuLvVlsg52V/a7B4tfUFmKiW7za0h+vWyKSZFyVuMni BlOR/IEl5nZcx70qgrd6JfKbn0xlWV7UWu4eL8NNPSQT+HpZDVcuD4/6znmfrQPjexvoqFvSWRmL zLQLGn2mdrXqXlwUcCooxcnck+1TH4cV7VjoHrGjC5efkBVzLnHY9tXWxXYhebyXBDX1w+q6yi5y cq/1ByrXUqS3xhV7it6Kqtq35J4ya67t+oyzVyrddXZ7soYYUniekqSmftdSyGNxeCFjkawwz2mr /Djjt+b7RO9+OtVDayaaVCR2xU5jRFTpswWZ/ZfU5+qaG+1f3QplIfB7YxCwmSzufN4bb1LJNBEc cK9+j+P9zdTmZ3hFnuxL8dW/Iy/gxrm/nH5V+/ZcHy1TS9N0aSeBVPPH/s4OabBfdPyZgai5lenx 6v20LanmBaW5mqGCrEVihcbrV23rhaQ2594gm/CMKvMBuYq8qFPpEhb2MnZFF9zPmEfe9SkcPNxu +gYS7ni7r96GUqy/OrRtzWNTU5ddC9e7rdoj2rglVKCwzIKlhH/VnpOHbZhcZBrjEpbfUGJy2SVT uj9XdzzcZOWGKTZy8tL0VXuK7tIk1Lg/qJA79PjCvUv0J+QPcJs/cfSSodvqxXl4xSV52cgWnw0B Mb44Zn/HeB+Ud7WoveXCCNX6u9Gx91peT2q0aXlabR3fWppbKSby3ivg7jsDg5r9D0op2xrKG1No aST7Ose3lvfXqi/tG/x6rKQeApIDDHeUny5JCT0HkcbeNjsgbn5VWmhB1d3KRrovvn2dOVUno/e2 npH8jvl63nY7IO3a/cetLzb49gVUnqA/YXkr4PGHxSc9r0VDKBJQuuZJltRaSSKTIe+4vZmS66Qn mbui7+UYQ86ASvnzpk4SGzgG/Qo8b9UcP0Fi1fIzFptZMZZWe1zuMG7aXHM8M7dEWKRv1Z2o/eV4 X31ErqfQeE+aJrzfPshXF6YV2bYlj9HiIBP6i2PkLRLbjlXnMZqfXRDXm6Zp3GFKXWRHe743czhG m+PS4ikpV/0RhwI67v40qegQTSmqo4wNGsLkwfeSM3r114YK5CvvN+O+XZj02lwvqEiGPP+6igL2 i2Mc4x+mYkrFPl+2D3oz/rGSo2JvUotkhuIR2xMjV0ZPSkonKoVfy36XXhjtP6+TIqfJKDbp7ZBZ 1MI1F6aGdTrasoMnQyf8EhqGldTagic4T2y1S2SMlTUIOK1pf3PPevKmBYgaN+/oOndHifNJb0uj rzCXOew50KGncT3pOrW88SmVVZ/bczsrxoKeblT9qiS/MVrJsHHbmjHXjM+D22S6iwoXNp00N+rn 7HlxbjKG/H73J71bsbFr6IwuXsvNm3rezEt1W+LeQGBj4sH42823SvRu++uuuv00w3xw6/q1q4Sy Dhio8TdlSwcH3V4WriLYemFjpv/eA8yruyZSnzqdHT/lIH3HIEbhbUTtoVerRmP3OHRf2j3qkMX0 9MvxFRSfijW7jsYOe/N+Ii1W0nx81Nirp3ZzsGxphmUn3WjL/P1hF7Pz7j+7p05GGWR9+uiq1LMy hWNlETvrq70CWi2u7b2xel1rTIPNeNmSxIPnSsaFPDoUJq0vXHdbPy+49cZpLLJweeNhDvSXxg6G Kly1CeePEbd/WV5k0likix35gqbxKgsW53dTsS+sAVQqFpd+8BE4bSUfc5yzoPSyz0PWzD3kn+9Q ul35t33N0Awp5bQS373C/cizJ9Ga+fNXLMyqYj7UpD14/jmXm1PmtV1vU6+VHLWnu8Zle6j7tHMU 9ptiEg3B1strsd8UY+tSKjmE+00xuiEuyzW43xTbFjlf7ATuN8WurtjB2oz7qTKcOvSnyiqlmpxu fMJ+qmyWWu8e64yKpBturWbvGnwuXDc8deVBNC33iOMi+WuF/Hx6r/JZEy7ksPO8YGDtHNS6cerN Dua+D9Qe3Is/uiiFUtoojJccuVhyhFmM43XJhnt73zxc5Hrys03xxRKLncMFTVGv66MEypIKMkK1 h7HDz46V2F0ssWMWOxFouWYIizo4VrL6Yslq5r7ArOFHB4etnWtPBLd6Vy+pL5S5Vd3s0fHRrSPZ Onpe42OX0bIM5a0l9Zta3Rxa3XZWdXqcHC9vFbRcft3mxr4lxexxJVVq3ncPQha4OmjmJW9iPzPx 8KvuWruYXbV2Xy0/eU7ZqXhwKyj1nXt7M6g34dn8zBEVum7eTw6P/OkMdKmI9/FF+C4IPyF78tt/ hXHenD4++nCEeB+ffrqPf4YS7eNH7Kgv2Hx03pfowaHC+nyJwilkPyWuj3+6HD0bro+/C+K+P5Ka G0GsQaE9HEXKDOdnRJANNeaI9T5nxBp9ywb6+CfTHRI4dbhueky5C7ff7XrQVxVgHdTWdbh3WPxk WQSr72Fvk/rUinCqG1cDn7jW1nVlrXqczfB1JxO5yZjQqMDYsU+FN1pjyxjjswt42HKNGXV6Eo02 MWpeMJi82+AXdHD1EdcKTvkj7RDqHpmcdA8rr+fdvc/4I/9rjb085fRX1Hj7NohVU3FqkoRoam+g aRzUiH9Jou1lTLfN9oPxY+ej7WubEjYskOA6coRTV/2pRrT+kWunmzZ0Mz65kFZ10FajpmeJ06Yj pCkhfQ1SVczJuxQVr9n46p8eHxV05L9k/vVMjAnZGoEgDsaKw/xpVMsub3MzpRl1IXkpohkeWSNo 6q1w88LYwYM9Sqa+T6uvmoyb3H/eeTMrx5uv+K7Pu8cXLDjlFGrObJZVLC09/+DxoW36m65cj/us tsaXrLJVb+TQm7Nhkx+ted1y78dZWGXfVBnx3LruyMszD/gZYvaN9g+vDQwNFJs4fPeoQd7dextv L80LajcudHRNTDcvVNwx/7LHAjWTRwzZjFxaHxKP0h+XSmG4fFF/tUnxwsbebQ7hAtWlVh8XjFg9 p32c117dLhr6cuBG/vLe5px1mvyR0Q3iR5tYGyszNHaITJrwzDeLpXxz6e7QnWdP1xYujGG7ttpy 3rJHNB43pG4/+eixPCVqMJxzODxZQUBa7WX+Hp/WNTuSjizLkksUlN0jdCSL53VsMdcW05r82k8L cyfXb/uaMBUsc/zWx1c1K6s8N/gvuJj/okadwvuq/5a+iVelbisPMfczDXKku2XedW1wvbM0/bh1 2SHb2+4NPp7kN15ck00n9yvX00imljCybaO83036qT9N7Uie08See3bbhzXPHWDerqP1eI20EBXN gWP8Ma23OMSEmAokjOLSFn+Ua5dN0BX3eMZm09h4ZFtwYXx7Q/vSShUDF6bjqudSK87esGyse7X1 xuvtnzyen+ixb9Rd+oJX5NSey6cetT/wTNAUveLuvPpQQWrxmnA7bhV5v8JPZQ/vPG1vTzNwvf6p +MFIeVJs2tP6pztEXsS07zsTYlp4qMktUai31Cy38OFrxGATz9lBT+O80khmrWe3/bqb/Rjq8yNE Yx+L55aLHW9f92DejeD03cmGa+0O77vfqnY1fe1H9/bzBgORT4/QLBMxel68+OyQSO7pjY8LTNV8 09Y8TFx7UmVncF6n8dOa/M7L6rcVWEdSHoi84PXRv+7eKX707qlFHmQN8o9qlb6Uj4RP0r3rZHcO L1zub58jJsZ/dP5d1iAaljSWdlaOEZ71ZskWrt5raeYX3DrS2RqxyDz51MZLlKWRHWauGcy6GyP3 nD7TavZ59wNP+jedawaTmmrTX68fNnsT11T7sWwrc+nYPM9mSrdH4oM8vk8Pqa4t6r+7OGvD2Yms wv43d4UMzq2q96Y1EfZlM5CKz37Yd7+rtv38gM7d2uVDOVNpUwvvqj5b9KIyi8m22LfN0nvJWMfQ RFrm9djRjos1avl24VZdkUvTFA/cPWp05HbSlOy7Kafcp9UD1R/3vsvuf722+evrntW774X1vKne dW/RYrmswVsJvp/NFhcWLr89evpyjqjaVauH/BdOKintnxr93Mx/pr3qNksZd9zmO72JG+m9UluO XuBmUFHbdUPITL6Uvy+WrW93QKxlJJm3ITdLb8Qa6yZR/2PejmsL4taTLVmQcY9CR1cv8+bwWqsb JmXZujf8QtxCTUq2rLfhZjp67/2ITHXbxKRn+AOHm8KTHVUqz0+B1KXecM2R3Os9nfvHcuzSeiNs eteGGxehCZJKx+lu7e6Pf+rgOnKbNTTrqWr5UBD9uzu9p9/F+3HJVB8MiA3ZEaijurumOf0cZZhb KKnK8SevnEK6VSd1wq6Y3aTL7E/e1GBGUUMpGZVxj4Y2R6XoU35HvKmJcEr/Y24TL0crS9VdLMqN 9T2ZHz/nr39kd9PJP/y9gD/rO46Iur74ft4lOavHxnISv/QqdvWtVegqhkwtG8+4d9I2JLDq0i0/ M7Fe+apo1yxTb9A0oJQ95L3bz6TPqKbWlnugpdp74cMix7bLTd5rezYq5xxpG2/2MzhVYBYV/j7p rdxpseLqzj2N/Tl74vxNTrd0Nm+p0aKpFDhz6rPP9rUDDZLJCmynM8aiXMYZPgStunD15Pz1Lx5H n8uiOqrqFVnXmU1esOTzEamk7pvdDiJpDfPulL7h8b8qf1FhXc3J2CZ9rgU9X6ZIDEUukuhTEm9F j3K9Yq4mrfntmTLaOa0oOk1FvBWlmW5Fz1GgrehKhgc2EWUs9Bcm49dHv03OmkJSKHCt6L6t6Nlw rehuiPv+SNNFCEIJB1JBjiOg4U4FxZdHdZHNjyQRW/THZKAVrUp32MCFtqIe7h7h/fJda1x2x/cu qsoIUFq23OqqiODyPZGrHvCHty5NyLj7VlDoY8P6bNZkHibTMuadOg7apyM36Bwn37ZiQ0HeA7Wl O48xXl/5gWGU+bbWkriqh88a+idvd5j4DZypmVdzdujIs5GhI0ePTt7NjFPUfH1hC6OWmsAZleNc zsMFizri6XkZnGk1OXR7Qk8rk3U9Lb+XR2F+rOakGMMtsQVVxx4ZCzxIKO3PPvahnfrNhg5xaYWD bu/3W1I7hex5N7LquVVtaJ6JrYkrz+V9Oj6iCxRapcyup2951naiY0FjgSnVdfd6ITFSbo7AyxkU XwUZHxz7qj5aW1UlaLvS06yh4OuNok+Sh6ts5e6oJW59F1OZKG9ydlxqSLT9cImeiEe7S+TTu5G6 50+ysp4VE+DVqc7VD09abPrZzj1Vf+ez1NTUXROloh399O+K7/l/XrxgjOnj8iHpxjq9vE10k5v3 LoocUOy++2nt6tEGS7rXCzqv7E2tLNr6ajius8HfxiKQ4cak7qCfvIHdXp/QFyc8zx+iP17lESWu tmU7s7ud3E3zxh0FdEvvDiZsMdsXck731m7XFZ0KXPTHGWm1lkuw1jMPqKTpKq89eEv5S6nAg6B5 qQHc+9Y5Ra2//0L88CGO4TpnMt7XB6NZvHZ0+B8o03pvrp6t7pTPbifAb9mh/ell2cI6FmHpzi3X H65OF1AmDaE33nj5savJ+Jt0VXeGnLHd1bnKNzaecu20jDXvG2rQe5V+ToGReoHJDomXQt5n9WJs csauHW5+vcTrbNaEi2rps3vzFXX7D7xetcnYN64i8/79soZHYmYfaU4t0rYld0x6R+noe7pul+Ky 3Xes3GTptHNURitdci4uTpepY/Ucer3SKNZcLZH3WJWKt/i+Yh+qKY0M55qbzir6L+R2Uo5n38/8 qub/Ll3fYRmtTc2xBUM7vtRLLgsfcLzU/26etKb9wxvzpLlUF3/8LMQibL+2ac0dJUUBm2tBK0Zf 9+vVyqfXPIwcEU6pyXD+rO++/n3oznA3f7t3rqJM2/UfCx7t+OKb8bXXVngoaXiDjPQzTu9qlSc5 rbszBpp6PV7xi77wEGnNeF+v8vCmXPtBlo8h1RI+qh/Vepqdqw02cqQ1jYckb5l/Ozmk2MQswzOG bKn65u6BF6MZu3bJ5KzrOtgUeZ1zjDfuvs6ZLcvKmao2+sXnHTV2Nl0lYhLD+Fic7JNA/AfBspx3 Zo3JuYFJ5sXvdsj7x32ct/SS1vulVKlKh6W7NkjcWd5ifqbtiYabtuGiquEzWem13M6fo1Ru7dfd 18Is09JwqE82enmf7Z17VbYpsRUpU+WFF+jvPJETic07cudZ7+cUq+GUsiKr4onFBRPz3sxLOeWr apEYwbLsJZ2FukVbQuHGrY8sOvmPROx9eGKCYnmq0ZOozG29i20KRiMlpzL1P85/v3CSPVi+u7cr /9BpmginJretYUNX3Dbav7AO98mrE7SjVD+eQOF577NK6KLgq4EPyiZk64fS170Kt7wyJPom4lpZ hmz9q+y4/GLazHy5pGehPuLnxTPr15ifXXImq0LilfLCmx1PPbMVcp30POS0Ty3iiu0PO9xjdLYg prL28IXPTGfWMj8UyX43ss+o8NCW7Sxvr3/ycZYVl9FRd911trE2sfsmCXuKv8Ybs4CNnZatTC/8 m6ljz7wsydk4MNGo3BLT9engIdYwlUvXJ+52dWxteBv6UDTYnXuYgX/FnQz79JLl3VZC3iWPU3ey V5G4Jz2Osmu3iw8/TR1ucbT25BZt4RQx4/7yvI07Q8tWN5iVBX3pFp7iSn+2WXWw9Jqt4eeKuEDv T67KBw5pm23jqtll27Uk4arvlDrby0nt18NTJBcLmHXtyYm3Iyu5vjDWkF747XaEZk47Ag79B+0I 7XQ70kiGtiNtn5g8Xr5WPFylXhe17U5h9BRSRIZrRx7tRM+Ga0eyIe77I0Og7XgACl3g4CUwEpOA UySwQDuySBQJQMeU6GjM8q43i8aCWBWVmiOnznhz9BrY0Q9vTfAs20arm5xm2XPFS6rsuQbvnsQ9 uUtkCyupbsSu/NSlwaBzL2eUKuFgVEIcVaL+Xr6IoX1xzmWam4bCzhg+pl6lwCIvkx45ND7Z+URh Wc7mJSsNexDl6ysryUYz7j25HCfhgwiVBG0uIQ24Tt4zvOWRBptaueNo37EMJQMZLmXeTUrpu1cW zsuncCfPup9W87xyc+X8fazI1iwvuRO7Lj1+vSa+RDEeEbzHf3i70T63VAtJXd7PGksYstc8N6AT DQsL02dQexW3h7Mm8MWCXoWAyWXByddL7W987GVgCTxWF/V6l+bnoxO5A/uU8koCPRQQjdWcZ2qf +Pb7pY5JZ5sPbXAVlAob8jl99gqnz+UBvhpFiUf+llLvZG/Gma2ZuBp3j9/V+0Fpm13SG5e2t5kv vqwTYvA8b3VA1NsloUrtRnbm8UbJd1SkgmkjZ18udVtIe749vSf1tkrYGUXqwIYc9viyva84z21+ 5nS4b5/irutOFrUJa0K5nN9F9RwfvH5WZX7VgtacMfbCTmO1L48DQ+Tkkncn5Xxq8FVRdvfwax/a t1ljLORywic+yVr9WyZcMuOx9g/vVA813K5O9DGK8b0UfvG9+gkhLqtFJR953dO1SpS3joaVfhE4 sHaNgWFXQq9UePGe5XZFbrZFC7uW7P9itbXBzVUy2jnmJnfX3gvLu5jPNjCPXJ1YE3zIYcOe5cu8 086XRDpJ9s4fUq1d3qXTIb1wOCrdO+se1WP3DypTHZUsj7WEZQuHx68pGjR2Bbfn9Ww4caiwQMJp 4nrBYYEe16ji5acivAuOxnqXU41ELozc12j45P7ONTFXJPUZxky6qT0XpxzmbhkfeZ5YvXhFvp/c 3a3XXl9ZPVziMDFlmsp15OiBQTFR16vBm9RdrmsaDZs2p+xYdd5P6tJlo3YZ6wc5CzzOBg1YWDP4 HbleRXpVaP2hiop7y6Y4ncc1Q1JLqeJNFc7YO0eaZc07uWHvYbZ6dpF3zc/GlcOc08/kdw+mZ68P 5Ajne7J3MuGhw1RhicV9yUVrdWrcZS3v79/uJkTvz3r300nyhbsvqoYv81f60nIoO4NrsaHTYELG mlsXSliPRAUY7hxfwcP36sLeqJfrVWhV7gf4JQrpkD2nDxTbPZybRqsTzeEumuNQZ/eqUyXKrfhi c2JxvsHQFCJXIefn+wPv4snFylJLevHf/jLd/Gnv0oF5lwGu2/qvVUQ2OARsrDgpGd0whZyf9i4Z 19Gz4bxLGcR9f+SDWd5lGXgXCnBqjuG6SIHFMiR2xrtYGW4A7xKjojLelvv+8PZzeSe3WwvuqGzV ZM3RF6z65Ch3yPaDMW9dle6DEwKFZ6huFFNdOUKlaq6x9+X9rT0aDOcjTid8WpptfE+LPNV221hY 2H4hT9pVChU+7tJDXZuejXTdfVeKcGw+lELi2kNR/O7q+Oan8yl9HEnuOaWTCpBv3qq8Ob6L46xx OsWV2JrIJrVWreN0Qo3aOfa3FjpeHnx7Izp3WPlR3ja7s1JiCKn6DYMsvq/e3ar27jpX6PW3dFgm fwhLjj+95mTakRWWJ9bpsxTc27X7fbpa6XOy+YcUyxioxHkobk4lZwt7W2Y5FtsKW3JZ85Ko8UmN S4puODpm4bTtcQXJIW8/LYOKxDxFO9dQklrzl/oNdwZN9lTo2p8/ceuY5ad1n5p3DT+Tjr/rbGfM xnK33LGztsHSoyLT/1HayK5sMmGZ2xG0QqPrdlaUvL/G0bdwniXL6/Y9w46rM3Mr5X1uNPjIp2cO Z9WG3F3zejsPucaFFdY7AijWPj+1Y/jLuSVbxnlZq1jT7yiS36YYWf/ioi33Dtt5fU4d9danaAZa 5vscTTTUnXylr6rmO3azYdRNhsyJ3fkgA986nYRi6iFLaploFdaq8n5F6bdXtpi5ro5JbT2a9qnY emAhTck9J+eea7nSWzeItJknCcgIHBcqt6pMjr5et4/+/j36+zSD4UkTxRqvSfkWcvFeypMfVHnM HpTJEZWprBGztP2WUW7dvoMCWg77M3i6XTm/nHjKPhjn00MXVHurKrzH923CuNimjtfcHKlfffrv 6Ud9NpCWucZwsJybo0uleauK9MuejEjdJ0+5PwU3m5Mf2mVXaTfk6M2n5DIm/KowUqZeh0szk6lu U0LwGZuBdVf0Pu7oO3TuvixF9KG4/JcmJ2vPzXd5e/59m2N3A4NY+DqG128lmqqPSg+4Nri9Se6q sxQ/e0h6dZPgklhRpRfRJvbhtckxCkpWY29I0sTuh4imW3/aez34Y3l+IdUpnlcc7u/6LIz7KhVP Psq/EZlX1sxXxB5lHhhm29Or0HaBT8H35Ej5o02m2+VWv90guunakiMyLG414vFMFeE2kyolyl4O Acesqp5xjz/UzT5jsNXLmKGoMftMEW1/YFWOp0mFTP825UZpP9n0O+npvecirdNC5bhqHu+ST20f yFY2o/yw/yMLNc11tgqlYEr3en6by+EPTjogb/IGE69ElbHaTMUe6dHPJuI/Zm3MSDR4DhLEDpzK jN8RgH7OxylS9BOhRNYi/kgQ4os4IT4IzmGRI776NOQpCMlKEginQIw4oo+4wRGuiCfih3ggPMhy iNuA7fWn96FIGOAKukIRZ9h7It4Q74QEwD8eOHauvA+CrhdZBLkjEyCjECChFCChFULodEmQBbkR yEoh1BHKUW/RMmBHjAxIERMAXCvpSibIlTZIzpuTK2ksJ9KQxgbH0AqRoMpWCpHQ11GRrCQl2UBC SY5oGSxAHBGylbxwhCMcyTVHiwymBd1bQIwrpAbhXRV6Fik4Aj0LGZyFFHcWUvQs97CzIMgaKEX0 DGuwe/D9GWSx0pPFzoPuZae1kYM2Mpw2MlSbIxlOmzJCgWlDf16KZo42OUyWAmTJcbLkqOyHaVlt uMck0yU2V1YeYhfCEXAHaIUoUHGW3A9Q/itADQVChcij5c+GaqH6gRYFTAsVTgslvhZKaJhmbp8y fGcieh2K2HVQw3VQ4a6DCr2OYxQzZUDzA1klTJYGZKlxstSorBQlTnYForFycOo4sgI7Shtk3UE6 FCwwBGSN4XsQ4IHtA+DO8CC6UCv8IHX2pobQQo0YhE8SuNZV07YRgVkz+oCFAb1++joKhMSah5SA 7WoiX42g3pFoImg9s0U0sVJjRJhdP8C3BVBi9HXUCCkdawoHhFlw8jzf5KFSUsPVG8PZmUnQUqAD Df6Qh0jIgTmWkxCsDiBYKTO7biAhgbqvKUqzgRrxgxq9FjGF/PORrMVskpDszDX5fdO0AI5kiA+g xmljgXqJ1k0yVCt4DjPIi/Qv65PB9LGAvg0khPQpIpqQP00SRewOz9WHlskCtIzxhWFbiZhATkxJ VhItFRlMmpWANO7cKxEtOLczpoHxp9eCdrHYsOtgij/0FZcJZcQcNARhdwZKHWzLH3EBbzE7/wvg fs+Pv0fKEH+MApcNnOxisIxkkjiSxQiaH3NEA/MHpAg7hMAKwD98NSJB9pPIfkvXwq50EVwPCc5z Qq61DJjxjEUc4YEcZZOII6ifRy3aH3KBejPUWjlw1vac8TIvCer1hRCRldlIGYkQptkYqw9ukPu1 UE98wffh5BDEEjwRCXKVxBLTMrsW4NdJBM7AheAyxxDvR84Uv38c9QoCrvPA4aO5FcDL7VLkK8ML kgckS7Er18Ssbz7CDaVsRsYU/xpKuRLXMsGR0pCDl9iRlOBhPZHgb/ZKC2XJACWM3hcEWYqWG+ng N53LMZ1L4AhFUnydAsgytLUjRdtE8m86UX083+4zgkhCHlEvKInp0wGrQ+8pL3qVqCqsQM8xBfCT kKJaEXJFxAZyykeKWvQ88DuoRaClOVMjDDF/g14FHyKhzUOCekpyKBFy8FQsWOu7AuQp4I4bwR3H +RlWhP+b8WIn3EdyhhfySYtaigr1FvS8QsgCTFoIT1oaO5MAXM8tsCJlsCshhJXAcTLYcYJw3D4S MrQFgHQ2ZO5xsthxQnCcNSk5Zn1CYN9zj5PDjhOG43jIZo5jJ3CcPHbcUjiu59txiwgcp4AdJwLH nSafOY6DwHGK2HGicFwExcxxnASOU8KOE4PjVlLijlPG6ttVUmXsPptjtZEF2ulvtY0Fmjb0juO8 PJ6HlsJkH5BKITN1Fe0DUCMS03WBUD1dgtozKa6eztSimXoq+V09lQZbQa8BvZtUkH/UgkLAXtH2 CrXXZdNt7wdIlUPNAfJkPG23xgihXtNyOIc+ZluLIfdzayx6obhaS43VWlSlGmg0AY1qWAnpY/du CeggE0CwPhyUTPwVKqZ49VGcrVZCk0wzK0fsUEqDU7xk2HAW2kI9aEsMEQS7vq8MH6ekyaQRXCuJ 9jgYwCY5hYyXCyD8AiSL4lNU4SpmN436IMOE5QN3v8zhUxDsc3ZuCF0Pmic6XDuLuyy4x18ZnMhM ycQxTWvBa6JtkRxCidZwrPRm3z1x7F47fzvaCD6ZoCwo0AL0hxOenMCsBOdjgrArCyILwo42xuzC CKyZvs4AYd8M2dlMjlBupkJoNtMi8zZDf2Iz9A02Q6u1mQ3SFyGcm7mQxZuXILyb+bC+O+ENzSEj 5JACckiBtiwM90njyP5qWUwR9GVdRSgb1JrEsTztn76CNVhpz4cagbMCZtc1UwjWf8NpE8fsKHv6 aB3EGrteZdz1nqBkig8bm3W9XNjR5WRc2NG6mPWRIiqzUp3Irk6nrkWsENT60WqFXgWaepzswXSq znSq6nSqNCb7ErMRekhFbTkEG8cIg9/mwcY0aEuHYBaKtvCUaO8LrnSQbKb3pQGfPIg6Wg6zTMuf nCO+U1gItQ4SMW0OMrQ0l3673zgdpOQzOlA7Y4e+A6ZjJejAdeUwTaNT0z04vu97cKgOZnLlaR0W 2NVqfJcPe3Y0H5iVkvzVf+bD7iYfOd+3u4n2vdDeBq6VPDnxrf6Qz9QfnO/S+qv+sMdPTC2KT+WY 1S8XAJkrpJrkAgiu/uhi5QojBwFwJriuKWyymGZTctlpzXoI2pvWwcs5O1w3qvwv3VDTGQLJncnZ EVwbLDNtDQj4GhnkBUkQuRSC346jR8wH7bgqNLuVRnUlk8d904XLCXqFAvA9kHw/ucB3unBt1CrQ tYsCwfJSRp79TV4O+zTA5OWQZPLyOfK4tms1gpo3AnUHLJrkKrkpVv7o/UfriwQc/60M5sdzYVZA gpkqdi/NydB7SV9HOd21n/Y4S7EuAmbpTOQPyLmmS9USO6MhsiieVx2B1uurUTbyglwUQeuhHvQe PMHancBzu2D2TYu2z5qipOioVgqrb4NYeYKnhtw6wDgn6NtIhga8DfR/sbuJK093nD3DUej9JtYu oC0DL9RenE9YLkDEmULbP7tPB4MOOMU8dOCB2TwJBW7sRmjULjk9ap8HPSoWTCFqb+SYjzeYlkXv 0kICY0ZJuAtO0D/1wXqr3/dBaaEUGOLBS8WjGnmwEpKm4EFm6o8BVlZm09c2c4QmdgRqWahHR3sK qLfE9cW5MJ9vSsE1fYQO9mkxncqOaxEocBZmNe3z0Hu6Euf9KVZO3+fVCNqXs0IwmwmETOZDmdqM Y3eHhWApKmLjxzgKxWkN6BhgPvhgMuymTA9rCEpqYq1tMgXqt1ggT6hNBEDJuU/bBg/WdpmC1aG9 FfTOSyG4lmQB6KMEfZRY7QffTyGLpRAeeaKWQgk5Y4jnIkEtjI5cGtcGUKB3lw60SsFxM7J/jYso ETswpKfYHWfDSgrtraAlRTXr7jpAzxfN/zr0inGWyJKrQLogNxDNEXrdxgZU036aGyrgA+x66b+N fPymW4XZIzJ6ZD2u9aqDLr7yV7TeQOuJ1g1luNNoLpSxo2bPkn0/FqRF7OGK0YzM+ClZZDH0qwen y0oLZH1n9fpnX7cD8pdUFK42UkaBDBPYpAVchxbcDw34ZgZ2xgPfdcCWdLB7hHomOXQma2bubKbD xezKOIXz2frg1QQQBQFEUQBR0iZFsLmJK1Tfeq24G4u1Sn64VonSD87NjtUMTexsklB6q8DvWIB1 oCFJ6J9rga2g4VUQY4rgRiWcUDLfesffnxcbm6ITIWRwQjLshCuwe8xHuQLOB3cdrm/tdA/UGcry OqmAKyW0fILYXgjbC2N7tKTmkRvg2jhKA5CmnJVbaSwnLr+VkzWYLk3KNaBrPlwtep1oWRtjfSUN uHZ0b4y1Msxw179XOQ+ZXZC4nJliOSP/Zulortxwcw89MIyckysW6KEw4DJGDaqocffEEtPlTGmJ 6UJrqDnmbZZBvQVdDPF5lKgX/sn9zqNE8PNIjhsNBFEaY1dsBvdxOVjSjFV7Qvk5Tfem0PvhMe3i id8PGmpUIy9lHKaR8dvd5IGWkQerdTxwV1F9M6OaxcgGzCvj/LwgthfC9sLYHp2xQ/O4H7OP+d9q H/4ssgKCm7OmhDCax79GF2h/JpkyG7ov86BGfy+Fek+vb+conz6HMXblIdDCBsHx37cjNIg3alWz erfa2DVfpdTGbHDmmh0wO+GDfKHXtwCb7yB8jbj2AvWPyWQPKKWxe4z2v3H1iQWulgztgKM9Cdxo c8XMmbHWFHlJqQwyaG8N9XJoOeNMHrtTFNidosDuFAV2pyjIZ1n7IGbtaBuC9qtFoXRn+vszM5EE TYmOddrPznRmp/vDVJrT2lDrXAItC5bzQySoqstkc6wd1UEDOmi+jQOSyZipuODq0KtBWzUKJBDV gZUk5ieo+ECKBCtbSrg/+HcbN66SpgqCYxZAaVhAOaLewBwrSx6oL6htr4Wy1YE96i3MIYzAiD8Y V48USJnib0/i6hHBC1eYzjUt5JoWy7UtnBO8DpUtxM+DdtMfsxX3b7VnZjy+BL6TTT/XQLBeKDpI wnWcEGxMPOORENCNzCpVU6xU0b5JCNbfQ3t9aA1CRwuhaL6h+SN0p9D7TEVujZWbKZU16KBHnk7P 3wVD7jZgTzHcv/WOOZGw2T27mQziBu3fcjdzz6nIXXH9GCpX7Mpntw48WLmaY2WPICJI+LQfxjon aNnOTEzMsYjv2yNy0IvmP45KF6tdaLl6TNdM9Poj/vLws5S7gnI0V7M9vDzOj1Ch8xN0s/r1ZtM1 2wfTSAM+GrtFkch0+UkhttCCZ1Oh/SBa8A0+UPqoxOzWmxSJmjU2RjcSLBb7eyKgB/tRLAR9JwJ9 XI8tE8K0oTlB7Ql7KQN9WA/Xj5Y0OpZG2xi09qPzimj/EB1hof1edOyCPitDZ1XRe4aWAgK9HNSX olaGegC0l47WGATrJ6EjGUEEndcFj4Ogc6HoPUFrO2r56MgfHbkg2FzmMgTBenyo50HbUHQEhtoG 2sdASw71mWivE50pQ/tDKgiCPUtRRRBsBggGKlhvTQNBMG+E1mF0ZITaATrSQ0eKaN1Fax3a40b7 vujsBzrjg45g0V422lNG51PRsZUZgI6t0bEx2ndGvRQ612AD2AJ2wDpgPYJ7EcUBcAScAGfABUBr Cnpv0bEN6sE3AJ4A6vm9gSVXEGQKNvgK923m28xGMid25t7ix87cbfzYmfuPHztjEfixMzaCHztj NfixM3aEHztjWfixM7aGHztjffixM/aIHztjofixMzaLHztjxfixM3aNHztj6fixM7aPHztTG/Bj Z+oHfuxMjcGPnalD+LEztQo/dqae4cfO1Dz82Jm6iB87UzvxY2fqK37sTA3Gj52p0/ixM7UcPxaN 4ZkTi8bwzomd8Q34sTPeAj92xn/gx854FPzYGR+DHzvjdfBjZ/wQfuyMZ8KPnfFV+LEz3gs/dsaf 4cfOeDj82Bmfhx874wXxY2f8In7sjKfEj53xnfixM94UP3bGv+LHznhc/NgZH4wfO+OV8WNn/DR+ 7Iznxo+d8eX4sTPeHT92xt/jx860APixM20CfuxMK4Efi8asnBOLxmjMiZ1pW/BjZ1ob/NiZ9gc/ dqZFwo+daaPwY2daLfzYmXYMP3amZcOPnWnr8GNnWj/82Jn2ED92poXEj51pM/FjZ1pR/NiZdhU/ dqalxY+daXvxY2daY/xYtH21nBPriOBaafxYtA23mROLStvOiUXbebs5sajOdXNiUZ3r58TO9Bzw Y72mwY9Fz28/JxbV6TAnFj3OcU4seiarObGotNOc2Jm+CX4serUWc2Jn+jD4sa7T4Me6TYMf6z4N fqzHNPixG6bBj/WcBj8WvQ/eCKHtT9/3v6fvi45MsY2aBNuTYnsybE+O7bHxDDUltqfC9tTYngbb 02J7Omw/D9vTY/v52J4B2zNieyZsz4ztWbD9AmzPiu3ZsP1CbM+O7Rdhew5sz4ntubA9N7ZfjO2X YHsebM+L7fmwPT+2F8D2gtheCNsLY/ul2F4E24tiezFsL47tJbC9JLZfhu2lsD32i1bU0theBtvL Yns5bC+P7RWwvSK2x369mBr7M5DUKth+BbZXxfZq2F4d26/E9hrYXhPba2F7bWyvg+11sb0ettfH 9quwvQG2X43t12B77Nk59Vpsb4TtjbG9CbY3xfZm2N4c21tge0tsb4XtrbG9Dba3xfZ22H4dtl+P 7e2xvQO2d8T2TtjeGdu7YHtscovaDdu7Y3sPbL8B23tiey9s/5dXQcdiYFOaqAXO9jY/2lCL45gF ZiFgvMvAXJPATKWhCMUhw2mQufiNCDJyAEFu5yHIsxoEOXUdznkDV0dm6kU0sBdIBrKAfsAcqsde 4BgJTvceqBBCYPaWYMpJYLyxYH7ow9gKwBkMrwNwBhMrAzOQhfPTwW0xhpuSDzeAE4qZFAr5BLAK ivkzcBsK2gOKWRcKeRsUpaIPgtQCRr7gv6CSlgC7/cH/BYBfCkeQvk3gl7YjyGuAZwcUGBAGHAda gC6APwGuCwgFrgEfAMGd4MuAECADeAi8AWJ3wfmAV8AHgD0Ryg+wAtyBDOAU0AWQ7Aa/B6wGAoDN APke8ItAHLAXqAEeALRJcD8Aa8ADSAUeAtRQwMLASeAlQLYP/DGgCLgBG4EzQBMwD26ENHAG6AIk 98P5gWigDHgLjAEn4b42AWQpcAwQCuwBzFIRJBKoBK4AncAwIJQGZZGG/uUgBNkEVAHXgSmA8SD4 ZsAFyADKgD6A5BCUP6AF+ANJQDXwGJiXDu0RsArYAKQCVcAToA9NOwx2CNgC3sBBoAB4DnwAuI5A +wBsAnIB/gy4BuA0UAu8BsYBkaNQ1kAgsBk4B9wEeoExQDIT2iPAG4gGJgBbMOTDwD1A5BiCRADH gS+A5XEESQcmAdNsKHugHmDPgbYHyAVeAvNyoc0B6gAyqD/rgMw8XF3iO4Eg+4D7wNp8OBdwHwgp gDIABoFrhSBXBHYDxAD5gH8xyAH1wCNgFGAogfsNaAJhwHbgJHARMD8J9QZ4AfQD9KXQxgN6gBWQ CBwBmoBnAOcpsCvAFHAG3gAKpxEkCIgFioArAMsZBGk/CzZyHsoU/MLJS2AXlyEe/FEp6pOugi8A xK+BDwGGAFHwHdnALeANQAp+ZPENnD9B/R3q59A2Fqow1s5C1cWeeQQDoUAYEAGgT4XALSExQCyw BdgKxANQvRGoyghUXQSqJQJVDYFqhUC1QMDksTX5YK4ImCYCJoaA2SBgIgjccuQYALcUgVuJwC1D 4DYhcHsQuC0I3A4EbgcCtwCBIkegaBEoLgSKB4HiQMqAcqACqASqACgi5BwARYRUA1BMyAWgFkD/ GBcUGXIZgOJCoKgQKCIEigKpA24Ct4DbwB2gHmgA7gKNQBNwD3gANAMPgRagFWgDHgHtwGPgCfAU 6AA6gefAC+Al8Ap4DbwBuoBuoAd4C/QB74D3wADwAfgIDAJDwCfgMzACjAJfgDFgHJgAJoGvANYo QTtAApACZAAFgL3GD6BdKRqAFqAD5gH0wHyAAWAEmABmYAHACrABCwF2YBHAAXACXAA3sBhYAvAA vAA/gD4WEQSEAGFgKSACiAJigDggAUgCy4DlgDQgA8gCcoA8oAAoAkqAMqACqAJqgDqwEtAANAEt QBvQBfQAfWAVYACsBtYAhsBawBgwAUwBM8ACsASsAGvAFrAD1gHrAXvAAXAEnElwL5u5Am6AO+AB bAA8AS/AG/AB/AB/IAAIBIKAYCAECAXCgHAgAogEooCNwCYgBogFNpOgr9FB+wVsBeKBbcB2YAew E9gFJAK7gT3APiAZ2A8cAFKANOAggD7ySgcOA0eADOAokAlkAWgfAu0MV0Pf4Q0v1D/osqpD91QB OoDvoCPXuRbXT8iBPgI79A04oG+wELpebtAnEASHYggOJR76AyvAqXCAg7gCDqIKHIQ+OAhbaF8b wEGMgoPYD+1cEjiHRHAOEeAcaqB9eAdtQCQ4hZvgFPzBGSwCJ+ADDmBPKc4XukGljryK82Nojw1O icCpkEAAfdoB3Q8kCoAuCLIZiAO2AdCNQKB7gMDpEWiGETg1As0iAk0bAqdFoAlBwGUj4GYRcJfI feAZ0AsMo0UC5cIC8AFSwApABzACbAAnwBeIBhKAJCCVBFdnUPtH7XjGzlD72D59XC3QDjwBvgCs MMhZCIgBesAqwBfYCSQCzcAA8BFYAB1RKUAa2ADEAzuAU0A9gL62PQjMh/vJBCgAZoAlEALsAw4A bcAQ8BlQhiGVJWAD+AI7AfSnQU4DDUAT0AmMAZPAFAWuX8xCHzLFIhgylXr5f2afijY22KgdHeuh vWx0xIaO1NAeNgtvylTqZtwexnkfsFEPQom9lkpKjZsBKCTFzQagFJGio+PFH9HR4OXLl7He/ebN m1Fvy4i+kvYBbaYYEeoP1NMChZTocJ7940wYVciAkH2QQnDvxeKmj2k+oAoXfJ2awoaK0xspgntf Fq1mFNPHQ81CmKfjSSAenXMwQ+g+oENJ3Luz9ehppt+gJSdDL1odfDsayYS9TYt+wz0sQoex9DDg NscW8ssiSogC/FNE5OHfcoB4msIP0hR/kKZENE0akfpB2vIfpEn/IE3mB2myP0iT+0Ea8XKR/kG5 SP+gXKR/UC4yPygXmR+Ui8wPykUG/glBjQiC2nAShn4XF4Hb54XukhxUEhjlD8MY3wnG9l4r4VMD XBGM5MlgtL0Qhng2MARd7QjNAfjTcYDnCs5WZ2ybDPn702XScHAcJHRAnlogT8chT/cgTwaQJyZV cEOQp0TIUwzkKQTyxAF5MoU8pUCerCFP1ZAfCt+/8mQGuswBF3FoegE+GehmAKnykH/gGFAAmCuA PHAaqAJGgQlgJwx79wIpQAbwVBm6Z0A3MAAIQL6EgAVQXmyAPxAI3AWa0DDkORCYhGZwCjhvAmUN UMLwmQ4wA6yBY0Ae8B4YBFjModkElIGVwAPgMSBkAd0gwBZwBvYAqUAVUAPYWcK1AvLQ5KoB3kAw UACUAk+AF8BlKKsbQKUTNGPAEWdozoG1rlAWQCaQDRQCJ4FJAJ1boABogOfQhr4GyqAdrQICoC0N AV5Bv/890ANN+UdgEBgHIqBJ3wh0A31AGrjkw0Az8BzoBfoBOWhvVwAPgSeADbS9tqm4IWIUcBjI AZKhyU8DjgIngPfQ9I8ApDAGmAeUQBegFNCGcYAeCvT/1wABQDSwCYgHdgOHgIvAdWAA+ARwwFiB DxAApABFYAUQAWwCjgOFQDFwCngItANfAToYY9ADHIAD4ANUAheAe8AjgBzGIDSAJKAArAXMgAgg DjgBnAQ+AGPABEAO/Y1EYC9QDzQD22Eckwy8AXqAUBjTRACfgHGU6XENNTAf2A/jm4Mol+HeAeWX cXWFCmosFcL1h/8IqMCPYlPUiBr4rkBAG5ykHnANeiU3gM1c0L0H4paADQAreeAYIAyIAvqBQUAM uuPSwDPwl90Aiz74KuAw+KBMoBvoA2TB5ygCW4BtQCPwAJAGn6AKZHiCPQKCMO4XAdbCeN8aiIAx /2YgDcb9h4FEGPvvAy6BD7gFxGyGPAJPYJz+CjgDdfECQArjchqAGWyYE+gAugBXGIt7A1eB20AX 2Or7aXs9DuQCpbNsl/vKbPvl+F9m5h8ptp+aQruZ6DJMt+mXVNGF4rgXs/2whebS0JHUQZSRddAa 68FxxlhrbQbfHQAdbJnuWmyRuDQcg1syimrygZA7tnjLCfuOykpgS9GloN8iBS29A7YIFtUXhgRj 2tCX0Rzguxu2IBRdKu+K9Qv+5O/fmb9l/5b8Kf45+5+z/397dlKSjTDkph2JeDDF8P0/EmQTpHFt 2K5JKC0G0k6zaZ8nlBYLaSt79B8RStsMaV3+5jcJpW2BtHlUYe2E0uIg7c5r0xpCaVshbYX581JC aQmQ9jX1TiehtJ2QVuCzbpRQ2vjU9DYnDXqm39KQ7zYSJF+lgpQEoSEnlBam6Ed2YmmJMaG0vVob yYnJLfGoIKdDaKgJpXEJllM0btpXRiifXnTxVL3PTigRktvkepeKisj5VvClURfUduUS0umiy0Pj Xt0vSUjOZ40kjV/4ZztCafEqnjTEruGqVTQNsWundGelJVbWV/QqaRcR0enLp0tHTCePwUY6qZfW 3YTS7ipSz2MgIpdteGqeM53lR0JpW7TuzCNWnpUhbfMLckyXEUors7NgIHa+TpsShsUnU/II3QeK 5RcZiF2fR+BDhlz/oC2E0tTWhjPuFsrdRSitIFqG6dbDjQTlRBWYmImVdQJXCzOxa1+zqpsF8jmP UBqJJ7KA2LVrLfNZQOz6WpflLdB+vPYeoTTyRQOsDETOV04lzLYmn+8aoTR1PXs2Yvmc8C1nS+hS lCYoxy7E/vTiuTRC92iz0kqOxVynrxOSU4xayvnyqSQtITk2QVVOYnVlYbgZZ4GUJcH68GJlMKe5 eLkxIZ1foui49t1rvRD5vRjIJbKzcl302+hBSGfoMn4uYvehVCSAaNoFjmEuxONTDqG0pwEM3M97 Bt8TSlvG78JNTOfl6LgljjdzTxFKW8G4fcl2ljtvCKUtXl/CR0wnuZgov72M8zVCZTbfuYjfeMXL TkJyTJuUBYjpvM58T5iByP1LZukmmsa+XmSp9XFyI0Jpy83XiHayKe8klM8mq1RRYnkRElETWzr8 oZBQWhKpnlgRiaQ2IZ27fdzEiOk0iigWe/51jKBfSt8UJU5M7j3nB3Fzt3kE2lsEqVmsJHHMn0eO UFqpW4KEfaWBBCGdOSQZEsTah5M6xRJxN/orCaV9cHwpsbn44SpCaVzGopLEroFEo1qSfMVlAUJp RSqXJYnZJzNtwTJiOivNSKSIpa2Uvyi161jJc0Jp+gvfSYlWJiQTSqPwWL6cmM4oDmZpYj5yqWyU tMGhgsWE0roNxWWI6Sz2ypXxyu2tI3T/KjnJZBcSkWNcGiFLrO2wjVgsR+x849aNcsTkbrBryxvc lX9GKM3NskpBukVqLaF8xtnfUyCms5v9quLzhwJchOQ4aJsUSRAqgnL0wgxKj8LICfRNESR3vaQS set7S+aktJDIPWp3pFNhPjlPjVBakOspFWI6pexIVzxXMSeo87xtjCqxa580rFDVzI9XJJQWYimv tn+edCSh68tkc1BjrpI/TUjO1+m2WkiAaTohOSWDD2rWL6njCMllM+9VJ9Y2CvC1qDM+dL5HSKcJ teBKyihdgu20p/6plXVeUUboC/1kCDlCgVAiVAg19pTFKWCjBrHy3LJAUZNYWgt9vOZKr54rhNI0 2HM04+6EPCWUNmzFphWWhlgSyude6dfaxM7HID+gTcwPliHUOiUKEwOE0tI0LHWI5VOc11eHWFmX 8p3QOXfXNoBQWiRNnw6xfN5fLqbLptX1mKCdsanrEsunl4KfLrF+66VFp3WJnS9tgbQesbQrwnpE 0/QobukR6w8ySLcSlVumkaF/TrWOYHn2RR3XJyZ3iatKv4e0fIzQfW+TGNDfeGTpIYJ2LbtwFbE+ dDtPwCpi58tTKiKadtK2dBUxf80mdXrV0mpSJkJpexFGA91OXU2CdTNcweBxbdEpQtfgq9trQMz3 xDC8X80j3jBK8P6tU19DzD7ZzP3WELu+82ota67y0hLsf9asWmpITK5uiZjhiYQ1boTSXGItDIn1 NWAQa0hs/EdvM7wWSSwVJpTGbfrMiFhe1kknGnt1kkcTLJfF6SbOO+eREyrra0ZsphdSRwn2I59p hJkSu7cvbbJMiV3DVRZyM2L5vG1LaUbs3jqwa5hfmH+L4FzCabpT5inzKFkJpWWze1gQu++t2pst qDt3FRFK06NNtPDLFZUllEapyWxJrB6lKwlYhWmxZRJK0zKVtiLqQ3zMrYj1syyXslifu/9ajlBa w9Ica2I6m5R4bIld+5C4qB0xG4xw5VpHq8seQui+N3paryN2vm7Z90TTMkk41hNLuybGZa88as9H 6HwTohL2XTtKThCSO2qpac/mcYHgvNvhUBEHYn1hW3oFB2JtB5u3iQMxG5QicXNYt6nIi1BaF02y A+W5iCuE8iLhXeBA6zX2ilAaA5msI7HzOclwOdkiGQT7ph5UsU7yH9YoENJZx/jKiegYz4zemWgb F7LUmdj1XQ4oIyqXG1HgMnggYzGhvHxyFHIlJmfAtNeV2LVLcm52S1JdeZ9QWqn4Vjdi9a+b/KA7 sfMd8S51r9u5cTOhfNJoyXsQkzPxqPN4Kqh9nFDaxIJHHkxE5GoFBTes07XuJ5RmqM3gSaxunqM6 7hmR5rqLUD7nBz/w1K5ICiQkx+1q6EXsGlTJs72kxpB9hNLMfS94dRZ+IOjLl0YLe8c8EBgjlNYu 88BbeslVI0L5NKUs8iE2v3vM+omP10bEj5AcvaW5H7FruCiErtMlnHZUwZBoWhyrpT/Rtn/5TqJy DE7cAcTk2qRliKad5OUKJKZztbZcoH3U7t2E0jLcU4KIyRVrswY78pTIEiqz67EuwaJ7FxQQkuul PxscMdhISrjMHELYV0sFENLp56gcRqwNzzF2CyPaXzJlCVdL4QskpJNxxfHw3TrS44TkEvUoI4jp VFpvHEEsL7IrvCLm+yfcIXQ+Zoa6CGkFoYOE5N468kVKWd6JICRX4SkfSSwvgzEJUeT2L7MJyb1S yY/aN/bJgJDcXq+KKGI+y8lrKoqYHwwlEYwmlpe75iEbiT0j6l+xbSMxnT2L+jee8dxMcN7mqeDg RrX3fDKErk+ak20TMZ2XhT7GEhvbk0wfM2djRH/IiJoK/UlsVvTXkaipKNGVjJI/kThG8U3iGMUv SSiSf5NQJP8lCdwPf2MS90hnSSycezxCR+A6jAyg3QD8l4LY2Q8/FsW/oN8Sxb+y3xLFv0QCosRL B/cz5pjoBpJfKh18CUInW/nXyQJnic+6WStJyAgdQTZ9xMwxFASOoZg+RhL0fTuOau5xVLOOkwTN fx1LM+dYmu+OlUTIZx9P9/3xdASOl4SczZah/06GnoiMJEKJL8eAL8fwAzlJhOo7WSY8WaafyEpi y4qJbySI6D8xBnIiomQERDERiX9qegRF2eeK2kPYEcJGBnSggg6n4tEHnGXMrSpk3+q249hM3cZE cEYNIt/M+SciMxY+IzZj4T8Rm2P0yF9G/xNRgvUA+ase/EScaNVA/qoaP1Hxw9qC/FVbfqLmpxUI +asC/UTVL9Up5K869RN1v1LNflwX4v9y4PGkP6sLDATqAu733WcZc+AH1GbmEzXmXBBfhxPPRWsf 9ncE5qNvvKBCRMxZn4wp/twEJqRPhgqRTQt9K7BfE6OYFvu5Oc8RpZol+nNzniNO8534z815jgo6 Aip+bs5z1NATUfNzc56jiuEHqn5uznPUMf1EHWrO6CtWv+6ncb9jOcusyVfi2yX6gistJsoJom++ 2sOnI3zKUSPy1NhPTqOWJoLwEK0Uv+Hl/0EbgxbNwpX4YvFozaHGHAOU5MbJb9c47eRnb0RaPrLp X6P5BzlDiIj+xL8Qb+3mZPKv7hs5ASFivUniF/WLbuwflAmxCyTe8/1xByAZHL8/zvEnf+sAkONE iHjMOSIzHYDpMxHxmHPEZncAyGZECXrMOaK/1wGYI/77HYA5Kv5eB2COmv/uDsA/rNvErVIZ6nbd JCaqTDpjlX/PTc46q8R07SHmw8rhrA9xKspJcV2Bv3zYv9D1/Sd6iX+Dm6Yj4KYJ3o/fySe6/Yv6 nL9YjoRaBjLM5LLIvolmkYHJZZGhJjfdrIjM+LS5wth5t0FWo3Emvg3PxIk7XnRKRAonco90tuOl nBYj7HjniP36yAudv7k1jokqkv++4/3PGXmh01+jo5gaaqp/5ngDqJni941gqgKo/7njnaPuVx3v 7/VYcJMixIwxBO7zbtx9DiGfMcaZNvkXRfAmuoga4xyxXzfGOaK/Z4xzxH/fGOeo+HvGOEfN/9Fe wK8PX9AO5/fjJ2wMgssVNgaxh09H+MTZ83QX9ftz/siecUb1P2nP3/zy37PnvzrFf+z5v6NXi/uV i7/ZX/gH5/0HojRERH/Sofq+tqI/XUVH/dfZZk2Q/Euu7vfH58S9Q8pfF5Xy89HFrxUhwbNhdx1/ zGcPYUcIzzorQZ/0Y9EZ37RgWnyOb/qx+C+NvH+s4pfb3h+r+S2f9WNVv+27fqzub/kw9rlOB5ot UOk49k982Y/V/qpPm/0ME93QKovMqrL/mgelhOrpDzoCv/K0m9A48B9O1hJ3DkTmCLGNnFjngcAU wKzOA/nfH5mRE+s8zBElWCHJiXUe5ogTrYjkxDoPc8aGP6yA5MQ6D3PU/LTikROoeP+g80BOoML9 Z3UeCLfEuJYOtxFre1L/Ol8qWudSSaZ7HDNtD/lmYtXV7a+lG27kIOpGjquuJAiuupLGEZOUg7H2 milMUo4KJOWoHCFMihUaJkP0nBS0385JQQuSFLS4c5JNSxLPbcu8b5It80CyZR5Okvynuc1j+Jbb PAaQzGPA5Zbip7kNZf52zlBmkAxlxp2T8qe51WH9JqnDCpI6rDhJqp/mlpX9W25Z2UGSlR2XW2rk H3nu6YHKHFGc6RF8RjDtRX/3GcG37savic12iN/WF/x5RoD8tCfyf2E09TfG+D9euvJnzupvW+Wc e/8fY5VzpnZ/denKb5rW35wO/fGqqD+m9X9y+mg+QuxhIboyZReu4z2z3Ih6CkFopn51GQa6/eZ8 DekPReaMXf7hMzPcgcSqFoGz4Q7+1yzA+PfOlWH5XImfz19f5kNN7MQ/nCefM3T9Hx+cUxCR/MkN /Zv5pMUOJHY2gl3R6Qz+D3ZFf+yZf9oV/asn+6cr+j/smf+b1nn9wzP/Zp398XKFLEqmeKcvmEgW 5YzIj9eJzRGZqXis02KEK94csV8fA84R/b0u0Rzx3694c1T8vYo3R83fr3hzVP2zijdH3T8ZA/6i MRPtrGNNVyGIW+HEC9GmqxCaLquv06u/JYk/9WUnAWEF6C/dxnXHFEhBWIHUEcIgTI7MXNa38pij gBQU3AAFKjgFN1AFN0CByuT0evCZcpmpJ3OfsZCBCjPo253ELVY2Qx8LmpE5QhhUUCPfFy1R+2Un B0XPQRHPxIxTtIewI4SnV4j/sh2zU4AqP+iT78f1yf3Q2T8/ckcIg6p5BFRJ/jVZRsii2SlB4QQo JMcpnEAVToBCclThfKIKKb9XivekhQqU7oJWIAzXCuxCL3gXhSOEQSnjD5VSzVE8+1kLNSheCFb+ FmflCylB8UJKRwiDYuafKv6HM3FE1+lgto4/VLKHsCOEf9YN+rHojFf+ZqS/J/5L3aIfq/i9Z4lE 1fz+s0Siqv7es0Si6v7vPUv8V6+nJNwt+WsdJfFFFfZ/LaqwR72n/b90UQXxqvjDxRzEXcBv9N+I TyJwwrkLcI0OJ94kwt+Yx//xtBbRwdNMs/o/P3gi6h3+DJ6Qn9b+vz94Qk3rN+edfmyNBCdZfzyi +DPJ+ret8f/gJOu/fqHdDyfi8Bas/lfMUv15YPrfaNpEVxMSVoke+OOnnnNEfs205oj9utecI/rf +trIHDX//V6TkGnhJkBPg+Mzxjm+0yTon/v9lgXCx6+ENv8yrhe6kpTyZ4/S//rhmr/Wnf2KReHk HMGjH8NNbTiSUf6qOeFkP4AsI072Axnl79gSTn4zNJ2bcU3nZnLK3zUknA5GuF0fcLeLkYLy71gR QuC2/10TwumSomSKv4eb5JCipPwfGPn9Dy//JjZ6IrBYE/e+5n/FKqhvon8ePSH/XZ73b5r/ry4M +Ju/xvIveu7+611nYifF5dOV8psKV+z5wj+exmEnIvqDcvkX/rDNb76c/r/jXf9PiOJuDoFfDvhH yyZ+vFDsXzmj9uM5jB+2CUSfL/1amzDL3/2K+J824V/TJuAKiphp/Vne+kum9Wd67PcHenMbdknk f8+X/14HBN2In+z7Hw3FWzz34xls/FdlZjUcxMvxv3zATODlsD8D5tm6/n0D5t9Y+PK/0j//Vz/e /Uez8r96XmLj/a1/OYWt0z+b89d4/1/Vzf95JnEHEigcAvXc/6/Zhb95Nloiogw/uBUz/tIe32f+ Zh/lx91fon2Umccjf/oo/5/0UX68qg9/nSFYKKUjhKdNjPiavh+K/nT27cfiv/Ro7ccqvje9v34g htBKJ6Jqfn+lE1FVf2+lE1F1f3+lE1GV/2ylE1G1v2Ki6PY3O5v/sDX7F4v+Yn+DWKPxm2+ofP9D E3+9IoMut0VfkUGX2f6bfgkXrZnE+yD4jbo9hPH6ILjtt9to4kMEQkMtLeR/sttBNH8/KNK/hoTE J2rxrd//X9SL+4c3/2/06HAbMXv58wMKP83tnx9Q+F+bCv/xUhGCk9N/86edp9c7/VmFRLR3/v/J A8sfeNL/ikcl34aZf6wR+e+yxr//4vX//N8p+Wf5/RvrUGYGkr8oMlORphuQP7/Y//9LRfqzbvlf YFpzSv5/fXHpnN/A+Wem9bd+Uudf4TIJWCbxZx3Enp/jnCz+bKkcNQnqYadNmthj9B9L/syyfyz9 KxPWP9bwq3b+Yy2/Y+4/1vS7Vv9jbX/H+GkJ1KO/NP7dOvBjrf/h62RX/t1Oxz848Y/fWQ4j/faL R2HolFsYqSOEf9a4YKL4E272EHaE8Kyq+ON3lomK/9LDI0wF/q+T2kPYEcK/0+iwzzWmWe/b/v5M PlFVf28mH9/V20PYEcJ/tzHCVOL/RQt7CDtC+J80Sj9W+79UI3/jGT7xwQe+uP+sOXQC9enfsnqH WP5YfjBfjs75G899WIzlYvNcVbgJXHOKb6rMUcM1p8CpogA1FDgV/j9RIUD9TYUAagIC1HPmgPM/ /FjFp79mSD+hM6SfaOesxD37ExXX6b+puE4PKq7T//aFpDB+U5HCCCpSGH/7QlxZvqlwZQEVriy/ fSGybN9UyLKBClm2374Q8kXfVJAvAhXki4hdyFwNv/70gtjKjjlD99l/eYv4MGdOpfvJ0rKf1IRf eer3648wUBXziWb9z584RX7aTBJWQUdAxc/HaP/H/sQppnIlvnH9y/8MABkRUVy+8ZceTdcbVIT4 o0YiP33+44d9wdBzK8SVTzD5r7WsCMIEzFwVybcjia3nnHU8gvziek78H3v69fWc+Of6vRcg8WV/ fz0nvvzfW8+Jr+Pvr+fE1/PP1nPi6/r3z0P/+HEdwdUFP17wT/QPAjJMixF27D/8sxM/ntf9tT87 QdSx//qfnSDq2H/vz04Qdey//2cniDr2/+THdf99L4D9Xk/pP/Ds/yMXgBAR/ckqp3+4luhvrDf4 sQP7dzzh/at2/ZLonwdT/0FvLP29gd5KfIsk3KH9n7Pdf/Dk64/t/ml8f1X0z6z7n1n3WSr/E2fd cRsxn0tg7hv5X6pLf2PpGtF3UH7cOHwr7V8T+7N07b+9cfhbU1vEXvz8pZcYUDHyzXOFkR88hvmV Zeno05fppdPfnr782rJ0wg9dfmVZOuFnLb+yLB19xDKd22+PWH5tWTrhJyu/siyd8AOVX1mWjj5H mc7tt+co/4Jl6f9zfm1G7I9f+zNgI+TXfvZk7vefbf/7/wbL33x0/w8z+y//4TqCE8s/XjBMdGL5 xwuG/8HE8pz52N+r5nPE/6zq/I9Y1fnnB+n/NED/pgaIHnR66p9aiczarlpF492Dk7xcgbPDFMsv zn6iiHydmppCP48d2EWCZvGuIvW82enLzdeIzg5/cHwpMTucu15SaXa421BcZnZ4Gb8LN1667Pt1 s8N9Ucf1Z4cbluZYzw7vlX6tPTv8yVHIdXb40qLTurPDbMt3+s8Od5MfdJ8drjQjkZod5nY19Jod ptGS95gdznBPCZodTlcSsJodTlsgrTc7XMf4yml22DZisdzs8OWAMufZ4UiaPp3Z4SvCenj6Gj2t 8crrqIIh3vWxSZ1eNTv8TCPMdHZYy1QaL79Mm5QFZodP2pbiyVd4ykfODnObPjOaHY6dtpeZLeG7 8Nbvwju/C8d9F97yXXjzd2HyRQOss8PvOT+Izw5vcr2L57Nu21KazQ5v0bqDZ89OXlNRs8Ns3iYO s8PSnGybZof3elXgHb/xu/xt+i4c8114pn59mK5fh0NF8M63Uv4inj0mkeqJzQ6vk040nh0+4l2K Z88z+s1TcPqvGbHh3X8lgw9qs8Ot2pstZodzIwpcZofpbYbXzg4zyA/g1b8ckgy8+k/pzko7O9y6 LG/B7HA3+1XF2WHZFV4RhNILIP+o43LR5cHzX+zrRZbODnvRxePdb0nOzW6zw7b0Cnjle9c8ZOPs cJiiH167WoZQ49W/STZ1PH+iR5uIV15Lo4W9Z4eXaWTg+a8YhverZ4ezDU/h2d+LlcGcs8NOMlx4 /mKz0kqO2eFSkQCu2eEJUQn72WE9ilt4/mLNqm6W2WF1PXu22eFhKzat2WHLpSx4/paZoQ7v/pj7 XsDzj0Iianj2aRRRjBcu5TuBV55vyZzw2ofx7+qHB1Us3vUrRi3FKx+PwId47dU5quOes8Mr+NKo kVlbqVsCnn1OGlaozg4XRMvMWgQD/tRSE688RRWYmGeHTagFV84OX+AYxrsfX6Lo8MKXo+OWzA53 2pTg5b/YKxevfeQSLMfrrx1VcAjBO16bNXh2+JoYF15+Bfha1GeHL3FV4dmjhHcBXn1QWm+Md3+h AhvODr60ycLzH5UhbfNnh/0clcNmhwdjEvD84xW9Sjx/MOOfPk37p5mwcSou3Et/Fu/6ZsIl0+kC 4QoGs9PbZR7g1T8O2iY8/zI/+AGefcyEJ6b1ucRa4F3vkLio3ezwSZ1iPPvxdbqN5z+7aJLxyvOp 4CCef7myON1kdngvwoiX/+uxLnjXa+JRh9ffeKWSj1eeM+W1Jg2X//nORfyz02fCBdPp9JbmfrPT a1YtxbteLmNRydlhp4CNGrPDl4U+xs4OX2Uhx2tPexb1411v6DJ+PPvPUyrC60+EWMrjlV8oiWD0 7PDi9SV8s8Ma7Dmas8Ns5n5rZod9+XTxxgeJepR49nxRCMHrH+3V2kg+O5yvUoE3uZCmYYnnr1ro 4/HOf8z6ic/scM1iJTz7SGbpFp4dLlK5jFe+JBrVeOGJBY/w7nebxABefV0qGyU9O8y44nj47PAN dm352eEVjNvx/E0mmwNeeZdTCeP5//vLxfDaNx6DjXjlaUpZhHe9Pmsk8drj1dpyeOMJKRI3vPpw JWQpXv92xn5Hp+3zNN0p89npM+E1B3Hp+gvf4fWHHNg18I4nFxPFs/+3jnx4/dWF4WZ47Yfa2nDG 2WE9H3O8/rCXgh9eeSzxqMCzlzZpmYDZYTZBVTz9htoMeP4mjtUSz/6alHhsZ4ez2T3w+hPivL54 9pfNvBfPn8ereOKVP4MTN15+rqxTx6sfURzMePZTKyi4YXa43ZFOZXZ4wrcczz6uM9/Ds+dEdla8 +n1erQXvfFJ2pCtmh+mFGfDa+/OmLHj2G+HKhTeeeRrAgDc+VGcXYp8ddrOsUpgdrlsihufPVMmz 8fonDGSyjrPDCVwteO15nP09PH0GTHvxxpOl4lvx+pOZJBzrZ4ebrFLxxsM5xm547SGJJ4LX/x23 bsQb//nq9uK1B/0rtuH50/O2MXj9lfRNUXjjHcalEbKzw+08AXj+llKT2XJ2WGuZD15+TGQX4h1f yUmGp2/LAkU8/xfkegrPXhikW/H6m8y0Bctmh8vsLPD6O0Jm9Hj+YLePG15/kcJj+fLZ4SkCWwmM nXim07//OxDohjqw7yauCan5v7BNoEVBglu/8n1RZJHNzOm3UjDFO03Yw6cjfH73hg4x1Y4puFKm JqAa+2sbuIkq7K9t2MOn4/Rf3SCmj9iGulfj+EPz0GEc2hVHvb6pwXzsiS/LdHjB9Cdr/Lqv6Cfb ivnY2whW8fuwVsIajv/5mf5vbkgq7j6RELhP6Ep8OmzhH+53BgnUinUg7ujp50FIfMM3cdzTKzxx iW+V6hyWAxncU5qVJHNUzF16SOg6qNNw1/HPtPxos04jXlJ/XSruDET8RyWocESc/42Z/N/ayA8S d6rYlTH+ZQczCyxmV3frg8Rv36//3OWPcvj/x0aKX3R/tv9Pt6mVJJtJEHN6BOPyohJSdKmc+fRD LFn4TJkS5yOdGcwsuQJjU9T9rEQQdIJRj20fGBIpKSUZBTkFKRn59w8PZ6zMHPFEfBE3JBgq31r4 DIdPUxgy+yJOCDpxIAd6SBEKChJSEipK0m/PA2ePoTajOzMkEmScQRIdLsoIYWenoyQnRTeiZ9dA guD8TpiMwvJ9eKZPTEYLzhGKybkh6KMYuW/ngkslJyXfoYwvNzO9aA7n2TB9ZTCukMOkqMhoSEkp SMmJ5hD/bDNlhCAqfL+WW3043gcJg30I6HDBzi3DiC/7vZi6Oo+6OpSlxJTMFA8y353bA2SYf+18 f91PGIuieZz11JOYjAXcaU8sj0GYHSxFrOA6RRD8+6OKaps1N/mzK8aXVqHE7Og7mbl2ZAUSfogH 4jr9iV4HH/QFA6kTYByIdnU34E40ZqAryrJ6uwvz6u2VCLpM5CmMw+9movlAJ9zIETJGU4idhAZ5 hQwai06j+06finfOs/Q/269veZSXqSqRSrhhzFLoLVyEoEPmRQD5NQRRwhv//2iTnf1E/tuGm46b mpoZpguDb1mFGINdhoE1SMKnHsQYwqcW2EgQ1KlQ+AyBrogZ1Ez0mwvUczfIE3oEan0+8M0Mq4Gh yMxkyTzQiMbgarUmHBeEebxIZD7RFB4EbyrlP3v7OkX4L4Cgtef5tqzBL0YbGIuTqREx4Yp2dIbt NCQwT6cfQnC34RiCq+b3ENzP5D5FcCPNT8j0cikS3OrIeSS4YSJaPdHZKcVpXdrwic7+O5LgBuU+ JLjGKQI+0XsfT4L+SAOCoK4NnSU4RILzCMdIcEO/AhJcPl7DyRfDJ/rkz2yVMU9YsCSPnpkhj5Zn kEuoZ4iEWbhniMsGN1ceLScfHx4zt5DQAOx4zFPA8eh39HzGbiFuQTyaTkFOfpEIyH47BuK//47m d61/kK+Tj6SrfwgSicYxfKeDRxrBdKBls1xRCjsnmm9DT5cg/2B/9xAeK/8gVx5FSSlEYiWq+5iV ATq7h333ogl7qX2ZBPv+4eITTa3p77tPpk5APNl0ftBP1LWhn6h7++O5/mx/tj/bn+3P9mf7s/3Z /mx/tj/bn+3PNnsjNv5HY0hb7rZkSHIyHjgI43/xL6Xoil6K7+LQMTvX9HgdHYeiq0bQ8S86gYLO ASQguDmAfQjusS06Z4C+FnMMwY2dCxDcWP40ghsTnwPQlSWXEdxY/BaC0z2B4I/xURkYd4e4+fCs dQsJ9w/yDsbGvOhkHvqJTu6hn+hUE/q5nHXm74YjRD8XM+Ku4XfmD+Yx4vKF5gm9TnPPEB83ZGZU jrvembE4z3QsuhILlVGbDqPf0fkPB+NV2g56Fqu0v12pBnyi66qjkeWILsjpwr/liDQggWghMogC ognflsM/bQhJwPGaiCwiB9+k4J8WIIvJyEG6FqCJ4K1S/7P92f5sf7Y/25/tz/Zn+7P92f5sf7Y/ 2/8328z4ExsrI7gxOzqORZ/Xo8/q0ef06NgUHSOj43B0TI4+i0fH+OgYHB3To8/w0bE7uvwafesa Hb+jY3z0jQx0uQe6pAZ9+wV9IwR9awMdK6NvH/EAvAi6cAdB0Ldz0DfMBQEhBF3OgUz/RguCoG9O oKv/0Tca0Leo0Dej0LcH0PUI6FsA6HIL9O1I9I0E9K0JdHyNvq2BvuGHvlWCrvRC30ZAV5ygb0mg 4270bZmVCG6Ejb65gL7dis5voM/d0Td70LcV0Des0Lce0Dcv0Ldz0TdY0LdI0BE5+nY7+oY1Os+A vvmIvu2GvnGEvqWDvkmBvi2EviFrA6Bv8qBvC6JvsKBvhaBvYqJvPzkCTgD6poMLgC6PQd8iQd/U Rt/2QudS0LeE0DdV0LcX0QVS6NIkdMEd+rYQOseCvlWFLm9DF0Chb4CGAuiiKnTxGfqGG/qWE/pm IPr2HPrGCDr+jwHQt/U2A1uAOGArEA9sA7YDOxDc3M1OYBeQCOwG9gBJCPqCIm5OJxnYDxwAUoBU IA04iODmPtKBw8ARIAM4CmQCWQhuDug4kA3kALlAHnACyEdwc0OFQBFQDJQAJ4FS4BSCmzMqA8qB CqASqALOAGcR3FzSeaAaqAEuALXAReASgptjugJcBa4B14EbQB1wE8HNPd0G7gD1QANwF2gEmhDc epf7wAOgGXgItACtQBvwCGgHHgNPENy6mA6gE3gGPAdeAC+BV8Br4A3QBXQDPcBboBfoA94B74F+ YAD4AHwEBoEhBLfeZhj4DIwAo8AXYAwYR3BzaJPAV2R6uSNUfvS9CHQtMRlADlAA6DsTVAA1QAPQ AnQkuPU76I+HzAcYAEaACWAGWIAFACvABiwE2IFFAAcJbm03Ok/IDSwGlpDg1gHxAnwAPyAACAJC gDCwFBABRAExQByQACSBZSToS4RQ/wFpQAaQBeQAeUCBBLe+SAlQBlSAFYAqoAaok+CWn2sAmoAW CW4dkg6gC+gB+sAqwABYDawBDIG1gBFgDJiQ4OYczQBzwAKwBKwAa8AGsAXsgHXAesAecCDBrXdy ApwBF8AVcAPcAfRFC3QJoyfgBXiT4NZF+QJ+gD8QAAQCQUAwEEKCvigL9R8IJ8Gtn4oEooBoYCOw CYgBYoHNwBYA/XG9rSS4dVbbgO3ADiAB2AnsAhKB3cAeIAnYS4Jbj5UM7AcOAClAKpAGHCTBrdNK Bw4DR4AM4CgJ+nIc1H8S3Pqt4yS4lz1z4DMXyANOAPkkuHVdhUARUAyUACeBUuAUCW4tWhlQDlQA lUAVcAY4C5wDzgPVQA1wAagFLgKXgMvAFeAqcA24DtwA6oCbwC3gNnAHqAcagLtAI9AE3APuAw+A ZuAh0AK0Am3AI6AdeAw8AZ4CHUAn8Ax4DrwAXgKvgNfAG6AL6AZ6gLdAL9AHvAPeA/3AAIAuZ/0I DAJDwCdgGPgMjACjwBdgDBgHJoBJAH03CvvLR9Dwo38HiRQgA8gBCgD9/TgqgBqgAWgBOmAeQA/M BxgARoAJYAZYgAUAK8AGLATYgUUAB8AJcAHcwGJS3D3ngU9egA/gBwQAQUAIEAaWAiKAKCAGiAMS gCSwDJAClgPSgAwgC8gB8oACoAgoAcqACrACUAXUAHVgJaABaAJagDagA+gCeoA+sAowAFYDawBD YC1gBBgDJoApYAaYAxaAJWAFWAM2gC1gB6wD1gP2gAPgCDgBzoAL4Aq4Ae6AB7AB8AS8AG/AB/AF /AB/IAAIBIKAYCAECAXCgHAgAogEooBoYCOwCYgBYoHNwBYgDthKintdbxuwHdgBJAA7gV1AIrAb 2EOK/tgM1H9gH5AM7AcOAClAKpAGHAQOAenAYeAIkAEcBTKBLOAYcBzIBnKAXCAPOAHkAwVAIVAE FAMlwEmglBRnP6fhswwoB9DX8yuBKuDMdPo5+DwPVAM1wAWgFrg4nT5JhLrp9Bn+L2/oSxz+0HPk gZ6vH3wGIXjvxf90Y4Mew4wudAxBiToMBNe3QnBdaXAcuZkX/99Aa1jnp20DrVk9wQRdxc8AanMn Am1NRDeWaMAFbL0g+4ewDmB6A5Z9935C2IbgDR9JwLY1yv5togEfA+QYPFLslwf6PxvUAGIA9RPy gWGeAgyHfPASddCmjDwGlLNc8AIpoP9B/TVQv41Y+0FAyQkyK8kK7LmAbM0FL2CvBPZ38oD9D5Cb csExkwlko5wMggY0yAj/9aAkAt3SwYrhc9LcYwG0H9RvJcX+7Uj2M4K37uQC+1L+wFSAciYAUUAI aD/IOFB/mZTwh9kEsTUVGAIlwP5kPnRjFPFADOgDQuEPy3cwGlkOxBnuZdwowA0YgbHPzAVJu+hl N2j8Bm2Pgkt+cmlual4JeEzINxgkBhQCZyYQWw8mr2fB8MVyE8qRL6NgMAIAUEsBAhQAFAAAAAgA W2ViKSyBlpxjpgEAAJQFAA0AAAAAAAAAAQAgALaBAAAAAEdQLTAwMDUwOC5kb2NQSwUGAAAAAAEA AQA7AAAAjqYBAAAA ------_=_NextPart_000_01C11520.524B2E00-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 13:19:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13138 for ; Wed, 25 Jul 2001 13:19:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11742; Wed, 25 Jul 2001 12:47:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11708 for ; Wed, 25 Jul 2001 12:47:00 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09328 for ; Wed, 25 Jul 2001 12:45:37 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PGkbi18440 for ; Wed, 25 Jul 2001 11:46:37 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 11:46:34 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Jul 2001 11:46:34 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 11:46:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] New I-D on compression of SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEUtEoEhgFl/4CnEdWBSQBQi2X+DwAcaBug To: , Cc: , X-OriginalArrivalTime: 25 Jul 2001 16:46:34.0236 (UTC) FILETIME=[5D1193C0:01C11529] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11709 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Hmm. I guess I have to wonder whether the marginal > difference is actually worth much over the base > Huffman encoding and whatever you manage to eek > out with the dictionary across packets. It does > come at the expense of quite a bit of extra shared > state. If you're sold on that, maybe it would be > best of all to just standardize a SIP specific > dictionary :-) That is definitely one thing we need to investigate. To summarize, we have three kinds of data that can be used for compression: 1) static and protocol specific 2) user specific 3) dynamic I'm not sure the difference between using 1) only and using all of them is marginal. At least the user specific part can boost compression efficiency significantly. Below are some results copied from Appendix A of SCRIBE-01. Scenario A: each message is compressed individually Scenario B: 2) is used Scenario C: 1) and 2) are used ================================================================== Table 1. The Average Compression Ratio in Different Scenarios. Scenario A, Scenario B, Scenario C, Compression Ratio Compression Ratio Compression Ratio (Average) (Average) (Average) ------------------------------------------------------------------------ LZSS, 12-bit position, 4-bit 1.31 4.19 4.51 match length LZSS, 11-bit position, 5-bit 1.33 4.87 5.27 match length Linux GZIP compression 1.47 6.23 6.37 ======================================================================= Br, Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 13:33:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14595 for ; Wed, 25 Jul 2001 13:33:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12588; Wed, 25 Jul 2001 13:09:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12559 for ; Wed, 25 Jul 2001 13:09:16 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11641 for ; Wed, 25 Jul 2001 13:08:16 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PGG7G20552 for ; Wed, 25 Jul 2001 19:16:07 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 19:12:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVFP5Z>; Wed, 25 Jul 2001 19:12:07 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E08BB14@esebe014.NOE.Nokia.com> To: sip@ietf.org Cc: christer.holmberg@lmf.ericsson.se, dean.willis@softarmor.com, sean.olson@ericsson.com Subject: RE: [Sip] Discussion: draft-hoeneisen-sip-proxy-supported-00.txt] Date: Wed, 25 Jul 2001 19:12:02 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer! >-----Original Message----- >From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >Sent: 23. July 2001 15:43 >To: bernhard.honeisen@nokia.com >Cc: sip@ietf.org; dean.willis@softarmor.com; sean.olson@ericsson.com >Subject: Re: [Sip] Discussion: >draft-hoeneisen-sip-proxy-supported-00.txt] > > > >Hi, > >My comments... > >In general, I think it is a good idea if proxies somehow can indicate >features that they support. For example, in the discussion about to be >able to CANCEL a specific call-leg I mentined that the UAC could use >that information to decide if to keep or cancel a call-leg etc etc. In >the forward direction it can also be used by proxies to >decided where/if to fork a request (yes, this IS related to >the caller preferences draft). Thanks for your feedback. >My opinion about your proposal (I DID understand the draft - I hope :), >though, is that I think you try to make things too complicated. > >First, why do we need a new header (Proxy-Supported) for this? >Why can't >the Supported header be used, and the proxies can then check the option >tags and add Record-Route parameter(s) if needed. Yes, we were thinking about Supported header as well. However, we found some reasons against _redefining_ the Supported header field: - In a standard we'd need a clear separation of _User_Agent_supported_ and _proxy_supported_ features. This to keep the protocol flexible and logical. - Some features would only need support in the UA, whereas some would require also support by proxies. There would need to be a way to distinguish between the two as is the case with the separation of Require and Proxy-Require. For example 100rel would only be a Supported tag, while s100rel (as we proposed), would be a Proxy-Supported one. >Second (and this is what I think makes it complicated) is the proposal >that the proxies shall remove option tags from the header, and remove >the whole header if there are no more option tags innit... I >don't think >this is necessary. The UAS, and the UAC, simply have to check the >Record-Route headers to check if all proxies support a >specific feature. >Yes, it takes a little more time, but it is more simple. In principle, this would be one way to go. But we were thinking about implementations, which either encrypt or remove the Record-Route header field(s) from the Request and store them locally, as e.g. 3GPP wireless networks do. (This is not nice, but the chances are we have to live with it.) If this is the case, a proxy server would have to evaluate all the rr-entries (including its own) and put the result into its own rr-entry. Such an entry would not look anymore logical, as it is a mixture of "its own" entry and the entries it encrypts or removes. Furthermore, in case, there are many features listed in Proxy-Supported and many proxy servers, the message length increases quite much. Using the approach described in the I-D, after one proxy server removes an entry from Proxy-Supported (or the whole field), the UAS and the following proxy servers do not have to care anymore about the whole issue. This can save some time, if there are many proxy servers in a signalling path. br, Bernie >Regards, > >Christer Holmberg >Ericsson Finland > > > > > > > >bernhard.honeisen@nokia.com wrote: >> >> Hi Sean! >> >> >-----Original Message----- >> >From: ext sean.olson@ericsson.com [mailto:sean.olson@ericsson.com] >> >Sent: 20. July 2001 22:38 >> >To: bernhard.honeisen@nokia.com; sip@ietf.org >> >Cc: dean.willis@softarmor.com >> >Subject: RE: [Sip] Discussion: >> >draft-hoeneisen-sip-proxy-supported-00.txt] >> > >> > >> >With Proxy-Require, it is clear what is intended: >> >you require every proxy on the path to support/use >> >a given extension. With Proxy-Supported, this is >> >more difficult. You are querying for the (optional) >> >support of a feature. >> >> Could you please outline a bit further, what is >> unclear with "Proxy-Supported"? >> >> >What does it mean for 3 out of 4 proxies to support >> >a given feature? >> >> Sorry, but I don't understand this question. >> Could you please describe the issue a bit further. >> >> >The biggest problem I see with this approach is >> >that it doesn't work for the initial request (e.g >> >INVITE). Most features that come to mind need to >> >be invoked on the initial request and possibly >> >subsequent requests for a call. >> >> First of all: "Proxy-Supported" is _not_ intended to >> be a general replacement for "Proxy-Require". >> (I wasn't sure, whether this has been misunderstood.) >> >> With "Proxy-Supported" a proxy server knows latest >> about the feature support in all proxies (which >> remain in the signalling path for subsequent >> requests), when the first (non-100Trying) response >> to the INVITE is arriving at the proxy server. >> For certain features this is early enough. >> >> But the more important cases are, where certain >> features are used only in subsequent requests. >> One example is described in >> http://www.ietf.org/internet-drafts/draft-kiss-sip-s100rel-00.txt, >> which proposes a light way of the provisional >> response acknowledgement. >> >> The main goal of the "Proxy-Supported" proposal is, >> that in those cases, where certain features are used >> only in subsequent requests, an INVITE goes through >> to the UAS even if one (or more) proxy servers do not >> support one (or more) listed feature. >> >> Furthermore it addresses only those proxy servers, >> which remain in the signalling path for subsequent >> requests. >> >> Hope things got more clear now... >> >> br, >> Bernie >> >> > >> >regards, >> >sean olson >> > >> >>-----Original Message----- >> >>From: bernhard.honeisen@nokia.com >[mailto:bernhard.honeisen@nokia.com] >> >>Sent: Friday, July 20, 2001 11:30 AM >> >>To: sip@ietf.org >> >>Cc: dean.willis@softarmor.com >> >>Subject: Re: [Sip] Discussion: >> >>draft-hoeneisen-sip-proxy-supported-00.txt] >> >> >> >> >> >>Hi Dean, >> >> >> >>Dean Willis wrote: >> >>> >> >>>Ok, my turn to be obtuse. What's the difference between the >> >>goal of this >> >>>draft and >> >>> >> >>>draft-ietf-sip-serverfeatures-04.txt? >> >> >> >>The main difference is, that with the Proxy-Supported mechanism >> >>the intermediate _proxy_servers_ are queried for support of certain >> >>features, whereas the draft-ietf-sip-serverfeatures-04 >> >>(Supported header field) describes a mechanism, where the >> >>_User_Agent_ informs about features itself supports. >> >> >> >>This proposal (Proxy-Supported) somehow complements the >Proxy-Require >> >>mechanism. With Proxy-Supported a request goes through even if one >> >>(or more) of the intermediate proxy servers doesn't support an >> >>indicated extension, whereas Proxy-Require results in an error >> >>response in the proxy server. >> >> >> >>Hope this answers your question. >> >> >> >>br, >> >> Bernie >> >> >> >>> >> >>>-- >> >>>Dean >> >> >> >>------------ Original Message -------- >> >>Subject: [Sip] I-D >ACTION:draft-hoeneisen-sip-proxy-supported-00.txt >> >>Date: Mon, 16 Jul 2001 07:01:31 -0400 >> >>From: Internet-Drafts@ietf.org >> >>Reply-To: Internet-Drafts@ietf.org >> >>To: IETF-Announce: ; >> >>CC: sip@ietf.org >> >> >> >>--NextPart >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> >> >> >> >> Title : The SIP Proxy-Supported header field >> >> Author(s) : B. Hoeneisen et al. >> >> Filename : >draft-hoeneisen-sip-proxy-supported-00.txt >> >> Pages : 11 >> >> Date : 13-Jul-01 >> >> >> >>The Session Initiation Protocol (SIP) provides a mechanism that >> >>allows a User Agent Client (UAC) to request that a particular >> >>protocol extension has to be used to process the request. The User >> >>Agent Server (UAS) declines the request if it does not support the >> >>extension. Recently also means have been defined for the User Agent >> >>Server (UAS) to determine which extensions are supported >by the User >> >>Agent Client (UAC). Furthermore there are also means for requiring >> >>proxy servers to understand certain features. >> >> >> >>A URL for this Internet-Draft is: >> >>http://www.ietf.org/internet-drafts/draft-hoeneisen-sip-proxy-s >> >upported-00.t >> >xt >> > >> >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-hoeneisen-sip-proxy-supported-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-hoeneisen-sip-proxy-supported-00.txt". >> > >> >_______________________________________________ >> >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 14:29:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20327 for ; Wed, 25 Jul 2001 14:29:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13564; Wed, 25 Jul 2001 13:43:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13484 for ; Wed, 25 Jul 2001 13:43:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15551 for ; Wed, 25 Jul 2001 13:42:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28947; Wed, 25 Jul 2001 13:42:32 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21447; Wed, 25 Jul 2001 13:42:35 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Jul 2001 13:42:33 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465840@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Price, Richard'" Cc: "'sip@ietf.org'" Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 13:42:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Megaco is a protocol with binary and text encodings. The binary is BER encoded, and there are exactly equivalent ASN.1 and ABNF descriptions of the encodings to match the protocol text. The results we have so far suggest that message length of binary encoding is larger than the text encoding for the same message. This isn't speculation, it's what we measure when you take an implementation that has both encodings and look at the message lengths. If you simply use binary encodings for the basic syntactic constructs, you will get negative compression. The compression available comes from dealing with the contents of the values, not the basic method/header constructs. Brian > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, July 25, 2001 11:58 AM > To: 'Christer Holmberg'; Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Hi, > > Is compression so different from binary encoding? > > Our own EPIC scheme uses the BNF description of a protocol to > "learn" a > set of binary encodings for the protocol. The compressor then replaces > each text string with its equivalent binary encoding. > > It is feasible to write a SIP implementation that uses these binary > encodings directly, missing out the text-based version of the message > altogether. This is not a change to the core protocol, but rather a > combined SIP stack/SIP compressor. > > Normally this would be a big amount of effort for very little gain. > However it certainly solves the concerns about processing requirements > (as it doesn't have any!) > > Regards, > > Richard P > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, July 25, 2001 3:26 PM > To: Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [rohc] Re: [Sip] New I-D on compression of SIP > > > > Hi, > > A few comments from me. > > First, my personal opinion about the binary talk: let's skip > the binary > talk. If we start talking about it, we will argue about it > for at least > 6 months (I think the people who have been involved in the MEGACO work > know what I'm talking about...) Then, IF we would decide to also go > binary, experience (read: MEGACO) has shown that it's not that easy to > define text- and binary rules that "match" 100%. Ok, SIP > would probably > be a little easier than Megaco, since we don't have wildcard > values etc, > but still. Then we would also have the encoding negotiation > problem, and > the issue about which nodes MUST/SHALL/SHOULD support what... > And, which > has been mentioned also by others, that we really don't transport that > much information in SIP, so would the gain (not very much, I'd say) be > worth the pain (very much, I'd say)? > > Compression is more "flexible". For most > networks/architectures I don't > think it will provide very much, but if peope want to use it they are > free to do so - but it would not affect the core protocol. > > Then, if we assume that we need compression, we have the other > questions, which I think are more important to discuss: > > 1. Hop-to-hop vs end-to-end > > 2. Do we compress the whole message, or only parts of it (the message > body, for example) > > 3. Compression negotiation > > a) Do we use an external negotiation mechanism, and > negotiate before > we start the SIP session. Since the proxies in many cases > also must be involved in this negotiation we would probably need some > kind of > "centralized" function for this. > > b) Do we send the initial INVITE uncompressed (or partly > compressed) > with a Supported/Require/Proxy-Require > header listing the supported compression algorithms. > And again, if > the proxies must support the compression, there must be a > way for them to indicate it (can be done for example either by > using Proxy-Require, or some Record-Route parameter) > > c) Do we use "manual" configuration, either by hand or by > using some > of the SIP extensions that have been defined for remote > configuration. > > > My thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Michel de Boer [mailto:michelboer@lucent.com] > > > Sent: Thursday, July 19, 2001 3:54 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > > > > Jonathan, > > > > > > You state that one of the ways to achieve message size > reduction is to > > > define a binary encoding, but that this introduces > interoperability > > > problems. > > > > > > How can a compression scheme based on dynamically constructed > > > codebooks > > > be simpler? > > > > Simpler, perhaps not (although if you're using PER or BER, > its not clear to > > me that this is simpler, codewise). But, it totally breaks > compatibility > > with the existing protocol. By pushing this into a > transport problem, it is > > isolated to the two entities that need to worry about it. > > > > > In my opinion this approach is more prone to > > > interoperability > > > issues. > > > > Thats not clear at all. Either way, we would require new code in > > implementations. For a new binary coding, we would be back > to square 1, so > > that everyone would have to work out the kinks in their > encoder/decoders for > > every element in the syntax. However, with a shim, we > leverage existing, > > mature parsers and generators. We add a layer that is not > specific to SIP, > > so it has no syntax or anything else to get wrong. Its > defined by a fairly > > simple set of state machines, which should not be that hard > to get correct. > > I would argue its easier to get that right than it is to > get a totally new > > encoding of SIP right. > > > > > Codebooks can get out of sync. > > > > Yes, and that does need to be handled in the protocol. > > > > > As codebooks are specific to a sender- > > > receiver pair, an entity communicating with multiple other > > > entities, i.e. > > > a proxy talking to many UA's must manage multiple codebooks. > > > > Well, the problem at hand is really a wireless phone > talking to its local > > outbound proxy. THus, the phone has only one relationship, > and the proxy has > > one with each phone it communicates with. This pushes the burden of > > compression to the elements that benefit the most from it. > From this point > > onwards, normal SIP would be used, and so its compatible > with existing > > proxies and UAs. > > > > > > > > For trouble shooting one might want to monitor a network > interface and > > > analyze SIP messages coming in. It's impossible to read a > compressed > > > message. > > > > The output of the decompressor would need to be monitored. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 14:42:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21684 for ; Wed, 25 Jul 2001 14:42:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13955; Wed, 25 Jul 2001 13:58:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13893 for ; Wed, 25 Jul 2001 13:58:30 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16969 for ; Wed, 25 Jul 2001 13:57:30 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PHAQI13520 for ; Wed, 25 Jul 2001 12:10:26 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 12:09:38 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Jul 2001 12:09:38 -0500 content-class: urn:content-classes:message Date: Wed, 25 Jul 2001 12:09:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: SCRIBE-01 (signaling compression) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEVLNRvK39ds4DpEdWaKQAQpIbXLw== To: Cc: X-OriginalArrivalTime: 25 Jul 2001 17:09:38.0494 (UTC) FILETIME=[962695E0:01C1152C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA13894 Subject: [Sip] SCRIBE-01 (signaling compression) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello, I just found out that the new version of SCRIBE I-D has been put into the IETF repository, though no announcement appeared on the mailing list. http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-01.txt Please take a look and it may help the current discussion on this issue. Br, Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 16:06:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01429 for ; Wed, 25 Jul 2001 16:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16925; Wed, 25 Jul 2001 15:41:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16896 for ; Wed, 25 Jul 2001 15:41:55 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28413 for ; Wed, 25 Jul 2001 15:40:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6PJfJki006095; Wed, 25 Jul 2001 15:41:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:41:52 -0400 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! Date: Wed, 25 Jul 2001 15:41:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Tuesday, July 24, 2001 6:16 AM > To: 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: RE: [Sip] update to nat traversal draft! > > > Hi Jonathan, > > Very interesting draft. > > I have a couple of comments. It seems that in section 4.2 Contact > Translation (and maybe I am being thick...) that the proxy Y > is not required > to Record-Route the call: > > "In order for this connection to be used for re-INVITEs or > BYEs, the > proxy needs to record route." > > Thus when Joe calls Bob and Proxy Y does not Record-Route > then the Joe would > send the ACK directly to the Translated Contact in the 200 OK > from Bob. > However this is not going to work for a symmetric NAT. > Shouldn't there be > some sort of requirement that Proxy Y must Record-Route > unless Bob's NAT is > known to be a cone NAT (eg indicated in Translate header)? Am > I completely > missing something here? No, you are correct. The bit about record-routing is unchanged from the -01 version, where this was needed. Now, if the proxy is contacting a user behind a full-cone nat, it isn't needed. > > Also for the symmetric RTP section: I think would be much > more interoperable > if we define symmetric RTP as being indicated when transport > profile RTP/AVP > is used _AND_ the a=direction parameter is present (rather than a new > transport profile "RTP/UDP"). In this manner a UA supporting > symmetric RTP > and a plain vanilla UA can still communicate when NAT is not involved. > Obviously it is much cleaner that a separate transport > profile is used but I > believe it will hamper the deployment of your suggestion. Oops! My bad. I meant to say RTP/AVP, not RTP/UDP. My apologies. It is supposed to be interoperable in this way as you have described. The UAC sends an INVITE, and lists RTP/AVP with the port and IP address it wishes to receive on. If its supporting symmetric RTP, it includes a direction. Lets say it wishes to be active. So, it includes: a=direction:active And it is still prepared to receive media on the IP/port it listed. Lets say this hits a UAS which doesn't support symmetric RTP. In this case, the SDP in the response doesn't include a direction attribute, and if there is no nat, the UAC gets media on the IP and port it placed into the INVITE. Now, if the UAS does support symmetric RTP, it returns in the response the IP and port, with RTP/AVP as the transport, and then indicates a direction of passive. When the UAC sees this, it begins sending RTP to the IP/port in the 200 OK, and then prepares to receive media on the socket it sent RTP from. > > In the above suggestion, a UA not understanding symmetric RTP (ie, not > understanding the direction attribute) will setup a call as normal. > Additionally, the UA supporting symmetric RTP can detect that > the peer does > not support the extension by the lack of the a=direction > attribute in the > SDP answer. Simple! Right! And that was the whole idea, but I fouled it up by putting UDP instead of AVP into the example SDP. Thanks for pointing it out, Robert. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, July 24, 2001 8:51 AM > > To: 'sip@ietf.org' > > Subject: [Sip] update to nat traversal draft! > > > > > > Folks, > > > > I've submitted an update to draft-rosenberg-sip-entfw, > which discusses > > traversal of SIP through enterprise and residential nats. > > There are a LOT of > > differences between this version (-02) and the previous. > Specifically: > > > > 1. SIP "via port" parameter defined to allow SIP-UDP traversal > > 2. Translate header replaces Contact cookie > > 3. NAT detection and allocation protocol is defined, and used > > between the UA > > and some elements deployed in the SIP provider network. This > > is effectively > > midcom without midcom compliant nats. It vastly simplifies > > things and also > > solves the case where both sides are behind a symmetric nat. > > 4. lots more > > > > Until the draft appears in the archives, you can pick up a copy at: > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt > > > > Thanks, > > Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 16:31:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04265 for ; Wed, 25 Jul 2001 16:31:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17881; Wed, 25 Jul 2001 16:07:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17854 for ; Wed, 25 Jul 2001 16:07:44 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01496 for ; Wed, 25 Jul 2001 16:06:43 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f6PK7kE02343; Wed, 25 Jul 2001 15:07:46 -0500 Message-ID: <006c01c11545$54ebc9b0$55fa403f@blazer> From: "Dean Willis" To: "Price, Richard" , "'Christer Holmberg'" , "Jonathan Rosenberg" Cc: "'Michel de Boer'" , , References: <76C92FBBFB58D411AE760090271ED4186F9DF7@RSYS002A> Subject: Re: [rohc] Re: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 15:06:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems like failure of this approach is assured if a new token (one not in the BNF) is encountered. SIP has lots of those. In the "compression" systems, the new token is still transported correctly, but may not be optimally compressed. -- Dean ----- Original Message ----- From: "Price, Richard" To: "'Christer Holmberg'" ; "Jonathan Rosenberg" Cc: "'Michel de Boer'" ; ; Sent: Wednesday, July 25, 2001 10:58 AM Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > Hi, > > Is compression so different from binary encoding? > > Our own EPIC scheme uses the BNF description of a protocol to "learn" a > set of binary encodings for the protocol. The compressor then replaces > each text string with its equivalent binary encoding. > > It is feasible to write a SIP implementation that uses these binary > encodings directly, missing out the text-based version of the message > altogether. This is not a change to the core protocol, but rather a > combined SIP stack/SIP compressor. > > Normally this would be a big amount of effort for very little gain. > However it certainly solves the concerns about processing requirements > (as it doesn't have any!) > > Regards, > > Richard P > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, July 25, 2001 3:26 PM > To: Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [rohc] Re: [Sip] New I-D on compression of SIP > > > > Hi, > > A few comments from me. > > First, my personal opinion about the binary talk: let's skip the binary > talk. If we start talking about it, we will argue about it for at least > 6 months (I think the people who have been involved in the MEGACO work > know what I'm talking about...) Then, IF we would decide to also go > binary, experience (read: MEGACO) has shown that it's not that easy to > define text- and binary rules that "match" 100%. Ok, SIP would probably > be a little easier than Megaco, since we don't have wildcard values etc, > but still. Then we would also have the encoding negotiation problem, and > the issue about which nodes MUST/SHALL/SHOULD support what... And, which > has been mentioned also by others, that we really don't transport that > much information in SIP, so would the gain (not very much, I'd say) be > worth the pain (very much, I'd say)? > > Compression is more "flexible". For most networks/architectures I don't > think it will provide very much, but if peope want to use it they are > free to do so - but it would not affect the core protocol. > > Then, if we assume that we need compression, we have the other > questions, which I think are more important to discuss: > > 1. Hop-to-hop vs end-to-end > > 2. Do we compress the whole message, or only parts of it (the message > body, for example) > > 3. Compression negotiation > > a) Do we use an external negotiation mechanism, and negotiate before > we start the SIP session. Since the proxies in many cases > also must be involved in this negotiation we would probably need some > kind of > "centralized" function for this. > > b) Do we send the initial INVITE uncompressed (or partly compressed) > with a Supported/Require/Proxy-Require > header listing the supported compression algorithms. And again, if > the proxies must support the compression, there must be a > way for them to indicate it (can be done for example either by > using Proxy-Require, or some Record-Route parameter) > > c) Do we use "manual" configuration, either by hand or by using some > of the SIP extensions that have been defined for remote > configuration. > > > My thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Michel de Boer [mailto:michelboer@lucent.com] > > > Sent: Thursday, July 19, 2001 3:54 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > > > > Jonathan, > > > > > > You state that one of the ways to achieve message size reduction is to > > > define a binary encoding, but that this introduces interoperability > > > problems. > > > > > > How can a compression scheme based on dynamically constructed > > > codebooks > > > be simpler? > > > > Simpler, perhaps not (although if you're using PER or BER, its not clear to > > me that this is simpler, codewise). But, it totally breaks compatibility > > with the existing protocol. By pushing this into a transport problem, it is > > isolated to the two entities that need to worry about it. > > > > > In my opinion this approach is more prone to > > > interoperability > > > issues. > > > > Thats not clear at all. Either way, we would require new code in > > implementations. For a new binary coding, we would be back to square 1, so > > that everyone would have to work out the kinks in their encoder/decoders for > > every element in the syntax. However, with a shim, we leverage existing, > > mature parsers and generators. We add a layer that is not specific to SIP, > > so it has no syntax or anything else to get wrong. Its defined by a fairly > > simple set of state machines, which should not be that hard to get correct. > > I would argue its easier to get that right than it is to get a totally new > > encoding of SIP right. > > > > > Codebooks can get out of sync. > > > > Yes, and that does need to be handled in the protocol. > > > > > As codebooks are specific to a sender- > > > receiver pair, an entity communicating with multiple other > > > entities, i.e. > > > a proxy talking to many UA's must manage multiple codebooks. > > > > Well, the problem at hand is really a wireless phone talking to its local > > outbound proxy. THus, the phone has only one relationship, and the proxy has > > one with each phone it communicates with. This pushes the burden of > > compression to the elements that benefit the most from it. From this point > > onwards, normal SIP would be used, and so its compatible with existing > > proxies and UAs. > > > > > > > > For trouble shooting one might want to monitor a network interface and > > > analyze SIP messages coming in. It's impossible to read a compressed > > > message. > > > > The output of the decompressor would need to be monitored. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Jul 25 16:52:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06732 for ; Wed, 25 Jul 2001 16:52:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17750; Wed, 25 Jul 2001 16:02:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17722 for ; Wed, 25 Jul 2001 16:02:37 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01028 for ; Wed, 25 Jul 2001 16:01:37 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f6PK2tE02312 for ; Wed, 25 Jul 2001 15:02:55 -0500 Message-ID: <004d01c11544$a6e32cf0$55fa403f@blazer> From: "Dean Willis" To: References: <034272783A93C944A6CA1D87FBF6F49E107EAE@esebe014.NOE.Nokia.com> <02f801c11522$065a3110$710410ac@effnet.com> Subject: Is that hop-by-hop or end-to-end? (Was Re: [rohc] RE: [Sip] SIP Compression) Date: Wed, 25 Jul 2001 15:01:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The problem is that hop-by-hop and end-to-end mean different things to different people. There are SIP hops and IP hops. IP hops are between IP devices (hosts and routers) , and a stop at an application node like a SIP proxy represents the start of an entirely seperate IP route. SIP hops are between SIP nodes like UAs and proxies. So for example: UA->rtr->rtr->rtr->proxy is 4 IP hops and one SIP hop. There's no reason for the routers to compress/decompress SIP information. They do need to decompress IP headers to do IP routing, but they don't look at the SIP stuff at all. UA->rtr->proxy->rtr->ua is two SIP hops, each with two IP hops. Here, the proxy in the middle needs to decompress the SIP in order to make a SIP-level routing decision.. When an IP person says end-to-end, they mean the source UA compresses, the proxy decompresses and recompresses, and the destination UA decompresses. A SIP person says end-to-end, they mean the source UA compresses and the destination UA decompresses. That only works if there is no proxy in the middle. So, the SIP-specific compression protocols under discussion (like Rosenburg's) tend to be hop-by-hop at a SIP level, and end-to-end at an IP level. -- Dean ----- Original Message ----- From: "Aniruddha Kulkarni" To: ; Cc: ; ; Sent: Wednesday, July 25, 2001 10:54 AM Subject: Re: [rohc] RE: [Sip] SIP Compression > end-to-end compression seems more efficient as it doesn't depend on link > characterictics of link between each hop. A payload compression scheme > should be designed considering worst link characteristics that a packet may > encounter in it's path.. cellular link is a good example for this between > two hops. The gain obtained on those poor links can be carried over to > better links without any loss. > end-to-end scheme becomes more attractive when two disjoint hop-to-hop links > are of poor characteristics. > The processing time on hops could be a issue in hop-to-hop schemes. An > intermediate hop serving multiple connections, if under load, could affect > all connected entities.e.g. a base station serving multiple phones. > (Particularly in payload compression schemes an intermediate hop need not > decompress at all..) > In end-to-end scheme, there is no such problem, resulting in a better > overall performance. > > > Definitely, this is not applicable in header compression schemes but for > completely different reason, header required for routing. There hop-to-hop > is the best scheme regardless of processing time issue on base station or > any other benefits of end-to-end compression. > > ---Aniruddha > > ----- Original Message ----- > From: > To: ; > Cc: ; ; > Sent: Wednesday, July 25, 2001 4:26 PM > Subject: [rohc] RE: [Sip] SIP Compression > > > > Hi, > > > > > -----Original Message----- > > > From: ext Suheel Hussain [mailto:ssh@cisco.com] > > > Sent: 25 July, 2001 15:46 > > > To: Aniruddha Kulkarni > > > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > > > Subject: Re: [Sip] SIP Compression > > > > > > > > > I have nagging issue with SIP compression -- compressing and > > > decompressing on > > > each proxy server is going to slow down call processing on > > > large networks. > > > IMO, it (compression) is not scalable. > > > > > > > Well, obviously you would only compress/decompress where it makes sense. > > This would usually be between UA in a cellular host and its outbound > proxy. > > There you may only have a few kilobits of capacity available (and during > the > > actual voice call even less), so it is feasible to trade between > > transmission delay and processing complexity. So it is a classical > > optimization problem with two constraints. Between proxies, where you > > (should) have enoungh capacity, compression will probably just slow down > > things. > > > > > Even end-to-end can be a problem if either (or both) UAS and > > > UAC service a > > > number of attached SIP-unaware systems. For instance a > > > SIP-PSTN gateway. > > > > > > > Again, using compression between gateways/controllers probably does not > make > > sense as the capacity limitations shouldn't be a problem. > > > > Regards, > > Markus > > > > > Aniruddha Kulkarni wrote: > > > > > > > If one has high latency link then nothing can be done about > > > it. Compression > > > > is not a solution for that. > > > > If one has low bandwidth link and large data to send then > > > Compression can be > > > > the solution. > > > > SIP messages take up only small portion of the available > > > bandwidth (even on > > > > Cellular links..). Then why use compression for SIP messages? Well.. > > > > cellular links have high BER, in this situation it is > > > advisable to have > > > > smaller packets to reduce error probability.. that is why > > > use compression. > > > > ... correct? > > > > > > > > Still large number of connections to internet are over > > > telephone modem links > > > > with low bandwidth, comparable with latest cellular links. > > > Isn't it useful > > > > to have end-to-end SIP message compression in that situation? > > > > > > > > How much the SIP compression schemes are dependant on RoHC? > > > Could they have > > > > in-built mechanism for configuration negotiation? Should > > > they demand this > > > > facility from lower layers? It seems to me that these > > > schemes work more at > > > > application level and should have configuration negotiation > > > at that level > > > > only. That way they could be easily extened for use on > > > end-to-end rather > > > > than limiting them to hop-to-hop (by depending on RoHC). > > > > > > > > ---Aniruddha > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: "'Aniruddha Kulkarni'" ; > > > > ; > > > > Sent: Tuesday, July 24, 2001 6:27 PM > > > > Subject: RE: [Sip] SIP Compression > > > > > > > > > > > > > > > >> SIP is not intended to transport large amounts of information. > > > >> That plus the ratio of bandwidth used by signalling vs. > > > >> the bandwidth used by the media, means that signalling compression > > > >> for SIP is not in general a problem. It only really becomes a > > > >> problem on low bandwidth, high latency *links* such as a cellular > > > >> link where sometimes every byte counts. > > > >> > > > >> In short, I believe signalling compression is a hop-by-hop > > > >> problem and not an end-to-end one. A hop-by-hop solution seems > > > >> appropriate in this case. > > > >> > > > >> It should also be noted that you can always apply gzip compression > > > >> to the MIME body of a SIP message to achieve some end-to-end > > > >> compression. IMHO, this is not needed. > > > >> > > > >> I believe the compression techniques that have been > > > >> described so far (ROGER, SCRIBE, EPIC, etc.) are > > > >> fairly generic and would work well on a variety of > > > >> link types. Some have been tailored with cellular > > > >> in mind. > > > >> > > > >> Hopefully this addresses your concerns, > > > >> Sean Olson > > > >> Ericsson Inc. > > > >> > > > >> -----Original Message----- > > > >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > > >> Sent: Tuesday, July 24, 2001 8:30 AM > > > >> To: rohc@cdt.luth.se; sip@ietf.org > > > >> Subject: [Sip] SIP Compression > > > >> > > > >> RoHC works hop-to-hop, not end-to-end when there are > > > multiple hops between > > > > > > > > two ends. > > > > > > > >> Does SIP Compression mechanisms also have this constraint? > > > If yes, why? > > > >> Are those designed to work only on cellular link between > > > mobile terminal > > > > > > > > and > > > > > > > >> fixed end of cellular link (hop-to-hop) ? Why those > > > mechanisms are not > > > > > > > > designed > > > > > > > >> for end-to-end compression? > > > >> (reduce large payloads ,whatever be the link characteristics...) > > > >> > > > >> ---Aniruddha > > > >> > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > -- > > > > > > Suheel Hussain > > > ssh@cisco.com > > > Cisco Work # (919) 392-2312 > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 11:20:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17428 for ; Thu, 26 Jul 2001 11:20:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21637; Thu, 26 Jul 2001 10:43:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21605 for ; Thu, 26 Jul 2001 10:43:48 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13593 for ; Thu, 26 Jul 2001 10:42:48 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6Q8jpN28485 for ; Thu, 26 Jul 2001 10:45:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6Q8jo524093 for ; Thu, 26 Jul 2001 11:45:50 +0300 (EET DST) Message-ID: <3B5FD8BC.B3DC7AC7@lmf.ericsson.se> Date: Thu, 26 Jul 2001 11:45:48 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------BE5EC5D27B37EEB62028EB3A" Subject: [Sip] Response code for bad SIP version Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------BE5EC5D27B37EEB62028EB3A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just a small detail/cosmetic/clarification question: The 505 SIP Version not supported, which belongs to the Server Error category, response code is used when a request with a non-supported SIP version (other than SIP/2.0, that is) is received. The ABNF grammar (bis-04, page 27), however, allows ONLY "SIP/2.0". If something else is received, isn't it then, from a grammar point of view, a Syntax Error (ie a 4xx response code should be used)? So, if we want to use 505, shouldn't the grammar look something like: SIP-Version = "SIP/2.0" | other-version other-version = "SIP/" 1*DIGIT "." 1*DIGIT ...or something similar. Regards, Christer Holmberg Ericsson Finland --------------BE5EC5D27B37EEB62028EB3A Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------BE5EC5D27B37EEB62028EB3A-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 11:20:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17442 for ; Thu, 26 Jul 2001 11:20:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19548; Thu, 26 Jul 2001 09:09:26 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id JAA19518 for ; Thu, 26 Jul 2001 09:09:21 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:08:26 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DF9@RSYS002A> From: "Price, Richard" To: "'Rosen, Brian'" Cc: "'sip@ietf.org'" Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Thu, 26 Jul 2001 14:08:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, The compression ratio depends on how the binary encodings are obtained. BER is not designed for efficiency and will most likely produce binary encodings that are even longer than their text equivalents. In contrast, schemes like EPIC and Lempel-Ziv are designed specifically to convert text strings into shorter binary equivalents. Both schemes use Huffman compression for this task, which on its own would get a compression ratio of about 1.2:1. Compression is further improved by introducing a new binary encoding that means "text is same as a previous text string". It's debatable whether this should be called "binary encoding" or not. However I stick by my original point (that you can implement a combined SIP stack/SIP compressor to lower the overall processing requirements). Out of curiosity, what was the motivation for doing MEGACO as both text and binary? Regards, Richard P -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, July 25, 2001 6:43 PM To: Price, Richard Cc: 'sip@ietf.org' Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Megaco is a protocol with binary and text encodings. The binary is BER encoded, and there are exactly equivalent ASN.1 and ABNF descriptions of the encodings to match the protocol text. The results we have so far suggest that message length of binary encoding is larger than the text encoding for the same message. This isn't speculation, it's what we measure when you take an implementation that has both encodings and look at the message lengths. If you simply use binary encodings for the basic syntactic constructs, you will get negative compression. The compression available comes from dealing with the contents of the values, not the basic method/header constructs. Brian > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, July 25, 2001 11:58 AM > To: 'Christer Holmberg'; Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Hi, > > Is compression so different from binary encoding? > > Our own EPIC scheme uses the BNF description of a protocol to > "learn" a > set of binary encodings for the protocol. The compressor then replaces > each text string with its equivalent binary encoding. > > It is feasible to write a SIP implementation that uses these binary > encodings directly, missing out the text-based version of the message > altogether. This is not a change to the core protocol, but rather a > combined SIP stack/SIP compressor. > > Normally this would be a big amount of effort for very little gain. > However it certainly solves the concerns about processing requirements > (as it doesn't have any!) > > Regards, > > Richard P > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, July 25, 2001 3:26 PM > To: Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [rohc] Re: [Sip] New I-D on compression of SIP > > > > Hi, > > A few comments from me. > > First, my personal opinion about the binary talk: let's skip > the binary > talk. If we start talking about it, we will argue about it > for at least > 6 months (I think the people who have been involved in the MEGACO work > know what I'm talking about...) Then, IF we would decide to also go > binary, experience (read: MEGACO) has shown that it's not that easy to > define text- and binary rules that "match" 100%. Ok, SIP > would probably > be a little easier than Megaco, since we don't have wildcard > values etc, > but still. Then we would also have the encoding negotiation > problem, and > the issue about which nodes MUST/SHALL/SHOULD support what... > And, which > has been mentioned also by others, that we really don't transport that > much information in SIP, so would the gain (not very much, I'd say) be > worth the pain (very much, I'd say)? > > Compression is more "flexible". For most > networks/architectures I don't > think it will provide very much, but if peope want to use it they are > free to do so - but it would not affect the core protocol. > > Then, if we assume that we need compression, we have the other > questions, which I think are more important to discuss: > > 1. Hop-to-hop vs end-to-end > > 2. Do we compress the whole message, or only parts of it (the message > body, for example) > > 3. Compression negotiation > > a) Do we use an external negotiation mechanism, and > negotiate before > we start the SIP session. Since the proxies in many cases > also must be involved in this negotiation we would probably need some > kind of > "centralized" function for this. > > b) Do we send the initial INVITE uncompressed (or partly > compressed) > with a Supported/Require/Proxy-Require > header listing the supported compression algorithms. > And again, if > the proxies must support the compression, there must be a > way for them to indicate it (can be done for example either by > using Proxy-Require, or some Record-Route parameter) > > c) Do we use "manual" configuration, either by hand or by > using some > of the SIP extensions that have been defined for remote > configuration. > > > My thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Michel de Boer [mailto:michelboer@lucent.com] > > > Sent: Thursday, July 19, 2001 3:54 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > > > > Jonathan, > > > > > > You state that one of the ways to achieve message size > reduction is to > > > define a binary encoding, but that this introduces > interoperability > > > problems. > > > > > > How can a compression scheme based on dynamically constructed > > > codebooks > > > be simpler? > > > > Simpler, perhaps not (although if you're using PER or BER, > its not clear to > > me that this is simpler, codewise). But, it totally breaks > compatibility > > with the existing protocol. By pushing this into a > transport problem, it is > > isolated to the two entities that need to worry about it. > > > > > In my opinion this approach is more prone to > > > interoperability > > > issues. > > > > Thats not clear at all. Either way, we would require new code in > > implementations. For a new binary coding, we would be back > to square 1, so > > that everyone would have to work out the kinks in their > encoder/decoders for > > every element in the syntax. However, with a shim, we > leverage existing, > > mature parsers and generators. We add a layer that is not > specific to SIP, > > so it has no syntax or anything else to get wrong. Its > defined by a fairly > > simple set of state machines, which should not be that hard > to get correct. > > I would argue its easier to get that right than it is to > get a totally new > > encoding of SIP right. > > > > > Codebooks can get out of sync. > > > > Yes, and that does need to be handled in the protocol. > > > > > As codebooks are specific to a sender- > > > receiver pair, an entity communicating with multiple other > > > entities, i.e. > > > a proxy talking to many UA's must manage multiple codebooks. > > > > Well, the problem at hand is really a wireless phone > talking to its local > > outbound proxy. THus, the phone has only one relationship, > and the proxy has > > one with each phone it communicates with. This pushes the burden of > > compression to the elements that benefit the most from it. > From this point > > onwards, normal SIP would be used, and so its compatible > with existing > > proxies and UAs. > > > > > > > > For trouble shooting one might want to monitor a network > interface and > > > analyze SIP messages coming in. It's impossible to read a > compressed > > > message. > > > > The output of the decompressor would need to be monitored. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 11:29:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17863 for ; Thu, 26 Jul 2001 11:29:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15046; Thu, 26 Jul 2001 05:19:06 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id FAA14958 for ; Thu, 26 Jul 2001 05:19:00 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:17:37 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DF8@RSYS002A> From: "Price, Richard" To: "'Dean Willis'" , "'Christer Holmberg'" , Jonathan Rosenberg Cc: "'Michel de Boer'" , sip@ietf.org, rohc@cdt.luth.se Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Thu, 26 Jul 2001 10:17:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, We solved the "new token" problem by having a binary version of every ASCII character. If there is a binary version of the whole token then we send that, otherwise we send the binary versions of each individual character. Regards, Richard P -----Original Message----- From: Dean Willis [mailto:dwillis@greycouncil.com] Sent: Wednesday, July 25, 2001 9:07 PM To: Price, Richard; 'Christer Holmberg'; Jonathan Rosenberg Cc: 'Michel de Boer'; sip@ietf.org; rohc@cdt.luth.se Subject: Re: [rohc] Re: [Sip] New I-D on compression of SIP It seems like failure of this approach is assured if a new token (one not in the BNF) is encountered. SIP has lots of those. In the "compression" systems, the new token is still transported correctly, but may not be optimally compressed. -- Dean ----- Original Message ----- From: "Price, Richard" To: "'Christer Holmberg'" ; "Jonathan Rosenberg" Cc: "'Michel de Boer'" ; ; Sent: Wednesday, July 25, 2001 10:58 AM Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > Hi, > > Is compression so different from binary encoding? > > Our own EPIC scheme uses the BNF description of a protocol to "learn" a > set of binary encodings for the protocol. The compressor then replaces > each text string with its equivalent binary encoding. > > It is feasible to write a SIP implementation that uses these binary > encodings directly, missing out the text-based version of the message > altogether. This is not a change to the core protocol, but rather a > combined SIP stack/SIP compressor. > > Normally this would be a big amount of effort for very little gain. > However it certainly solves the concerns about processing requirements > (as it doesn't have any!) > > Regards, > > Richard P > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, July 25, 2001 3:26 PM > To: Jonathan Rosenberg > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: [rohc] Re: [Sip] New I-D on compression of SIP > > > > Hi, > > A few comments from me. > > First, my personal opinion about the binary talk: let's skip the binary > talk. If we start talking about it, we will argue about it for at least > 6 months (I think the people who have been involved in the MEGACO work > know what I'm talking about...) Then, IF we would decide to also go > binary, experience (read: MEGACO) has shown that it's not that easy to > define text- and binary rules that "match" 100%. Ok, SIP would probably > be a little easier than Megaco, since we don't have wildcard values etc, > but still. Then we would also have the encoding negotiation problem, and > the issue about which nodes MUST/SHALL/SHOULD support what... And, which > has been mentioned also by others, that we really don't transport that > much information in SIP, so would the gain (not very much, I'd say) be > worth the pain (very much, I'd say)? > > Compression is more "flexible". For most networks/architectures I don't > think it will provide very much, but if peope want to use it they are > free to do so - but it would not affect the core protocol. > > Then, if we assume that we need compression, we have the other > questions, which I think are more important to discuss: > > 1. Hop-to-hop vs end-to-end > > 2. Do we compress the whole message, or only parts of it (the message > body, for example) > > 3. Compression negotiation > > a) Do we use an external negotiation mechanism, and negotiate before > we start the SIP session. Since the proxies in many cases > also must be involved in this negotiation we would probably need some > kind of > "centralized" function for this. > > b) Do we send the initial INVITE uncompressed (or partly compressed) > with a Supported/Require/Proxy-Require > header listing the supported compression algorithms. And again, if > the proxies must support the compression, there must be a > way for them to indicate it (can be done for example either by > using Proxy-Require, or some Record-Route parameter) > > c) Do we use "manual" configuration, either by hand or by using some > of the SIP extensions that have been defined for remote > configuration. > > > My thoughts... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Michel de Boer [mailto:michelboer@lucent.com] > > > Sent: Thursday, July 19, 2001 3:54 AM > > > To: Jonathan Rosenberg > > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > > > > Jonathan, > > > > > > You state that one of the ways to achieve message size reduction is to > > > define a binary encoding, but that this introduces interoperability > > > problems. > > > > > > How can a compression scheme based on dynamically constructed > > > codebooks > > > be simpler? > > > > Simpler, perhaps not (although if you're using PER or BER, its not clear to > > me that this is simpler, codewise). But, it totally breaks compatibility > > with the existing protocol. By pushing this into a transport problem, it is > > isolated to the two entities that need to worry about it. > > > > > In my opinion this approach is more prone to > > > interoperability > > > issues. > > > > Thats not clear at all. Either way, we would require new code in > > implementations. For a new binary coding, we would be back to square 1, so > > that everyone would have to work out the kinks in their encoder/decoders for > > every element in the syntax. However, with a shim, we leverage existing, > > mature parsers and generators. We add a layer that is not specific to SIP, > > so it has no syntax or anything else to get wrong. Its defined by a fairly > > simple set of state machines, which should not be that hard to get correct. > > I would argue its easier to get that right than it is to get a totally new > > encoding of SIP right. > > > > > Codebooks can get out of sync. > > > > Yes, and that does need to be handled in the protocol. > > > > > As codebooks are specific to a sender- > > > receiver pair, an entity communicating with multiple other > > > entities, i.e. > > > a proxy talking to many UA's must manage multiple codebooks. > > > > Well, the problem at hand is really a wireless phone talking to its local > > outbound proxy. THus, the phone has only one relationship, and the proxy has > > one with each phone it communicates with. This pushes the burden of > > compression to the elements that benefit the most from it. From this point > > onwards, normal SIP would be used, and so its compatible with existing > > proxies and UAs. > > > > > > > > For trouble shooting one might want to monitor a network interface and > > > analyze SIP messages coming in. It's impossible to read a compressed > > > message. > > > > The output of the decompressor would need to be monitored. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 11:29:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17876 for ; Thu, 26 Jul 2001 11:29:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10412; Thu, 26 Jul 2001 01:45:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10382 for ; Thu, 26 Jul 2001 01:45:50 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18468 for ; Thu, 26 Jul 2001 01:44:47 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6Q5gWF03653 for ; Thu, 26 Jul 2001 00:42:32 -0500 Message-ID: <012601c11596$2208e310$55fa403f@blazer> From: "Dean Willis" To: Date: Thu, 26 Jul 2001 00:45:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Draft Agenda for SIP WG IETF 51 Posted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, the first draft of an agenda is posted on the supplementary web site at: http://www.softarmor.com/sipwg/meets/ietf51/draftagenda.html As usual, I probably missed a bunch of stuff. Let me know ASAP. SIPPING should be published shortly. Text follows: DRAFT AGENDA FOR SIP WG, IETF 51 Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 0900 Agenda Bash -- Chairs 0910 Status Review -- Chairs 0920 Last Call Process and Report -- Rakesh Shah 0930 Call Control Extensions draft-biggs-sip-replaces-01.txt -- Billy Biggs draft-ietf-sip-refer-00.txt -- Robert Sparks 1000 Events (Two Issues) draft-ietf-sip-events-00.txt -- Adam Roach 1030 Early Media Extensions draft-sb-sip-earlymedia-00.txt -- Jayshree Bharatia draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg 1100 SIP and NAT Extensions draft-boer-sip-src-00.txt -- Michel de Boer draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg 1130 break Session 2: 7Aug01 0900-1130 King's Suite/Sandringham 0900 Agenda Bash -- Chairs 0910 Message Integrity via Digest draft-undery-sip-digest-00.txt -- James Undery draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg 0930 Server Features Negotiation draft-hoeneisen-sip-proxy-supported-00.txt -- Bernard Hoeneisen draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1000 Reliability of Provisional Messages Extensions draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1030 Discussion of Remote-Party Extensions Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston 1100 Discussion of Further Open Issues 1130 Close Updated June 27, 2001 09:44 UST Proposed Bar BOFs Security Privacy _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 12:01:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19535 for ; Thu, 26 Jul 2001 12:01:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22852; Thu, 26 Jul 2001 11:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22820 for ; Thu, 26 Jul 2001 11:28:55 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17807 for ; Thu, 26 Jul 2001 11:27:54 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PJZAI23092 for ; Wed, 25 Jul 2001 14:35:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 14:34:17 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Jul 2001 14:34:17 -0500 content-class: urn:content-classes:message Subject: RE: [rohc] RE: [Sip] SIP Compression Date: Wed, 25 Jul 2001 14:34:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [rohc] RE: [Sip] SIP Compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEVIjy7Jp2CWIEVEdWBSQBQi2X+DwAFxfiw To: , , Cc: , , X-OriginalArrivalTime: 25 Jul 2001 19:34:17.0074 (UTC) FILETIME=[CAFCCD20:01C11540] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22822 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Somehow, I feel we're drifting away from the real issue. First of all, the need of SIP compression arises only because a SIP user is connected to the rest of world via a bandwidth limited link (e.g. cellular). Otherwise, we won't make all the mess to compress SIP, which negates all the reasons why SIP is text based in the first place. Therefore, I think a compression between the SIP user and a SIP proxy on the other side of the low-bandwidth link is a reasonable approach. Note that this is neither hop-by-hop, nor end-to-end (I assume by e2e you mean the two end SIP users, not including the proxies). This solves the problem where it arises, with no effect to the rest of networks. Specifically, a "normal" SIP user with fast connection does not need to have the compression function, nor does it have to determine if the peer SIP user is a mobile or not. As to the extra load on SIP proxy performing the compression, I don't think it is a problem as Markus indicated. Furthermore, the function needs to be there anyway since the proxy needs uncompressed (at least part of) SIP messages. Br, Zhigang > -----Original Message----- > From: ext Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > Sent: July 25, 2001 10:54 AM > To: Isomaki Markus (NRC/Helsinki); ssh@cisco.com > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > Subject: Re: [rohc] RE: [Sip] SIP Compression > > > end-to-end compression seems more efficient as it doesn't > depend on link > characterictics of link between each hop. A payload compression scheme > should be designed considering worst link characteristics > that a packet may > encounter in it's path.. cellular link is a good example for > this between > two hops. The gain obtained on those poor links can be carried over to > better links without any loss. > end-to-end scheme becomes more attractive when two disjoint > hop-to-hop links > are of poor characteristics. > The processing time on hops could be a issue in hop-to-hop schemes. An > intermediate hop serving multiple connections, if under load, > could affect > all connected entities.e.g. a base station serving multiple phones. > (Particularly in payload compression schemes an intermediate > hop need not > decompress at all..) > In end-to-end scheme, there is no such problem, resulting in a better > overall performance. > > > Definitely, this is not applicable in header compression > schemes but for > completely different reason, header required for routing. > There hop-to-hop > is the best scheme regardless of processing time issue on > base station or > any other benefits of end-to-end compression. > > ---Aniruddha > > ----- Original Message ----- > From: > To: ; > Cc: ; ; > Sent: Wednesday, July 25, 2001 4:26 PM > Subject: [rohc] RE: [Sip] SIP Compression > > > > Hi, > > > > > -----Original Message----- > > > From: ext Suheel Hussain [mailto:ssh@cisco.com] > > > Sent: 25 July, 2001 15:46 > > > To: Aniruddha Kulkarni > > > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > > > Subject: Re: [Sip] SIP Compression > > > > > > > > > I have nagging issue with SIP compression -- compressing and > > > decompressing on > > > each proxy server is going to slow down call processing on > > > large networks. > > > IMO, it (compression) is not scalable. > > > > > > > Well, obviously you would only compress/decompress where it > makes sense. > > This would usually be between UA in a cellular host and its outbound > proxy. > > There you may only have a few kilobits of capacity > available (and during > the > > actual voice call even less), so it is feasible to trade between > > transmission delay and processing complexity. So it is a classical > > optimization problem with two constraints. Between proxies, > where you > > (should) have enoungh capacity, compression will probably > just slow down > > things. > > > > > Even end-to-end can be a problem if either (or both) UAS and > > > UAC service a > > > number of attached SIP-unaware systems. For instance a > > > SIP-PSTN gateway. > > > > > > > Again, using compression between gateways/controllers > probably does not > make > > sense as the capacity limitations shouldn't be a problem. > > > > Regards, > > Markus > > > > > Aniruddha Kulkarni wrote: > > > > > > > If one has high latency link then nothing can be done about > > > it. Compression > > > > is not a solution for that. > > > > If one has low bandwidth link and large data to send then > > > Compression can be > > > > the solution. > > > > SIP messages take up only small portion of the available > > > bandwidth (even on > > > > Cellular links..). Then why use compression for SIP > messages? Well.. > > > > cellular links have high BER, in this situation it is > > > advisable to have > > > > smaller packets to reduce error probability.. that is why > > > use compression. > > > > ... correct? > > > > > > > > Still large number of connections to internet are over > > > telephone modem links > > > > with low bandwidth, comparable with latest cellular links. > > > Isn't it useful > > > > to have end-to-end SIP message compression in that situation? > > > > > > > > How much the SIP compression schemes are dependant on RoHC? > > > Could they have > > > > in-built mechanism for configuration negotiation? Should > > > they demand this > > > > facility from lower layers? It seems to me that these > > > schemes work more at > > > > application level and should have configuration negotiation > > > at that level > > > > only. That way they could be easily extened for use on > > > end-to-end rather > > > > than limiting them to hop-to-hop (by depending on RoHC). > > > > > > > > ---Aniruddha > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: "'Aniruddha Kulkarni'" ; > > > > ; > > > > Sent: Tuesday, July 24, 2001 6:27 PM > > > > Subject: RE: [Sip] SIP Compression > > > > > > > > > > > > > > > >> SIP is not intended to transport large amounts of information. > > > >> That plus the ratio of bandwidth used by signalling vs. > > > >> the bandwidth used by the media, means that signalling > compression > > > >> for SIP is not in general a problem. It only really becomes a > > > >> problem on low bandwidth, high latency *links* such as > a cellular > > > >> link where sometimes every byte counts. > > > >> > > > >> In short, I believe signalling compression is a hop-by-hop > > > >> problem and not an end-to-end one. A hop-by-hop solution seems > > > >> appropriate in this case. > > > >> > > > >> It should also be noted that you can always apply gzip > compression > > > >> to the MIME body of a SIP message to achieve some end-to-end > > > >> compression. IMHO, this is not needed. > > > >> > > > >> I believe the compression techniques that have been > > > >> described so far (ROGER, SCRIBE, EPIC, etc.) are > > > >> fairly generic and would work well on a variety of > > > >> link types. Some have been tailored with cellular > > > >> in mind. > > > >> > > > >> Hopefully this addresses your concerns, > > > >> Sean Olson > > > >> Ericsson Inc. > > > >> > > > >> -----Original Message----- > > > >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > > >> Sent: Tuesday, July 24, 2001 8:30 AM > > > >> To: rohc@cdt.luth.se; sip@ietf.org > > > >> Subject: [Sip] SIP Compression > > > >> > > > >> RoHC works hop-to-hop, not end-to-end when there are > > > multiple hops between > > > > > > > > two ends. > > > > > > > >> Does SIP Compression mechanisms also have this constraint? > > > If yes, why? > > > >> Are those designed to work only on cellular link between > > > mobile terminal > > > > > > > > and > > > > > > > >> fixed end of cellular link (hop-to-hop) ? Why those > > > mechanisms are not > > > > > > > > designed > > > > > > > >> for end-to-end compression? > > > >> (reduce large payloads ,whatever be the link > characteristics...) > > > >> > > > >> ---Aniruddha > > > >> > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > -- > > > > > > Suheel Hussain > > > ssh@cisco.com > > > Cisco Work # (919) 392-2312 > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > > > > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 12:16:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17430 for ; Thu, 26 Jul 2001 11:20:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21737; Thu, 26 Jul 2001 10:46:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21704 for ; Thu, 26 Jul 2001 10:46:43 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13901 for ; Thu, 26 Jul 2001 10:45:42 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Jul 2001 14:46:42 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 26 Jul 2001 12:07:45 +0100 Message-ID: <3B5FF9DF.A5A7D226@ubiquity.net> Date: Thu, 26 Jul 2001 12:07:11 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] bis-04 available! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2001 11:07:45.0434 (UTC) FILETIME=[32924FA0:01C115C3] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Well I for one am glad the Authentication-Info is now mentioned in the spec, that makes my digest draft actually potentially useful!! It would be nice however to have the header mentioned in section 10, even if it's just a short entry like Authorization. James Undery Jonathan Rosenberg wrote: > Folks, > > I have submitted an updated version of the bis specification, > draft-ietf-sip-rfc2543bis-04. This should appear in the archives later this > week. In the meantime, you can pick up a copy from: > > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.txt > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.ps > http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-04.pdf > > Some people complained about difficulties downloading the PDF version from > the site, so I have also left a copy at: > > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.pdf > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.ps > http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-04.txt > > The changes between bis-03 and bis-04 are a collection of mostly minor > stuff, detailed in Appendix J. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 13:45:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25535 for ; Thu, 26 Jul 2001 13:45:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23835; Thu, 26 Jul 2001 11:51:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23748 for ; Thu, 26 Jul 2001 11:51:34 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19012 for ; Thu, 26 Jul 2001 11:50:33 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6QESbT00912; Thu, 26 Jul 2001 07:28:37 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW29344; Thu, 26 Jul 2001 07:28:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11098; Thu, 26 Jul 2001 07:28:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15200.10503.705040.948513@thomasm-u1.cisco.com> Date: Thu, 26 Jul 2001 07:28:23 -0700 (PDT) To: Cc: , , , Subject: RE: [Sip] New I-D on compression of SIP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the numbers. What needs to be taken into account also is the recidivism rate. Sharing state with a first hop proxy is quite likely to get good compression, while direct communication with another UA is more likely to degrade into the individually compressed case since there won't be that much signaling, typically. Also: there's an interesting question of dictionary/window sizes. Gzip, as I recall, uses a 32k window to do its magic, which is a pretty hefty amount of memory. I'd be worried about both the UA if it needed quite a few of these, as well as large proxies which need to subtend 10-100's of thousands of UA's. You could, I suppose, set the window size down, but I'm sure the ratios are non-linear. Guestimating with the two points on the graph given your numbers (always a dangerous thing to do :-), the sweet spot is still likely to be in the 8k range, or so which is still a fair amount of state to be dragging around. And as always, introduction of state always reduces your flexibility since there's a higher energy barrier to surmount when moving. This, of course, runs afoul of load balancing schemes which like statelessness generally. Given security state considerations, they may already be on the losing end, but it's worth noting the cost. Mike zhigang.liu@nokia.com writes: > > Hmm. I guess I have to wonder whether the marginal > > difference is actually worth much over the base > > Huffman encoding and whatever you manage to eek > > out with the dictionary across packets. It does > > come at the expense of quite a bit of extra shared > > state. If you're sold on that, maybe it would be > > best of all to just standardize a SIP specific > > dictionary :-) > > That is definitely one thing we need to investigate. > To summarize, we have three kinds of data that can > be used for compression: > > 1) static and protocol specific > 2) user specific > 3) dynamic > > I'm not sure the difference between using 1) only > and using all of them is marginal. At least the > user specific part can boost compression efficiency > significantly. > > Below are some results copied from Appendix A of SCRIBE-01. > > Scenario A: each message is compressed individually > Scenario B: 2) is used > Scenario C: 1) and 2) are used > > ================================================================== > Table 1. The Average Compression Ratio in Different Scenarios. > > Scenario A, Scenario B, Scenario C, > Compression Ratio Compression Ratio Compression Ratio > (Average) (Average) (Average) > ------------------------------------------------------------------------ > LZSS, 12-bit > position, 4-bit 1.31 4.19 4.51 > match length > > LZSS, 11-bit > position, 5-bit 1.33 4.87 5.27 > match length > > Linux GZIP > compression 1.47 6.23 6.37 > ======================================================================= > > Br, > Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 13:46:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25680 for ; Thu, 26 Jul 2001 13:46:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22297; Thu, 26 Jul 2001 11:06:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22268 for ; Thu, 26 Jul 2001 11:06:16 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16124 for ; Thu, 26 Jul 2001 11:05:15 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6QCxpN17914 for ; Thu, 26 Jul 2001 14:59:51 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6QCxo529213 for ; Thu, 26 Jul 2001 15:59:50 +0300 (EET DST) Message-ID: <3B601442.E6A32A34@lmf.ericsson.se> Date: Thu, 26 Jul 2001 15:59:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------939CA5F55CCCCE330C441EE9" Subject: [Sip] Response code for unsupported SIP version Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------939CA5F55CCCCE330C441EE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just a small detail/cosmetic/clarification question: The 505 SIP Version not supported, which belongs to the Server Error category, response code is used when a request with a non-supported SIP version (other than SIP/2.0, that is) is received. The ABNF grammar (bis-04, page 27), however, allows ONLY "SIP/2.0". If something else is received, isn't it then, from a grammar point of view, a Syntax Error (ie a 4xx response code should be used)? So, if we want to use 505, shouldn't the grammar look something like: SIP-Version = "SIP/2.0" | other-version other-version = "SIP/" 1*DIGIT "." 1*DIGIT ...or something similar. Regards, Christer Holmberg Ericsson Finland --------------939CA5F55CCCCE330C441EE9 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------939CA5F55CCCCE330C441EE9-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 13:46:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25682 for ; Thu, 26 Jul 2001 13:46:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22785; Thu, 26 Jul 2001 11:26:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22754 for ; Thu, 26 Jul 2001 11:26:38 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17771 for ; Thu, 26 Jul 2001 11:25:35 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6QB0xO17232 for ; Thu, 26 Jul 2001 13:00:59 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6QB0x526844 for ; Thu, 26 Jul 2001 14:00:59 +0300 (EET DST) Message-ID: <3B5FF868.C8E3C1D5@lmf.ericsson.se> Date: Thu, 26 Jul 2001 14:00:56 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------B0E9AE6CD06E50006248E9C4" Subject: [Sip] Media goes draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------B0E9AE6CD06E50006248E9C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, A small idea... We now have a number of SIP extensions, defined in separate drafts, and things like compression and security will also be outside the core bis document. This way is very good and flexible, and the bis doesn't have to be changed every time there is a change elsewhere. I have been thinking of this before, and it came back now when the early media draft was released: why not make the whole SIP media handling as a separate draft? Some advantages I see: 1. Today we have SDP, tomorrow maybe SDPng, so we still would have to write a separate document for that, or update the RFC2543 again. 2. Annex B is IP specific, even IPv4 specific, so we still will have to write separate documents how SIP uses SDP for IPv6 bearers/ATM bearers/whatever-future bearers (I KNOW there allready are separate documents some of these). 3. It would be possible to go into the handling of EACH media- and bearer type much more in detail. 4. All media handling, including services like call hold, media modification and early media, would be in the same document. I know that doing this is not very high on the priority list, but I also don't think that it would take very much time (to start with, we only have to cut-paste Annex B...:). Just an idea. Comments? Christer Holmberg Ericsson Finland Ps. I think that doing this would also make things more clear for those who still think that SIP is a protocol used to transport media :) --------------B0E9AE6CD06E50006248E9C4 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------B0E9AE6CD06E50006248E9C4-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 13:51:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26334 for ; Thu, 26 Jul 2001 13:51:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26441; Thu, 26 Jul 2001 13:25:43 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id NAA26411 for ; Thu, 26 Jul 2001 13:25:40 -0400 (EDT) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Jul 2001 10:25:03 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Jul 2001 09:01:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Jul 2001 09:01:20 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Jul 2001 09:00:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP Date: Wed, 25 Jul 2001 09:00:10 -0700 Message-ID: Thread-Topic: [rohc] RE: [Sip] New I-D on compression of SIP Thread-Index: AcEVF3Dbru64978SQI2RR90fql6ghgACxvjw From: "Christian Huitema" To: "Dean Willis" , X-OriginalArrivalTime: 25 Jul 2001 16:00:10.0369 (UTC) FILETIME=[E1C12F10:01C11522] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA26412 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Assume a 9.6kbps single-channel GPRS link. > > Assume that approximately 5kbps of that is used by a > half-rate AMR (Alternative Minimum Rate) codec. That gives us > roughly 4.6kbps available for processing signaling, such as a > re-INVITE, BYE, or new INVITE arriving. Dean, let's do a reality check. We are constantly receiving requests to tweak our TCP stack in order to match the long delays of GPRS channels -- more than 600 ms is not uncommon. These delays seem to be intrinsic to the technology, probably due to a mix of contention on access and low level retransmission. Do you really believe that you are going to conduct a meaningful VoIP conversation over this kind of channel? -- Christian Huitema _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 13:52:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26380 for ; Thu, 26 Jul 2001 13:52:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26509; Thu, 26 Jul 2001 13:28:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26478 for ; Thu, 26 Jul 2001 13:28:00 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22663 for ; Thu, 26 Jul 2001 13:27:00 -0400 (EDT) From: zhigang.liu@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6QH0Ii07918 for ; Thu, 26 Jul 2001 12:00:18 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 26 Jul 2001 11:59:57 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 26 Jul 2001 11:59:57 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] New I-D on compression of SIP Date: Thu, 26 Jul 2001 11:59:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] New I-D on compression of SIP X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEV3z2Buc7UZ4HREdWxLgAIx6TWeAAB7AZQ To: Cc: , , X-OriginalArrivalTime: 26 Jul 2001 16:59:57.0541 (UTC) FILETIME=[6649F150:01C115F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA26479 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Thanks for the numbers. What needs to be taken > into account also is the recidivism rate. Sharing > state with a first hop proxy is quite likely to > get good compression, while direct communication > with another UA is more likely to degrade into the > individually compressed case since there won't be > that much signaling, typically. By "direct communication with another UA", do you mean the compression is not done at the first hop proxy, or some SIP messages may not go through the proxy? We have been assuming that the first hop proxy of a mobile UA (yes, I take cellular as an example) is on the path of all SIP messages sent by and to the mobile UA. This is not true in general, but I think it can be configured that way for the purpose of compression. Also, those numbers were measured without the use of dynamic dictionary. Only static and user specific data are used. The former doesn't need any signaling. The latter only needs to be populated once (to wherever the other compression point is). > Also: there's an > interesting question of dictionary/window > sizes. Gzip, as I recall, uses a 32k window to do > its magic, which is a pretty hefty amount of > memory. I'd be worried about both the UA if it > needed quite a few of these, as well as large > proxies which need to subtend 10-100's of > thousands of UA's. You could, I suppose, set the > window size down, but I'm sure the ratios are > non-linear. Guestimating with the two points on > the graph given your numbers (always a dangerous > thing to do :-), the sweet spot is still likely to > be in the 8k range, or so which is still a fair > amount of state to be dragging around. That's our concerns too and that's why we also used the very simple lzss.c for comparison. Just to highlight some quick facts (they can be found in Appendix A in SCRIBE-01): - Static dictionary: 243 bytes - user specific dictionary: 640 bytes - lzss.c: ring buffer = 2 KBytes, pointer = (11-bit position, 5-bit length) For such a humble configuration, a compression ratio about 5:1 (compared to gzip 6.xx:1) is pretty good. What we see is different capabilities of UAs (e.g. a cell phone vs.. a laptop) as well as the proxy. SCRIBE tries to address the issue by a framework that is scalable and flexible. It allows different compression algorithms and different compression data synchronization mechanisms. I believe the static and user-specific data, coupled with a simple compression algorithm, is a good starting point. From there, we can add dynamic and more powerful compression algorithm if we can afford the complexity. > And as always, introduction of state always > reduces your flexibility since there's a higher > energy barrier to surmount when moving. Yes, that's why we propose the SIP proxy as the other compression point. The mobile UA won't change its proxy often. Even if the state transfer is needed, the extra vost is not that high considering all the state queries/transfers already needed in current cellular networks. (And you're right, as a law of physics, you need more energy to be moble. :-)) BR, Zhgiang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 15:59:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08024 for ; Thu, 26 Jul 2001 15:59:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01927; Thu, 26 Jul 2001 15:38:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01889 for ; Thu, 26 Jul 2001 15:38:45 -0400 (EDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06303 for ; Thu, 26 Jul 2001 15:37:43 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QJbc906355 for ; Thu, 26 Jul 2001 15:37:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 26 Jul 2001 15:37:46 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:37:49 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514F960@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Media goes draft Date: Thu, 26 Jul 2001 15:37:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1160A.6DAA35C0" X-Orig: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1160A.6DAA35C0 Content-Type: text/plain; charset="iso-8859-1" I like it! Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Thursday, July 26, 2001 7:01 AM To: sip@ietf.org Subject: [Sip] Media goes draft Hi, A small idea... We now have a number of SIP extensions, defined in separate drafts, and things like compression and security will also be outside the core bis document. This way is very good and flexible, and the bis doesn't have to be changed every time there is a change elsewhere. I have been thinking of this before, and it came back now when the early media draft was released: why not make the whole SIP media handling as a separate draft? Some advantages I see: 1. Today we have SDP, tomorrow maybe SDPng, so we still would have to write a separate document for that, or update the RFC2543 again. 2. Annex B is IP specific, even IPv4 specific, so we still will have to write separate documents how SIP uses SDP for IPv6 bearers/ATM bearers/whatever-future bearers (I KNOW there allready are separate documents some of these). 3. It would be possible to go into the handling of EACH media- and bearer type much more in detail. 4. All media handling, including services like call hold, media modification and early media, would be in the same document. I know that doing this is not very high on the priority list, but I also don't think that it would take very much time (to start with, we only have to cut-paste Annex B...:). Just an idea. Comments? Christer Holmberg Ericsson Finland Ps. I think that doing this would also make things more clear for those who still think that SIP is a protocol used to transport media :) ------_=_NextPart_001_01C1160A.6DAA35C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Media goes draft

I like it!

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: Thursday, July 26, 2001 7:01 AM
To: sip@ietf.org
Subject: [Sip] Media goes draft



Hi,

A small idea...

We now have a number of SIP extensions, defined in = separate drafts, and
things like compression and security will also be = outside the core bis
document. This way is very good and flexible, and = the bis doesn't have
to be changed every time there is a change = elsewhere.

I have been thinking of this before, and it came back = now when the early
media draft was released: why not make the whole SIP = media handling as a
separate draft? Some advantages I see:

1. Today we have SDP, tomorrow maybe SDPng, so we = still would have to
write a separate document for that, or update the = RFC2543 again.

2. Annex B is IP specific, even IPv4 specific, so we = still will have to
write separate documents how SIP uses SDP for IPv6 = bearers/ATM
bearers/whatever-future bearers (I KNOW there = allready are separate
documents some of these).

3. It would be possible to go into the handling of = EACH media- and
bearer type much more in detail.

4. All media handling, including services like call = hold, media
modification and early media, would be in the same = document.

I know that doing this is not very high on the = priority list, but I also
don't think that it would take very much time (to = start with, we only
have to cut-paste Annex B...:).

Just an idea. Comments?


Christer Holmberg
Ericsson Finland

Ps. I think that doing this would also make things = more clear for those
who still think that SIP is a protocol used to = transport media :)

------_=_NextPart_001_01C1160A.6DAA35C0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 17:17:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12779 for ; Thu, 26 Jul 2001 17:17:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03061; Thu, 26 Jul 2001 16:26:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03031 for ; Thu, 26 Jul 2001 16:26:08 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09610 for ; Thu, 26 Jul 2001 16:25:06 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08423 for ; Thu, 26 Jul 2001 16:25:09 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08414 for ; Thu, 26 Jul 2001 16:25:08 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11611.3723DF7C" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] Media goes draft Date: Thu, 26 Jul 2001 14:26:13 -0600 Message-ID: Thread-Topic: [Sip] Media goes draft Thread-Index: AcEV567+x22D+pBjRte8ZwTb84JUvgAKMFxw From: "Zmolek, Andrew (Andrew)" To: "Christer Holmberg" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C11611.3723DF7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The concept sounds great, but this could be quite an operation and the timing might be an issue right now. And while allowing for SDPng is good, we also run the risk of ending up at a point where we might allow for all kinds of SDP replacement candidates which could create more interoperability islands over time.=20 If we take this approach, let's make sure we're convinced the reward outweighs the risks. If so, I'm all for it. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Thursday, July 26, 2001 5:01 AM To: sip@ietf.org Subject: [Sip] Media goes draft Hi, A small idea... We now have a number of SIP extensions, defined in separate drafts, and things like compression and security will also be outside the core bis document. This way is very good and flexible, and the bis doesn't have to be changed every time there is a change elsewhere. I have been thinking of this before, and it came back now when the early media draft was released: why not make the whole SIP media handling as a separate draft? Some advantages I see: 1. Today we have SDP, tomorrow maybe SDPng, so we still would have to write a separate document for that, or update the RFC2543 again. 2. Annex B is IP specific, even IPv4 specific, so we still will have to write separate documents how SIP uses SDP for IPv6 bearers/ATM bearers/whatever-future bearers (I KNOW there allready are separate documents some of these). 3. It would be possible to go into the handling of EACH media- and bearer type much more in detail. 4. All media handling, including services like call hold, media modification and early media, would be in the same document. I know that doing this is not very high on the priority list, but I also don't think that it would take very much time (to start with, we only have to cut-paste Annex B...:). Just an idea. Comments? Christer Holmberg Ericsson Finland Ps. I think that doing this would also make things more clear for those who still think that SIP is a protocol used to transport media :) ------_=_NextPart_001_01C11611.3723DF7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Media goes draft

The concept sounds great, but this could be quite an = operation and the timing might be an issue right now. And while allowing = for SDPng is good, we also run the risk of ending up at a point where we = might allow for all kinds of SDP replacement candidates which could = create more interoperability islands over time.

If we take this approach, let's make sure we're = convinced the reward outweighs the risks. If so, I'm all for it.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmber= g@lmf.ericsson.se]
Sent: Thursday, July 26, 2001 5:01 AM
To: sip@ietf.org
Subject: [Sip] Media goes draft



Hi,

A small idea...

We now have a number of SIP extensions, defined in = separate drafts, and
things like compression and security will also be = outside the core bis
document. This way is very good and flexible, and the = bis doesn't have
to be changed every time there is a change = elsewhere.

I have been thinking of this before, and it came back = now when the early
media draft was released: why not make the whole SIP = media handling as a
separate draft? Some advantages I see:

1. Today we have SDP, tomorrow maybe SDPng, so we = still would have to
write a separate document for that, or update the = RFC2543 again.

2. Annex B is IP specific, even IPv4 specific, so we = still will have to
write separate documents how SIP uses SDP for IPv6 = bearers/ATM
bearers/whatever-future bearers (I KNOW there = allready are separate
documents some of these).

3. It would be possible to go into the handling of = EACH media- and
bearer type much more in detail.

4. All media handling, including services like call = hold, media
modification and early media, would be in the same = document.

I know that doing this is not very high on the = priority list, but I also
don't think that it would take very much time (to = start with, we only
have to cut-paste Annex B...:).

Just an idea. Comments?


Christer Holmberg
Ericsson Finland

Ps. I think that doing this would also make things = more clear for those
who still think that SIP is a protocol used to = transport media :)

------_=_NextPart_001_01C11611.3723DF7C-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 17:18:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12873 for ; Thu, 26 Jul 2001 17:18:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04350; Thu, 26 Jul 2001 17:04:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04319 for ; Thu, 26 Jul 2001 17:04:09 -0400 (EDT) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12009 for ; Thu, 26 Jul 2001 17:03:08 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f6QL10F05502; Thu, 26 Jul 2001 16:01:01 -0500 Message-ID: <004c01c11616$a59547c0$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "Christian Huitema" , References: Subject: Re: [rohc] RE: [Sip] New I-D on compression of SIP Date: Thu, 26 Jul 2001 16:05:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Store and forward speech messaging delivered on a one-to-many basis, aka "group voice chat" is a potential application over high-latency networks like GPRS/GERAN. Real-time two-way may be problematic for the first generation of systems, but GPRS/UTRAN should be much better. Maybe the real wireless wonks (I'm not one!) can shed some light . . . And I think the latency problem is derived from the way that TDM applies, wherein the mobile waits for a request slot, requests a slot to talk in, waits for a response telling it which slot to use, and then waits for the slot to occur. I wouldn't be surprised if somebody comes up with an isochronous model akin to the DOCSYS "unsolicited grant" that will work nicely for VoIP. -- Dean ----- Original Message ----- From: "Christian Huitema" To: "Dean Willis" ; Sent: Wednesday, July 25, 2001 11:00 AM Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP > > Assume a 9.6kbps single-channel GPRS link. > > > > Assume that approximately 5kbps of that is used by a > > half-rate AMR (Alternative Minimum Rate) codec. That gives us > > roughly 4.6kbps available for processing signaling, such as a > > re-INVITE, BYE, or new INVITE arriving. > > Dean, let's do a reality check. We are constantly receiving requests to > tweak our TCP stack in order to match the long delays of GPRS channels > -- more than 600 ms is not uncommon. These delays seem to be intrinsic > to the technology, probably due to a mix of contention on access and low > level retransmission. Do you really believe that you are going to > conduct a meaningful VoIP conversation over this kind of channel? > > -- Christian Huitema > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Jul 26 17:57:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16124 for ; Thu, 26 Jul 2001 17:57:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04664; Thu, 26 Jul 2001 17:16:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04636 for ; Thu, 26 Jul 2001 17:16:22 -0400 (EDT) Received: from dal-mail2.ricochet.net (dal-mail1.ricochet.net [204.179.143.30]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12668 for ; Thu, 26 Jul 2001 17:15:22 -0400 (EDT) From: shh@ricochet.net Received: from shiv-mcet (mg-631126-107.sfc1-mg2.ricochet.net [63.112.6.107]) by dal-mail2.ricochet.net (8.9.3/8.9.3) with SMTP id QAA27966; Thu, 26 Jul 2001 16:13:17 -0500 (CDT) Message-Id: <3.0.1.32.20010726142217.01006bc8@pop.ricochet.net> X-Sender: shh@pop.ricochet.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 26 Jul 2001 14:22:17 -0700 To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, I may have missed something, but I feel that there may be limitations to the proposed scheme. I am unable to see how 2 SIP devices behind the same NAT device are going to communicate with each other. A secondary issue is that you would be exposing private IP addresses on the outside. In the port sharing (on the AVT mailing list) case, with a VPN like tunnel, local calling (2 sip devices behind the same NAT) may require sending all packets across the WAN link and back. Shiv shh@microappliances.com At 04:55 AM 7/24/2001 -0700, Fairlie-Cuninghame, Robert wrote: >Perhaps I am misinterpreting the quoted statement (in original email), >Jonathan? I think perhaps you might be saying that the proxy Y must always >record-route - regardless of whether the proxy wants to be on the call path >for re-INVITE's and BYE's. However, there doesn't seem to be any requirement >for this when the NAT is known to be of the cone type. > >Robert. > >> Hi Jonathan, >> >> Very interesting draft. >> >> I have a couple of comments. It seems that in section 4.2 Contact >> Translation (and maybe I am being thick...) that the proxy Y >> is not required >> to Record-Route the call: >> >> "In order for this connection to be used for re-INVITEs or >> BYEs, the >> proxy needs to record route." >> >> Thus when Joe calls Bob and Proxy Y does not Record-Route >> then the Joe would >> send the ACK directly to the Translated Contact in the 200 OK >> from Bob. >> However this is not going to work for a symmetric NAT. >> Shouldn't there be >> some sort of requirement that Proxy Y must Record-Route >> unless Bob's NAT is >> known to be a cone NAT (eg indicated in Translate header)? Am >> I completely >> missing something here? >> >> Also for the symmetric RTP section: I think would be much >> more interoperable >> if we define symmetric RTP as being indicated when transport >> profile RTP/AVP >> is used _AND_ the a=direction parameter is present (rather than a new >> transport profile "RTP/UDP"). In this manner a UA supporting >> symmetric RTP >> and a plain vanilla UA can still communicate when NAT is not involved. >> Obviously it is much cleaner that a separate transport >> profile is used but I >> believe it will hamper the deployment of your suggestion. >> >> In the above suggestion, a UA not understanding symmetric RTP (ie, not >> understanding the direction attribute) will setup a call as normal. >> Additionally, the UA supporting symmetric RTP can detect that >> the peer does >> not support the extension by the lack of the a=direction >> attribute in the >> SDP answer. Simple! >> >> Regards, >> >> Robert. >> >> > -----Original Message----- >> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> > Sent: Tuesday, July 24, 2001 8:51 AM >> > To: 'sip@ietf.org' >> > Subject: [Sip] update to nat traversal draft! >> > >> > >> > Folks, >> > >> > I've submitted an update to draft-rosenberg-sip-entfw, >> which discusses >> > traversal of SIP through enterprise and residential nats. >> > There are a LOT of >> > differences between this version (-02) and the previous. >> Specifically: >> > >> > 1. SIP "via port" parameter defined to allow SIP-UDP traversal >> > 2. Translate header replaces Contact cookie >> > 3. NAT detection and allocation protocol is defined, and used >> > between the UA >> > and some elements deployed in the SIP provider network. This >> > is effectively >> > midcom without midcom compliant nats. It vastly simplifies >> > things and also >> > solves the case where both sides are behind a symmetric nat. >> > 4. lots more >> > >> > Until the draft appears in the archives, you can pick up a copy at: >> > >> > http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt >> > >> > Thanks, >> > Jonathan R. >> > >> > --- >> > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> > Chief Scientist First Floor >> > dynamicsoft East Hanover, NJ 07936 >> > jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> > http://www.jdrosen.net PHONE: (973) 952-5000 >> > http://www.dynamicsoft.com >> > >> > >> > _______________________________________________ >> > Sip mailing list http://www.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 27 01:20:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11019 for ; Fri, 27 Jul 2001 01:20:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14691; Fri, 27 Jul 2001 01:03:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14665 for ; Fri, 27 Jul 2001 01:03:47 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08441 for ; Fri, 27 Jul 2001 01:02:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6R53jN14982; Fri, 27 Jul 2001 07:03:45 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.3]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f6R53i512895; Fri, 27 Jul 2001 08:03:45 +0300 (EET DST) Message-ID: <3B60F629.F3CC9277@lmf.ericsson.se> Date: Fri, 27 Jul 2001 08:03:37 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: sip@ietf.org Subject: Re: [Sip] Media goes draft References: Content-Type: multipart/mixed; boundary="------------1CC01F386B7B21E0F924ACB9" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------1CC01F386B7B21E0F924ACB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andy, Thanks for your comments! A small clarification, though. I did not mean that we have to include SDPng from the beginning - I think it's enough to start with SDP. SDPng, and whatever other SDP "replacements" that may come up in future, can be added later, or written in separate drafts. The point is that it wouldn't affect the core SIP specification (ie RFC2543). Regards, Christer Holmberg Ericsson Finland "Zmolek, Andrew (Andrew)" wrote: > > The concept sounds great, but this could be quite an operation and the > timing might be an issue right now. And while allowing for SDPng is > good, we also run the risk of ending up at a point where we might > allow for all kinds of SDP replacement candidates which could create > more interoperability islands over time. > > If we take this approach, let's make sure we're convinced the reward > outweighs the risks. If so, I'm all for it. > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, July 26, 2001 5:01 AM > To: sip@ietf.org > Subject: [Sip] Media goes draft > > Hi, > > A small idea... > > We now have a number of SIP extensions, defined in separate drafts, > and > things like compression and security will also be outside the core bis > > document. This way is very good and flexible, and the bis doesn't have > > to be changed every time there is a change elsewhere. > > I have been thinking of this before, and it came back now when the > early > media draft was released: why not make the whole SIP media handling as > a > separate draft? Some advantages I see: > > 1. Today we have SDP, tomorrow maybe SDPng, so we still would have to > write a separate document for that, or update the RFC2543 again. > > 2. Annex B is IP specific, even IPv4 specific, so we still will have > to > write separate documents how SIP uses SDP for IPv6 bearers/ATM > bearers/whatever-future bearers (I KNOW there allready are separate > documents some of these). > > 3. It would be possible to go into the handling of EACH media- and > bearer type much more in detail. > > 4. All media handling, including services like call hold, media > modification and early media, would be in the same document. > > I know that doing this is not very high on the priority list, but I > also > don't think that it would take very much time (to start with, we only > have to cut-paste Annex B...:). > > Just an idea. Comments? > > Christer Holmberg > Ericsson Finland > > Ps. I think that doing this would also make things more clear for > those > who still think that SIP is a protocol used to transport media :) --------------1CC01F386B7B21E0F924ACB9 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------1CC01F386B7B21E0F924ACB9-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 27 04:54:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02260 for ; Fri, 27 Jul 2001 04:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28138; Fri, 27 Jul 2001 04:41:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28054 for ; Fri, 27 Jul 2001 04:41:23 -0400 (EDT) Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01532 for ; Fri, 27 Jul 2001 04:40:06 -0400 (EDT) Received: from email.eximsoft.com ([164.164.87.130]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with ESMTP id f6RIg1U08517; Fri, 27 Jul 2001 13:42:07 -0500 (GMT) Received: from localhost (localhost.eximsoft.com [127.0.0.1]) by email.eximsoft.com (Postfix) with ESMTP id 30DA4690F3; Fri, 27 Jul 2001 14:07:22 +0530 (IST) Received: from postman.eximsoft.com (mcpostman [10.10.30.11]) by email.eximsoft.com (Postfix) with ESMTP id A4C72690F2; Fri, 27 Jul 2001 14:07:20 +0530 (IST) Received: from ewsmc005 (unknown [10.10.40.129]) by postman.eximsoft.com (Postfix) with SMTP id 0AB941F54E; Fri, 27 Jul 2001 14:15:09 +0530 (IST) From: Hrishikesh Saria Reply-To: hrishikesh.saria@eximsoft.com Organization: Eximsoft To: sip-implementors@cs.columbia.edu Date: Wed, 25 Apr 2001 14:04:22 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain Cc: sdonovan@dynamicsoft.com, sip@ietf.org MIME-Version: 1.0 Message-Id: <01042514100505.00833@ewsmc005> Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS snapshot-20010407 Content-Transfer-Encoding: 8bit Subject: [Sip] Sip info method Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi When can the UAS and the UAC send the info request. Can the UAS send it before sending a 200 ok or can the UAC send it before sending an ACK or before getting a final respomse. Is the following scenarios valid A -------------> B invite A <--------------B 180 A <------------- B info A--------------->B info A <--------------B 200 ok A-------------->B ACK Regards Hrishikesh Saria _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 27 07:17:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07363 for ; Fri, 27 Jul 2001 07:17:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01184; Fri, 27 Jul 2001 07:00:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01154 for ; Fri, 27 Jul 2001 07:00:43 -0400 (EDT) Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06267 for ; Fri, 27 Jul 2001 06:59:40 -0400 (EDT) Received: from email.eximsoft.com ([164.164.87.130]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with ESMTP id f6RL2EU16234; Fri, 27 Jul 2001 16:02:25 -0500 (GMT) Received: from localhost (localhost.eximsoft.com [127.0.0.1]) by email.eximsoft.com (Postfix) with ESMTP id 8E450690FB; Fri, 27 Jul 2001 16:29:32 +0530 (IST) Received: from postman.eximsoft.com (mcpostman [10.10.30.11]) by email.eximsoft.com (Postfix) with ESMTP id 8F2C9690F5; Fri, 27 Jul 2001 16:29:23 +0530 (IST) Received: from ewsmc005 (unknown [10.10.40.129]) by postman.eximsoft.com (Postfix) with SMTP id 890B51F55B; Fri, 27 Jul 2001 15:45:04 +0530 (IST) From: Hrishikesh Saria Reply-To: hrishikesh.saria@eximsoft.com Organization: Eximsoft To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Wed, 25 Apr 2001 15:29:32 +0530 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <01042515395907.00833@ewsmc005> Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS snapshot-20010407 Content-Transfer-Encoding: 8bit Subject: [Sip] The SIp info method. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, In the bis draft A regular transaction is defined as a transaction other than that of an ACK, INVITE, CANCEL. So I infer that an INFO is a regular transaction. Now. if a regular transaction is in progress, ie if a UAC has initiated an INFO request then if the response to the INFO request has not yer arrived can the UAC issue a BYE request. if yes what happens to the INFO request. Also if an UAC has sent an INFO request(1) can it also send another INFO request (2) before getting the repsonse for the first INFO request(1). if this allowed then what should be the behaviour of the UAS if the second request arrives before the first one,as the CSEQ of the second INFO will e higher than the first one, which means the ordering of the CSEQ is affected. I am sorry if such issues have already been disucussed before, even pointers to those discussion will be helpful Thanks and Regards Hrishikesh Saria _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 27 08:41:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12972 for ; Fri, 27 Jul 2001 08:41:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03023; Fri, 27 Jul 2001 08:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02994 for ; Fri, 27 Jul 2001 08:12:45 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10850 for ; Fri, 27 Jul 2001 08:11:46 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6RCDOI03560 for ; Fri, 27 Jul 2001 15:13:24 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 27 Jul 2001 15:12:33 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVG588>; Fri, 27 Jul 2001 15:12:33 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E107EBD@esebe014.NOE.Nokia.com> To: huitema@windows.microsoft.com, dean.willis@softarmor.com, sip@ietf.org Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP Date: Fri, 27 Jul 2001 15:12:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, There are three wireless network scenarios I know of where SIP is intended to be used and where compression is either helpful or even critical. 1) GPRS as discussed below, which already exists to some extent and will probably start properly within the next 6 months, as handsets should be available in volume. As Christian says VoIP is probably out of question for GPRS, as GPRS causes delay in addition to the theoretical bit transmission time, and the realistic capacities will initially be around 10-20 kbps. However, things like SIP-based presence and messaging should be completely doable for GPRS, and any reduction of transmission time would be nice. And perhaps people start to use some form of semi-real-time stuff as well, who knows. => So, this is mainly an optimization. 2) WCDMA (UMTS, 3GPP) and CDMA2000 (3GPP2) which will be available within the next couple of years to some extent. Here VoIP will be possible, what comes to available radio capacity and latency, as long as IP QoS (DiffServ) can be mapped to the actual radio bearers. As WCDMA is quite flexible the required amount of capacity can be applied e.g. for SIP based on traditional IP traffic classification. However, in my understanding it is not very nice to keep capacity allocated, even though you are not using it (as would be with SIP, which is very bursty in nature). Also call setup with PRACK and COMET (and Privacy-headers etc.) is quite heavy and requires several round trips. Thus, it is desirable to have as small messages as possible. => It seems that compression would be a big optimization! 3) GERAN/GSM with header stripping This means that it looks like VoIP (the core network is normal IP), but actually the voice frames/packets are carried over the air as circuit-switched, using the channel coding for the voice codec. SIP is carried using the signalling channels originally provisioned for GSM signaling, so they are quite narrow. Especially during the speech call itself, part of the signalling capacity is obtained by stealing bits from the speech channels. These kind of hybrid systems are really complex, but they are also very efficient, and a lot of legacy stuff in the radio can be utilized. => It seems that in these kind of environments compression will be really critical to get the call setup times tolerable. Markus > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 25 July, 2001 19:00 > To: Dean Willis; sip@ietf.org > Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP > > > > Assume a 9.6kbps single-channel GPRS link. > > > > Assume that approximately 5kbps of that is used by a > > half-rate AMR (Alternative Minimum Rate) codec. That gives us > > roughly 4.6kbps available for processing signaling, such as a > > re-INVITE, BYE, or new INVITE arriving. > > Dean, let's do a reality check. We are constantly receiving > requests to > tweak our TCP stack in order to match the long delays of GPRS channels > -- more than 600 ms is not uncommon. These delays seem to be intrinsic > to the technology, probably due to a mix of contention on > access and low > level retransmission. Do you really believe that you are going to > conduct a meaningful VoIP conversation over this kind of channel? > > -- Christian Huitema > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Jul 27 09:25:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16335 for ; Fri, 27 Jul 2001 09:25:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04681; Fri, 27 Jul 2001 09:08:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04653 for ; Fri, 27 Jul 2001 09:08:25 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15020 for ; Fri, 27 Jul 2001 09:07:26 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6RD94I23459 for ; Fri, 27 Jul 2001 16:09:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 27 Jul 2001 16:08:18 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVG74P>; Fri, 27 Jul 2001 16:08:18 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E107EBE@esebe014.NOE.Nokia.com> To: jdrosen@dynamicsoft.com, christer.holmberg@lmf.ericsson.se, sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Date: Fri, 27 Jul 2001 16:08:14 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, > > I think this approach is a bad idea. It has been discussed > and discarded at > least twice so far on the lists. Maybe third time is the charm. > > WHy is it really bad? Well, draft-ietf-sip-guidelines clearly > describes why. > THe extension mandates Proxy-Require *and* Require. According to the > guidelines draft: > > The Proxy-Require header SHOULD be avoided at all costs. The > failure likelihood in an individual proxy stays > constant, but > the path failure grows exponentially with the > number of hops. > This is true if you assume that the support for a feature is a random variable. However, it could also be possible to deploy a new feature in proxies by implementing it in islands of proxies such as ones serving wireless hosts. > This means that you are going to have an exponentially increasing > probability of needing to fallback to the normal PRACK > behavior, and the > resulting cost is that these cell phones, whom you are trying > to serve, now > need to implement two already-complex specifications. > This is a valid point unless the wireless-serving proxies would in most cases support SPRACK. However, what I have heard, SIP implementation in phone is not as big issue as delays are. > Now, if I ignore the fact that this extension is effectively > not backwards > compatible with SIP, there is another problem, which is that it really > doesn't achieve any useful results. > > The supposed goal, as outlined in the introduction, is: > > The motivation for defining an alternative approach to [6] is that > certain networks, e.g. cellular networks, have limited bandwidth > for signalling purposes. Thus every extra message in the session > initiation increases the duration of the session setup, > which might > cause that the session setup delay crosses the acceptable limit. > > This makes no sense to me. I'm assuming that the reliable provisional > responses are being used to acknowledge the 1xx used for > manyfolks. Once the > provisional response is received, resource resveration can happen in > PARALLEL with the transmission of PRACK/200, and the final > response to the > INVITE can also happen in parallel to that. So, call setup time is not > affected. > > Perhaps you are concerned about overhead on the wireless > link. In terms of > byte savings, using something like the ROGER protocol or my > UDP compression > proposal, > http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp > -00.txt, you > get far, far, far better compression gains than the improvements afforded > from eliminating this message. Yes, call setup delays and wireless link overhead would be the main motivation for trying to reduce the number of messages/bytes needed. It's true that QoS setup & radio bearer establishment can start right at the same time as PRACK is being sent and 200 OK for it is being waited for. However, especially if compression is not used, we have calculated that PRACK-200 RTT takes actually longer than QoS setup in some of the wireless systems (read GERAN) that we are dealing with. So, that is the constraint. I agree it may not be a big difference, and if compression is being standardized, as I really hope, your argumentation is correct. There is still another issue. What if 200 OK for PRACK or any other SIP message is lost? That causes a retransmission, and the call setup delay becomes larger. Following the reasoning you had above about the proxies, the likelihood of loss grows exponentially with the number of messages. > So, the SPRACK proposal: > > 1. necessitates Proxy-Require, which is an effective break in compatibility > with the SIP protocol, The extension COULD be used with Proxy-Require, however in the I-D we propose the usage of _Proxy-Supported_, (as described in draft-hoeneisen-sip-proxy-supported-00.txt) which means, that the call can be set-up with the first INIVITE and depending, whether all record routing proxy servers support the s100rel, either the s100rel or the 100rel mechanisms are applied, i.e. no 420 Bad Extension for s100rel is sent by any proxy server. There will be no path failures with this proposal. > 2. doesn't really help call setup times for the manyfolks flows In some cases it does, as explained above. I agree that compression is more important, though. > 3. provides tiny compression compared with other alternatives. > OK. > So, I do not understand why this is a good path to follow. > IF it was possible to redo SIP, would Provisional Responses/PRACK be done differently? I guess so. Our proposal is one way, and it provides backwards compatibility with a fallback system. I don't know if there ever will be SIPv3... > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Markus _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Jul 28 20:46:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13211 for ; Sat, 28 Jul 2001 20:46:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24179; Fri, 27 Jul 2001 23:49:27 -0400 (EDT) Received: from public.szptt.net.cn ([202.96.136.222]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id XAA24148 for ; Fri, 27 Jul 2001 23:49:12 -0400 (EDT) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43b626fcb; Sat, 28 Jul 2001 03:43:44 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm3f3b5f5c3c; Wed, 25 Jul 2001 22:46:11 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04002 for ietf-123-outbound.01@ietf.org; Wed, 25 Jul 2001 15:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25787 for ; Wed, 25 Jul 2001 06:40:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08401; Wed, 25 Jul 2001 06:40:48 -0400 (EDT) Message-Id: <200107251040.GAA08401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:47 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@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 : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-05.txt Pages : 28 Date : 24-Jul-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-05.txt 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-session-timer-05.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-session-timer-05.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: <20010724132840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Jul 29 13:07:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26748 for ; Sun, 29 Jul 2001 13:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18614; Sun, 29 Jul 2001 12:41:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18580 for ; Sun, 29 Jul 2001 12:41:30 -0400 (EDT) Received: from femail36.sdc1.sfba.home.com (femail36.sdc1.sfba.home.com [24.254.60.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25932 for ; Sun, 29 Jul 2001 12:40:28 -0400 (EDT) Received: from tnpfrancis ([24.5.201.140]) by femail36.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010729164122.MOCI20441.femail36.sdc1.sfba.home.com@tnpfrancis> for ; Sun, 29 Jul 2001 09:41:22 -0700 Message-ID: <007001c1184d$4b08f070$6601a8c0@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: Date: Sun, 29 Jul 2001 09:41:19 -0700 Organization: TAHOE Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP and v4/v6 translation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Has anyone written down how to interwork SIP between v4 and v6 hosts? PF _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 05:16:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10317 for ; Mon, 30 Jul 2001 05:16:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14778; Mon, 30 Jul 2001 05:03:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14716 for ; Mon, 30 Jul 2001 05:03:01 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09639 for ; Mon, 30 Jul 2001 05:01:59 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f6U92eQ10121; Mon, 30 Jul 2001 12:02:40 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.8880.627402.538638@lohi.eng.telia.fi> Date: Mon, 30 Jul 2001 12:02:40 +0300 (EEST) To: sip@ietf.org X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Subject: [Sip] proxy routing of a request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ther first paragraph of chapter 16 of bis-03 says: Record routing is the process whereby a proxy server can request to receive all messages between two UAs for a particular call leg. The proxy accomplishes this by inserting a header, called Record-Route into the initial request that begins the call leg. The user agents use these headers to construct a set of Route headers, that gets inserted into subsequent requests in the call leg. The Route headers contain a set of proxies that the request must visit on its way from one UA to another. Proxies use these to forward the requests, much like strict IP source routing. the above is not true, since if an invite arrives at the uas with only one proxy listed in the record-route, according to 16.2 the route-set contains uri-from-the-record-route uri-from-the-contact when the uas then sends a bye, according to 16.4 the request-uri will contain the uri of the proxy that inserted the record-route and the route header will contain the uri of the contact: The request is constructed as specified in Section 15.4. The UA then takes the list of URI in the route set. The top URI is inserted into the request URI of the request, including all parameters. Any URI parameters not allowed in the request URI MUST then be stripped. Each of the remaining URIs (if any) from the route set, including all URI parameters, are placed into a Route header into the request, in order. as the result, the route header of the bye will not contain uri of the the record-routing proxy as the first paragraph claims. one could say that the first paragraph just gives an overall idea of what happens and is not intended as an accurate description. the problem, however, seems to be more than editorial, since if the uas is using another proxy to route its requests, this other proxy will route the bye according to 16.5 as follows: When a proxy receives a request, it MUST check for the existence of a Route header. If one exists, it MUST pop that Route header, and place it (including all URI parameters) into the Request-URI. in this case the request-uri contains the uri of the proxy, but since there is also a route header containing the contact uri, this other proxy will forget the request-uri and route the bye directly to the uac that originally sent the invite. as the result, the very idea of the record-routing proxy wanting to be on the path of subsequent requests gets lost. section 16.4.1 talks about UAs and outbound proxies, but i don't see that the text would change what i described above, since the main rule still is: A UA which uses a local outbound proxy, and attempts to send a subequent request in a call leg with a route set, SHOULD use the procedures in Section 16.4. the rest of the section seems to apply only to dns uncapable UAs. what is the point that i'm missing here? -- juha _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 09:14:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20700 for ; Mon, 30 Jul 2001 09:14:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19813; Mon, 30 Jul 2001 09:00:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19781 for ; Mon, 30 Jul 2001 09:00:04 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20275 for ; Mon, 30 Jul 2001 08:59:03 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 Jul 2001 13:00:03 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 14:00:49 +0100 From: "Neil Deason" To: Cc: "Rakesh Shah" , "'Sip@Ietf. Org'" Date: Mon, 30 Jul 2001 14:00:48 +0100 Message-ID: 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 Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-OriginalArrivalTime: 30 Jul 2001 13:00:49.0053 (UTC) FILETIME=[A7936CD0:01C118F7] Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-campbell-sip-e164-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Some comments as requested: - The title of the draft in the page headers appears mangled to me. It also doesn't match the published name (draft-campbell-sip-e164-00.txt). - Section 'User Agent Client' says "A UAC that is configured to use a local outbound proxy SHOULD not use enum." This could use a SHOULD NOT. - On the editors note about including text re: interpreting the NAPTR RRs. I can't see what needs to be added beyond RFC 2916. - Application Examples: E.164 as a Universal Identifier. The editor identifies this as a somewhat ill advised thing to do so other examples would be preferable. Would an example of how a 1800 number could be mapped on to an IP endpoint in a SIP network be a better example? - Reference [1] has moved on from an ID to RFC 2916. - On a personal level I was left wondering what this draft really says beyond that SIP entities can try to use DNS to resolve E.164 numbers. The how this works is dealt with by RFC 2916 and I am not sure what really can be said about the why and when this is done. Not that the draft doesn't offer sensible advice but the decision ultimately seems to be a local policy decision. One thing that could have added interest would have been some info on how TRIP may relate to routing to E.164 numbers on SIP networks. If there is more than one path open for making the routing decision precedence may need specifying. There is a draft on ENUM, SIP URIs, TRIP, and Gateways: http://search.ietf.org/internet-drafts/draft-ymbk-enum-trip-00.txt A reference or even some closer co-operation between the authors may be of interest. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 12:17:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02630 for ; Mon, 30 Jul 2001 12:17:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26259; Mon, 30 Jul 2001 12:06:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26229 for ; Mon, 30 Jul 2001 12:06:55 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01594 for ; Mon, 30 Jul 2001 12:05:54 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15270; Mon, 30 Jul 2001 11:53:03 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11162; Mon, 30 Jul 2001 11:53:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Jul 2001 11:53:03 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465862@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Price, Richard'" Cc: "'sip@ietf.org'" Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Mon, 30 Jul 2001 11:52:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree that any text (or BER) protocol is compressible using techniques that recognize repetition of sequences. SIP is especially sensitive to anything that detects repeated domain names. Megaco has both text and binary because there were two camps who could not agree. The binary camp was convinced that their encoding would be significantly smaller and faster. In order to avoid a split, and thus two close, but not identical protocols, we compromised. I actually proposed, and at one point had agreement on a coin toss! The coin was tossed, and it came out text. The binary folks succeeded in overturning the agreement on the coin toss. Thus we have both. Around 95% of implementations so far are text only. Brian > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Thursday, July 26, 2001 9:08 AM > To: 'Rosen, Brian' > Cc: 'sip@ietf.org' > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Hi, > > The compression ratio depends on how the binary encodings are > obtained. BER is not designed for efficiency and will most > likely produce binary encodings that are even longer than their > text equivalents. > > In contrast, schemes like EPIC and Lempel-Ziv are designed > specifically to convert text strings into shorter binary > equivalents. Both schemes use Huffman compression for this task, > which on its own would get a compression ratio of about 1.2:1. > Compression is further improved by introducing a new binary > encoding that means "text is same as a previous text string". > > It's debatable whether this should be called "binary encoding" or > not. However I stick by my original point (that you can implement > a combined SIP stack/SIP compressor to lower the overall processing > requirements). > > Out of curiosity, what was the motivation for doing MEGACO > as both text and binary? > > Regards, > > Richard P > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, July 25, 2001 6:43 PM > To: Price, Richard > Cc: 'sip@ietf.org' > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Megaco is a protocol with binary and text encodings. > The binary is BER encoded, and there are exactly equivalent > ASN.1 and ABNF descriptions of the encodings to match the > protocol text. The results we have so far suggest that message > length of binary encoding is larger than the text encoding > for the same message. This isn't speculation, it's what we > measure when you take an implementation that has both encodings > and look at the message lengths. > > If you simply use binary encodings for the basic syntactic > constructs, you will get negative compression. The compression > available comes from dealing with the contents of the > values, not the basic method/header constructs. > > Brian > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Wednesday, July 25, 2001 11:58 AM > > To: 'Christer Holmberg'; Jonathan Rosenberg > > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > > > > Hi, > > > > Is compression so different from binary encoding? > > > > Our own EPIC scheme uses the BNF description of a protocol to > > "learn" a > > set of binary encodings for the protocol. The compressor > then replaces > > each text string with its equivalent binary encoding. > > > > It is feasible to write a SIP implementation that uses these binary > > encodings directly, missing out the text-based version of > the message > > altogether. This is not a change to the core protocol, but rather a > > combined SIP stack/SIP compressor. > > > > Normally this would be a big amount of effort for very little gain. > > However it certainly solves the concerns about processing > requirements > > (as it doesn't have any!) > > > > Regards, > > > > Richard P > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Wednesday, July 25, 2001 3:26 PM > > To: Jonathan Rosenberg > > Cc: 'Michel de Boer'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: [rohc] Re: [Sip] New I-D on compression of SIP > > > > > > > > Hi, > > > > A few comments from me. > > > > First, my personal opinion about the binary talk: let's skip > > the binary > > talk. If we start talking about it, we will argue about it > > for at least > > 6 months (I think the people who have been involved in the > MEGACO work > > know what I'm talking about...) Then, IF we would decide to also go > > binary, experience (read: MEGACO) has shown that it's not > that easy to > > define text- and binary rules that "match" 100%. Ok, SIP > > would probably > > be a little easier than Megaco, since we don't have wildcard > > values etc, > > but still. Then we would also have the encoding negotiation > > problem, and > > the issue about which nodes MUST/SHALL/SHOULD support what... > > And, which > > has been mentioned also by others, that we really don't > transport that > > much information in SIP, so would the gain (not very much, > I'd say) be > > worth the pain (very much, I'd say)? > > > > Compression is more "flexible". For most > > networks/architectures I don't > > think it will provide very much, but if peope want to use > it they are > > free to do so - but it would not affect the core protocol. > > > > Then, if we assume that we need compression, we have the other > > questions, which I think are more important to discuss: > > > > 1. Hop-to-hop vs end-to-end > > > > 2. Do we compress the whole message, or only parts of it > (the message > > body, for example) > > > > 3. Compression negotiation > > > > a) Do we use an external negotiation mechanism, and > > negotiate before > > we start the SIP session. Since the proxies in > many cases > > also must be involved in this negotiation we would probably > need some > > kind of > > "centralized" function for this. > > > > b) Do we send the initial INVITE uncompressed (or partly > > compressed) > > with a Supported/Require/Proxy-Require > > header listing the supported compression algorithms. > > And again, if > > the proxies must support the compression, there > must be a > > way for them to indicate it (can be done for example either by > > using Proxy-Require, or some Record-Route parameter) > > > > c) Do we use "manual" configuration, either by hand or by > > using some > > of the SIP extensions that have been defined for remote > > configuration. > > > > > > My thoughts... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Michel de Boer [mailto:michelboer@lucent.com] > > > > Sent: Thursday, July 19, 2001 3:54 AM > > > > To: Jonathan Rosenberg > > > > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > > Subject: Re: [Sip] New I-D on compression of SIP > > > > > > > > > > > > Jonathan, > > > > > > > > You state that one of the ways to achieve message size > > reduction is to > > > > define a binary encoding, but that this introduces > > interoperability > > > > problems. > > > > > > > > How can a compression scheme based on dynamically constructed > > > > codebooks > > > > be simpler? > > > > > > Simpler, perhaps not (although if you're using PER or BER, > > its not clear to > > > me that this is simpler, codewise). But, it totally breaks > > compatibility > > > with the existing protocol. By pushing this into a > > transport problem, it is > > > isolated to the two entities that need to worry about it. > > > > > > > In my opinion this approach is more prone to > > > > interoperability > > > > issues. > > > > > > Thats not clear at all. Either way, we would require new code in > > > implementations. For a new binary coding, we would be back > > to square 1, so > > > that everyone would have to work out the kinks in their > > encoder/decoders for > > > every element in the syntax. However, with a shim, we > > leverage existing, > > > mature parsers and generators. We add a layer that is not > > specific to SIP, > > > so it has no syntax or anything else to get wrong. Its > > defined by a fairly > > > simple set of state machines, which should not be that hard > > to get correct. > > > I would argue its easier to get that right than it is to > > get a totally new > > > encoding of SIP right. > > > > > > > Codebooks can get out of sync. > > > > > > Yes, and that does need to be handled in the protocol. > > > > > > > As codebooks are specific to a sender- > > > > receiver pair, an entity communicating with multiple other > > > > entities, i.e. > > > > a proxy talking to many UA's must manage multiple codebooks. > > > > > > Well, the problem at hand is really a wireless phone > > talking to its local > > > outbound proxy. THus, the phone has only one relationship, > > and the proxy has > > > one with each phone it communicates with. This pushes the > burden of > > > compression to the elements that benefit the most from it. > > From this point > > > onwards, normal SIP would be used, and so its compatible > > with existing > > > proxies and UAs. > > > > > > > > > > > For trouble shooting one might want to monitor a network > > interface and > > > > analyze SIP messages coming in. It's impossible to read a > > compressed > > > > message. > > > > > > The output of the decompressor would need to be monitored. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 12:34:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04285 for ; Mon, 30 Jul 2001 12:34:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26824; Mon, 30 Jul 2001 12:28:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26795 for ; Mon, 30 Jul 2001 12:28:08 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03691 for ; Mon, 30 Jul 2001 12:27:06 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 Jul 2001 16:28:07 UT Received: from jhornsby ([193.195.52.78]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 17:28:55 +0100 From: "Jo Hornsby" To: "Dean Willis" , Subject: RE: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt Date: Mon, 30 Jul 2001 17:28:07 +0100 Message-ID: <006301c11914$9d63faa0$4e34c3c1@ubiquity.co.uk> 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 Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <031b01c11056$1954bc20$56fa403f@directlink.net> X-OriginalArrivalTime: 30 Jul 2001 16:28:55.0812 (UTC) FILETIME=[BA43A440:01C11914] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > One might ask why a nonparticipatory redirector returns cookies > when UASes are required to store cookies and resubmit them. I'm getting confused. Should this read "UACs"? > It's because of a case that > I'm not sure is handled clearly in the current draft. How does a > participatory server indicate that a particular cookie should be deleted? > Remember that the UAS doesn't know whether a particular server is > participatory or not on a given cookie. So one approach would be > a for a UAS to discard cookies for a particular call when those > cookies aren't present in a 302 response to that call. I'm not > entirely happy with this approach, and the floor is open for > suggestions. The problem that leaps out at me here is that a Redirect Server that knows nothing of this extension will not return the cookie, which would be interpreted as a deletion with this logic. This doesn't seem desirable. Also, the draft seems to indicate that this behaviour be extended to classes other than 3xx. The moment we break out of 3xx, it seems to me that deciding whether a SIP Server is a Redirect Server or not becomes a little less clear. How about looking at the response to see if it has a Cookie header in? If it doesn't, then the Redirect Server either doesn't understand the extension or doesn't care. If it does have a header, then this could be taken as the updated list of Cookies to use. This would require a slight change to the grammar to allow no Cookies (so that all could be deleted), but that doesn't seem too offensive. Cheers, - Jo. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 12:54:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06035 for ; Mon, 30 Jul 2001 12:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27304; Mon, 30 Jul 2001 12:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27273 for ; Mon, 30 Jul 2001 12:39:07 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04700 for ; Mon, 30 Jul 2001 12:38:06 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA11245 for ; Mon, 30 Jul 2001 09:37:48 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA27305 for ; Mon, 30 Jul 2001 09:37:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 11:37:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E26E@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: sip@ietf.org Date: Mon, 30 Jul 2001 11:37:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] session ID filed in service-examples-02 section 2.1 F10 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org draft-ietf-sip-service-examples-02.txt 2.1 Call Hold F10 /* User B places User A on hold. Note that the version is incremented in the o= field of the SDP */ o=UserB 2890844528 2890844528 IN IP4 client.there.com Isn't the session ID field supposed to stay the same as in the original 200 OK that B sent? (i.e. 2890844527) ======================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 ======================================================================= _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 13:14:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07850 for ; Mon, 30 Jul 2001 13:14:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27970; Mon, 30 Jul 2001 13:01:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27930 for ; Mon, 30 Jul 2001 13:01:03 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06550 for ; Mon, 30 Jul 2001 13:00:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6UH05ki019369; Mon, 30 Jul 2001 13:00:06 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 13:00:40 -0400 Message-ID: From: Jonathan Rosenberg To: "'Markus.Isomaki@nokia.com'" , Jonathan Rosenberg , christer.holmberg@lmf.ericsson.se, sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt Date: Mon, 30 Jul 2001 13:00:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, July 27, 2001 9:08 AM > To: jdrosen@dynamicsoft.com; christer.holmberg@lmf.ericsson.se; > sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt > > > WHy is it really bad? Well, draft-ietf-sip-guidelines clearly > > describes why. > > THe extension mandates Proxy-Require *and* Require. According to the > > guidelines draft: > > > > The Proxy-Require header SHOULD be avoided at all costs. The > > failure likelihood in an individual proxy stays > > constant, but > > the path failure grows exponentially with the > > number of hops. > > > > This is true if you assume that the support for a feature is a random > variable. However, it could also be possible to deploy a new > feature in > proxies by implementing it in islands of proxies such as ones serving > wireless hosts. SIP does not assume a closed universe. I would like for those wireless handsets to be able to call wireline SIP phones supported by existing SIP proxies. Your proposal will require all record-routing proxies to support this extension, including ones outside of the "wireless islands". > > Perhaps you are concerned about overhead on the wireless > > link. In terms of > > byte savings, using something like the ROGER protocol or my > > UDP compression > > proposal, > > http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp > > -00.txt, you > > get far, far, far better compression gains than the > improvements afforded > > from eliminating this message. > > Yes, call setup delays and wireless link overhead would be the main > motivation for trying to reduce the number of messages/bytes > needed. It's > true that QoS setup & radio bearer establishment can start > right at the same > time as PRACK is being sent and 200 OK for it is being waited for. > > However, especially if compression is not used, we have > calculated that > PRACK-200 RTT takes actually longer than QoS setup in some of > the wireless > systems (read GERAN) that we are dealing with. So, that is > the constraint. I > agree it may not be a big difference, and if compression is being > standardized, as I really hope, your argumentation is correct. There are something like 4 drafts on the subject of sip compression within the rohc group. I plan on attending the meeting to argue that this work be taken up as a standards track item somewhere, probably rohc. Without that, there will be a MILLION proposals for a vagary of "improvements to sip for wireless performance", which will all ultimately kill sip interoperability and get performance improvements only by by slowly and painfully hacking up the protocol in ways much like you propose. A middle-layer compression gives tremendous benefits in terms of compression and wireless performance without killing the protocol. The cost is a moderate increase in complexity, and I feel that is well justified. > > There is still another issue. What if 200 OK for PRACK or any > other SIP > message is lost? That causes a retransmission, and the call > setup delay > becomes larger. Following the reasoning you had above about > the proxies, the > likelihood of loss grows exponentially with the number of messages. This is no different in what you are proposing. You still need retransmissions for reliability. In your case, what if the 1xx is lost? Or the PRACK is lost? Same difference. > > > So, the SPRACK proposal: > > > > 1. necessitates Proxy-Require, which is an effective break in > compatibility > > with the SIP protocol, > > The extension COULD be used with Proxy-Require, > however in the I-D we propose the usage of _Proxy-Supported_, > (as described in draft-hoeneisen-sip-proxy-supported-00.txt) > which means, that the call can be set-up with the first > INIVITE and depending, whether all record routing proxy > servers support the s100rel, either the s100rel or the > 100rel mechanisms are applied, i.e. no 420 Bad Extension > for s100rel is sent by any proxy server. > There will be no path failures with this proposal. Well, you are adding even more complexity and mess with this Proxy-Supported, just to support this one thing which buys you something like 5% improvement in bandwidth usage and questionable improvements in latency. This is what I mean about lots of hacks to the protocol, cutting it to pieces until it dies.... > > So, I do not understand why this is a good path to follow. > > > > IF it was possible to redo SIP, would Provisional > Responses/PRACK be done > differently? I guess so. Our proposal is one way, and it > provides backwards > compatibility with a fallback system. I don't know if there > ever will be > SIPv3... If I could do SIP over from scratch, I would change many, many things, not the least of which was reliability of provisional responses. But, we have no such luxury. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 15:20:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17154 for ; Mon, 30 Jul 2001 15:19:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01245; Mon, 30 Jul 2001 15:09:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01211 for ; Mon, 30 Jul 2001 15:09:57 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16382; Mon, 30 Jul 2001 15:08:55 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f6UJAI316267; Mon, 30 Jul 2001 14:10:19 -0500 Message-ID: <00ca01c1192b$5a3cb2a0$ee036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: Cc: "Brian Rosen \(E-mail\)" , "Joerg Ott" , "Scott Bradner \(E-mail\)" , "Allison Mankin \(E-mail\)" , "IETF SIP" Date: Mon, 30 Jul 2001 14:07:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP WG Agenda, IETF 51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The following is the agenda for SIP (Session INitiation Protocol) WG at IETF 51. ---------------------------- Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 0900 Agenda Bash -- Chairs 0910 Status Review -- Chairs 0920 Last Call Process and Report -- Chairs 0930 Call Control Extensions draft-biggs-sip-replaces-01.txt -- Billy Biggs draft-ietf-sip-refer-00.txt -- Robert Sparks 1000 Events (Two Issues) draft-ietf-sip-events-00.txt -- Adam Roach 1030 Early Media Extensions draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg 1100 SIP and NAT Extensions draft-boer-sip-src-00.txt -- Michel de Boer draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg 1130 break Session 2: 7Aug01 0900-1130 King's Suite/Sandringham 0900 Agenda Bash -- Chairs 0910 Message Integrity via Digest draft-undery-sip-digest-00.txt -- James Undery draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg 0930 Proxy Server Features Negotiation draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1000 Reliability of Provisional Messages Extensions draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1030 Discussion of Remote-Party Extensions Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston 1100 Discussion of Further Open Issues 1130 Close _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 17:29:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26240 for ; Mon, 30 Jul 2001 17:29:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04957; Mon, 30 Jul 2001 17:07:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04927 for ; Mon, 30 Jul 2001 17:07:00 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24828 for ; Mon, 30 Jul 2001 17:05:59 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GHB00B191A4A9@firewall.mcit.com> for sip@ietf.org; Mon, 30 Jul 2001 21:06:04 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHB0030119URW@dgismtp01.wcomnet.com>; Mon, 30 Jul 2001 21:06:04 +0000 (GMT) Received: from wcom.com ([166.42.33.181]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHB0032M19LH5@dgismtp01.wcomnet.com>; Mon, 30 Jul 2001 21:05:46 +0000 (GMT) Date: Mon, 30 Jul 2001 15:59:03 -0500 From: Alan Johnston Subject: Re: [Sip] session ID filed in service-examples-02 section 2.1 F10 To: Baniel Uri-CUB001 Cc: sip@ietf.org Message-id: <3B65CA97.907EBB05@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <35DBB8B7AC89D4118E98009027B1009B0137E26E@IL27EXM10.cig.mot.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Thanks for the comments. You are right, I have incremented both the version and the session fields in the SDP - I should keep the session field the same. Thanks, Alan Johnston sip:alan@siptest.wcom.com Baniel Uri-CUB001 wrote: > draft-ietf-sip-service-examples-02.txt 2.1 Call Hold F10 > > /* User B places User A on hold. Note that the version is > incremented in the o= field of the SDP */ > > o=UserB 2890844528 2890844528 IN IP4 client.there.com > > Isn't the session ID field supposed to stay the same as in the original 200 > OK that B sent? (i.e. 2890844527) > > ======================================================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 > ======================================================================= > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 17:44:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27563 for ; Mon, 30 Jul 2001 17:44:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05771; Mon, 30 Jul 2001 17:39:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05735 for ; Mon, 30 Jul 2001 17:39:00 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26871 for ; Mon, 30 Jul 2001 17:37:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6ULbvjc021360; Mon, 30 Jul 2001 17:37:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 17:38:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Romeo Zwart'" , Jonathan Rosenberg Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Date: Mon, 30 Jul 2001 17:38:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Romeo Zwart [mailto:Romeo.Zwart@att.com] > Sent: Thursday, July 19, 2001 3:27 PM > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org; rohc@cdt.luth.se > Subject: Re: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt > > > Jonathan, > > In the diagram of section 4.6, the WRITE HIGH REFERENCE token > is shown as > identical to the WRITE HIGH token. I assume this is a typo. > What is the > intended token for the WRITE HIGH REFERENCE case? No, they're not the same. The WRITE HIGH REFERECE appears on the top of page 9. So, WRITE REFERENCE is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| index |1|1|0| TC | tokens.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and WRITE HIGH REFERENCE is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| index |0|1|1| index |x|x|x| TC | tokens +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In the same diagram, is there a defined value for the three > 'padding' bits > that fill up the third octet? No. It doesn't really matter. > > In section 5 you describe your proposed new LZW variant. Your > 'friendly > test' shows very nice results, except for the initial message in the > series, which has an (expected) larger compressed size than the > uncompressed size. Have you considered jumpstarting the > codebook with a set > of default entries (e.g. INVITE, From:, To:, etc.)? Would you expect > earlier convergence? Yes, I had thought about usage of static codebooks, which is used in one of the other proposals. I think its probably a good idea. The draft I wrote up is not really meant to be a complete solution, and I expect the final compression work will be a synthesis of many of the fine ideas in SCRIBE, ROGER, EPIC, and this proposal. My main goals with this were to emphasize some key points: 1. this is the BEST way to solve the problem for wireless usage of SIP 2. the protocol is best viewed as a mechanism for maintenance and management of codebooks, and that allowing different compression algorithms within that framework is a good thing 3. There are reasonable ways to handle compression of out of order messages that must be taken into account. 4. The mechanism, from a SIP perspective, is best done at the "transport layer", in the sense that its something for which SRV record-entries are defined, and a SIP transport param is defined, so that the existing transport negotiation mechanisms in SIP can be applied. Looking forward to discussing it all in London.... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 18:01:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28598 for ; Mon, 30 Jul 2001 18:01:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06276; Mon, 30 Jul 2001 17:56:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06244 for ; Mon, 30 Jul 2001 17:56:50 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28219 for ; Mon, 30 Jul 2001 17:55:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6ULu9jc021422; Mon, 30 Jul 2001 17:56:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 17:56:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'Aniruddha Kulkarni'" , Sean Olson , rohc@cdt.luth.se, sip@ietf.org Subject: RE: [Sip] SIP Compression Date: Mon, 30 Jul 2001 17:56:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > Sent: Wednesday, July 25, 2001 7:45 AM > To: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > Subject: Re: [Sip] SIP Compression > > > If one has high latency link then nothing can be done about > it. Compression > is not a solution for that. > If one has low bandwidth link and large data to send then > Compression can be > the solution. > SIP messages take up only small portion of the available > bandwidth (even on > Cellular links..). Then why use compression for SIP messages? Well.. > cellular links have high BER, in this situation it is > advisable to have > smaller packets to reduce error probability.. that is why use > compression. > .. correct? As Dean has indicated, its the latency that becomes an issue. The amount of time it takes to send a large message can impact post dial delay and other related metrics. > > Still large number of connections to internet are over > telephone modem links > with low bandwidth, comparable with latest cellular links. > Isn't it useful > to have end-to-end SIP message compression in that situation? I think there is some confusion over e2e vs. hBh. The proposed compression scheme is, based on the SIP meaning, hop by hop, because its between a SIP client and its proxy. In the IP stack, this is end to end, since it occurs between application entities that send messages directly to each other over an IP network. The SIP compression proposal is NOT a link-layer compression mechanism, as ROHC itself is. > > How much the SIP compression schemes are dependant on RoHC? > Could they have > in-built mechanism for configuration negotiation? Should they > demand this > facility from lower layers? It seems to me that these schemes > work more at > application level and should have configuration negotiation > at that level > only. That way they could be easily extened for use on > end-to-end rather > than limiting them to hop-to-hop (by depending on RoHC). The proposed compression scheme does not depend on ROHC, nor does it depend on lower layers (IP or below) in any way. Negotiation of usage of the scheme is done at the SIP layer. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > ----- Original Message ----- > From: > To: "'Aniruddha Kulkarni'" ; > ; > Sent: Tuesday, July 24, 2001 6:27 PM > Subject: RE: [Sip] SIP Compression > > > > SIP is not intended to transport large amounts of information. > > That plus the ratio of bandwidth used by signalling vs. > > the bandwidth used by the media, means that signalling compression > > for SIP is not in general a problem. It only really becomes a > > problem on low bandwidth, high latency *links* such as a cellular > > link where sometimes every byte counts. > > > > In short, I believe signalling compression is a hop-by-hop > > problem and not an end-to-end one. A hop-by-hop solution seems > > appropriate in this case. > > > > It should also be noted that you can always apply gzip compression > > to the MIME body of a SIP message to achieve some end-to-end > > compression. IMHO, this is not needed. > > > > I believe the compression techniques that have been > > described so far (ROGER, SCRIBE, EPIC, etc.) are > > fairly generic and would work well on a variety of > > link types. Some have been tailored with cellular > > in mind. > > > > Hopefully this addresses your concerns, > > Sean Olson > > Ericsson Inc. > > > > -----Original Message----- > > From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > Sent: Tuesday, July 24, 2001 8:30 AM > > To: rohc@cdt.luth.se; sip@ietf.org > > Subject: [Sip] SIP Compression > > > > RoHC works hop-to-hop, not end-to-end when there are > multiple hops between > two ends. > > Does SIP Compression mechanisms also have this constraint? > If yes, why? > > Are those designed to work only on cellular link between > mobile terminal > and > > fixed end of cellular link (hop-to-hop) ? Why those > mechanisms are not > designed > > for end-to-end compression? > > (reduce large payloads ,whatever be the link characteristics...) > > > > ---Aniruddha > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 18:09:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29197 for ; Mon, 30 Jul 2001 18:09:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06095; Mon, 30 Jul 2001 17:50:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06010 for ; Mon, 30 Jul 2001 17:50:17 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27871 for ; Mon, 30 Jul 2001 17:49:16 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6ULn7jc021402; Mon, 30 Jul 2001 17:49:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 17:49:41 -0400 Message-ID: From: Jonathan Rosenberg To: "'Romeo Zwart'" , zhigang.liu@nokia.com, Romeo.Zwart@att.com, jundery@ubiquity.net, Lars-Erik.Jonsson@epl.ericsson.se Cc: Jonathan Rosenberg , sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Mon, 30 Jul 2001 17:49:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Romeo Zwart [mailto:Romeo.Zwart@icoe.att.com] > Sent: Friday, July 20, 2001 7:38 AM > To: zhigang.liu@nokia.com; Romeo.Zwart@att.com; jundery@ubiquity.net; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: jdrosen@dynamicsoft.com; sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > > At 09:28 PM 7/19/2001, zhigang.liu@nokia.com wrote: > >> The draft talks about the encoder that learns "in some way" > >> that the message was received at the other end. Magic I can > >> think of here would either look very much like an (implicit) > >> acknowledgement mechanism, where the decoder and encoder on > >> one side of the link communicate to confirm message reception. > >> Alternatively, message confirmation might depend on direct > >> signalling from the application layer to the compression layer. > >> However, since the SIP layer is not aware of the encoder, I > >> don't think that's a valid approach. I'd be interested to > >> how this is perceived to work. > > >Or explicit acknowledgement, which can be either stand-lone or > >piggybacked on the compressed message from the other direction. > >This makes the compression layer independent of the upper layer > >(e.g. SIP in this case). > > The 3-way SCRIBE acknowledgement seems rather elaborate for > what it needs to do. The ROGER draft section 5.6 shows that > at least the third leg of the acknowledgement can be done > implicitly too. > > >Of course, if there is some interface > >between SIP and compression layer, we should not exclude the > >use of such interface. > > My understanding of the SIP compression draft is that the > interface is left unspecified. However, defining an internal > mechanism to allow the application layer to keep track of the > messages sent at the compression layer seems more complex than > defining a simple acknowledgement scheme. The idea with the proposal (and, BTW, SIP Compression is a misnomer since the mechanism, like everyone elses, is not application specific. I called the draft Compression of SIP to draw the SIP community's attention to this kind of approach as the preferred solution) is that the application layer protocol already has its own reliability and handshake messages. So, there would be some kind of API interface between the sip layer and the transport, which the sip layer would use to inform the transport when a message has been acknowledged. The benefit is message overhead reduction and simplicity, at the cost of requiring a small amount of support from the application (sip) to support the transport. Is it worth it? Maybe, maybe not. I am not particularly religious on this, and my goal was to just keep it simple. James Undery wrote: > "Lars-Erik Jonsson (EPL)" wrote: > > > Hi Jonathan, > > > > First of all I have to say that I think it is good that we > now have several contributors to this discussion about > signaling compression, e.g. SIP compression. I have read your > draft and have a number of comments but before I take them > all I would like to ask you for some clarifications about how > you mean this new "protocol shim" is introduced in reality. > You say that it becomes a new alternate transport but it is > not clear how this is indicated. Is your intention to create > a new "UDP-compress" transport protocol (new protocol ID)? > > I think by this Jonathan means to have a new transport > parameter for SIP URLs and position the encoding/decoding > just above the UDP "stack" code and below the SIP "stack" > code. Yes, exactly. I am not proposing a new tranport protocol that needs to be signaled within IP (peer to UDP, TCP), but rather something that SIP considers a transport protocol. This means that we can have SRV records of the form: _sip._cudp.foo.com which would identify servers for foo.com providing SIP over this transport (Compressed UDP, or whatever we call it). We can also have a SIP URL transport param: sip:jdrosen@dynamicsoft.com;transport=cudp which can be used in record-routing, for example. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 18:36:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00679 for ; Mon, 30 Jul 2001 18:36:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06916; Mon, 30 Jul 2001 18:14:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06887 for ; Mon, 30 Jul 2001 18:14:44 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29436 for ; Mon, 30 Jul 2001 18:13:43 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6UMEEi09711 for ; Mon, 30 Jul 2001 17:14:14 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 30 Jul 2001 17:14:11 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Jul 2001 17:14:11 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Date: Mon, 30 Jul 2001 17:14:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEZQBi2Zpsow4UsEdWBSQBQi2X+DwAAllqQ To: , Cc: , X-OriginalArrivalTime: 30 Jul 2001 22:14:11.0314 (UTC) FILETIME=[F5AA6520:01C11944] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA06888 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The following is a very good way to proceed. I share the same view as yours (need to do some homework on point 4 to understand the details). It is also important that we can proceed fast to meet 3GPP schedule. Otherwise, we will all spend 20 or more seconds listening to the ring each time we make a SIP call. Br, Zhigang > Yes, I had thought about usage of static codebooks, which is > used in one of the other proposals. I think its probably a good idea. > > The draft I wrote up is not really meant to be a complete > solution, and I expect the final compression work will be > a synthesis of many of the fine ideas in SCRIBE, ROGER, > EPIC, and this proposal. My main goals with this > were to emphasize some key points: > > 1. this is the BEST way to solve the problem for wireless usage of SIP > 2. the protocol is best viewed as a mechanism for maintenance > and management of codebooks, and that allowing different compression > algorithms within that framework is a good thing > 3. There are reasonable ways to handle compression of out of > order messages that must be taken into account. > 4. The mechanism, from a SIP perspective, is best done at the > "transport layer", in the sense that its something for which SRV > record-entries are defined, and a SIP transport param is defined, > so that the existing transport negotiation mechanisms in SIP > can be applied. > > Looking forward to discussing it all in London.... > > -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 18:50:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01428 for ; Mon, 30 Jul 2001 18:50:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06999; Mon, 30 Jul 2001 18:17:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06970 for ; Mon, 30 Jul 2001 18:17:32 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29610 for ; Mon, 30 Jul 2001 18:16:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6UMGnjc021481; Mon, 30 Jul 2001 18:16:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 18:17:23 -0400 Message-ID: From: Jonathan Rosenberg To: "'Price, Richard'" , "'Dean Willis'" , "'Christer Holmberg'" , Jonathan Rosenberg Cc: "'Michel de Boer'" , sip@ietf.org, rohc@cdt.luth.se Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Mon, 30 Jul 2001 18:17:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Thursday, July 26, 2001 5:17 AM > To: 'Dean Willis'; 'Christer Holmberg'; Jonathan Rosenberg > Cc: 'Michel de Boer'; sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Hi, > > We solved the "new token" problem by having a binary version > of every ASCII > character. If there is a binary version of the whole token > then we send that, > otherwise we send the binary versions of each individual character. It seems like what you are really talking about is a static dictionary based on a study of the BNF of the protocol. I suspect that you could probably hand tune a static dictionary to be even better based on knowledge of what actually comes in a SIP message in real scenarios. I still think a dynamic dictionary ontop of a static one like you propose is even better, any my initial tests gave me 8:1 compression, far better than anything reported with pure static (and I will note that this was with an LZW variant; if you pay the compute overhead of LZSS it will really rock, but I have not done explicit tests.) Is the improved efficiency of dynamic codebooks worth the cost of state management that comes with dynamic codebooks? Indeed thats a good question, and one which depends entirely on your view of whats important in the system. It is not a cut-and-dry comparison. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 19:13:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02191 for ; Mon, 30 Jul 2001 19:13:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07474; Mon, 30 Jul 2001 18:33:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07445 for ; Mon, 30 Jul 2001 18:32:58 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00476 for ; Mon, 30 Jul 2001 18:31:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6UMWJjc021532; Mon, 30 Jul 2001 18:32:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 18:32:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Euchner Martin'" , "'Michael Thomas'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Subject: RE: [Sip] New I-D on compression of SIP - security issues Date: Mon, 30 Jul 2001 18:32:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] > Sent: Wednesday, July 25, 2001 12:20 PM > To: 'Michael Thomas'; Jonathan Rosenberg; Euchner Martin > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: RE: [Sip] New I-D on compression of SIP - security issues > > > Security experts, > > my understanding of draft SIP udpcomp is, that the > compression occurs on lower protocol layers (as indicated in > chapter 2). However, I do not see how this would make sense > when assuming that the SIP message to be compressed has been > integrity protected and/or possibly encrypted on a SIP > application protocol layer above the compression scheme. It > is well known that once a message has been encrypted there is > no way for compression afterwards; thus, compression must > come before encryption. My recommendation is, that the SIP > compression scheme be applied before any SIP message security > processing takes place. Sure, that is obviously what you want. Unfortunately, doing SIP-layer compression first, followed by SIP-layer encryption, breaks the nice, clean transport-layer model in the draft I have proposed. Fixing that depends on how the SIP layer encryption is done. Mike Thomas has proposed a framework for such a thing in: http://search.ietf.org/internet-drafts/draft-thomas-sip-sec-framework-00.txt His approach uses multiparts to convey compressed entities. An interesting idea is to treat each multiparty as a "transport stream" in its own right. A multipart is associated with a compression context. You compress it within that context, and the resulting thing is then encrypted and placed into the message. Whats interesting is that the compression context would then exist between the sender of the message and the recipient of the specific multipart (Mike has used a new To-field construct, X-SIP-SECURE-TO to designate this). That means that support for compression would need to extend to proxies beyond the outbound proxy for the mobile. Now, all of this is an issue if you think that sip layer encryption is a common thing. I suspect most of the times, transport layer encryption is more common (IPSec or TLS). THose would happen after the compression has been applied, so there is no problem. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Jul 30 23:44:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14847 for ; Mon, 30 Jul 2001 23:44:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12984; Mon, 30 Jul 2001 23:30:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12928 for ; Mon, 30 Jul 2001 23:30:02 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13922 for ; Mon, 30 Jul 2001 23:28:59 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f6V3UD317247; Mon, 30 Jul 2001 22:30:13 -0500 Message-ID: <00a801c11970$ea828b60$01000001@blazer> From: "Dean Willis" To: "IETF SIP" Cc: "Brian Rosen \(E-mail\)" , "Joerg Ott" , "Scott Bradner \(E-mail\)" , "Allison Mankin \(E-mail\)" References: <00ca01c1192b$5a3cb2a0$ee036e3f@dfw.dynamicsoft.com> Subject: Re: [Sip] SIP WG Agenda, IETF 51 Date: Mon, 30 Jul 2001 22:28:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ok, it's been brought to my attention that since the draft agenda was proposed: 1) The heated debate on provisional reliable responses has been effectively concluded. 2) We've allocated more time than is needed to the proxy-supported discussion. 3) The new session-timer draft may need some discussion 4) I failed to allocate time for 2543bis If there are no strenuous objections, I would suggest changing the agenda to: Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 0900 Agenda Bash -- Chairs 0910 Status Review -- Chairs 0920 Last Call Process and Report -- Chairs 0930 Call Control Extensions draft-biggs-sip-replaces-01.txt -- Billy Biggs draft-ietf-sip-refer-00.txt -- Robert Sparks 1000 Events (Two Issues) draft-ietf-sip-events-00.txt -- Adam Roach 1030 Early Media Extensions draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg 1100 SIP and NAT Extensions draft-boer-sip-src-00.txt -- Michel de Boer draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg 1120 Changes in Session Timer -- Jonathan Rosenberg 1130 break Note: Any additional time will be used to start 2543bis issues Session 2: 7Aug01 0900-1130 King's Suite/Sandringham 0900 Agenda Bash -- Chairs 0910 Message Integrity via Digest draft-undery-sip-digest-00.txt -- James Undery draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg 0930 Proxy Server Features Negotiation draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 0950 Reliability of Provisional Messages Extensions draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1000 Changes and Issues in the 2543bis draft -- Jonathan Rosenberg 1120 Discussion of Remote-Party Extensions Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston 1130 Close ----- Original Message ----- From: "Dean Willis" To: Cc: "Brian Rosen (E-mail)" ; "Joerg Ott" ; "Scott Bradner (E-mail)" ; "Allison Mankin (E-mail)" ; "IETF SIP" Sent: Monday, July 30, 2001 2:07 PM Subject: [Sip] SIP WG Agenda, IETF 51 > The following is the agenda for SIP (Session INitiation Protocol) WG at IETF > 51. > > ---------------------------- > > Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 > 0900 Agenda Bash -- Chairs > 0910 Status Review -- Chairs > 0920 Last Call Process and Report -- Chairs > 0930 Call Control Extensions > draft-biggs-sip-replaces-01.txt -- Billy Biggs > draft-ietf-sip-refer-00.txt -- Robert Sparks > 1000 Events (Two Issues) > draft-ietf-sip-events-00.txt -- Adam Roach > 1030 Early Media Extensions > draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia > draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg > 1100 SIP and NAT Extensions > draft-boer-sip-src-00.txt -- Michel de Boer > draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg > 1130 break > > > Session 2: 7Aug01 0900-1130 King's Suite/Sandringham > 0900 Agenda Bash -- Chairs > 0910 Message Integrity via Digest > draft-undery-sip-digest-00.txt -- James Undery > draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg > 0930 Proxy Server Features Negotiation > draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen > draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg > 1000 Reliability of Provisional Messages Extensions > draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss > draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg > 1030 Discussion of Remote-Party Extensions > Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston > 1100 Discussion of Further Open Issues > 1130 Close > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 02:22:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05312 for ; Tue, 31 Jul 2001 02:22:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25075; Tue, 31 Jul 2001 02:02:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25046 for ; Tue, 31 Jul 2001 02:02:33 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27189 for ; Tue, 31 Jul 2001 02:01:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6V5xDjc022014; Tue, 31 Jul 2001 01:59:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 01:59:47 -0400 Message-ID: From: Jonathan Rosenberg To: "'shh@ricochet.net'" , "Fairlie-Cuninghame, Robert" , Jonathan Rosenberg , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! Date: Tue, 31 Jul 2001 01:59:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: shh@ricochet.net [mailto:shh@ricochet.net] > Sent: Thursday, July 26, 2001 5:22 PM > To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: RE: [Sip] update to nat traversal draft! > > > Jonathan, > > I may have missed something, but I feel that there may be > limitations to > the proposed scheme. I am unable to see how 2 SIP devices behind the > same NAT device are going to communicate with each other. Well, it will work fine, but the media may be routed to the enterprise nat and back in, when it doesn't really have to be. There are ways to fix that problem if either the UA or proxy know set of users behind the nat. So, lets say A calls B through proxy P. A and B are in some enterprise that has a nat. A allocates an address using the mechanisms specified. The call is routed out of the enterprise to proxy P. P determines the called party B, and knows (presumably through configuration) that A and B are behind the same NAT. If it can recognize the address in the SDP as a public binding, it can reject the request and inform the caller to retry without the binding. A similar thing can be done if the UAS recognizes the scenario rather than the proxy. Lots of assumptions here about detection this case. I'll note that the problem isn't really specific to this solution. The same problem would arise if a traditional SIP ALG were embedded in the nat. It would also arise if a midcom nat were used, and the client or proxy allocated bindings. It would also arise (and, in fact, be far worse) if VPN were being used, as the media would not just go to the enterprise nat and back, but all the way to the vpn server and back. An interesting solution might be for the caller (and callee) to always offer two alternate media streams (using the FID draft), one of which is with its public address, and another with the private address. If media starts arriving on the private address, it re-invites to disable the stream on the public one. Actually, that is probably the most robust and simplest solution. Not sure FID gives you all the semantics you need for this, though... > > A secondary issue is that you would be exposing private IP addresses > on the outside. How is that? The whole idea is that a public address is used in the SDP. > > In the port sharing (on the AVT mailing list) case, with a VPN like > tunnel, local calling (2 sip devices behind the same NAT) may require > sending all packets across the WAN link and back. Yes, as I comment above, it is worse for the VPN case. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 03:11:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08456 for ; Tue, 31 Jul 2001 03:11:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25998; Tue, 31 Jul 2001 02:57:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25967 for ; Tue, 31 Jul 2001 02:57:48 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08239 for ; Tue, 31 Jul 2001 02:56:47 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6V6vgN03515; Tue, 31 Jul 2001 08:57:42 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id IAA29766; Tue, 31 Jul 2001 08:57:40 +0200 (MET DST) Message-ID: <00b401c1198e$1541aa80$0eb08496@e0000865d41e2.epl.ericsson.se> From: "Hans Hannu" To: , , Cc: , Subject: Re: [rohc] RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Date: Tue, 31 Jul 2001 08:57:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3612.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id f6V6vgN03515 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA25968 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id CAA25998 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA08456 Hi, I agree, it is important that we can proceed fast, and also that the final compression work will probably be a synthesis of the ideas in the current contributions. I also share the idea with Jonathan, to separate message compression into two problems; a Protocol and the actual compression Algorithm, see 1) and 2) below. 1) The Scheme/Protocol - Message handling. E.g. verification of correct decompression, usage of previous messages in the compression process, context handling (dictionary/codebook handling) 2) The actual compression algorithm - What to save in the dictionaries/codebooks etc.. - Compressed message representation. E.g. different Lempel-Ziw based representations. In our contribution, ROGER http://www.ietf.org/internet-drafts/draft-hannu-rohc-roger-01.txt we are following this grouping. E.g. the actual compression algorithm can be substituted and ROGER's focus has been more set on number 1 above. I believe that the other contributions more or less have this separation. BR /Hans H >The following is a very good way to proceed. I share the same >view as yours (need to do some homework on point 4 to understand >the details). It is also important that we can proceed fast to meet >3GPP schedule. Otherwise, we will all spend 20 or more seconds >listening to the ring each time we make a SIP call. > >Br, >Zhigang > >> Yes, I had thought about usage of static codebooks, which is >> used in one of the other proposals. I think its probably a good idea. >> >> The draft I wrote up is not really meant to be a complete >> solution, and I expect the final compression work will be >> a synthesis of many of the fine ideas in SCRIBE, ROGER, >> EPIC, and this proposal. My main goals with this >> were to emphasize some key points: >> >> 1. this is the BEST way to solve the problem for wireless usage of SIP >> 2. the protocol is best viewed as a mechanism for maintenance >> and management of codebooks, and that allowing different compression >> algorithms within that framework is a good thing >> 3. There are reasonable ways to handle compression of out of >> order messages that must be taken into account. >> 4. The mechanism, from a SIP perspective, is best done at the >> "transport layer", in the sense that its something for which SRV >> record-entries are defined, and a SIP transport param is defined, >> so that the existing transport negotiation mechanisms in SIP >> can be applied. >> >> Looking forward to discussing it all in London.... >> >> -Jonathan R. >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ ************************************************************************ Hans Hannu | Phone: +46 920 20 21 84, +46 70 55 99 015 Ericsson Erisoft AB | Fax: +46 920 20 20 99 Laboratoriegränd 11, Box 920, S-971 28 Luleå, Sweden ************************************************************************ _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 08:06:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13565 for ; Tue, 31 Jul 2001 08:06:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02435; Tue, 31 Jul 2001 07:53:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02404 for ; Tue, 31 Jul 2001 07:53:42 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13346 for ; Tue, 31 Jul 2001 07:52:39 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 12:52:23 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DFC@RSYS002A> From: "Price, Richard" To: "'Jonathan Rosenberg'" , "'Dean Willis'" , "'Christer Holmberg'" Cc: "'Michel de Boer'" , sip@ietf.org, rohc@cdt.luth.se Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP Date: Tue, 31 Jul 2001 12:52:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, EPIC is not just a static dictionary for a Lempel-Ziv compressor: rather it is a new compression algorithm proposed as an alternative to Lempel-Ziv. The key difference between the algorithms is that all Lempel-Ziv variants store the dictionary as a single text string, whereas EPIC stores the dictionary as a set of named "fields" as defined by the BNF of the protocol. EPIC includes the concept of a dynamic dictionary, since one of the binary characters we can send means "field is same as previous instance of field". This is optional though, depending on whether the bigger compression ratio is worth the extra hassle of maintaining robustness. We tested EPIC against several variants of Lempel-Ziv and found the compression ratio to be around twice that even of LZSS. This seems to be independent of whether we use a dynamic dictionary or not: without one we get a compression ratio of 2.8 vs 1.4 for LZSS, and with dynamic dictionaries we get 22.2 vs 10.6 for LZSS. Perhaps more importantly, the memory requirements of EPIC are much lower than Lempel-Ziv because it only keeps the fields which will reappear in the message flow with high probability. The dynamic dictionary requirements of our implementation are sub 100 bytes for the SIP flow tested above. Processing requirements are lower too, just because there is less dictionary to search. Questions and comments gratefully appreciated. Richard P -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, July 30, 2001 11:17 PM To: Price, Richard; 'Dean Willis'; 'Christer Holmberg'; Jonathan Rosenberg Cc: 'Michel de Boer'; sip@ietf.org; rohc@cdt.luth.se Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Thursday, July 26, 2001 5:17 AM > To: 'Dean Willis'; 'Christer Holmberg'; Jonathan Rosenberg > Cc: 'Michel de Boer'; sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP > > > Hi, > > We solved the "new token" problem by having a binary version > of every ASCII > character. If there is a binary version of the whole token > then we send that, > otherwise we send the binary versions of each individual character. It seems like what you are really talking about is a static dictionary based on a study of the BNF of the protocol. I suspect that you could probably hand tune a static dictionary to be even better based on knowledge of what actually comes in a SIP message in real scenarios. I still think a dynamic dictionary ontop of a static one like you propose is even better, any my initial tests gave me 8:1 compression, far better than anything reported with pure static (and I will note that this was with an LZW variant; if you pay the compute overhead of LZSS it will really rock, but I have not done explicit tests.) Is the improved efficiency of dynamic codebooks worth the cost of state management that comes with dynamic codebooks? Indeed thats a good question, and one which depends entirely on your view of whats important in the system. It is not a cut-and-dry comparison. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 08:30:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13941 for ; Tue, 31 Jul 2001 08:30:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03043; Tue, 31 Jul 2001 08:19:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03012 for ; Tue, 31 Jul 2001 08:19:45 -0400 (EDT) Received: from coltrane.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13800 for ; Tue, 31 Jul 2001 08:18:44 -0400 (EDT) Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 13:19:05 +0100 Message-ID: From: Jonathan Cumming To: "'Billy Biggs'" Cc: "'sip@ietf.org'" Date: Tue, 31 Jul 2001 13:18:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Re-use of Call-ID in the SIP Replaces header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Billy In section 2.2 of draft-biggs-sip-replaces-01, you specify that "A unique call-id may be given to the replacement call.". This seems unnecessarily weak and could lead to interoperability problems where an application assumes the re-use of the Call-ID. If a unique Call-ID is required, as specified in RFC 2543, then why give the end-point the option to re-use the existing Call-ID? I suggest that "A unique call-id MUST be given to the replacement call". Regards Jonathan --------------------------- Jonathan Cumming DC-SIP Product Manager Voice Networking Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: jrc@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 11:35:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21751 for ; Tue, 31 Jul 2001 11:35:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07847; Tue, 31 Jul 2001 11:21:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07761 for ; Tue, 31 Jul 2001 11:21:01 -0400 (EDT) Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20924 for ; Tue, 31 Jul 2001 11:19:56 -0400 (EDT) Received: from cybertron.div8.net ([64.230.148.156]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010731143007.BBDN17648.tomts13-srv.bellnexxia.net@cybertron.div8.net>; Tue, 31 Jul 2001 10:30:07 -0400 Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian)) id 15RacX-0000tv-00; Tue, 31 Jul 2001 10:35:41 -0400 Date: Tue, 31 Jul 2001 10:35:41 -0400 From: Billy Biggs To: Jonathan Cumming Cc: SIP List Subject: Re: [Sip] Re-use of Call-ID in the SIP Replaces header Message-ID: <20010731103541.A3458@dumbterm.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jrc@dataconnection.com on Tue, Jul 31, 2001 at 01:18:48PM +0100 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan Cumming (jrc@dataconnection.com): > In section 2.2 of draft-biggs-sip-replaces-01, you specify that "A > unique call-id may be given to the replacement call.". This seems > unnecessarily weak and could lead to interoperability problems where > an application assumes the re-use of the Call-ID. > > If a unique Call-ID is required, as specified in RFC 2543, then why > give the end-point the option to re-use the existing Call-ID? When we were first discussing methods of performing attended call transfer, there was alot of discussion about using the Call-ID to perform the replaces operation, that is, the replacement call (or joining call) would be identified by having the same Call-ID as an existing call. So, the text should really read "in our replaces model, a unique call-id may be given to the replacement call, instead of previous models which overloaded the meaning of the call-id". I wasn't trying to dictate behavior either way. > I suggest that "A unique call-id MUST be given to the replacement > call". Since this seems to be the modern consensus on the issue, I will clarify this in the draft. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 13:34:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02334 for ; Tue, 31 Jul 2001 13:34:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12375; Tue, 31 Jul 2001 13:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12340 for ; Tue, 31 Jul 2001 13:16:52 -0400 (EDT) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00815 for ; Tue, 31 Jul 2001 13:15:52 -0400 (EDT) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id KAA21097 for sip@ietf.org; Tue, 31 Jul 2001 10:16:09 -0700 Date: Tue, 31 Jul 2001 10:16:09 -0700 From: John Lazzaro Message-Id: <200107311716.KAA21097@snap.CS.Berkeley.EDU> To: sip@ietf.org Subject: RE: [Sip] update to nat traversal draft! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Jonathan Rosenberg writes > An interesting solution might be for the caller (and callee) to always offer > two alternate media streams (using the FID draft), one of which is with its > public address, and another with the private address. If media starts > arriving on the private address, it re-invites to disable the stream on the > public one. Actually, that is probably the most robust and simplest > solution. Not sure FID gives you all the semantics you need for this, > though... Yes, the online gaming world uses this technique and it seems to work well, so there's some successful history with the general idea of "send to both the public and private address and see what comes back in the return packets on the same UDP port." Also, if the source address on the return packet is neither the public or private address that a third party has handed you, its an indication that the sender is behind a NAT that is not a Full Cone NAT, I think (not totally sure). ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 14:32:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06683 for ; Tue, 31 Jul 2001 14:32:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13165; Tue, 31 Jul 2001 13:46:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13139 for ; Tue, 31 Jul 2001 13:46:12 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02874 for ; Tue, 31 Jul 2001 13:45:11 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6VHjKN09769; Tue, 31 Jul 2001 19:45:20 +0200 (MEST) Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id TAA11178; Tue, 31 Jul 2001 19:45:11 +0200 (MET DST) Message-ID: <3B66F16C.4C06B517@lmf.ericsson.se> Date: Tue, 31 Jul 2001 20:57:00 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Rosen, Brian'" , "'Michael Thomas'" , "'Henning Schulzrinne'" , Juan-Carlos.Rojas@alcatel.fr, Paul Kyzivat , Jay Batson , sip@ietf.org Subject: Re: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) References: <61D824C63B99D311975E00508B0CC98502251946@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > The list of protocols which are designed to say this sort of thing > is rather short. I'll leave it as an exercise for the readers of > this list to find any beyond those that have already been mentioned. An example of transcoder invokation using 3pcc can be found at: http://www.hut.fi/~gonzalo/papers/draft-camarillo-3pcc-qos-00.txt Note that this is an already expired draft though. I fully agree with Adam that we do not have to design architectures that send signalling thru a transcoder. Using 3pcc or H.248 (as it was also suggested) allows to implement media-related services such as adding music or manipulating video images in a much nicer way. Regards, Gonzalo > /a > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, July 12, 2001 10:00 AM > > To: 'adam.roach@ericsson.com'; 'Michael Thomas' > > Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; Paul Kyzivat; > > Jay Batson; sip@ietf.org > > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > > proposa l.) > > > > > > I like almost all of what you are saying, but one part is > > a little confusing. > > > > If I have a SIP end point, and it's not a PSTN gateway, but > > a sipphone, and it doesn't have a codec for whatever is > > coming at it, you don't want the sipphone to know about > > transcoders and Megaco do you? You want some intermediate > > proxy server to recognize the problem and DTRT. > > > > I really do buy into the central argument that just because > > the media stream is going through an extra device DOESN'T > > mean the signalling has to. > > > > Brian > > > > > -----Original Message----- > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Wednesday, July 11, 2001 8:53 PM > > > To: 'Michael Thomas'; adam.roach@ericsson.com > > > Cc: 'Henning Schulzrinne'; Juan-Carlos.Rojas@alcatel.fr; > > Paul Kyzivat; > > > Jay Batson; sip@ietf.org > > > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > > > proposal.) > > > > > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > > > adam.roach@ericsson.com writes: > > > > > This is why (I feel) we need to come up with a good > > architecture > > > > > to support transcoding which doesn't require a B2BUA. > > No, I'm not > > > > > proposing a work item (we do protocols, not architectures); I'm > > > > > just thinking out loud. > > > > > > > > Well, stop it :-) > > > > > > > > I sense that what you're hoping for is the moral equivalent > > > > of an RTP NAT and to that I say TANSTAAFL. There's a variety > > > > of ways that you could implement and/or control your transcoder > > > > box, but let's not allow delusion to creep in here that what > > > > is finally shaked and baked isn't, in fact, a form of an > > > > application layer gateway, lest the curse of Deering be upon > > > > you :-) > > > > > > Okay, now you've provoked me. :) > > > > > > The fact that you would assume that the *signalling* needs to > > > go through > > > some special box to allow transcoding just highlights how > > > entrenched the > > > mindset that I'm railing against has become. This is a > > fallacy that no > > > one seems to even question. > > > > > > Allow me to clarify. > > > > > > If we have network-provided transcoding, we'll need to send the RTP > > > through some transcoder box. There are two ways to achieve this. > > > > > > The trivial solution is to send the signaling through some > > transcoder > > > control box; it acts as a B2BUA, in much the same way that a > > > conference > > > bridge would. (This is extremely simple for terminals to do: > > > if you send > > > me an INVITE for a codec I don't know, I send you a 305 > > > response to tell > > > you to go to my transcoder -- or, if I get a 488 or 606, I > > send a new > > > invite through my transcoder). > > > > > > Alternately, when a codec mismatch is detected, you can set up some > > > relationship whereby the terminal communicates with a > > transcoder using > > > an appropriate protocol (H.248 comes to mind) to > > pre-arrange the fact > > > that media coming in to the transcoder on a negotiated port will be > > > transcoded and sent to the terminal (and the same thing in > > the reverse > > > direction). > > > > > > Both approaches work, and one of them will *need* to be deployed. > > > > > > The former has all the drawbacks of a B2BUA combined with the > > > drawbacks of > > > needing a transcoder in the network; the latter merely has > > > the drawbacks > > > of having a transcoder. Unfortunately, most people seem to > > be leaning > > > towards the first solution -- which is terrible, in my mind. > > > Just because > > > we're having to use a transcoder should not mean that feature > > > transparency > > > is destroyed. I'm trying to being attention to the fact that > > > using a B2BUA > > > for this application is EVIL, and should be avoided when possible. > > > > > > I agree that trying to put a "transparent" SIP proxy in the > > > path to munge > > > the SDP is completely the wrong answer, and -- lest anyone be > > > confused -- > > > such a solution is absolutely nothing like what I was suggesting. > > > > > > /a > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 15:38:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14528 for ; Tue, 31 Jul 2001 15:38:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15643; Tue, 31 Jul 2001 15:27:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15613 for ; Tue, 31 Jul 2001 15:27:23 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13277 for ; Tue, 31 Jul 2001 15:26:21 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6VJRCN25405; Tue, 31 Jul 2001 21:27:12 +0200 (MEST) Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA15721; Tue, 31 Jul 2001 21:27:09 +0200 (MET DST) Message-ID: <3B670951.93A4D00A@lmf.ericsson.se> Date: Tue, 31 Jul 2001 22:38:57 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: adam.roach@ericsson.com, Jonathan Rosemberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 489 status code Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, A minor comment about 489 status code: In Adam's event draft it means "Bad Event", and in Jonathan's early media draft it means "Request Updated". Since both are just I-Ds this is not really an issue right now, but when they advance to RFCs we will have to resolve this conflict. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 16:03:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17139 for ; Tue, 31 Jul 2001 16:03:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15035; Tue, 31 Jul 2001 14:58:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15004 for ; Tue, 31 Jul 2001 14:58:30 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10493 for ; Tue, 31 Jul 2001 14:57:28 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f6VIwAO04467; Tue, 31 Jul 2001 20:58:10 +0200 (MEST) Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA14709; Tue, 31 Jul 2001 20:58:07 +0200 (MET DST) Message-ID: <3B670282.4E3F57FB@lmf.ericsson.se> Date: Tue, 31 Jul 2001 22:09:54 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I am sending this mail to SIP and MMUSIC because both groups are interested in this issue. Sorry if somebody receives it twice. We have already agreed that the SDP 0.0.0.0 mechanism for putting the other party on hold does not work because it does not provide an address for RTCP. Therefore, we need a new mechanism for putting on hold. It seems that the best proposal is to use the direction tag (sendonly, sendrecv, recvonly) to do this. It has been proposed to define a new direction tag value that would mean that the media stream will not carry media (neither-send-nor-receive). This could be encoded as a=nomedia, for instance. The first question is, do we all agree that this is the mechanism that should be used? If so, is it appropriate to add this new tag value to SDPnew (Colin?) ? We also have to think about the current SDP 0.0.0.0 mechanism. While it does not work for putting UAs in hold, it is useful in 3pcc scenarios, where the controller does not have an IP address to provide to the callee. Do we want to still use SDP 0.0.0.0 in this scenario? Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 17:08:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22070 for ; Tue, 31 Jul 2001 17:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17039; Tue, 31 Jul 2001 16:13:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17007 for ; Tue, 31 Jul 2001 16:13:05 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17838 for ; Tue, 31 Jul 2001 16:12:04 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f6VKD4H98421; Tue, 31 Jul 2001 16:13:04 -0400 (EDT) Reply-To: From: "Brett Tate" To: "sip-ietf \(E-mail\)" , Date: Tue, 31 Jul 2001 16:11:58 -0400 Message-ID: <000e01c119fd$0def9570$2b01a8c0@broadsoft.com> 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 Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] rfc2806: Escaping contents of telephone-url Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The following paragraph from rfc2806 indicates to me that a "+", "=" and ";" would require escaping when used within a telephone-url. Am I understanding this correctly? The SIP-URL allows "&", "=", "+", "$", ",", ";", "?", "/" for a telephone-subscriber. Should any of these also be allowed unescaped in the telephone-url? rfc2806: section 1.2 paragraph 2 Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this document specifies strings of raw, unescaped characters. If those characters are present in a URL, and are not unreserved [RFC2396], they MUST be escaped as explained in [RFC2396] prior to using the URL. In addition, when parsing a URL, it must be noted that some characters may have been escaped. rfc2396: section 2.3 unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" If this isn't the appropriate working group list, please let me know where I should post the question. -brett _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 17:16:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22533 for ; Tue, 31 Jul 2001 17:16:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17206; Tue, 31 Jul 2001 16:22:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17179 for ; Tue, 31 Jul 2001 16:22:39 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18504 for ; Tue, 31 Jul 2001 16:21:37 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VKMB306102; Tue, 31 Jul 2001 13:22:11 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f6VKM0601308; Tue, 31 Jul 2001 13:22:00 -0700 (PDT) Received: from CHSHARP-W2K1.cisco.com (rtp-vpn-56.cisco.com [10.82.192.56]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA11009; Tue, 31 Jul 2001 13:21:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20010731161850.01d26b90@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 16:21:42 -0400 To: From: Chip Sharp Subject: Re: [Sip] rfc2806: Escaping contents of telephone-url Cc: "sip-ietf \(E-mail\)" , In-Reply-To: <000e01c119fd$0def9570$2b01a8c0@broadsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Depends on how they are used. These characters are defined as part of the syntax. When used as such, they don't need to be escaped. Section 2.6 of RFC2806 gives several examples. Chip At 04:11 PM 7/31/2001, Brett Tate wrote: >The following paragraph from rfc2806 indicates >to me that a "+", "=" and ";" would require >escaping when used within a telephone-url. >Am I understanding this correctly? The SIP-URL >allows "&", "=", "+", "$", ",", ";", "?", "/" >for a telephone-subscriber. Should any of these >also be allowed unescaped in the telephone-url? > > >rfc2806: section 1.2 paragraph 2 > >Note on non-unreserved characters [RFC2396] >in URLs: the ABNF in this document specifies >strings of raw, unescaped characters. If >those characters are present in a URL, and >are not unreserved [RFC2396], they MUST be >escaped as explained in [RFC2396] prior to >using the URL. In addition, when parsing a >URL, it must be noted that some characters >may have been escaped. > >rfc2396: section 2.3 > >unreserved = alphanum | mark >mark = "-" | "_" | "." | "!" | "~" | "*" > | "'" | "(" | ")" > > >If this isn't the appropriate working group >list, please let me know where I should post >the question. > >-brett > > >_______________________________________________ >Sip mailing list http://www.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 18:27:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28193 for ; Tue, 31 Jul 2001 18:27:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18962; Tue, 31 Jul 2001 17:28:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18935 for ; Tue, 31 Jul 2001 17:28:06 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23312 for ; Tue, 31 Jul 2001 17:26:54 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VLR2525973; Tue, 31 Jul 2001 17:27:02 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AGA00453 (AUTH pkyzivat); Tue, 31 Jul 2001 17:27:05 -0400 (EDT) Message-ID: <3B672171.684C8D42@cisco.com> Date: Tue, 31 Jul 2001 17:21:53 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg References: <3B670282.4E3F57FB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hello, > > I am sending this mail to SIP and MMUSIC because both groups are > interested in this issue. Sorry if somebody receives it twice. > > We have already agreed that the SDP 0.0.0.0 mechanism for putting the > other party on hold does not work because it does not provide an address > for RTCP. Therefore, we need a new mechanism for putting on hold. > > It seems that the best proposal is to use the direction tag (sendonly, > sendrecv, recvonly) to do this. It has been proposed to define a new > direction tag value that would mean that the media stream will not carry > media (neither-send-nor-receive). This could be encoded as a=nomedia, > for instance. > > The first question is, do we all agree that this is the mechanism that > should be used? If so, is it appropriate to add this new tag value to > SDPnew (Colin?) ? > > We also have to think about the current SDP 0.0.0.0 mechanism. While it > does not work for putting UAs in hold, it is useful in 3pcc scenarios, > where the controller does not have an IP address to provide to the > callee. Do we want to still use SDP 0.0.0.0 in this scenario? I know I will remember eventually, but can you remind me of such a scenario? I think I recall some cases where you invite on hold, and then reinvite. But when would this be used rather than inviting without SDP? Where this isn't sufficient, it might be better to simply invite without any media sessions at all, just to establish a signalling relationship. (But I don't believe that is technically legal at the moment.) One thing to keep in mind is that these should be mechanisms that work with transports other than RTP and UDP. The connection oriented transports introduce new problems. The c=0.0.0.0 for hold is one of the things that don't work there either. The direction tag is much better. Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 18:27:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28182 for ; Tue, 31 Jul 2001 18:27:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19559; Tue, 31 Jul 2001 17:40:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19532 for ; Tue, 31 Jul 2001 17:40:09 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24213 for ; Tue, 31 Jul 2001 17:39:06 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f6VLdhN13774; Tue, 31 Jul 2001 23:39:44 +0200 (MEST) Received: from lmf.ericsson.se (rmt160229.am.ericsson.se [138.85.160.229]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA21911; Tue, 31 Jul 2001 23:39:39 +0200 (MET DST) Message-ID: <3B67285F.AE7C83F6@lmf.ericsson.se> Date: Wed, 01 Aug 2001 00:51:27 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > I know I will remember eventually, but can you remind me of such a > scenario? I think I recall some cases where you invite on hold, and then > reinvite. But when would this be used rather than inviting without SDP? Actually you INVITE without SDP and get an SDP in the 200 OK. Now you MUST send an SDP in the ACK. You MAY try to send an INVITE with the SDP just obtained to the other party and expect the 200 OK to arrive quickly enough. That is, before the fist party gets tired of retransmitting the 200 OK without getting an ACK. Luckily you have another option. When you receive the 200 OK from your first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then you INVITE the other party and get his SDP. Now you can re-INVITE the first party. > Where this isn't sufficient, it might be better to simply invite without > any media sessions at all, just to establish a signalling relationship. > (But I don't believe that is technically legal at the moment.) You INVITE without any media description. The thing is that since you will get media description in the 200 OK, you MUST send an SDP in your ACK. > > One thing to keep in mind is that these should be mechanisms that work > with transports other than RTP and UDP. The connection oriented > transports introduce new problems. The c=0.0.0.0 for hold is one of the > things that don't work there either. The direction tag is much better. Yes, the direction tag is the way to go (as I proposed in my previous mail). I was just saying that the direction tag resolves 95% of the scenarios, but not all of them. Regards, Gonzalo > Paul -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 18:58:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00511 for ; Tue, 31 Jul 2001 18:58:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20696; Tue, 31 Jul 2001 18:11:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20665 for ; Tue, 31 Jul 2001 18:11:14 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26599 for ; Tue, 31 Jul 2001 18:10:12 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f6VMBAm21078; Tue, 31 Jul 2001 18:11:10 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Chip Sharp'" Cc: "'sip-ietf \(E-mail\)'" Subject: RE: [Sip] rfc2806: Escaping contents of telephone-url Date: Tue, 31 Jul 2001 18:10:04 -0400 Message-ID: <001201c11a0d$8db019f0$2b01a8c0@broadsoft.com> 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 Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010731161850.01d26b90@dogwood.cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Depends on how they are used. These characters are defined > as part of the > syntax. When used as such, they don't need to be escaped. > Section 2.6 of RFC2806 gives several examples. > Thanks for the response. I agree in the concept of your answer. However rfc2806 does not specifically unreserved any characters for the syntax. And it does not mention them in section 1.2 paragraph 2 which explicitly mentions to escape all that is non-unreserved from rfc2396 even if unescaped in ABNF. Which characters have been reserved for the syntax or future-syntax? Which characters within private-prefix, token-char, and quoted-string need to be escaped? > > At 04:11 PM 7/31/2001, Brett Tate wrote: > >The following paragraph from rfc2806 indicates > >to me that a "+", "=" and ";" would require > >escaping when used within a telephone-url. > >Am I understanding this correctly? The SIP-URL > >allows "&", "=", "+", "$", ",", ";", "?", "/" > >for a telephone-subscriber. Should any of these > >also be allowed unescaped in the telephone-url? > > > > > >rfc2806: section 1.2 paragraph 2 > > > >Note on non-unreserved characters [RFC2396] > >in URLs: the ABNF in this document specifies > >strings of raw, unescaped characters. If > >those characters are present in a URL, and > >are not unreserved [RFC2396], they MUST be > >escaped as explained in [RFC2396] prior to > >using the URL. In addition, when parsing a > >URL, it must be noted that some characters > >may have been escaped. > > > >rfc2396: section 2.3 > > > >unreserved = alphanum | mark > >mark = "-" | "_" | "." | "!" | "~" | "*" > > | "'" | "(" | ")" > > > > > >If this isn't the appropriate working group > >list, please let me know where I should post > >the question. > > > >-brett > > > > > >_______________________________________________ > >Sip mailing list http://www.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 19:00:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00686 for ; Tue, 31 Jul 2001 19:00:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21779; Tue, 31 Jul 2001 18:39:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21749 for ; Tue, 31 Jul 2001 18:39:43 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29202 for ; Tue, 31 Jul 2001 18:38:42 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VMcp529192; Tue, 31 Jul 2001 18:38:51 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AGA00857 (AUTH pkyzivat); Tue, 31 Jul 2001 18:38:54 -0400 (EDT) Message-ID: <3B673246.596702B5@cisco.com> Date: Tue, 31 Jul 2001 18:33:42 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hello, > > > I know I will remember eventually, but can you remind me of such a > > scenario? I think I recall some cases where you invite on hold, and then > > reinvite. But when would this be used rather than inviting without SDP? > > Actually you INVITE without SDP and get an SDP in the 200 OK. Now you > MUST send an SDP in the ACK. > > You MAY try to send an INVITE with the SDP just obtained to the other > party and expect the 200 OK to arrive quickly enough. That is, before > the fist party gets tired of retransmitting the 200 OK without getting > an ACK. > > Luckily you have another option. When you receive the 200 OK from your > first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then > you INVITE the other party and get his SDP. Now you can re-INVITE the > first party. OK, that makes some sense. But it is problematic unless it can be depended upon to work all the time, with any type of media. (The 3pcc may not understand the media being used by the endpoints.) I am not sure this is the case. Also, isn't there a potential problem with this technique? After you re-INVITE the first party with the SDP from the other party, the SDP you get back may not be the same as it was in the first invite. If not, then you have to reinvite the other party again. This process may never terminate. Seems like it would be better to count on turning around the invite to the other party before the first party times out. It takes a long time to timeout, so this shouldn't usually be a problem. > > > Where this isn't sufficient, it might be better to simply invite without > > any media sessions at all, just to establish a signalling relationship. > > (But I don't believe that is technically legal at the moment.) > > You INVITE without any media description. The thing is that since you > will get media description in the 200 OK, you MUST send an SDP in your > ACK. What I meant was that you might invite with the intent of establishing a call that has no media sessions. It isn't straightforward to do, since if you offer SDP that contains no m= lines it is like offering no SDP. You can probably do it by offering an SDP with "m=xxx 0 ...", but probably most UAs would reject this as useless. And in any case it wouldn't serve your purpose. Paul _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 19:17:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01930 for ; Tue, 31 Jul 2001 19:17:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21734; Tue, 31 Jul 2001 18:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21704 for ; Tue, 31 Jul 2001 18:39:27 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29173 for ; Tue, 31 Jul 2001 18:38:26 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VMcxg01334 for ; Tue, 31 Jul 2001 15:38:59 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f6VMd4K28034 for ; Tue, 31 Jul 2001 15:39:04 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id PAA21240 for ; Tue, 31 Jul 2001 15:38:53 -0700 (PDT) Message-ID: <3B6733E7.7BF0E8EA@cisco.com> Date: Tue, 31 Jul 2001 18:40:39 -0400 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] test - ignore Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Jul 31 19:52:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05787 for ; Tue, 31 Jul 2001 19:52:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22723; Tue, 31 Jul 2001 19:11:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22637 for ; Tue, 31 Jul 2001 19:11:06 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01442 for ; Tue, 31 Jul 2001 19:10:05 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6VNAO120967 for ; Tue, 31 Jul 2001 19:10:24 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6VNAOe20954 for ; Tue, 31 Jul 2001 19:10:24 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11A16.194B73E4" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Sip] SIP WG Agenda, IETF 51 - UPDATED Date: Tue, 31 Jul 2001 17:11:15 -0600 Message-ID: Thread-Topic: [Sip] SIP WG Agenda, IETF 51 Thread-Index: AcEZcVA1uZIAltAhTC6Gzwr4BZeodgApKVPQ From: "Zmolek, Andrew (Andrew)" To: "Dean Willis" , "IETF SIP" Cc: "Brian Rosen (E-mail)" , "Joerg Ott" , "Scott Bradner (E-mail)" , "Allison Mankin (E-mail)" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C11A16.194B73E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI- From the looks of it, the SIP WG agenda will include changes mentioned below: --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, July 30, 2001 9:29 PM To: IETF SIP Cc: Brian Rosen (E-mail); Joerg Ott; Scott Bradner (E-mail); Allison Mankin (E-mail) Subject: Re: [Sip] SIP WG Agenda, IETF 51 Ok, it's been brought to my attention that since the draft agenda was proposed: 1) The heated debate on provisional reliable responses has been effectively concluded. 2) We've allocated more time than is needed to the proxy-supported discussion. 3) The new session-timer draft may need some discussion 4) I failed to allocate time for 2543bis If there are no strenuous objections, I would suggest changing the agenda to: Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 0900 Agenda Bash -- Chairs 0910 Status Review -- Chairs 0920 Last Call Process and Report -- Chairs 0930 Call Control Extensions draft-biggs-sip-replaces-01.txt -- Billy Biggs draft-ietf-sip-refer-00.txt -- Robert Sparks 1000 Events (Two Issues) draft-ietf-sip-events-00.txt -- Adam Roach 1030 Early Media Extensions draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg 1100 SIP and NAT Extensions draft-boer-sip-src-00.txt -- Michel de Boer draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg 1120 Changes in Session Timer -- Jonathan Rosenberg 1130 break Note: Any additional time will be used to start 2543bis issues Session 2: 7Aug01 0900-1130 King's Suite/Sandringham 0900 Agenda Bash -- Chairs 0910 Message Integrity via Digest draft-undery-sip-digest-00.txt -- James Undery draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg 0930 Proxy Server Features Negotiation draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 0950 Reliability of Provisional Messages Extensions draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg 1000 Changes and Issues in the 2543bis draft -- Jonathan Rosenberg 1120 Discussion of Remote-Party Extensions Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston 1130 Close ----- Original Message ----- From: "Dean Willis" To: Cc: "Brian Rosen (E-mail)" ; "Joerg Ott" ; "Scott Bradner (E-mail)" ; "Allison Mankin (E-mail)" ; "IETF SIP" Sent: Monday, July 30, 2001 2:07 PM Subject: [Sip] SIP WG Agenda, IETF 51 > The following is the agenda for SIP (Session INitiation Protocol) WG at IETF > 51. > > ---------------------------- > > Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2 > 0900 Agenda Bash -- Chairs > 0910 Status Review -- Chairs > 0920 Last Call Process and Report -- Chairs > 0930 Call Control Extensions > draft-biggs-sip-replaces-01.txt -- Billy Biggs > draft-ietf-sip-refer-00.txt -- Robert Sparks > 1000 Events (Two Issues) > draft-ietf-sip-events-00.txt -- Adam Roach > 1030 Early Media Extensions > draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia > draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg > 1100 SIP and NAT Extensions > draft-boer-sip-src-00.txt -- Michel de Boer > draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg > 1130 break > > > Session 2: 7Aug01 0900-1130 King's Suite/Sandringham > 0900 Agenda Bash -- Chairs > 0910 Message Integrity via Digest > draft-undery-sip-digest-00.txt -- James Undery > draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg > 0930 Proxy Server Features Negotiation > draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen > draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg > 1000 Reliability of Provisional Messages Extensions > draft-kiss-sip-s100rel-00.txt -- Krisztian Kiss > draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg > 1030 Discussion of Remote-Party Extensions > Remote Party ID, Caller Preferences ID, REFER Source -- Alan Johnston > 1100 Discussion of Further Open Issues > 1130 Close > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C11A16.194B73E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] SIP WG Agenda, IETF 51 - UPDATED

FYI-

From the looks of it, the SIP WG agenda will include = changes mentioned below:

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.co= m]
Sent: Monday, July 30, 2001 9:29 PM
To: IETF SIP
Cc: Brian Rosen (E-mail); Joerg Ott; Scott Bradner = (E-mail); Allison
Mankin (E-mail)
Subject: Re: [Sip] SIP WG Agenda, IETF 51


Ok, it's been brought to my attention that since the = draft agenda was
proposed:

1) The heated debate on provisional reliable responses = has been effectively
concluded.
2)  We've allocated more time than is needed to = the proxy-supported
discussion.
3)  The new session-timer draft may need some = discussion
4) I failed to allocate time for 2543bis

If there are no strenuous objections, I would suggest = changing the agenda
to:

Session 1: 6Aug01 0900-1130, King's Suite/Balmoral = 2
0900 Agenda Bash -- Chairs
0910 Status Review -- Chairs
0920 Last Call Process and Report -- Chairs
0930 Call Control Extensions
    draft-biggs-sip-replaces-01.txt -- = Billy Biggs
    draft-ietf-sip-refer-00.txt -- = Robert Sparks
1000 Events (Two Issues)
    draft-ietf-sip-events-00.txt -- = Adam Roach
1030 Early Media Extensions
    draft-sen-sip-earlymedia-00.txt -- = Jayshree Bharatia
    = draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg
1100 SIP and NAT Extensions
    draft-boer-sip-src-00.txt -- = Michel de Boer
    draft-rosenberg-sip-entfw-02.txt = -- Jonathan Rosenberg
1120 Changes in Session Timer -- Jonathan = Rosenberg
1130 break
Note: Any additional time will be used to start = 2543bis issues

Session 2: 7Aug01 0900-1130 King's = Suite/Sandringham
0900 Agenda Bash -- Chairs
0910 Message Integrity via Digest
    draft-undery-sip-digest-00.txt -- = James Undery
    = draft-rosenberg-sip-http-pnonce-00.txt -- Jonathan Rosenberg
0930 Proxy Server Features Negotiation
    = draft-hoeneisen-sip-proxy-supported-00.txt -- Bernie Hoeneisen
    = draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg
0950 Reliability of Provisional Messages = Extensions
    draft-kiss-sip-s100rel-00.txt -- = Krisztian Kiss
    = draft-ietf-sip-serverfeatures-05.txt -- Jonathan Rosenberg
1000 Changes and Issues in the 2543bis draft -- = Jonathan Rosenberg
1120 Discussion of Remote-Party Extensions
    Remote Party ID, Caller = Preferences ID, REFER Source -- Alan Johnston
1130 Close



----- Original Message -----
From: "Dean Willis" = <dean.willis@softarmor.com>
To: <agenda@ietf.org>
Cc: "Brian Rosen (E-mail)" = <Brian.Rosen@marconi.com>; "Joerg Ott"
<jo@Informatik.Uni-Bremen.DE>; "Scott = Bradner (E-mail)" <sob@harvard.edu>;
"Allison Mankin (E-mail)" = <mankin@isi.edu>; "IETF SIP" <sip@ietf.org>
Sent: Monday, July 30, 2001 2:07 PM
Subject: [Sip] SIP WG Agenda, IETF 51


> The following is the agenda for SIP (Session = INitiation Protocol) WG at
IETF
> 51.
>
> ----------------------------
>
> Session 1: 6Aug01 0900-1130, King's = Suite/Balmoral 2
> 0900 Agenda Bash -- Chairs
> 0910 Status Review -- Chairs
> 0920 Last Call Process and Report -- = Chairs
> 0930 Call Control Extensions
> draft-biggs-sip-replaces-01.txt -- Billy = Biggs
> draft-ietf-sip-refer-00.txt -- Robert = Sparks
> 1000 Events (Two Issues)
> draft-ietf-sip-events-00.txt -- Adam = Roach
> 1030 Early Media Extensions
> draft-sen-sip-earlymedia-00.txt -- Jayshree = Bharatia
> draft-rosenberg-sip-early-media-00.txt -- = Jonathan Rosenberg
> 1100 SIP and NAT Extensions
> draft-boer-sip-src-00.txt -- Michel de = Boer
> draft-rosenberg-sip-entfw-02.txt -- Jonathan = Rosenberg
> 1130 break
>
>
> Session 2: 7Aug01 0900-1130 King's = Suite/Sandringham
> 0900 Agenda Bash -- Chairs
> 0910 Message Integrity via Digest
> draft-undery-sip-digest-00.txt -- James = Undery
> draft-rosenberg-sip-http-pnonce-00.txt -- = Jonathan Rosenberg
> 0930 Proxy Server Features Negotiation
> draft-hoeneisen-sip-proxy-supported-00.txt -- = Bernie Hoeneisen
> draft-ietf-sip-serverfeatures-05.txt -- Jonathan = Rosenberg
> 1000 Reliability of Provisional Messages = Extensions
> draft-kiss-sip-s100rel-00.txt -- Krisztian = Kiss
> draft-ietf-sip-serverfeatures-05.txt -- Jonathan = Rosenberg
> 1030 Discussion of Remote-Party = Extensions
> Remote Party ID, Caller Preferences ID, REFER = Source -- Alan Johnston
> 1100 Discussion of Further Open Issues
> 1130 Close
>
>
>
> = _______________________________________________
> Sip mailing list  http://www.ietf.org/mai= lman/listinfo/sip
> This list is for NEW development of the core SIP = 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  http://www.ietf.org/mai= lman/listinfo/sip
This list is for NEW development of the core SIP = 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_01C11A16.194B73E4-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip