From extest-admin@lists.bell-labs.com Sun Apr 1 05:15:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17743 for ; Sun, 1 Apr 2001 05:15:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93B5F44952 for ; Sun, 1 Apr 2001 05:08:29 -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: <20010401090829.93B5F44952@lists.bell-labs.com> Date: Sun, 1 Apr 2001 05:08:29 -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 Apr 1 15:42:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23572 for ; Sun, 1 Apr 2001 15:42:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DDC7844344; Sun, 1 Apr 2001 15:42:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imo-r19.mx.aol.com (imo-r19.mx.aol.com [152.163.225.73]) by lists.bell-labs.com (Postfix) with ESMTP id 763F74433E for ; Sun, 1 Apr 2001 15:41:20 -0400 (EDT) Received: from Pisauthor@aol.com by imo-r19.mx.aol.com (mail_out_v29.14.) id r.63.13ff8138 (2520) for ; Sun, 1 Apr 2001 15:41:06 -0400 (EDT) From: Pisauthor@aol.com Message-ID: <63.13ff8138.27f8de52@aol.com> To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 121 Subject: [SIP] test no rep 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 Apr 2001 15:41:06 EDT Content-Transfer-Encoding: 7bit _______________________________________________ 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 Sun Apr 1 15:46:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24167 for ; Sun, 1 Apr 2001 15:46:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37CB34439A; Sun, 1 Apr 2001 15:46:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imo-r16.mx.aol.com (imo-r16.mx.aol.com [152.163.225.70]) by lists.bell-labs.com (Postfix) with ESMTP id D42A944397 for ; Sun, 1 Apr 2001 15:45:52 -0400 (EDT) Received: from Pisauthor@aol.com by imo-r16.mx.aol.com (mail_out_v29.14.) id r.f.12152d3c (2520) for ; Sun, 1 Apr 2001 15:45:38 -0400 (EDT) From: Pisauthor@aol.com Message-ID: To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: AOL 5.0 for Windows sub 121 Subject: [SIP] New ID: draft-pis-00.txt April 1, 2001 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 Apr 2001 15:45:37 EDT Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force =20 Internet Draft =20 draft-pis-00.txt April 1, 2001 Expires: April 1, 2002 =20 Turning SIP into PIS (Protocol Independent Sessions) STATUS OF THIS MEMO This document is an April-Fools-Internet-Draft=20 and is in full conformance with all provisions of Section 10 of RFC2026=20 and the long tradition of the April Fools Day Internet Draft. =20 Internet-Drafts are working documents of the Internet Engineering Task=20 Force (IETF), its areas, and its working groups. April Fools internet=20 drafts are especially reserved for those working groups, drafts, protocols, industry groups, standards bodies, and so forth that could benefit from some gentle humor and poking, and perhaps a nugget or two of wisdom. April Fool'= s internet drafts are works of fiction and not to be taken seriously. Note=20 that=20 other groups may also distribute working documents as Internet-Drafts. =20 Internet-Drafts are draft documents valid for a maximum of six months and ma= y=20 be updated, replaced, or obsoleted by other documents at any time. It is=20 inappropriate to use Internet- Drafts as reference material or to cite them=20 other than as work in progress. The list of current Internet-Drafts can be=20 accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of=20 Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html.=20 Abstract: This document discusses extensions for the SIP protocol to=20 extend it for protocol independent services for a variety of applications=20 that are relevant to user agents. 1 Introduction =20 The Session Initiation Protocol (SIP) is a general purpose tool=20 for the initiation, modification, and termination of sessions. SIP=20 is typically used to establish multimedia sessions, such as voice or=20 video over IP, but has also been proposed via a recent flurry of=20 drafts for use in presence services, as well as adopted by a variety=20 of industry flora, such as for use in distributed cable packet=20 systems, and proposed for use as the next generation terminal=20 protocol for wireless systems in an unusually massive technical=20 specification for UMTS (Universal Mobile Telecommunications=20 Service). Unfortunately for SIP, both of these efforts are apt to differ significantly from standard SIP. Telephony extensions led=20 by a variety of vendors and international switching conundrums also must be addressed. Many earlier protocols, such as H.323 have been=20 maligned for attempting to address too many diverse needs, and rightfully=20 so, but SIP is endangered by these very efforts and perhaps may go the=20 way of H.323. =20 An effort to unify both of these diverse needs into a common set and=20 extend SIP is necessary... this is collectively called PIS, or=20 Protocol Independent Sessions for SIP (the extra S isn't needed) and=20 takes in the needs of user agents of both cable and wireless=20 systems. PIS can also be extended for telephony needs to keep the=20 telephony community satiated, and this will be published in a=20 subsequent internet draft, PIS-T (pronounced piszt, and often legitimately describes the state of the telephony community in having their needs=20 sufficiently addressed by SIP). PIS addresses the following areas of SIP: - reliable cleanup of SIP sessions - cleanup of bandwidth allocation - transaction stalls - infrastructure and plumbing - application sanitization - urgent protocol streaming and session steering=20 2 PIS Methods PIS introduces the following new methods, and a short description=20 follows. PIS focuses on proxies and proxy-clusters and the methods by which user agents access proxy facilities. 2.1 SEEK: SEEK is used to determine the availability of a proxy. It is a=20 Protocol violation to initiate a PIS session to an occupied proxy,=20 depending on the proxy type. Seek is usually acknowledged as=20 follows: 110 Queued 200 Proxy Available at address 300 No suitable proxy available 301 Closed for cleaning Applications may timeout for excessive queuing and may result in=20 SEEK sessions being sent to different domains. An optional REQUIRES=20 parameter may be used to indicate application preferences, eg. PIS/1.0 SEEK To: resourcecontroller@latrine1.loo.com From: anonymous@latrine1.loo.com Requires: Clean-proxy Flushed-proxy Stall-proxy Paper Sani-Shield Note that certain elements of the requires field may be refined to=20 indicate user preferences: Eg,=20 Requires: Paper-Soft Paper-WholeRoll Paper-Charman=20 Sani-Shield is a local term. Alternatively, the term Wax-gasket,=20 But-gasket, Rump-protector, Horse-Collar, or other terms may be=20 substituted according to the local custom. Alternatively, the user=20 agent MAY use Paper, or choose to signal the Stand or Hover method=20 if appropriate and/or supported by the user agent and/or appropriate=20 for the proxy type during session flow or simply risk invoking Sit=20 on an unshielded proxy. PIS/1.0 200 Proxy Available From: stall2@latrine1.loo.com Info=A0: Resources-low |+ No-Shield |+ No-Paper | Malodor |=20 Previous-transaction-not-cleared | Previous-transaction-clearing |=20 Overflowed |Plugged | Lock-not-functional | Blue-water |=20 Clear-water | Green-Water Type: Stall | Urinal | Hole | Line-urinal | Tire |=20 Side-of-Building | Paris-subway | French-quarter-NOLA |=20 Bidet | Commode Requires: Payment-token Forbidden: Use-of-cellphone, eating Warning: Turbulence | Rough-Seas | Swells | Uneven-pavement | Grade Note that Stall-proxy and Paper parameters likely indicate the need=20 for another session which is not addressed by the PIS protocol, but=20 is included for reference and often goes by the names: POOP,=20 Protocol #2, #2, and other vernacular/jargon that the author=20 will not repeat such low-brow terms in the interests of maintaining the high moral and linguistic (and often cryptic, unintelligible, and=20 lofty language often used in many RFCs) standards of the IETF. The Urgency parameter may also be used to indicate the urgency of the Transaction. A user agent which uses the urgency parameter MAY be=20 expected to skip the AIM method, and MAY forego certain Requires=20 parameters. PIS/1.0 SEEK To: resourcecontroller@banos.com From: beergut@banos.com Urgency: Normal | Urgent | Bursting | Too-Late 2.2 AIM:=20 AIM is used prior to the establishment of a SIP session, before=20 INVITE, to ensure that the PIS session is directed in the=20 appropriate proxy. Such may be used by mobile clients to discover=20 their serving CSCF (call state commode function) and be forced to=20 go there. =20 Failure to use the AIM method may lead to the session establishment=20 failure, or in the jargon, the PIS session ending up on the floor. =20 Approximately 50% of all user agents are capable of implementing the=20 AIM method. User agents which are capable of implementing AIM SHOULD do so prior to issuing INVITE. AIM is typically acknowledged as follows: 165 Flow pending 180 Flowing 183 Flow progress 200 ON TARGET, indicating successful aiming 201 Some packets not on target (should this be an INFO message=20 during the INVITE?) 300 Lift seat please 307 Proxy overflow...with REDIRECT 506 Previous transaction not cleared. FLUSH recommended 507 Clogged=20 575 Temporary Failure - inebriated. 3 point stance required. The following is a typical AIM message: PIS/1.0 AIM To: crapper2@proxy1.wc.com From: tipsy@proxy1.wc.com PIS/1.0 575 Temporary Failure - inebriated. 3 point stance required Info-text: Don't be a lush. 2.3 FLUSH: FLUSH, which SHOULD be implemented by well-behaved agents is used=20 after the conclusion of the BYE method in SIP, and is used to ensure=20 that all resources have been cleaned up and that any residual matter=20 left from the previous session to the proxy are cleaned up and as a=20 courtesy to the next user agent, and that the FLUSH procedure is not required before AIM, thereby improving overall throughput of the=20 proxy. An optional '160 Swirling' or '161 Drain circleage'=20 indication MAY be used to indicate the progress of flushing. =20 155 'Tank Filling' MAY also indicate progress. =20 A 602 'Overflowed' error MAY be returned if there is congestion and=20 insufficient throughput to clean up the residual transaction and=20 to warn the application to use a different proxy for subsequent=20 transactions and notify the maintenance, although the scope of the=20 notification is beyond this protocol, and is a management issue (see=20 draft-pis-mib-00.txt). The dreaded 666 'Backup' or=20 667 'Septic Reflux' condition indicate an urgent need for the user=20 agent to abandon the proxy and/or proxy cluster. [Note that PIS=20 proxies are 'input' only networks in the normal condition...no media=20 output is expected.] 470 'Plugged' may also be used to indicate=20 the state of the proxy as well. 404 'No Water' also indicates such=20 a condition. 300 Partial Flush is used to indicate an incomplete=20 FLUSH, and very well-behaved user agents will issue a subsequent=20 FLUSH in response to it. FLUSH may also be used at any time within=20 a given session if so desired. Successful FLUSH is typically acknowledged by a 200 WOOOSH. Note=20 that some advanced proxies can detect that the user is no longer=20 using the proxy, and simply issue a 200 WOOSH on their own without=20 an explicit FLUSH request from the user. Such advanced proxies=20 SHOULD also support an interim FLUSH as an user override. Certain=20 special types, such as line-urinal, wall-urinal, and pizwah MAY=20 support a continuous or periodic FLUSH method, and the user agent=20 is not required to employ the FLUSH method. FLUSH has the following parameters: How: Tilt-Lever-handle | Injection-Tilt-Valve | Press-Button |=20 Automatic | Plunger | Marine-Plunger-Pump | Return-knob |=20 Pail-o-water | Overhead-pull-chain PIS/1.0 FLUSH TID=3D1 To: head@ships-a-hoy.com From: user@ships-a-hoy.com And is acknowledged by: 100 INFO TID=3D1 How: Marine-plunger-pump And the user successfully completes the transaction by: 200 OK TID=3D1 But the proxy may acknowledge with: 404 'No water'=20 or if water were available, 160 Swirling and a subsequent ACK. Three other methods of interest are introduced: 2.4 WASH: WASH, another optional method, is used by well-behaved polite user=20 agents following FLUSH or conclusion of the SIP transaction. PIS/1.0 WASH To: resourcecontroller@lavatory1.pizwah.com From: relieved@lavatory1.pizwah.com WASH is typically acknowledged as follows: 110 Queued 101 INFO Water-State: Hot, Cold, Tepid Water-Status: Cold-Available, Hot-Available Handle-Method: 2-handle, 1-handle, automatic Soap: Yes | No Dryer-Type: Pull-towel | Paper-towel | Dryer Dryer-State: OK | Not-OK Recommend: Hand-wring 200 SINK-Available 400, 500, 600 No-Water 400, 500, 600 Sink-not-clean, handle-dirty 2.5 FRESHEN: =20 FRESHEN SHOULD be used an automatic or manual maintenance procedure=20 in high-traffic, high-capacity proxy clusters, but SHOULD be found=20 in any size cluster. Such may be achieved by the Ozium method,=20 Potpourri, Carboline-based-propellant-spray (commercially known as=20 LYESOL), Aromatic-candle, any sufficiently strong or pleasant=20 smelling substance to mask and/or overpower ambient malodor or the Strike-Match or Light-Cigarette may be self-implemented by the user,=20 although strike-match and light-cigarette are inappropriate under=20 airplane-lavatory. Further, strike-match and light-cigarette may=20 pose a risk to the user agent if sufficient combustible gases (CH4...methane) are present, in which case the permanent=20 699 'Explosion' is returned. FRESHEN MAY be initiated by a user=20 agent in response to a SEEK response with a Info: Malodor parameter in an effort to mitigate the condition. Example: PIS/1.0 FRESHEN To: airs@current.port-o-let.com From: user@current.port-o-let.com How: Strike-Match PIS/1.0 300 Fail Info: Reeking-Stench, Ventilation-Not-Adequate, Temperature 110F Special conditions may be required for certain types of stalls,=20 such as Airplane-stall and Vacuum-Flusher-Airplane. The FLUSH=20 method on an airplane that supports Vacuum-Flush MAY achieve the=20 equivalent of FRESHEN. Further input from the airline and airplane=20 manufacturing industries is sought for the airplane-stall,=20 vacuum-flusher-airplane, as well as proper procedures under dynamic=20 conditions, such as turbulence, as well as certain state indicators,=20 such as Return-to-Seat, No-Smoking, and the appropriate use of the=20 Attendant-Call signal. [H.248 could be used as the protocol to light=20 the appropriate indicators via the NOTI method, or out-of-band aural=20 methods are possible.] [Author's observation: The FRESHEN method is=20 often implemented on airplane-stall via the hanging of coffee bags in=20 the lavatory, which explains the unique aroma and quality of airplane=20 coffee...ever wonder how airlines keep airfares so low and where=20 they're skimping?] Similarly, input from the maritime industry is sought for the=20 specifics of Marine-Toilet (or in jargon: Head) and behaviors under=20 dynamic conditions, such as Swells or Rough-Seas, as well as when the=20 floating-positive-buoyancy-upon-salt-fresh-brackishwater-vehicle=20 (jargon: boat) is in motion or stationary, and whether=20 electric-pump-flusher or manual-pump-flusher are required.=20 In fact, there are many specialized proxy types associated with=20 proxy mobility and proxies in motion (and pose special problems for=20 location-enabled services as in appendix 1). Bus, train, and RVs MAY=20 have embedded proxies. Furthermore, the specifics of portable=20 proxies, such as Chemical-Toilet, the commercial Port-O-Let,=20 Chamber-Pot, Bucket, Bedpan, and User-Instantiated-Proxy (with the=20 Dig and Requires: Spade methods), are also a consideration. [Author's note: While PIS is intended to be a simple protocol, even=20 a simple protocol can be ruined by too many specific implementations=20 and/or variants...perhaps the industry should take note in enhancements=20 to other protocols.]=20 2.6 VOMET: VOMET is used as a negative response to the COMET method, if so=20 implemented. COMET is an overloaded term, and is used for both=20 resource reservation and the presence of abrasive pumice-based=20 cleansing agents that MAY damage porcelain surfaces and MAY=20 contain bleach or other surfactants that MAY be used in the=20 maintenance of a proxy and leaves the proxy sparkling clean. =20 [Author's note: I am reminded by a childhood song: COMET...it=20 makes you VOMET...and you turn blue, blue, blue... / So if you=20 want to VOMET... / Go out and get some COMET... / so that you can=20 VOMET to-day.] 3 Session Reliability and Streaming It should be noted that the media flow or content of a PIS session=20 (or stream) is usually continuous, but occasionally, a PIS session=20 may have been terminated too soon and an automatic second session=20 follows. Reliable ordered and high-speed delivery is recommended,=20 and SCTP is to be used for the transport of these sessions. =20 [Author's observation: How IP may be different that how UP.] 4 Multicast/Multi-unicast, Scalability, and N-ary Relations User agents do not implement multicast or multi-unicast as a normal=20 biological condition of user agents. The relationship between a=20 user agent and a proxy is typically 1 PIS session to 1 Proxy. The=20 special Line-Urinal Proxy type and Pizwah are capable of handling=20 certain multiple user agents simultaneously without protocol=20 violation. Well behaved user agents being serviced by a line-urinal=20 or pizwah type will implement the Look-at-the-wall method during=20 (note this is also considered good etiquette when being serviced by a Urinal-Type proxy). 5 Local Implementation/National Protocol Variants=20 By no means is PIS a complete protocol. The use of local signaling=20 variants may be required depending on the location of the proxy and=20 the user agent when roaming may or may not be capable of=20 understanding the proper local protocols or methods. For example,=20 the Paper value might be well served in some locales by Leaves,=20 Lira, $1-USD, or Low-Denomination-Paper-Currency, [although this use of Paper is not part of PIS but may occur in conjunction with a PIS session]. Certain user agents may not understand the significance=20 of the Bidet or Pizwah type. Local names for proxies, such as=20 commodes, stalls, toilets, crappers, urinals, potties/poddy, loos,=20 wc's ( _______________________________________________ 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 Sun Apr 1 15:54:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26095 for ; Sun, 1 Apr 2001 15:54:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88B0B443A0; Sun, 1 Apr 2001 15:54:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by lists.bell-labs.com (Postfix) with ESMTP id E67FD4439D for ; Sun, 1 Apr 2001 15:53:51 -0400 (EDT) Received: from Pisauthor@aol.com by imo-m06.mx.aol.com (mail_out_v29.14.) id r.86.90223ff (2520) for ; Sun, 1 Apr 2001 15:53:46 -0400 (EDT) From: Pisauthor@aol.com Message-ID: <86.90223ff.27f8e14a@aol.com> To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 121 Subject: [SIP] New ID: draft-pis-00.txt April 1, 2001 contd 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 Apr 2001 15:53:46 EDT Content-Transfer-Encoding: 7bit continued...noticed truncation... 5 Local Implementation/National Protocol Variants By no means is PIS a complete protocol. The use of local signaling variants may be required depending on the location of the proxy and the user agent when roaming may or may not be capable of understanding the proper local protocols or methods. For example, the Paper value might be well served in some locales by Leaves, Lira, $1-USD, or Low-Denomination-Paper-Currency, [although this use of Paper is not part of PIS but may occur in conjunction with a PIS session]. Certain user agents may not understand the significance of the Bidet or Pizwah type. Local names for proxies, such as commodes, stalls, toilets, crappers, urinals, potties/poddy, loos, wc's (waterclosets), pizwahs, ditches, holes, lavatories, latrines, heads, outhouses, buckets, etc. and the appropriate user agent methods for accessing such need further investigation and definition (and could keep folks in committee meetings for years on the take and in conference, industry fora, venture capital, media blitzes, and for-profit-conferences, such as the new conference formed to address PIS in the network, called Voiding in the Net.) Such protocol transport and translation issues are part of PIS-T and other protocols, and of interest by ETSI and the ITU. Roaming issues, such as a user in a F-CSCF (foreign CSCF, a proxy not of home type), should be addressed by 33GBPP (33rd Generation Bathroom Protocols Project) as part of Release 55, scheduled for completion in 2055. The 33GBPP's goal is to ensure complete standardization and PIS availability to all user agents, whether roaming, or at home, and that user agents get the same services when roaming as when at home (as well as being captive in a walled stall so the user agents have the comfort and feel of the same crap(per) when roaming.) Appendix 1: Presence-Enabled and Location-Enabled PIS Of particular interest to user agents of PIS is need to locate an appropriate proxy when the user agent is away from home or well-known proxies, such as roaming in a foreign or non-home city, traveling via car, or simply in a new area. The user MAY have special criteria, like clean, no-graffiti, not-occupied, in-resturant, etc. as well as MAY indicate urgency where proximity and availability are most important. It is also important that user agents progressing to a particular proxy or proxy cluster be aware of any status changes, congestion, or other problems which MAY prevent a successful session. The SEEK method is enhanced to include the following parameters: Planet(oid): Earth, Moon, Mars, ...(the protocol should be extensible for interplanetary systems. Absolute spatial positioning is FFS but should nonetheless be considered in implementation) Geo-spatial-position: Latitude, Longitude, and Elevation or Implementation-Specific-Position: Building-Name, Floor, Column-Number, Office-Number And/or the following parameters: Currently-Near-to: Unique-specific-location Velocity: Vector Preferences: Public-type, private-type, clean Requires: Male, Female, Bano-Familiar + Handicapable Input is sought regarding general and implementation-specific positional description. In some cases, the user agent may not have geo-spatial information, and a more classical or human-oriented search is in order and the user agent may not have precise information and fuzzy or approximate searches may be appropriate. The SEEK method will return a list of proxy-cluster controllers for which the user agent should then join as an ad-hoc member of a presence group, as well as information about the overall facilities and any error conditions present in the cluster. State changes in each of the proxy-clusters represent group state changes and are propagated to the user agent. The proxy-cluster controller MAY have the capacity to determine loading and typical servicing times. Acknowledgements The author wishes to recognize the following. The Blue Man Group for the idea of proxies as being 'input' only terminals. "'There is a network that connects all humanity that things only flow intothe plumbing network. Bad things happen on BACKUPS.'" Chicago, 1997. ANSI-USTD 3466-T. Specification for toilets, commodes, and other facilities. Author's note: I'd love to publish this under my real name and from a legit email account where I work, but that would be an inappropriate use of company's resources. I certify that this is a result of the 'expertise' I have amassed in industry and as of publicly, biologically, and/or readily known information and expresses a personal opinion, is a work of literary fiction, and is not to be taken seriously. No similarity to persons, protocols, standards, drafts, working papers, industry forums, conferences, legal entities, corporations, and so forth living, dead, reincarnated, in-use, obsoleted, Bis-ed, version 2ed, and so on should be inferred by this work, and the respective copyrights, trademarks and IPRs (if any mentioned are the property of their respective companies). SIP is out of control and we're headed for the same disaster as a much maligned SG16-ITU protocol that starts with H.32. Yes, I'm squarely a big supporter of SIP and have been active in industry for quite some time in H.323, Gatekeepers, SIP, SIP-T, UMTS, Softswitches, H.248/xGCP/IPDC, and other areas, but I'm more than disturbed by what's going on, especially in that abomination proposed by certain UMTS flora and fauna we all know too well. Anyhow, April Fools! _______________________________________________ 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 Sun Apr 1 17:55:55 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17500 for ; Sun, 1 Apr 2001 17:55:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCAE744344; Sun, 1 Apr 2001 17:28:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id A03EB4433E for ; Sun, 1 Apr 2001 17:27:03 -0400 (EDT) Received: from flf960r1.ems.att.com ([135.71.244.37]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f31LR2715177; Sun, 1 Apr 2001 17:27:03 -0400 (EDT) Received: from njb140bh2.ems.att.com by flf960r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA20260; Sun, 1 Apr 2001 17:23:51 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 17:26:52 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Michael Thomas Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Response if user not registered? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Sun, 1 Apr 2001 17:26:50 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17500 For SIP, that means you have no control over who I use for the outbound proxy. There's no reason to modify SIP to enforce something that is unenforcible. [RRR] Still an association (e.g., registration/INVITE-authentication etc.) needs to be provided how charging can be made for service offerings. (It is not about control per se.) Radhika R. Roy Roy, Radhika R, ALCOO writes: > Folks: > > Let us not forget the reality in offering the VoIP services. As Brian has > explained, there has to be charging. That is, there need to be an > association between the caller (person) and the device/location/address. > > (No one is disputing the fact that calls can always be made is the IP > addresses are known and routers can route the calls to the destination IP > addresses, and IP addresses can be assigned dynamically.) > > Best regards, > > Radhika R. Roy > AT&T > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, March 30, 2001 2:40 PM > To: Michael Thomas > Cc: Drage, Keith (Keith); Markus.Isomaki@nokia.com; 'Juha Heinanen'; > sip@lists.bell-labs.com > Subject: Re: [SIP] Response if user not registered? > > > Michael, > > I don't have an IP address tatooed on my forhead and > my left hand. > > Also, some like to charge for calls based on where you > are calling from. They often like to charge you, not > your terminal. > > --Brian > > Michael Thomas wrote: (Fri, 30 Mar 2001 10:46:32) > > Brian F. G. Bidulock writes: > > > Michael, > > > > > > Sorry Mike, registration is for personal mobility as > > > well, not just terminal mobility. > > > > And this contradicts what I said... how? > > It certainly doesn't make a case for linkage > > of incoming and outgoing calls to some HLR-like > > entity. Location is only important on the > > incoming call side. The outgoing side is > > completely separate. Likewise, data > > connectivity is completely separate from > > call/SIP presence. This is the fundamental > > conflation that Q.931-like schemes get > > completely wrong in the IP world. > > > > Mike > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > > _______________________________________________ > 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 Sun Apr 1 19:52:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28983 for ; Sun, 1 Apr 2001 19:52:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CD6E44344; Sun, 1 Apr 2001 19:52:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 87C794433E for ; Sun, 1 Apr 2001 19:51:47 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GB50042Z0Y073@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 1 Apr 2001 23:51:37 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GB5003010XZ0X@dgismtp02.wcomnet.com>; Sun, 01 Apr 2001 23:51:36 +0000 (GMT) Received: from hsinnreich ([166.44.172.113]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GB500LI20XEO7@dgismtp02.wcomnet.com>; Sun, 01 Apr 2001 23:51:25 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] The Endless User-Network-Registration Debate Seems Mostly Bogus In-reply-to: <009001c0ba43$b6c801b0$56fa403f@dynamicsoft.com> To: "IETF SIP (E-mail)" , Dean Willis Cc: Christian Huitema , David Gurle 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 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, 01 Apr 2001 18:51:22 -0500 Content-Transfer-Encoding: 7bit Dean Willis wrote: >maybe my phone should send a REGISTER for every phone number and >every user name I go by (currently a list of over 50 identities) I believe the Microsoft Wallet (just emerging in the trade press) does also something like this, except it identifies the user to each server separately, when logging on. Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis Sent: Saturday, March 31, 2001 6:36 PM To: IETF SIP (E-mail) Subject: [SIP] The Endless User-Network-Registration Debate Seems Mostly Bogus ok, time for a soap-box speech. . . . We've been going around on whether networks can deregister phones and what the impact of a user who hasn't registered may be and whether it's the terminal or the user that is registering. I really don't think I understand this whole argument. That' or the argument is happening between people who just don't understand SIP. When I turn on the SIP phone on my desk, it sends register messages to three different registrars. Optionally, each registration could be authenticated with separate credentials. None of those credentials has anything whatsover to do with authorizing my phone to talk to the network. Getting permission to talk to the network happened when my phone used DHCP to get an address assignment from a server . . . And NONE of those registrations have anything whatsoever to do with whether that phone can make a call. They influence only INBOUND calls to the identities associated with the registrations. Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on whether that phone has "access" to the network. In fact, it has to have access to the network BEFORE it can register. Registration is an application, not an access control mechanism. I think we're getting layers 2, 3, and 4 horribly confused. Now let's think about a concept I call an "identity" and that I believe the kerberos people call a "principal". An identity is essentially a distinguished name. Generally, credentials exist which allow the holder of those credentials to be authenticated as the "identity" in question. A user can have an identity. A phone can have an identity. My dog can have an identity. REGISTER is a mechanism by which the holder of an identity says "HERE I AM: SEND PACKETS HERE TO REACH THIS IDENTITY". We might call that a dynamic binding. DNS and the various phone-route mechanisms provide a relatively static binding between an idenity (or classes of identities) and SIP proxies. For example: for all calls whose target identities have a domain poart of "dynamicsoft.com", please consult this proxy when resolving the call. SIP allows programmatic routing of calls, which may involve changing the identity to which the call is destined. When combined with REGISTER, we're using a static binding to get the call to a location at which a dynamic binding can be applied, a palce I call a "binding point" or "identity server". For example, sometimes there's a REGISTER application on my home PC that talks to my office proxy. But my home PC doesn't receive SIP calls. This application uses REGISTER to tell the proxy "calls to dwillis@dfw.dynamicsoft.com need to be remapped to the identity 9725199190 in your scope", which sends the calls out through a gateway to the PSTN. And if I stop stroking my home PC, it stops sending REGISTER messages, the registration expires, and my phone calls stop following me home and they go someplace else -- to an identity that DOESN'T send REGISTER messages, because it's a destination statically configured in the CPL attached to my profile in that proxy at the office. 3G efforts may wish to layer the user's identity on top of the phone's identity. For example, a phone, when actuated, might REGISTER with its home proxy or with some other proxy whose address is learned outside of SIP. The user identity's profile might wish to include logic (which could be CPL) that says "check to see if my phone is registered, and if so send the call there and if not send it to voice mail. The user's identity server (a REGISTRAR) might wish to SUBCRIBE to the registration state of the phone (provided by the phone's REGISTRAR, not the phone) in order to proactively start sending calls somewhere else if the phone deregisters. Or, if the phone's registrar and the user's registrar happen to be the same registrar, local application logic might be used to do the same thing (I do have an app that works that way). Or they could use a common lower-layer database replication to achieve the same effect. But I can do all this without having to change SIP or make it act in any way more SS7-like. It's an IMPLEMENTATION DECISION, not a PROTOCOL DEFINITION. But hey, maybe my phone should send a REGISTER for every phone number and every user name I go by (currently a list of over 50 identities) to each of the different identity servers (50 or so, scattered across the face of this planet) associated with those identities. That's a legitimate SIP usage, AND I HOPE YOU BELLHEADS (Sorry, Bob!) DON'T MESS THIS UP because I think it's a pretty cool application. And its rather completely unlike the way phones, mobile phones, or SS7, or IS-41, or GSM, etc. work today. And by the way, it shouldn't matter whether my phone has a UMTS or 802.11B or 100-base-T connection, because the application is just ordinary SIP running over ordinary IP. Thanks for listening. -- Dean _______________________________________________ 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 Sun Apr 1 23:48:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07019 for ; Sun, 1 Apr 2001 23:48:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BC0E44344; Sun, 1 Apr 2001 23:48:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-220.dallas.net [209.44.42.220]) by lists.bell-labs.com (Postfix) with ESMTP id B150B44344 for ; Sat, 31 Mar 2001 19:49:30 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id SAA20067; Sat, 31 Mar 2001 18:48:13 -0600 From: "Brian F. G. Bidulock" To: Dean Willis Cc: Baniel Uri-CUB001 , "'Bob Penfield'" , Sriram Parameswar , "'Romeo Zwart'" , "'Stephen Terrill'" , "'Igor Slepchin'" , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: Re: [SIP] Informing UA after network initiated deregistration? Message-ID: <20010331184813.I22883@bfgbhome> Reply-To: bidulock@openss7.org Mail-Followup-To: Dean Willis , Baniel Uri-CUB001 , 'Bob Penfield' , Sriram Parameswar , 'Romeo Zwart' , 'Stephen Terrill' , 'Igor Slepchin' , 'William Marshall' , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip References: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451CE@il27exm02.cig.mot.com> <007a01c0ba3e$866923f0$56fa403f@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <007a01c0ba3e$866923f0$56fa403f@dynamicsoft.com>; from dean.willis@softarmor.com on Sat, Mar 31, 2001 at 05:58:45PM -0600 Organization: http://www.openss7.org/ Dsn-Notification-To: 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, 31 Mar 2001 18:48:13 -0600 Content-Transfer-Encoding: 8bit Dean, People on this WG say how SIP is so different from PSTN; yet, you cling to this artificial distinction between inbound and outbound call? These are circuit switched network concepts. Clinging to the concept of inbound and outbound is why the PSTN had so much difficulty with services like Meet-Me conferencing, Call Waiting and other such stuff. Consider that the user is a participant in a communications session whose establishment is independent of its participants. Being able to give out invitations without also being able to receive them severly limits the scope of dependencies between sessions which can be expressed by the protocol. Proxies wishing to provide this wider scope of service offering should be permitted to track registration and deregistration as it affects the offering of this wider service range than just incoming and outgoing. --brian Dean Willis wrote: (Sat, 31 Mar 2001 17:58:45) > > I really don't think I understand this whole argument. > > When I turn on the SIP phone on my desk, it sends register messages to three > different registrars. > > Optionally, each registration could be authenticated with separate > credentials. None of those credentials has anything whatsover to do with > authorizing my phone to talk to the network. > > And NONE of those registrations have anything whatsoever to do with whether > that phone can make a call. They influence only INBOUND calls to the > identities associated with the registrations. > > Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on whether > that phone has "access" to the network. In fact, it has to have access to > the network BEFORE it can register. Registration is an application, not an > access control mechanism. > > I think we're getting layer 2, 3, and 4 horribly confused. > > -- > Dean > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ 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 Sun Apr 1 23:49:20 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07376 for ; Sun, 1 Apr 2001 23:49: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 DE8A9443AD; Sun, 1 Apr 2001 23:48:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 4478A4433E for ; Sat, 31 Mar 2001 20:29:42 -0500 (EST) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f2VJSZP04789; Sat, 31 Mar 2001 13:28:35 -0600 Message-ID: <00a901c0ba4b$2a82c2a0$56fa403f@dynamicsoft.com> From: "Dean Willis" To: Cc: "Baniel Uri-CUB001" , "'Bob Penfield'" , "Sriram Parameswar" , "'Romeo Zwart'" , "'Stephen Terrill'" , "'Igor Slepchin'" , "'William Marshall'" , "Chen Bonnie-BCHEN1" , "Xu Lang-LXU1" , "sip" References: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451CE@il27exm02.cig.mot.com> <007a01c0ba3e$866923f0$56fa403f@dynamicsoft.com> <20010331184813.I22883@bfgbhome> Subject: Re: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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@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, 31 Mar 2001 19:29:15 -0600 Content-Transfer-Encoding: 8bit Interesting point. One might take it even further -- the user may be represented by multiple identities, each of which may be participating in one or more sessions, each of which may have been instantiated by the user, another participant in the session, or by a non-participating third party. Some devices may be only be able to originate invitations. Some may be able only to respond to invitations. Some may do both, or their abilities may be dictated by the set of identities involved in the given context. Some devices will support multiple identities simultaneously. Others will not. One might choose to model the "meet me call" as a unique identity, instantiated for the duration of the "call", which participates in numerous "call legs" on a pairwise basis with each of the other participants. I believe a similar technique can be applied to all multiparty calling modes. In fact, I think Sparks and Campbell did an internet-draft illustrating that point. But "inbound" vs "outbound" is still a useful distinction, inasmuch as one or the other of the parties at each end of each call leg performed the signaling that instantiated that leg -- and the other party reacted to that signal. To paraphrase Einstein, I refuse to embrace a conceptuality without causality . . . -- Dean ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Dean Willis" Cc: "Baniel Uri-CUB001" ; "'Bob Penfield'" ; "Sriram Parameswar" ; "'Romeo Zwart'" ; "'Stephen Terrill'" ; "'Igor Slepchin'" ; "'William Marshall'" ; "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" ; "sip" Sent: Saturday, March 31, 2001 6:48 PM Subject: Re: [SIP] Informing UA after network initiated deregistration? > Dean, > > People on this WG say how SIP is so different from > PSTN; yet, you cling to this artificial distinction > between inbound and outbound call? These are circuit > switched network concepts. > > Clinging to the concept of inbound and outbound is > why the PSTN had so much difficulty with services > like Meet-Me conferencing, Call Waiting and other > such stuff. > > Consider that the user is a participant in a > communications session whose establishment is > independent of its participants. > > Being able to give out invitations without also being > able to receive them severly limits the scope of > dependencies between sessions which can be expressed > by the protocol. Proxies wishing to provide this > wider scope of service offering should be permitted > to track registration and deregistration as it affects > the offering of this wider service range than just > incoming and outgoing. > > --brian > > Dean Willis wrote: (Sat, 31 Mar 2001 17:58:45) > > > > I really don't think I understand this whole argument. > > > > When I turn on the SIP phone on my desk, it sends register messages to three > > different registrars. > > > > Optionally, each registration could be authenticated with separate > > credentials. None of those credentials has anything whatsover to do with > > authorizing my phone to talk to the network. > > > > And NONE of those registrations have anything whatsoever to do with whether > > that phone can make a call. They influence only INBOUND calls to the > > identities associated with the registrations. > > > > Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on whether > > that phone has "access" to the network. In fact, it has to have access to > > the network BEFORE it can register. Registration is an application, not an > > access control mechanism. > > > > I think we're getting layer 2, 3, and 4 horribly confused. > > > > -- > > Dean > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ 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 Apr 2 00:19:19 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15253 for ; Mon, 2 Apr 2001 00:19:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 265FB443B5; Sun, 1 Apr 2001 23:48:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 995A34433E for ; Sun, 1 Apr 2001 09:33:36 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA00375 for ; Sun, 1 Apr 2001 06:33:36 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA27535 for ; Sun, 1 Apr 2001 06:33:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Sun, 1 Apr 2001 08:33:36 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451D8@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Dean Willis'" , bidulock@openss7.org Cc: Baniel Uri-CUB001 , "'Bob Penfield'" , Sriram Parameswar , "'Romeo Zwart'" , "'Stephen Terrill'" , "'Igor Slepchin'" , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Sun, 1 Apr 2001 08:33:31 -0500 What you guys say in this mail thread mostly makes sense. [1] It is a good catch to notice that a user may actually "spawn" other user entities. I would say that from credentials and services perspectives we may want to have a "root" profile for the subscriber (which mostly contained his credentials and some basic identifiers), as well as a "sub profile" for each of this possible spawned entities. These sub profiles would define the limits and capabilities that each of this entities is allowed to have/use. [2] Incoming/outgoing (or if you will in PSTN terms originations/terminations) is more than helpful. It is essential to make this distinction, even giving that in the SIP world you seemingly have the ability to collapse it to just invitation to a multicast/unicast conference. As you, Dean, hinted there may be all kind of situations in which we may loose lots of essential information regarding the network behavior as well as the end points if we obscure everything to be regarded as just Invitation. [3] I still like to discuss (under a new mail thread with a different subject line) the very sensitive issues of a 3G mobile being able to bypass the IMS network by getting VOIP services from an external network (via the Access and the Packet Switch networks). If I remember correctly, it was brought up as a side affect discussion regarding the case of a stolen mobile in context of Informing UA after network initiated deregistration. [4]My understanding is that in Minneapolis it has been decided/approved to Inform a UA after network initiated deregistration. My questions to you guys are: [4.1] Has it been decided to go for implicit subscription for notification in the Registration request? or to specify it in a dedicated header? [4.2] Has any distinction been made between 'administrative' network initiated deregistration to 'reg. interval timer expiration' network initiated deregistration? (in the 3G cellular world there are possible rational for making these distinction, but let's keep it for later mails on the topic) Uri -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Saturday, March 31, 2001 7:29 PM To: bidulock@openss7.org Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip Subject: Re: [SIP] Informing UA after network initiated deregistration? Interesting point. One might take it even further -- the user may be represented by multiple identities, each of which may be participating in one or more sessions, each of which may have been instantiated by the user, another participant in the session, or by a non-participating third party. Some devices may be only be able to originate invitations. Some may be able only to respond to invitations. Some may do both, or their abilities may be dictated by the set of identities involved in the given context. Some devices will support multiple identities simultaneously. Others will not. One might choose to model the "meet me call" as a unique identity, instantiated for the duration of the "call", which participates in numerous "call legs" on a pairwise basis with each of the other participants. I believe a similar technique can be applied to all multiparty calling modes. In fact, I think Sparks and Campbell did an internet-draft illustrating that point. But "inbound" vs "outbound" is still a useful distinction, inasmuch as one or the other of the parties at each end of each call leg performed the signaling that instantiated that leg -- and the other party reacted to that signal. To paraphrase Einstein, I refuse to embrace a conceptuality without causality . . . -- Dean ----- Original Message ----- From: "Brian F. G. Bidulock" To: "Dean Willis" Cc: "Baniel Uri-CUB001" ; "'Bob Penfield'" ; "Sriram Parameswar" ; "'Romeo Zwart'" ; "'Stephen Terrill'" ; "'Igor Slepchin'" ; "'William Marshall'" ; "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" ; "sip" Sent: Saturday, March 31, 2001 6:48 PM Subject: Re: [SIP] Informing UA after network initiated deregistration? > Dean, > > People on this WG say how SIP is so different from > PSTN; yet, you cling to this artificial distinction > between inbound and outbound call? These are circuit > switched network concepts. > > Clinging to the concept of inbound and outbound is > why the PSTN had so much difficulty with services > like Meet-Me conferencing, Call Waiting and other > such stuff. > > Consider that the user is a participant in a > communications session whose establishment is > independent of its participants. > > Being able to give out invitations without also being > able to receive them severly limits the scope of > dependencies between sessions which can be expressed > by the protocol. Proxies wishing to provide this > wider scope of service offering should be permitted > to track registration and deregistration as it affects > the offering of this wider service range than just > incoming and outgoing. > > --brian > > Dean Willis wrote: (Sat, 31 Mar 2001 17:58:45) > > > > I really don't think I understand this whole argument. > > > > When I turn on the SIP phone on my desk, it sends register messages to three > > different registrars. > > > > Optionally, each registration could be authenticated with separate > > credentials. None of those credentials has anything whatsover to do with > > authorizing my phone to talk to the network. > > > > And NONE of those registrations have anything whatsoever to do with whether > > that phone can make a call. They influence only INBOUND calls to the > > identities associated with the registrations. > > > > Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on whether > > that phone has "access" to the network. In fact, it has to have access to > > the network BEFORE it can register. Registration is an application, not an > > access control mechanism. > > > > I think we're getting layer 2, 3, and 4 horribly confused. > > > > -- > > Dean > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ 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 Apr 2 03:25:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01718 for ; Mon, 2 Apr 2001 03:25:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EF1D44344; Mon, 2 Apr 2001 03:25: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 A7D834433E for ; Mon, 2 Apr 2001 03:24:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA11705; Mon, 2 Apr 2001 03:28:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 03:24:36 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , sip Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Apr 2001 03:24:30 -0400 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Saturday, March 31, 2001 10:18 PM > To: sip > Subject: [SIP] SDP: Sub-set or not in the 200 OK? > > > Hello, > > There have been already several mails showing certain confusion about > SDP usage in SIP. > In the last IETF the conclusion was: > For sendrecv flows (uni-directional flows are easy), the > caller puts in > the INVITe the codecs that he can both send AND receive. > > The open issue is what the callee returns: > 1) a sub-set of the codecs listed in the INVITE that he can send AND > receive. > 2) all the codecs that he can send AND receive. > > Note that caller and callee have reversed roles if the SDP from the > client to the server is sent in the ACK instead of in the INVITE. > > I would like to ask folks not to mix this open issue with another > similar issue: I have a DSP that cannot change codecs > on-the-fly, and I > want to pick up just one codec. Let us discuss this issue at > other time. > > My proposal is to go for solution number 2. This gives a symmetrical > negotiation. Besides, it covers more cases than solution number 1). It > can happen that for a particular codec, the callee can send > AND receive > it but the caller can just send it. Therefore, the caller does not > include it in the INVITE. However, if the callee lists it in > the 200 OK, > the caller will be able to send it. > > Opinions? I like it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Mon Apr 2 04:09:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07343 for ; Mon, 2 Apr 2001 04:09:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2761D44344; Mon, 2 Apr 2001 04:09: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 F018B4433E for ; Mon, 2 Apr 2001 04:08:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA11840; Mon, 2 Apr 2001 04:11:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 04:07:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Roy, Radhika R, ALCOO'" , Michael Thomas Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Response if user not registered? 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: Mon, 2 Apr 2001 04:07:49 -0400 I have to agree with Dean that this thread is awfully confused and sometimes frightening. People want to charge for outgoing calls through proxies. Whether I think thats a good idea or not is irrelevant. To do that, these people need to identify the person or phone making the call. Thats OK. In SIP, we have mechanisms for allowing outbound proxies to authenticate the caller, and determine exactly who they are. Just dandy. I am totally baffled as to what this has to do with SIP registrations. SIP registrations don't establish identity, they don't upload authorizations, or anything like that. They create address bindings. Creating address bindings has nothing to do with making outbound calls. I believe this issue in 3gpp arises because for them, they have "extended" register to do more than create bindings. They use it to assign the proxy which will handle both incoming and outgoing calls for the user, and basically do not allow outgoing calls until such a selection is made. So, we're really not talking about registrations in the sip sense. We are talking about a new function. As the function is one of policy, its also one which, arguably, is an implementation decision, not a protocol one. There is no reason why I cannot build proxies that refuse outgoing calls unless this assignment function has taken place. Again, whether or not this is a good thing, is an entirely separate question. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Sunday, April 01, 2001 5:27 PM > To: Michael Thomas > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Response if user not registered? > > > For SIP, that means you have no control over who I > use for the outbound proxy. There's no reason to > modify SIP to enforce something that is > unenforcible. > > [RRR] Still an association (e.g., > registration/INVITE-authentication etc.) > needs to be provided how charging can be made for service > offerings. (It is > not about control per se.) > > Radhika R. Roy > > Roy, Radhika R, ALCOO writes: > > Folks: > > > > Let us not forget the reality in offering the VoIP > services. As Brian has > > explained, there has to be charging. That is, there need to be an > > association between the caller (person) and the > device/location/address. > > > > (No one is disputing the fact that calls can always be > made is the IP > > addresses are known and routers can route the calls to the > destination IP > > addresses, and IP addresses can be assigned dynamically.) > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Friday, March 30, 2001 2:40 PM > > To: Michael Thomas > > Cc: Drage, Keith (Keith); Markus.Isomaki@nokia.com; 'Juha > Heinanen'; > > sip@lists.bell-labs.com > > Subject: Re: [SIP] Response if user not registered? > > > > > > Michael, > > > > I don't have an IP address tatooed on my forhead and > > my left hand. > > > > Also, some like to charge for calls based on where you > > are calling from. They often like to charge you, not > > your terminal. > > > > --Brian > > > > Michael Thomas wrote: (Fri, 30 Mar > 2001 10:46:32) > > > Brian F. G. Bidulock writes: > > > > Michael, > > > > > > > > Sorry Mike, registration is for personal mobility as > > > > well, not just terminal mobility. > > > > > > And this contradicts what I said... how? > > > It certainly doesn't make a case for linkage > > > of incoming and outgoing calls to some HLR-like > > > entity. Location is only important on the > > > incoming call side. The outgoing side is > > > completely separate. Likewise, data > > > connectivity is completely separate from > > > call/SIP presence. This is the fundamental > > > conflation that Q.931-like schemes get > > > completely wrong in the IP world. > > > > > > Mike > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts > himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one > persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to > himself. ¦ > > ¦ Therefore all progress > depends on the ¦ > > ¦ unreasonable man. -- George > Bernard Shaw ¦ > > > > _______________________________________________ > > 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@lists.bell-labs.com Mon Apr 2 06:01:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23152 for ; Mon, 2 Apr 2001 06:01:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FBF04433E; Mon, 2 Apr 2001 06:01:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9F1284433B for ; Mon, 2 Apr 2001 06:00:26 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 03:00:14 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Matt Holdrege'" , sip@lists.bell-labs.com Cc: tsvwg@ietf.org, "'Jonathan Rosenberg'" Subject: RE: [SIP] RE: SCTP as transport for SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB5B.B4B51C00" 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 Apr 2001 03:00:11 -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_01C0BB5B.B4B51C00 Content-Type: text/plain; charset="iso-8859-1" Hi Matt, Hi Matt, I'm not convinced that SIP needs to use ordered delivery of messages across multiple streams. If we are not using stream specification within SIP (and I think I agree with you now Jonathan) then I believe SIP should be using a single unordered reliable stream rather than any/all the streams. - This is simpler and as has been said before, a more complicated SIP adaptation layer may cause more complexity in transport-ignorant systems (whatever that might be ). This is also closer to the model used by the existing SIGTRAN adaptation layers (ie, one link => one stream). - The process of enforcing that an application must accept packets on all streams may force implementations on the API and design of the SCTP stack. The stack uses the concept of "used" and "unused" streams - what effect does using 64K streams on an association have on memory requirements. This may not be a relevant concern but I think SIP should try to be more conservative in its use of SCTP. - The sending of different call legs to different streams does not help much in my opinion. A single stream must still be able to accept packets for multiple call legs. - Using arbitrary streams does not allow the use of other streams for any future purpose. I'm also not convinced that the bundling of SIP messages is that useful - SIP messages are usually quite large anyway. However, an interesting application for SCTP with SIP might be on low bandwidth point to point connections. The SIP application controls the association and so it is not too unreasonable that the SIP application may negotiate the use of other streams in the same association for media use. Now the fragmentation properties of SCTP could reduce any delay/jitter in the media carried on the same SCTP association. This is not possible if SIP and media are carried in separate streams. [This is probably not a main-stream application and maybe not even useful/desirable but I don't think it should be impossible.] Jonathan, I see you think that SCTP is not worth the trouble for SIP. I think that SCTP becomes more attractive to SIP when the media also uses SCTP such that SCTP becomes the only transport protocol needed (although not necessarily on the same association). SCTP has the interesting property that it makes the normally connectionless unreliable UDP media become connection-oriented unreliable U-SCTP media. I can even foresee that in the future, SCTP associations could be linked to hardware routing and resource reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any work in this field although the stream-based flow-limiting extension is useful - sounds like a good thesis/paper to me.] Anyway, the only piece missing is an SDP profile for SCTP (which I'm still in the process of proposing something - input welcome). Comments please. Cheers, Robert. -- My opinions should not be taken as necessarily representing those of Nuera Communications, Inc. -- -----Original Message----- From: Matt Holdrege [mailto:matt@ipverse.com] Sent: Wednesday, March 28, 2001 3:39 AM To: sip@lists.bell-labs.com Subject: Re: [SIP] RE: SCTP as transport for SIP (from the SCTP AS) For SIP, considering the use of a reliable transport protocol (i.e. not UDP) the features of SCTP would be: - acknowledged error-free non-duplicated transfer of user data, - data fragmentation to conform to discovered path MTU size, - sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, - optional bundling of multiple user messages into a single SCTP packet, - network-level fault tolerance through supporting of multi-homing at either or both ends of an association. Applications that require framing of reliable data streams can get that feature from SCTP. Applications which transfer independent message sequences that are unrelated (sometimes called transactions) can benefit from the partial ordering provided by SCTP streams. Applications that wish to transfer messages that hold no particular sequence or relationship to one another can benefit from the unordered service provided by SCTP. Finally for those applications seeking network layer redundancy with multiple Network Interface cards can use SCTP's multi-homing feature. Is there any misunderstanding or disagreement with the above? _______________________________________________ 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_01C0BB5B.B4B51C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] RE: SCTP as transport for SIP

Hi Matt,

Hi Matt,

I'm not convinced that SIP needs to = use ordered delivery of messages across multiple streams. If we are not = using stream specification within SIP (and I think I agree with you now = Jonathan) then I believe SIP should be using a single unordered = reliable stream rather than any/all the streams.

  • This is simpler and as has been = said before, a more complicated SIP adaptation layer may cause more = complexity in transport-ignorant systems (whatever that might be = <grin>). This is also closer to the model used by the existing = SIGTRAN adaptation layers (ie, one link =3D> one = stream).
  • The process of enforcing that an = application must accept packets on all streams may force = implementations on the API and design of the SCTP stack. The stack uses = the concept of "used" and "unused" streams - what effect does using 64K = streams on an association have on memory requirements. This may not be = a relevant concern but I think SIP should try to be more conservative = in its use of SCTP.
  • The sending of  different call = legs to different streams does not help much in my opinion. A single = stream must still be able to accept packets for multiple call = legs.
  • Using arbitrary streams does not = allow the use of other streams for any future purpose.

I'm also not convinced that the = bundling of SIP messages is that useful - SIP messages are usually = quite large anyway. However, an interesting application for SCTP with = SIP might be on low bandwidth point to point connections. The SIP = application controls the association and so it is not too unreasonable = that the SIP application may negotiate the use of other streams in the = same association for media use. Now the fragmentation properties of = SCTP could reduce any delay/jitter in the media carried on the same = SCTP association. This is not possible if SIP and media are carried in = separate streams. [This is probably not a main-stream application and = maybe not even useful/desirable but I don't think it should be = impossible.]

Jonathan, I see you think that SCTP is = not worth the trouble for SIP. I think that SCTP becomes more = attractive to SIP when the media also uses SCTP such that SCTP becomes = the only transport protocol needed (although not necessarily on the = same association). SCTP has the interesting property that it makes the = normally connectionless unreliable UDP media become connection-oriented = unreliable U-SCTP media. I can even foresee that in the future, SCTP = associations could be linked to hardware routing and resource = reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of = any work in this field although the stream-based flow-limiting = extension is useful - sounds like a good thesis/paper to me.] Anyway, = the only piece missing is an SDP profile for SCTP (which I'm still in = the process of proposing something - input welcome).

Comments please.

Cheers,

Robert.

-- My opinions should not be taken as = necessarily representing those of Nuera Communications, Inc. --

-----Original = Message-----
From:   Matt Holdrege = [mailto:matt@ipverse.com]=
Sent:   Wednesday, March 28, 2001 3:39 AM
To:     sip@lists.bell-labs.com
Subject:       = Re: [SIP] RE: SCTP as transport for = SIP

(from the SCTP AS)

For SIP, considering the use of a = reliable transport protocol (i.e. not
UDP) the features of SCTP would = be:

- acknowledged error-free = non-duplicated transfer of user data,

- data fragmentation to conform to = discovered path MTU size,

- sequenced delivery of user messages = within multiple streams,
   with an option for = order-of-arrival delivery of individual user
   messages,

- optional bundling of multiple user = messages into a single SCTP packet,

- network-level fault tolerance = through supporting of multi-homing at
either or both ends of an = association.

Applications that require framing of = reliable data streams can get that
feature from SCTP.

Applications which transfer = independent message sequences that are
unrelated (sometimes called = transactions) can benefit from the partial
ordering provided by SCTP = streams.

Applications that wish to transfer = messages that hold no particular
sequence or relationship to one = another can benefit from the unordered
service provided by SCTP.

Finally for those applications seeking = network layer redundancy with
multiple Network Interface cards can = use SCTP's multi-homing feature.

Is there any misunderstanding or = disagreement with the above?


_______________________________________________
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_01C0BB5B.B4B51C00-- _______________________________________________ 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 Apr 2 06:16:02 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25234 for ; Mon, 2 Apr 2001 06:16:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFC574433E; Mon, 2 Apr 2001 06:16:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 57F0D4433B for ; Mon, 2 Apr 2001 06:15:36 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 03:15:24 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" , sip Cc: "'Robert Sparks'" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB5D.D2F3A770" 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 Apr 2001 03:15:21 -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_01C0BB5D.D2F3A770 Content-Type: text/plain; charset="iso-8859-1" Hi, Robert Sparks was saying at the bakeoff that UA's should put the set of vocoders that they can _receive_ in the SDP. This not only seems to be more in line with the SDP model but also cover a greater number of cases (such as playing RFC2833 DTMF but not detecting it). Perhaps you would be able to re-iterate what problems the send and receive approach solves that receive only does not ? Cheers, Robert. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, April 02, 2001 9:25 AM To: 'Gonzalo Camarillo'; sip Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Saturday, March 31, 2001 10:18 PM > To: sip > Subject: [SIP] SDP: Sub-set or not in the 200 OK? > > > Hello, > > There have been already several mails showing certain confusion about > SDP usage in SIP. > In the last IETF the conclusion was: > For sendrecv flows (uni-directional flows are easy), the > caller puts in > the INVITe the codecs that he can both send AND receive. > > The open issue is what the callee returns: > 1) a sub-set of the codecs listed in the INVITE that he can send AND > receive. > 2) all the codecs that he can send AND receive. > > Note that caller and callee have reversed roles if the SDP from the > client to the server is sent in the ACK instead of in the INVITE. > > I would like to ask folks not to mix this open issue with another > similar issue: I have a DSP that cannot change codecs > on-the-fly, and I > want to pick up just one codec. Let us discuss this issue at > other time. > > My proposal is to go for solution number 2. This gives a symmetrical > negotiation. Besides, it covers more cases than solution number 1). It > can happen that for a particular codec, the callee can send > AND receive > it but the caller can just send it. Therefore, the caller does not > include it in the INVITE. However, if the callee lists it in > the 200 OK, > the caller will be able to send it. > > Opinions? I like it. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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. ------_=_NextPart_001_01C0BB5D.D2F3A770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SDP: Sub-set or not in the 200 OK?

Hi,

Robert Sparks was saying at the = bakeoff that UA's should put the set of vocoders that they can = _receive_ in the SDP. This not only seems to be more in = line with the SDP model but also cover a greater number of cases (such = as playing RFC2833 DTMF but not detecting it).

Perhaps you would be able to = re-iterate what problems the send and receive approach solves that = receive only does not ?

Cheers,

Robert.

-----Original = Message-----
From:   Jonathan = Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent:   Monday, April 02, 2001 9:25 AM
To:     'Gonzalo Camarillo'; sip
Subject:       = RE: [SIP] SDP: Sub-set or not in the = 200 OK?



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Saturday, March 31, 2001 = 10:18 PM
> To: sip
> Subject: [SIP] SDP: Sub-set or = not in the 200 OK?
>
>
> Hello,
>
> There have been already several = mails showing certain confusion about
> SDP usage in SIP.
> In the last IETF the conclusion = was:
> For sendrecv flows = (uni-directional flows are easy), the
> caller puts in
> the INVITe the codecs that he = can both send AND receive.
>
> The open issue is what the = callee returns:
> 1) a sub-set of the codecs = listed in the INVITE that he can send AND
> receive.
> 2) all the codecs that he can = send AND receive.
>
> Note that caller and callee have = reversed roles if the SDP from the
> client to the server is sent in = the ACK instead of in the INVITE.
>
> I would like to ask folks not to = mix this open issue with another
> similar issue: I have a DSP that = cannot change codecs
> on-the-fly, and I
> want to pick up just one codec. = Let us discuss this issue at
> other time.
>
> My proposal is to go for = solution number 2. This gives a symmetrical
> negotiation. Besides, it covers = more cases than solution number 1). It
> can happen that for a particular = codec, the callee can send
> AND receive
> it but the caller can just send = it. Therefore, the caller does not
> include it in the INVITE. = However, if the callee lists it in
> the 200 OK,
> the caller will be able to send = it.
>
> Opinions?

I like it.

-Jonathan R.

---
Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; East Hanover, NJ 07936
jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
http://www.dynamicsoft.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.

------_=_NextPart_001_01C0BB5D.D2F3A770-- _______________________________________________ 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 Apr 2 07:03:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29099 for ; Mon, 2 Apr 2001 07:03: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 56B224433E; Mon, 2 Apr 2001 07:03: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 EC1C74433B for ; Mon, 2 Apr 2001 07:02:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr 2 06:59:59 EDT 2001 Received: by lists.bell-labs.com (Postfix) id D257244380; Mon, 2 Apr 2001 06:48:54 -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 4AA8B4437D for ; Mon, 2 Apr 2001 06:48:54 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 11:48:50 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E394@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" 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] A question about Cancel request 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 Apr 2001 11:48:41 +0100 I have a basic question about sip. Cancel request is used to cancel a pending INVITE. In sip signalling establishment procedure, if the callee agent for some reason fails, it can't receive anything from its proxy, after the proxy server of the callee retransmittes 6 times INVITE messges, it should give up sending INVITE. My quesiton is whether the Cancel request is needed to send out by the proxy server to the callee, if so, it will cause another 11 times cancle request beeing sent. 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@lists.bell-labs.com Mon Apr 2 08:47:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05679 for ; Mon, 2 Apr 2001 08:47:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41C214433E; Mon, 2 Apr 2001 08:47: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 0427A44344 for ; Mon, 2 Apr 2001 03:42:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA11747; Mon, 2 Apr 2001 03:40:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 03:37:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , "'Dean Willis'" , bidulock@openss7.org Cc: "'Bob Penfield'" , Sriram Parameswar , "'Romeo Zwart'" , "'Stephen Terrill'" , Igor Slepchin , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? 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: Mon, 2 Apr 2001 03:36:59 -0400 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Sunday, April 01, 2001 9:34 AM > To: 'Dean Willis'; bidulock@openss7.org > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > 'Romeo Zwart'; > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > Bonnie-BCHEN1; Xu Lang-LXU1; sip > Subject: RE: [SIP] Informing UA after network initiated > deregistration? > > [4]My understanding is that in Minneapolis it has been > decided/approved to > Inform a UA after network initiated deregistration. My > questions to you guys > are: > [4.1] Has it been decided to go for implicit subscription for > notification > in the Registration request? or to specify it in a dedicated header? More headers in registrations. I love it. When are we going to get the "by the way, I am interested in knowing when I have exactly 15 dollars left in my account, the one I set up with Mastercard". I propose: Mastercard-Balance-Subscription: 15;currency=dollar Just in case there are those who like this idea (and since sarcasm by email is sometimes missed) - no, we are NOT having a new header in registrations. Some have debated whether or not the presence spec allows or disallows "implicit" registrations. This fits into the growing category of things that "the SIP spec doesn't, nor shouldn't, say". SIP for presence specifies a way to create subscriptions, and a way to generate notifications for subscriptions. It does not say that when you build a system, the ONLY way to get subscriptions in there is to use the SUBSRIBE method. I think a web form is a perfectly fine way to create subscriptions. We then use our notification mechanisms to generate notifies for them. How the lifetimes of these subscriptions are managed is also an implementation issue. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Mon Apr 2 08:48:31 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05785 for ; Mon, 2 Apr 2001 08:48:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AFA9443A3; Mon, 2 Apr 2001 08:47:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-220.dallas.net [209.44.42.220]) by lists.bell-labs.com (Postfix) with ESMTP id 936C84433B for ; Mon, 2 Apr 2001 06:22:08 -0400 (EDT) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id FAA06247; Mon, 2 Apr 2001 05:21:50 -0500 From: "Brian F. G. Bidulock" To: Jonathan Rosenberg Cc: "'Roy, Radhika R, ALCOO'" , Michael Thomas , sip@lists.bell-labs.com Subject: Re: [SIP] Response if user not registered? Message-ID: <20010402052148.L22883@bfgbhome> Reply-To: bidulock@openss7.org Mail-Followup-To: Jonathan Rosenberg , "'Roy, Radhika R, ALCOO'" , Michael Thomas , sip@lists.bell-labs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from jdrosen@dynamicsoft.com on Mon, Apr 02, 2001 at 04:07:49AM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: 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 Apr 2001 05:21:48 -0500 Content-Transfer-Encoding: 8bit Jonathan, Good points. However, moving this exended registration function outside of SIP reduces SIP to no better than a connection establishment protocol which is ignorant of the service which is being provided by it. In that case, why not move SIP's inbound registration function outside the protocol as well... --Brian Jonathan Rosenberg wrote: (Mon, 02 Apr 2001 04:07:49) > > I have to agree with Dean that this thread is awfully confused and sometimes > frightening. > > People want to charge for outgoing calls through proxies. Whether I think > thats a good idea or not is irrelevant. To do that, these people need to > identify the person or phone making the call. Thats OK. In SIP, we have > mechanisms for allowing outbound proxies to authenticate the caller, and > determine exactly who they are. Just dandy. I am totally baffled as to what > this has to do with SIP registrations. SIP registrations don't establish > identity, they don't upload authorizations, or anything like that. They > create address bindings. Creating address bindings has nothing to do with > making outbound calls. > > I believe this issue in 3gpp arises because for them, they have "extended" > register to do more than create bindings. They use it to assign the proxy > which will handle both incoming and outgoing calls for the user, and > basically do not allow outgoing calls until such a selection is made. So, > we're really not talking about registrations in the sip sense. We are > talking about a new function. As the function is one of policy, its also one > which, arguably, is an implementation decision, not a protocol one. There is > no reason why I cannot build proxies that refuse outgoing calls unless this > assignment function has taken place. Again, whether or not this is a good > thing, is an entirely separate question. > > -Jonathan R. -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ 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 Apr 2 08:52:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05978 for ; Mon, 2 Apr 2001 08:52:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06F8E443AD; Mon, 2 Apr 2001 08:47:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id DC9E84433B for ; Mon, 2 Apr 2001 06:49:33 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA09287 for ; Mon, 2 Apr 2001 03:49:33 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA12748 for ; Mon, 2 Apr 2001 03:49:33 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 2 Apr 2001 05:49:32 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451DA@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Jonathan Rosenberg'" , Baniel Uri-CUB001 , "'Dean Willis'" , bidulock@openss7.org Cc: "'Bob Penfield'" , Sriram Parameswar , "'Romeo Zwart'" , "'Stephen Terrill'" , Igor Slepchin , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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: Mon, 2 Apr 2001 05:49:30 -0500 First, it is no one's hobby to change and complicate the spec every other day. Even in a case when a change/addition seems to be in place, I wouldn't want to be the programmer, who will have to go backward and update a SIP client/server code. (Maybe we should assume this work as a punishment to the person, who offers the change, and we will make him/her do it in assembly after the second pass of compilation to the original code) Anyhow one question is whether a Subscribe-Notify for a deregistration event may be on a registration cycle basis or per subscriber profile. For instance, say the Chief Scientist of dynamicsoft is waiting for a very important incoming call on his SIP phone and the call never comes. He may be upset to realize it happened (or as a matter of fact, did not happen), because his SIP phone had been deregistered (for whatever reason) already 20 minutes ago, and he had no idea about it. I totally agree that if the notification for deregistration is on a per subscriber basis, then the subscription may be done either by filling in a web page application form and shipping it off to the server, or by meeting the admin at the local pub and ask him/her to do it as a favor. If/when the notification for deregistration is on a per registration cycle basis, then if the client could hint the registrar (as part of the Registration request) about the wish to be notified either by winking his eye or by any other mean it could have been helpful. It is true that the SUBSCRIBE-NOTIFY mechanism is already out there, and now implementers may want to use some creativity in utilizing it, rather than changing the existing spec. Uri. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, April 02, 2001 2:37 AM To: 'Baniel Uri-CUB001'; 'Dean Willis'; bidulock@openss7.org Cc: 'Bob Penfield'; Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip Subject: RE: [SIP] Informing UA after network initiated deregistration? > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Sunday, April 01, 2001 9:34 AM > To: 'Dean Willis'; bidulock@openss7.org > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > 'Romeo Zwart'; > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > Bonnie-BCHEN1; Xu Lang-LXU1; sip > Subject: RE: [SIP] Informing UA after network initiated > deregistration? > > [4]My understanding is that in Minneapolis it has been > decided/approved to > Inform a UA after network initiated deregistration. My > questions to you guys > are: > [4.1] Has it been decided to go for implicit subscription for > notification > in the Registration request? or to specify it in a dedicated header? More headers in registrations. I love it. When are we going to get the "by the way, I am interested in knowing when I have exactly 15 dollars left in my account, the one I set up with Mastercard". I propose: Mastercard-Balance-Subscription: 15;currency=dollar Just in case there are those who like this idea (and since sarcasm by email is sometimes missed) - no, we are NOT having a new header in registrations. Some have debated whether or not the presence spec allows or disallows "implicit" registrations. This fits into the growing category of things that "the SIP spec doesn't, nor shouldn't, say". SIP for presence specifies a way to create subscriptions, and a way to generate notifications for subscriptions. It does not say that when you build a system, the ONLY way to get subscriptions in there is to use the SUBSRIBE method. I think a web form is a perfectly fine way to create subscriptions. We then use our notification mechanisms to generate notifies for them. How the lifetimes of these subscriptions are managed is also an implementation issue. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Mon Apr 2 09:42:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08913 for ; Mon, 2 Apr 2001 09:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6822A4433E; Mon, 2 Apr 2001 09:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by lists.bell-labs.com (Postfix) with ESMTP id 795C444395 for ; Mon, 2 Apr 2001 09:41:01 -0400 (EDT) Received: from pcx (isdn018120.usr.hananet.net [210.94.18.120]) by marlborough.cnchost.com id JAA14047; Mon, 2 Apr 2001 09:40:43 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <00c301c0bb7a$7b8b39e0$25125ed2@domaind> Reply-To: "dov" From: "dov" To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" , "sip" Cc: "'Robert Sparks'" References: Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? Organization: Startek Technologies MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C0BB8A.8B265500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Apr 2001 15:35:27 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C0BB8A.8B265500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SDP: Sub-set or not in the 200 OK?Hi, I agree with Robert that SIP-UAs shall send the set of vocoders that = they can _receive_ in the SDP, in order to allow SIP-UAs to receive Audio/Video streams, even if they = can not transmit them. This can be the case for SIP-UAs capable of receiving MP3 Audio or MPEG = video streams,=20 but do not have the Hardware and the CPU power (nor the license) to do = encoding. Best Regards, Dov Ben-Asher. General Manager, Startek Technologies. _____________________________________________ Email: dov@ipness.com Web: www.ipness.com Direct: +972 51 500017 Phone: +972 4 9887666 Fax: +972 4 9887667 _____________________________________________ ----- Original Message -----=20 From: Fairlie-Cuninghame, Robert=20 To: 'Jonathan Rosenberg' ; 'Gonzalo Camarillo' ; sip=20 Cc: 'Robert Sparks'=20 Sent: Monday, April 02, 2001 12:15 PM Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Hi,=20 Robert Sparks was saying at the bakeoff that UA's should put the set = of vocoders that they can _receive_ in the SDP. This not only seems to = be more in line with the SDP model but also cover a greater number of = cases (such as playing RFC2833 DTMF but not detecting it).=20 Perhaps you would be able to re-iterate what problems the send and = receive approach solves that receive only does not ?=20 Cheers,=20 Robert.=20 -----Original Message-----=20 From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Monday, April 02, 2001 9:25 AM=20 To: 'Gonzalo Camarillo'; sip=20 Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK?=20 =20 > -----Original Message-----=20 > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]=20 > Sent: Saturday, March 31, 2001 10:18 PM=20 > To: sip=20 > Subject: [SIP] SDP: Sub-set or not in the 200 OK?=20 >=20 >=20 > Hello,=20 >=20 > There have been already several mails showing certain confusion = about=20 > SDP usage in SIP.=20 > In the last IETF the conclusion was:=20 > For sendrecv flows (uni-directional flows are easy), the=20 > caller puts in=20 > the INVITe the codecs that he can both send AND receive.=20 >=20 > The open issue is what the callee returns:=20 > 1) a sub-set of the codecs listed in the INVITE that he can send AND = > receive.=20 > 2) all the codecs that he can send AND receive.=20 >=20 > Note that caller and callee have reversed roles if the SDP from the=20 > client to the server is sent in the ACK instead of in the INVITE.=20 >=20 > I would like to ask folks not to mix this open issue with another=20 > similar issue: I have a DSP that cannot change codecs=20 > on-the-fly, and I=20 > want to pick up just one codec. Let us discuss this issue at=20 > other time.=20 >=20 > My proposal is to go for solution number 2. This gives a symmetrical = > negotiation. Besides, it covers more cases than solution number 1). = It=20 > can happen that for a particular codec, the callee can send=20 > AND receive=20 > it but the caller can just send it. Therefore, the caller does not=20 > include it in the INVITE. However, if the callee lists it in=20 > the 200 OK,=20 > the caller will be able to send it.=20 >=20 > Opinions?=20 I like it.=20 -Jonathan R.=20 ---=20 Jonathan D. Rosenberg 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.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000=20 http://www.dynamicsoft.com=20 _______________________________________________=20 This list is for continuing development of the SIP protocol.=20 The sip-implementor's list is the place to discuss implementation,=20 and to receive advice on understanding existing sip.=20 To subscribe to it, send mail to=20 sip-implementors-request@cs.columbia.edu with "subscribe" in the body. = ------=_NextPart_000_00BA_01C0BB8A.8B265500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SDP: Sub-set or not in the 200 OK?
Hi,
 
I agree with Robert = that SIP-UAs shall send the set of vocoders that they = can _receive_ in = the=20 SDP,
in order to allow SIP-UAs to = receive=20 Audio/Video streams, even if they can not transmit them.
 
This can be the case for SIP-UAs = capable of=20 receiving MP3 Audio or MPEG video streams,
but do not have the Hardware and the = CPU power=20 (nor the license) to do encoding.
 
Best Regards,
Dov Ben-Asher.
General Manager,
Startek=20 Technologies.
_____________________________________________
Email: = dov@ipness.com    =     =20 Web: www.ipness.com
Direct: = +972 51=20 500017
Phone: +972 4 = 9887666        Fax:=20 +972 4 9887667
_____________________________________________
----- Original Message -----
From:=20 Fairlie-Cuninghame, Robert
To: 'Jonathan=20 Rosenberg' ; 'Gonzalo Camarillo' ; sip=20
Cc: 'Robert=20 Sparks'
Sent: Monday, April 02, 2001 = 12:15=20 PM
Subject: RE: [SIP] SDP: Sub-set = or not in=20 the 200 OK?

Hi,

Robert Sparks was saying at the bakeoff = that UA's=20 should put the set of vocoders that they can _receive_ in the SDP. = This not only=20 seems to be more in line with the SDP model but also cover a greater = number of=20 cases (such as playing RFC2833 DTMF but not detecting it).

Perhaps you would be able to re-iterate = what=20 problems the send and receive approach solves that receive only does = not=20 ?

Cheers,

Robert.

-----Original=20 Message-----
From:  =20 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
Sent:   Monday, April 02, 2001 9:25 AM
To:     'Gonzalo=20 Camarillo'; sip
Subject:        = RE: [SIP] SDP: Sub-set or not in the 200 = OK?=20



 

> -----Original Message----- =
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarill= o@lmf.ericsson.se]=20
> Sent: Saturday, March 31, 2001 = 10:18=20 PM
> To: sip =
> Subject: [SIP] SDP: Sub-set or not in the 200 OK? =
>
> =
> Hello,
>
> There have = been already=20 several mails showing certain confusion about
> SDP usage in SIP.
> In the=20 last IETF the conclusion was:
> For=20 sendrecv flows (uni-directional flows are easy), the
> caller puts in
>=20 the INVITe the codecs that he can both send AND receive. =
>
> = The open issue=20 is what the callee returns:
> 1) a=20 sub-set of the codecs listed in the INVITE that he can send AND =
> receive.
> 2) all the codecs that he can send AND receive. =
>
> = Note that=20 caller and callee have reversed roles if the SDP from the =
> client to the server is sent in the ACK = instead of in=20 the INVITE.
> =
> I would like to ask folks not to mix this = open issue=20 with another
> similar = issue: I have a=20 DSP that cannot change codecs
>=20 on-the-fly, and I
> want to = pick up just=20 one codec. Let us discuss this issue at
> other time.
>=20
> My proposal is to go for = solution=20 number 2. This gives a symmetrical
>=20 negotiation. Besides, it covers more cases than solution number 1). = It=20
> can happen that for a particular = codec, the=20 callee can send
> AND = receive=20
> it but the caller can just send = it.=20 Therefore, the caller does not
> include=20 it in the INVITE. However, if the callee lists it in
> the 200 OK,
> the=20 caller will be able to send it.
>=20
> Opinions?

I like it.

-Jonathan R.

---
Jonathan D.=20 = Rosenberg          &nbs= p;           =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.cs.columbia.edu/~jdrosen   =      =20 PHONE: (973) 952-5000
http://www.dynamicsoft.com


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

------=_NextPart_000_00BA_01C0BB8A.8B265500-- _______________________________________________ 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 Apr 2 10:00:43 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10102 for ; Mon, 2 Apr 2001 10:00:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA4154439E; Mon, 2 Apr 2001 10:00:40 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id A6C7644398 for ; Mon, 2 Apr 2001 09:59:32 -0400 (EDT) Received: from DDCW6701 [63.113.183.106] by edgeconnect.com with ESMTP (SMTPD32-6.06) id A3116EFE006A; Mon, 02 Apr 2001 06:48:01 -0700 From: "Victor A Paulsamy" To: "SIP" , "Gonzalo Camarillo" Cc: "Victor A Paulsamy" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AC69DDE.7A1EDC38@lmf.ericsson.se> 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: Fri, 2 Feb 2001 09:01:56 -0500 Content-Transfer-Encoding: 7bit -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo Camarillo Sent: Saturday, March 31, 2001 10:18 PM To: sip Subject: [SIP] SDP: Sub-set or not in the 200 OK? >My proposal is to go for solution number 2. This gives a symmetrical >negotiation. Besides, it covers more cases than solution number 1). It >can happen that for a particular codec, the callee can send AND receive >it but the caller can just send it. Therefore, the caller does not >include it in the INVITE. However, if the callee lists it in the 200 OK, >the caller will be able to send it. This holds good *only* for sending DTMF tones. Otherwise, this would mean two media streams encoded *differently* (one in each direction) in a session. Is my understanding correct? Warm regards, --victor _______________________________________________ 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 Apr 2 11:04:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13920 for ; Mon, 2 Apr 2001 11:04: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 2236E4433E; Mon, 2 Apr 2001 11:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id A7BF14433B for ; Mon, 2 Apr 2001 11:03:39 -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.9.3/8.9.1) with ESMTP id IAA01056; Mon, 2 Apr 2001 08:03:40 -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 ADH16802; Mon, 2 Apr 2001 08:03:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04643; Mon, 2 Apr 2001 08:03:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15048.38086.851231.705870@thomasm-u1.cisco.com> To: "Fairlie-Cuninghame, Robert" Cc: "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" , sip , "'Robert Sparks'" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? 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! 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 Apr 2001 08:03:34 -0700 (PDT) Content-Transfer-Encoding: 7bit That's in line with the way I understand things. I really don't know what send has to do with anything. I can claim I'm going to send purple elephants but when push comes to shove, the purple elephants never seem to make it onto the wire. The obnoxious thing for the receiver is that it may have had to load its purple elephant receiver. Unless the receiver can say that it doesn't want to receive purple elephants, you're going to end up with a situation where you can't communicate at all, and that doesn't sound like it's headed in the right direction. I believe that Gonzalo's proposal still misses one property which I have always thought is at the root of all of this: it doesn't allow us to propose several alternatives, but the the receiver picks one (or a subset) which is what is actually loaded into both the sender's and receiver's DSP. This obviously requires a three way handshake if you want the "this is what I can receive" model Robert is speaking of here. Maybe SIP too should look at Christian's proposal for multiple SDP's (in MEGACO) when this is the desired behavior. Mike Fairlie-Cuninghame, Robert writes: > Hi, > > Robert Sparks was saying at the bakeoff that UA's should put the set of > vocoders that they can _receive_ in the SDP. This not only seems to be more > in line with the SDP model but also cover a greater number of cases (such as > playing RFC2833 DTMF but not detecting it). > > Perhaps you would be able to re-iterate what problems the send and receive > approach solves that receive only does not ? > > Cheers, > > Robert. > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, April 02, 2001 9:25 AM > To: 'Gonzalo Camarillo'; sip > Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? > > > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Saturday, March 31, 2001 10:18 PM > > To: sip > > Subject: [SIP] SDP: Sub-set or not in the 200 OK? > > > > > > Hello, > > > > There have been already several mails showing certain confusion about > > SDP usage in SIP. > > In the last IETF the conclusion was: > > For sendrecv flows (uni-directional flows are easy), the > > caller puts in > > the INVITe the codecs that he can both send AND receive. > > > > The open issue is what the callee returns: > > 1) a sub-set of the codecs listed in the INVITE that he can send AND > > receive. > > 2) all the codecs that he can send AND receive. > > > > Note that caller and callee have reversed roles if the SDP from the > > client to the server is sent in the ACK instead of in the INVITE. > > > > I would like to ask folks not to mix this open issue with another > > similar issue: I have a DSP that cannot change codecs > > on-the-fly, and I > > want to pick up just one codec. Let us discuss this issue at > > other time. > > > > My proposal is to go for solution number 2. This gives a symmetrical > > negotiation. Besides, it covers more cases than solution number 1). It > > can happen that for a particular codec, the callee can send > > AND receive > > it but the caller can just send it. Therefore, the caller does not > > include it in the INVITE. However, if the callee lists it in > > the 200 OK, > > the caller will be able to send it. > > > > Opinions? > > I like it. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.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. > > > > > > RE: [SIP] SDP: Sub-set or not in the 200 OK? > > > >

Hi, >

> >

Robert Sparks was saying at the bakeoff that UA's should put the set of vocoders that they can _receive_ in the SDP. This not only seems to be more in line with the SDP model but also cover a greater number of cases (such as playing RFC2833 DTMF but not detecting it).

> >

Perhaps you would be able to re-iterate what problems the send and receive approach solves that receive only does not ? >

> >

Cheers, >

> >

Robert. >

> >

-----Original Message----- >
From:   Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >
Sent:   Monday, April 02, 2001 9:25 AM >
To:     'Gonzalo Camarillo'; sip >
Subject:        RE: [SIP] SDP: Sub-set or not in the 200 OK? >

>
>
> >

  >

> >

> -----Original Message----- >
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] >
> Sent: Saturday, March 31, 2001 10:18 PM >
> To: sip >
> Subject: [SIP] SDP: Sub-set or not in the 200 OK? >
> >
> >
> Hello, >
> >
> There have been already several mails showing certain confusion about >
> SDP usage in SIP. >
> In the last IETF the conclusion was: >
> For sendrecv flows (uni-directional flows are easy), the >
> caller puts in >
> the INVITe the codecs that he can both send AND receive. >
> >
> The open issue is what the callee returns: >
> 1) a sub-set of the codecs listed in the INVITE that he can send AND >
> receive. >
> 2) all the codecs that he can send AND receive. >
> >
> Note that caller and callee have reversed roles if the SDP from the >
> client to the server is sent in the ACK instead of in the INVITE. >
> >
> I would like to ask folks not to mix this open issue with another >
> similar issue: I have a DSP that cannot change codecs >
> on-the-fly, and I >
> want to pick up just one codec. Let us discuss this issue at >
> other time. >
> >
> My proposal is to go for solution number 2. This gives a symmetrical >
> negotiation. Besides, it covers more cases than solution number 1). It >
> can happen that for a particular codec, the callee can send >
> AND receive >
> it but the caller can just send it. Therefore, the caller does not >
> include it in the INVITE. However, if the callee lists it in >
> the 200 OK, >
> the caller will be able to send it. >
> >
> Opinions? >

> >

I like it. >

> >

-Jonathan R. >

> >

--- >
Jonathan D. Rosenberg                       72 Eagle Rock Ave. >
Chief Scientist                             First Floor >
dynamicsoft                                 East Hanover, NJ 07936 >
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050 >
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000 >
http://www.dynamicsoft.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. >

> > > _______________________________________________ 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 Apr 2 11:22:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14963 for ; Mon, 2 Apr 2001 11:22:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B678D443A7; Mon, 2 Apr 2001 11:22:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from socket.socketip.no (socket.socketip.no [195.159.100.120]) by lists.bell-labs.com (Postfix) with ESMTP id 4C62A4433E for ; Mon, 2 Apr 2001 11:21:03 -0400 (EDT) Received: from nlorentz (socketip111.socketip.no [195.159.100.111]) by socket.socketip.no (8.11.0/8.8.7) with SMTP id f32FL2v12972 for ; Mon, 2 Apr 2001 17:21:02 +0200 From: Nils Henrik Lorentzen X-Mailer: KMail [version 1.1.95.5] Content-Type: text/plain; charset="iso-8859-1" To: SIP List MIME-Version: 1.0 Message-Id: <01040217210300.11630@nlorentz> Content-Transfer-Encoding: 8bit Subject: [SIP] Inconsistency between SIP draft and FAQ ? 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 Apr 2001 17:21:03 +0200 Content-Transfer-Encoding: 8bit Hi, I have trouble understanding how to recognize when a request is a retransmit. From the FAQ: ---- header retransmitted duplicate matching response From same same same To same same same, but tag may have been added Call-ID same same same request URI same same n/a CSeq same same same Via - - must be local host; check for branch parameter to identify which --- So retransmits may be recognized by comparing From, To, CallID, CSeq and Request-URI. However, the sip draft says in section 11.5: "2. If the Call-ID exists, the request is for an existing call. If the To, From, Call-ID, and CSeq values exactly match (including tags) those of any requests received previously, the request is a retransmission." Here, the request-URI is not mentioned. Reason why I ask: If more than one of the forked requests of a forking proxy ends up at the same UAS, how does the UAS know that these are different callegs ? From what I can see in the examples in the spec, the forking proxy's downstream requests only differ in via branch and in request URL, ie To, From, CallID and CSeq are the same. So if the UAS uses just To, From, CallID and CSeq to identify a transaction, all but the first request that resulted from the fork will be ignored as retransmits. Would someone please enlighten me on this ? Nils Henrik _______________________________________________ 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 Apr 2 12:38:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19269 for ; Mon, 2 Apr 2001 12:38:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88DF2443A7; Mon, 2 Apr 2001 12:38:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by lists.bell-labs.com (Postfix) with ESMTP id 454A8443AD for ; Mon, 2 Apr 2001 12:36:55 -0400 (EDT) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f32Garr14294 for ; Mon, 2 Apr 2001 18:36:53 +0200 (MET DST) Received: from alcatel.be ([138.203.253.229]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A22.005B3D25; Mon, 2 Apr 2001 18:36:34 +0200 Message-ID: <3AC8AA8F.EBE6067@alcatel.be> From: Lieve Bos X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------7E0267415C15E4E1BACB5794" Subject: [SIP] unsubscribe 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 Apr 2001 18:36:31 +0200 This is a multi-part message in MIME format. --------------7E0267415C15E4E1BACB5794 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can somebody please unsubscribe me from this e-mail exploder? Thanks, Lieve Bos --------------7E0267415C15E4E1BACB5794 Content-Type: text/x-vcard; charset=us-ascii; name="lieve.bos.vcf" Content-Description: Card for Lieve Bos Content-Disposition: attachment; filename="lieve.bos.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bos;Lieve tel;fax:+32(0)3 2409932 tel;work:+32(0)3 2415891 x-mozilla-html:FALSE url:http://www.rc.bel.alcatel.be/projects/mobile/umts/nait1.html org:Alcatel Bell;Mobile Project / Network Strategy Group version:2.1 email;internet:lieve.bos@alcatel.be adr;quoted-printable:;;Francis Wellesplein 1=0D=0A=0D=0A;Antwerpen;;2018;Belgium x-mozilla-cpt:;-29776 fn:Lieve Bos end:vcard --------------7E0267415C15E4E1BACB5794-- _______________________________________________ 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 Apr 2 13:57:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23345 for ; Mon, 2 Apr 2001 13:57:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBEB6443A3; Mon, 2 Apr 2001 13:57:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id ABBDF4433E for ; Mon, 2 Apr 2001 13:56:52 -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 f32HuFI04114; Mon, 2 Apr 2001 19:56:16 +0200 (MEST) Received: from lmf.ericsson.se ([138.85.235.239]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id TAA17739; Mon, 2 Apr 2001 19:56:08 +0200 (MET DST) Message-ID: <3AC8BC9F.978DA15F@lmf.ericsson.se> 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: "Fairlie-Cuninghame, Robert" Cc: "'Jonathan Rosenberg'" , sip , "'Robert Sparks'" , dov , Michael Thomas , Victor A Paulsamy Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? 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 Apr 2001 20:53:35 +0300 Content-Transfer-Encoding: 7bit Hello, I am going to try to answer all the mails of the thread so far. Comments inline: "Fairlie-Cuninghame, Robert" wrote: > Robert Sparks was saying at the bakeoff that UA's should put the set > of vocoders that they can _receive_ in the SDP. This not only seems to > be more in line with the SDP model but also cover a greater number of > cases (such as playing RFC2833 DTMF but not detecting it). > > Perhaps you would be able to re-iterate what problems the send and > receive approach solves that receive only does not ? OK, first of all, we are just dealing with sendrev streams. This is just a clarification. Following your suggestion, the caller lists the codecs he can receive in the INVITE. The callee now does not know if a bi-directional stream can be established, because he does not know which codecs the caller is able to send. Example: both caller and callee can receive codecs 1 and 2, but not send them. The INVITE would contain codecs 1 and 2, and the 200 OK will also contain both codecs. The INVITE-200 OK-ACK is successful, but the session cannot be established. If both systems list the codecs that they can send AND receive, if the INVITE-200 OK-ACK is successful (that is, the 200 OK contains at least one codec that appeared int he INVITE), both parties are sure that the session can take place. dov wrote: >I agree with Robert that SIP-UAs shall send the set of vocoders that they can _receive_ in the SDP, >in order to allow SIP-UAs to receive Audio/Video streams, even if they can not transmit them. > >This can be the case for SIP-UAs capable of receiving MP3 Audio or MPEG video streams, >but do not have the Hardware and the CPU power (nor the license) to do encoding. If you want to receive a video stream, your should establish a recvonly stream and receive whatever you want. The open issue has to do with sendrecv streams. Michael Thomas wrote: > > That's in line with the way I understand things. > I really don't know what send has to do with > anything. It has to do with bi-directional streams. We want to negotiate a sendrecv stream. Therefore, we have to be sure that both parties can send AND receive. > I can claim I'm going to send purple > elephants but when push comes to shove, the purple > elephants never seem to make it onto the wire. > The obnoxious thing for the receiver is that it > may have had to load its purple elephant receiver. > Unless the receiver can say that it doesn't want > to receive purple elephants, you're going to end > up with a situation where you can't communicate > at all, and that doesn't sound like it's headed > in the right direction. If the receiver does not want to receive purple elephants (or codec number 1, for instace), it will just not list it in the 200 OK. Then, the caller will not send elephants of any kind. It will stick to what the callee has listed in the 200 OK. > > I believe that Gonzalo's proposal still misses one > property which I have always thought is at the > root of all of this: it doesn't allow us to > propose several alternatives, but the the receiver > picks one (or a subset) which is what is actually > loaded into both the sender's and receiver's DSP. I knew it!!!!! :o) I quoute from my first mail: Gonzalo wrote: > > I would like to ask folks not to mix this open issue with another > > similar issue: I have a DSP that cannot change codecs > > on-the-fly, and I > > want to pick up just one codec. Let us discuss this issue at > > other time. Victor A Paulsamy wrote: > This holds good *only* for sending DTMF tones. Otherwise, this would mean > two media streams encoded *differently* (one in each direction) in a > session. Is my understanding correct? No. What you want to do can be done using the SDP fid attribute (I will be releasing the new version of the draft today or tomorrow). Here we are dealing with plain SDP. Jonathan Rosenberg wrote: > I like it. I also think, as we discussed in the last SIP meeting, that this is the way to go. This way, when an implementation lists in the 200 OK at least one codec that was listed in the INVITE, it is ensured that the session will be established properly. Of course that we do not cover corner cases when one application can send a set of codecs and receive a different set of codecs. That's why we have extensions such as the fid stuff. Best 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 _______________________________________________ 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 Apr 2 16:49:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00446 for ; Mon, 2 Apr 2001 16:49:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49DCB4433F; Mon, 2 Apr 2001 16:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id 679CC44338 for ; Mon, 2 Apr 2001 16:48:16 -0400 (EDT) Received: from DDCW6701 [63.113.183.106] by edgeconnect.com with ESMTP (SMTPD32-6.06) id A2E522B0134; Mon, 02 Apr 2001 13:36:53 -0700 From: "Victor A Paulsamy" To: "Gonzalo Camarillo" Cc: "SIP" , "Victor A Paulsamy" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AC8BC9F.978DA15F@lmf.ericsson.se> 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: Mon, 2 Apr 2001 15:50:40 -0400 Content-Transfer-Encoding: 7bit -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo Camarillo Sent: Monday, April 02, 2001 1:54 PM To: Fairlie-Cuninghame, Robert Cc: 'Jonathan Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas; Victor A Paulsamy Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? Gonzalo Camarillo wrote: >My proposal is to go for solution number 2. This gives a symmetrical >negotiation. Besides, it covers more cases than solution number 1). It >can happen that for a particular codec, the callee can send AND receive >it but the caller can just send it. Therefore, the caller does not >include it in the INVITE. However, if the callee lists it in the 200 OK, >the caller will be able to send it. Victor A Paulsamy wrote: > This holds good *only* for sending DTMF tones. Otherwise, this would mean > two media streams encoded *differently* (one in each direction) in a > session. Is my understanding correct? Gonzalo Camarillo wrote: >No. What you want to do can be done using the SDP fid attribute (I will >be releasing the new version of the draft today or tomorrow). Here we >are dealing with plain SDP. Let me give an example. Using codec '0' the caller can only send and the callee can send and receive. The caller sends out codec 3, 4, 5 in the INVITE. The callee responds with 0, 3, 4, 5 in the 200 OK. If the caller choses to send its media stream using codec '0' (since it's included in 200 OK), it has to use *another codec* to receive the media stream as it cannot receive using codec '0'. This would give rise to two codecs, one for transmission and another for reception. This fits the model of transmitting DTMF tones, where PCM codecs will be used to transmit it rather than speech codecs. Warm regards, --victor _______________________________________________ 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 Apr 2 17:57:03 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 RAA02509 for ; Mon, 2 Apr 2001 17:57:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEB6044371; Mon, 2 Apr 2001 17:57:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id E223C44359 for ; Mon, 2 Apr 2001 17:56:05 -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 f32Lu5s02837; Mon, 2 Apr 2001 23:56:05 +0200 (MEST) Received: from lmf.ericsson.se (racom107003.am.ericsson.se [147.117.107.3]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA26844; Mon, 2 Apr 2001 23:56:01 +0200 (MET DST) Message-ID: <3AC8F4D7.C51FC7A9@lmf.ericsson.se> 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: Victor A Paulsamy Cc: SIP Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? 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: Tue, 03 Apr 2001 00:53:27 +0300 Content-Transfer-Encoding: 7bit Victor A Paulsamy wrote: > > The caller sends out codec 3, 4, 5 in the INVITE. The callee responds with > 0, 3, 4, 5 in the 200 OK. > If the caller choses to send its media stream using codec '0' (since it's > included in 200 OK), it has to use *another codec* > to receive the media stream as it cannot receive using codec '0'. This would > give rise to two codecs, one for transmission and another for reception. Actually that's why I am proposing to let the 200 OK contain the list of codecs that the callee can send AND receive (as opposed to just a sub-set of the codecs that were present in the INVITE). We both agree. 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 _______________________________________________ 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 Tue Apr 3 06:35: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 GAA25712 for ; Tue, 3 Apr 2001 06:35: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 9D9004433E; Tue, 3 Apr 2001 06:35:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6874E44338 for ; Tue, 3 Apr 2001 06:34:45 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 03:34:16 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Victor A Paulsamy'" , Gonzalo Camarillo Cc: SIP Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BC29.A1EC1AA0" 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 Apr 2001 03:34:16 -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_01C0BC29.A1EC1AA0 Content-Type: text/plain; charset="iso-8859-1" Victor, I think there is some confusion here: selecting different vocoders for each direction is entirely permissible. However, Gonzalo's point is illustrated in the following example: A can receive 0,1,2,3 but can only send 0. And B can send and receive only 2 & 3. In this case a bidirectional session is not possible because they is no vocoder that can be sent from A->B. Two approaches: - Use stardard SDP receive only SDP vocoder lists and then report incompatibilities in the SIP plane (one side can always detect this non-bidirectional situation and can terminate the call if desired - it may be happy to just receive). This is still more flexible and simpler in my mind. - Only place send and receive in the SDP list which creates big headaches for vocoders which can only be send or received (eg video or DTMF) (eg requires use of fid draft so that multiple media announcements can be linked to the same flow id). Regards, Robert. -----Original Message----- From: Victor A Paulsamy [mailto:victor@voicecore.com] Sent: Monday, April 02, 2001 9:51 PM To: Gonzalo Camarillo Cc: SIP; Victor A Paulsamy Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo Camarillo Sent: Monday, April 02, 2001 1:54 PM To: Fairlie-Cuninghame, Robert Cc: 'Jonathan Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas; Victor A Paulsamy Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? Gonzalo Camarillo wrote: >My proposal is to go for solution number 2. This gives a symmetrical >negotiation. Besides, it covers more cases than solution number 1). It >can happen that for a particular codec, the callee can send AND receive >it but the caller can just send it. Therefore, the caller does not >include it in the INVITE. However, if the callee lists it in the 200 OK, >the caller will be able to send it. Victor A Paulsamy wrote: > This holds good *only* for sending DTMF tones. Otherwise, this would mean > two media streams encoded *differently* (one in each direction) in a > session. Is my understanding correct? Gonzalo Camarillo wrote: >No. What you want to do can be done using the SDP fid attribute (I will >be releasing the new version of the draft today or tomorrow). Here we >are dealing with plain SDP. Let me give an example. Using codec '0' the caller can only send and the callee can send and receive. The caller sends out codec 3, 4, 5 in the INVITE. The callee responds with 0, 3, 4, 5 in the 200 OK. If the caller choses to send its media stream using codec '0' (since it's included in 200 OK), it has to use *another codec* to receive the media stream as it cannot receive using codec '0'. This would give rise to two codecs, one for transmission and another for reception. This fits the model of transmitting DTMF tones, where PCM codecs will be used to transmit it rather than speech codecs. Warm regards, --victor _______________________________________________ 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_01C0BC29.A1EC1AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SDP: Sub-set or not in the 200 OK?

Victor,

I think there is some confusion here: = selecting different vocoders for each direction is entirely = permissible. However, Gonzalo's point is illustrated in the following = example:

A can receive 0,1,2,3 but can only = send 0. And B can send and receive only 2 & 3. In this case a = bidirectional session is not possible because they is no vocoder that = can be sent from A->B.

Two approaches:

  • Use stardard SDP receive only SDP = vocoder lists and then report incompatibilities in the SIP plane (one = side can always detect this non-bidirectional situation and can = terminate the call if desired - it may be happy to just receive). This = is still more flexible and simpler in my mind.
  • Only place send and receive in the = SDP list which creates big headaches for vocoders which can only be = send or received (eg video or DTMF) (eg requires use of fid draft so = that multiple media announcements can be linked to the same flow id). =

Regards,

Robert.

-----Original = Message-----
From:   Victor A = Paulsamy [mailto:victor@voicecore.com]
Sent:   Monday, April 02, 2001 9:51 PM
To:     Gonzalo Camarillo
Cc:     SIP; Victor A Paulsamy
Subject:       = RE: [SIP] SDP: Sub-set or not in the = 200 OK?


-----Original Message-----
From: = sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bel= l-labs.com]On Behalf Of Gonzalo Camarillo
Sent: Monday, April 02, 2001 1:54 = PM
To: Fairlie-Cuninghame, Robert
Cc: 'Jonathan Rosenberg'; sip; = 'Robert Sparks'; dov; Michael Thomas;
Victor A Paulsamy
Subject: Re: [SIP] SDP: Sub-set or = not in the 200 OK?

Gonzalo Camarillo wrote:

>My proposal is to go for solution = number 2. This gives a symmetrical
>negotiation. Besides, it covers = more cases than solution number 1). It
>can happen that for a particular = codec, the callee can send AND receive
>it but the caller can just send = it. Therefore, the caller does not
>include it in the INVITE. = However, if the callee lists it in the 200 OK,
>the caller will be able to send = it.

Victor A Paulsamy wrote:

> This holds good *only* for = sending DTMF tones. Otherwise, this would mean
> two media streams encoded = *differently* (one in each direction) in a
> session. Is my understanding = correct?

Gonzalo Camarillo wrote:

>No. What you want to do can be = done using the SDP fid attribute (I will
>be releasing the new version of = the draft today or tomorrow). Here we
>are dealing with plain = SDP.


Let me give an example. Using codec = '0' the caller can only send and the
callee can send and receive.

The caller sends out codec 3, 4, 5 in = the INVITE. The callee responds with
0, 3, 4, 5 in the 200 OK.
If the caller choses to send its = media stream using codec '0' (since it's
included in 200 OK), it has to use = *another codec*
to receive the media stream as it = cannot receive using codec '0'. This would
give rise to two codecs, one for = transmission and another for reception.

This fits the model of transmitting = DTMF tones, where PCM codecs will be
used to transmit it rather than = speech codecs.

Warm regards,

--victor





_______________________________________________
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_01C0BC29.A1EC1AA0-- _______________________________________________ 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 Tue Apr 3 09:52:04 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 JAA00815 for ; Tue, 3 Apr 2001 09:52:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8097944345; Tue, 3 Apr 2001 09:52:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 604A44433E for ; Mon, 2 Apr 2001 13:43:44 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA0481013E; Mon, 02 Apr 2001 13:42:28 -0400 Message-ID: <006e01c0bb9c$c7750080$3700000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , "'Baniel Uri-CUB001'" , "'Dean Willis'" , Cc: "Sriram Parameswar" , "'Romeo Zwart'" , "'Stephen Terrill'" , "Igor Slepchin" , "'William Marshall'" , "Chen Bonnie-BCHEN1" , "Xu Lang-LXU1" , "sip" References: Subject: Re: [SIP] Informing UA after network initiated deregistration? 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 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 Apr 2001 13:45:59 -0400 Content-Transfer-Encoding: 7bit I don't think that it is necessary to add more headers. The Event header should be used for implicit subscription just like it is used for explicit subscriptions. Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 (781) 933-6166 bpenfield@acmepacket.com ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Baniel Uri-CUB001'" ; "'Dean Willis'" ; Cc: "'Bob Penfield'" ; "Sriram Parameswar" ; "'Romeo Zwart'" ; "'Stephen Terrill'" ; "Igor Slepchin" ; "'William Marshall'" ; "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" ; "sip" Sent: Monday, April 02, 2001 3:36 AM Subject: RE: [SIP] Informing UA after network initiated deregistration? > > > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Sunday, April 01, 2001 9:34 AM > > To: 'Dean Willis'; bidulock@openss7.org > > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > > 'Romeo Zwart'; > > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > > Bonnie-BCHEN1; Xu Lang-LXU1; sip > > Subject: RE: [SIP] Informing UA after network initiated > > deregistration? > > > > [4]My understanding is that in Minneapolis it has been > > decided/approved to > > Inform a UA after network initiated deregistration. My > > questions to you guys > > are: > > [4.1] Has it been decided to go for implicit subscription for > > notification > > in the Registration request? or to specify it in a dedicated header? > > More headers in registrations. I love it. When are we going to get the "by > the way, I am interested in knowing when I have exactly 15 dollars left in > my account, the one I set up with Mastercard". I propose: > > Mastercard-Balance-Subscription: 15;currency=dollar > > Just in case there are those who like this idea (and since sarcasm by email > is sometimes missed) - no, we are NOT having a new header in registrations. > > Some have debated whether or not the presence spec allows or disallows > "implicit" registrations. This fits into the growing category of things that > "the SIP spec doesn't, nor shouldn't, say". SIP for presence specifies a way > to create subscriptions, and a way to generate notifications for > subscriptions. It does not say that when you build a system, the ONLY way to > get subscriptions in there is to use the SUBSRIBE method. I think a web form > is a perfectly fine way to create subscriptions. We then use our > notification mechanisms to generate notifies for them. How the lifetimes of > these subscriptions are managed is also an implementation issue. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.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. > _______________________________________________ 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 Tue Apr 3 09:53:29 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 JAA00901 for ; Tue, 3 Apr 2001 09:53:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F5BA44368; Tue, 3 Apr 2001 09:52:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.satyam.net.in (unknown [202.144.12.32]) by lists.bell-labs.com (Postfix) with ESMTP id 9D88B44338 for ; Tue, 3 Apr 2001 01:47:24 -0400 (EDT) Received: from HQBNG01EXFE01.mindtree.com (lan-202-144-95-250.maa.sify.net [202.144.95.250] (may be forged)) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id LAA02479; Tue, 3 Apr 2001 11:18:02 +0530 Received: from hqbng01ex01.mindtree.com ([172.20.20.4]) by HQBNG01EXFE01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 3 Apr 2001 11:15:37 +0530 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by hqbng01ex01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 3 Apr 2001 11:15:37 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SIP] A question about Cancel request X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <2330401A6FE03445ADA682F5EBB7502D7AC76F@mtv01ex01.mindtree.com> Thread-Topic: [SIP] A question about Cancel request Thread-Index: AcC7ZG02ThWnrXdYQv6ouwsN3LXQ7wAnIllw From: "Mayank Sharma" To: "Chen, Xin (Xin)" , X-OriginalArrivalTime: 03 Apr 2001 05:45:37.0234 (UTC) FILETIME=[4EF98B20:01C0BC01] 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 Apr 2001 11:15:36 +0530 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00901 > I have a basic question about sip. > Cancel request is used to cancel a pending INVITE. > In sip signalling establishment procedure, if the callee > agent for some > reason fails, it can't receive anything from its proxy, after > the proxy > server of the callee retransmittes 6 times INVITE messges, it > should give up > sending INVITE. My quesiton is whether the Cancel request is > needed to send > out by the proxy server to the callee, if so, it will cause > another 11 times > cancle request beeing sent. The Cancel is required to be sent to the callee. Simple reason being that the proxy does not know weather the callee UA is down or is simply not responding for the time being. Sending Cancel ensures that in case UA is not down this Cancel will cancel the previous Invite, and the UA is not supposed to respond to that Invite at a later stage. Regards, Mayank Sharma Mindtree Consulting Pvt. Ltd. _______________________________________________ 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 Tue Apr 3 09:56:42 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 JAA00999 for ; Tue, 3 Apr 2001 09:56:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D726944373; Tue, 3 Apr 2001 09:52:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id F306644338 for ; Tue, 3 Apr 2001 07:53:33 -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 HAA27379; Tue, 3 Apr 2001 07:53:31 -0400 (EDT) Message-Id: <200104031153.HAA27379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-call-flows-04.txt 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, 03 Apr 2001 07:53:31 -0400 --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 Telephony Call Flow Examples Author(s) : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. Rosenberg, K. Summers, H. Schulzrinne Filename : draft-ietf-sip-call-flows-04.txt Pages : 220 Date : 02-Apr-01 This informational document gives examples of SIP (Session Initiation Protocol) call flows for IP telephony. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers, and Gateways to the PSTN (Public Switch Telephone Network). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-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-call-flows-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-call-flows-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: <20010402124905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-flows-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-flows-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124905.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 Tue Apr 3 10:49:05 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 KAA03058 for ; Tue, 3 Apr 2001 10:49:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8148444338; Tue, 3 Apr 2001 10:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by lists.bell-labs.com (Postfix) with SMTP id 581F644337 for ; Tue, 3 Apr 2001 10:48:20 -0400 (EDT) Message-ID: <20010403144819.87664.qmail@web13905.mail.yahoo.com> Received: from [149.112.117.3] by web13905.mail.yahoo.com; Tue, 03 Apr 2001 07:48:19 PDT From: aravindan shanmugam Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? To: Gonzalo Camarillo , "Fairlie-Cuninghame, Robert" Cc: "'Jonathan Rosenberg'" , sip , "'Robert Sparks'" , dov , Michael Thomas , Victor A Paulsamy In-Reply-To: <3AC8BC9F.978DA15F@lmf.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Apr 2001 07:48:19 -0700 (PDT) --- Gonzalo Camarillo wrote: > Hello, > > I am going to try to answer all the mails of the > thread so far. > > Comments inline: > > "Fairlie-Cuninghame, Robert" wrote: > > > Robert Sparks was saying at the bakeoff that UA's > should put the set > > of vocoders that they can _receive_ in the SDP. > This not only seems to > > be more in line with the SDP model but also cover > a greater number of > > cases (such as playing RFC2833 DTMF but not > detecting it). > > > > Perhaps you would be able to re-iterate what > problems the send and > > receive approach solves that receive only does not > ? > > OK, first of all, we are just dealing with sendrev > streams. This is just > a clarification. > > Following your suggestion, the caller lists the > codecs he can receive in > the INVITE. The callee now does not know if a > bi-directional stream can > be established, because he does not know which > codecs the caller is able > to send. > > Example: both caller and callee can receive codecs 1 > and 2, but not send > them. The INVITE would contain codecs 1 and 2, and > the 200 OK will also > contain both codecs. The INVITE-200 OK-ACK is > successful, but the > session cannot be established. > The callee will check if he can support either codec 1 or 2 before sending 200 OK with his codec. The caller is supposed to check if he can support either of the listed codecs before responding with ACK. So if there is no match in supported codec INVITE-200 OK-ACK should not be successful. > If both systems list the codecs that they can send > AND receive, if the > INVITE-200 OK-ACK is successful (that is, the 200 OK > contains at least > one codec that appeared int he INVITE), both parties > are sure that the > session can take place. > > Aravindan __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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@lists.bell-labs.com Tue Apr 3 10:54:04 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 KAA03253 for ; Tue, 3 Apr 2001 10:54:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BB4DD4435B; Tue, 3 Apr 2001 10:54:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id 2FA3D44338 for ; Tue, 3 Apr 2001 10:53:47 -0400 (EDT) Received: from DDCW6701 [63.113.183.106] by edgeconnect.com with ESMTP (SMTPD32-6.06) id A1484990120; Tue, 03 Apr 2001 07:42:16 -0700 From: "Victor A Paulsamy" To: "Fairlie-Cuninghame, Robert" Cc: "SIP" , "Victor A Paulsamy" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C0BC2C.AE8E5400" 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 In-Reply-To: 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 Apr 2001 10:56:05 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C0BC2C.AE8E5400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [SIP] SDP: Sub-set or not in the 200 OK?Hi Robert, Selecting two different vocoders for each direction is *possible* with the standard proposed by Gonzalo. However I'm not seeing how it's possible with the existing one. Here is an example. A caller sends 3, 4, 5 in the INVITE. Callee will check to see if these formats can be supported. For a session to be set up successfully, the callee should support at least one of these formats. Otherwise, it would report with "client-error: 415 Unsupported Media Type." Selecting two different codecs for each direction will not arise here. BTW, why would any one designate a codec as receive only and send only? It's supposed to be used for both. Warm regards, --victor -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Tuesday, April 03, 2001 6:34 AM To: 'Victor A Paulsamy'; Gonzalo Camarillo Cc: SIP Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Victor, I think there is some confusion here: selecting different vocoders for each direction is entirely permissible. However, Gonzalo's point is illustrated in the following example: A can receive 0,1,2,3 but can only send 0. And B can send and receive only 2 & 3. In this case a bidirectional session is not possible because they is no vocoder that can be sent from A->B. Two approaches: a.. Use stardard SDP receive only SDP vocoder lists and then report incompatibilities in the SIP plane (one side can always detect this non-bidirectional situation and can terminate the call if desired - it may be happy to just receive). This is still more flexible and simpler in my mind. b.. Only place send and receive in the SDP list which creates big headaches for vocoders which can only be send or received (eg video or DTMF) (eg requires use of fid draft so that multiple media announcements can be linked to the same flow id). Regards, Robert. -----Original Message----- From: Victor A Paulsamy [mailto:victor@voicecore.com] Sent: Monday, April 02, 2001 9:51 PM To: Gonzalo Camarillo Cc: SIP; Victor A Paulsamy Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo Camarillo Sent: Monday, April 02, 2001 1:54 PM To: Fairlie-Cuninghame, Robert Cc: 'Jonathan Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas; Victor A Paulsamy Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? Gonzalo Camarillo wrote: >My proposal is to go for solution number 2. This gives a symmetrical >negotiation. Besides, it covers more cases than solution number 1). It >can happen that for a particular codec, the callee can send AND receive >it but the caller can just send it. Therefore, the caller does not >include it in the INVITE. However, if the callee lists it in the 200 OK, >the caller will be able to send it. Victor A Paulsamy wrote: > This holds good *only* for sending DTMF tones. Otherwise, this would mean > two media streams encoded *differently* (one in each direction) in a > session. Is my understanding correct? Gonzalo Camarillo wrote: >No. What you want to do can be done using the SDP fid attribute (I will >be releasing the new version of the draft today or tomorrow). Here we >are dealing with plain SDP. Let me give an example. Using codec '0' the caller can only send and the callee can send and receive. The caller sends out codec 3, 4, 5 in the INVITE. The callee responds with 0, 3, 4, 5 in the 200 OK. If the caller choses to send its media stream using codec '0' (since it's included in 200 OK), it has to use *another codec* to receive the media stream as it cannot receive using codec '0'. This would give rise to two codecs, one for transmission and another for reception. This fits the model of transmitting DTMF tones, where PCM codecs will be used to transmit it rather than speech codecs. Warm regards, --victor _______________________________________________ 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_000_000A_01C0BC2C.AE8E5400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SDP: Sub-set or not in the 200 OK?
Hi=20 Robert,
 
Selecting two different vocoders for each = direction=20 is *possible* with the standard proposed by Gonzalo. However I'm = not=20 seeing how it's possible with the existing=20 one.
 
Here is an example. A=20 caller sends 3,=20 4, 5 in the INVITE. Callee will check to see if these = formats=20 can be supported. For a session to be set up successfully, the callee = should=20 support at least one of these formats. Otherwise, it would report with = "client-error: 415 Unsupported Media Type." Selecting two different = codecs for=20 each direction will not arise = here.
 
BTW, why would any one designate a codec as = receive=20 only and send only? It's supposed to be used for=20 both.
 
Warm=20 regards,
 
--victor
 
 
 
 -----Original=20 Message-----
From: Fairlie-Cuninghame, Robert=20 [mailto:rfairlie@nuera.com]
Sent: Tuesday, April 03, 2001 = 6:34=20 AM
To: 'Victor A Paulsamy'; Gonzalo Camarillo
Cc:=20 SIP
Subject: RE: [SIP] SDP: Sub-set or not in the 200=20 OK?

Victor,

I think there is some confusion here: = selecting=20 different vocoders for each direction is entirely permissible. = However,=20 Gonzalo's point is illustrated in the following example:

A can receive 0,1,2,3 but can only send = 0. And B=20 can send and receive only 2 & 3. In this case a bidirectional = session is=20 not possible because they is no vocoder that can be sent from=20 A->B.

Two approaches:=20

  • Use stardard SDP receive only SDP = vocoder lists=20 and then report incompatibilities in the SIP plane (one side can = always=20 detect this non-bidirectional situation and can terminate the call = if=20 desired - it may be happy to just receive). This is still more = flexible and=20 simpler in my mind.=20
  • Only place send and receive in the = SDP list=20 which creates big headaches for vocoders which can only be send or = received=20 (eg video or DTMF) (eg requires use of fid draft so that multiple = media=20 announcements can be linked to the same flow id). =

Regards,

Robert.

-----Original=20 Message-----
From:  =20 Victor A Paulsamy [mailto:victor@voicecore.com]=20
Sent:   Monday, April 02, 2001 9:51 PM
To:     Gonzalo=20 Camarillo
Cc:     SIP;=20 Victor A Paulsamy
Subject:        = RE: [SIP] SDP: Sub-set or not in the 200 = OK?


-----Original Message----- =
From: sip-admin@lists.bell-labs.com =
[mailto:sip-admin@lists.bell= -labs.com]On=20 Behalf Of Gonzalo Camarillo
Sent: Monday,=20 April 02, 2001 1:54 PM
To:=20 Fairlie-Cuninghame, Robert
Cc: = 'Jonathan=20 Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas; =
Victor A Paulsamy
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? =

Gonzalo Camarillo wrote:

>My proposal is to go for solution = number 2.=20 This gives a symmetrical
>negotiation.=20 Besides, it covers more cases than solution number 1). It =
>can happen that for a particular codec, the = callee can=20 send AND receive
>it but the = caller can=20 just send it. Therefore, the caller does not
>include it in the INVITE. However, if the callee lists it = in the=20 200 OK,
>the caller will be = able to send=20 it.

Victor A Paulsamy wrote:

> This holds good *only* for sending = DTMF tones.=20 Otherwise, this would mean
> = two media=20 streams encoded *differently* (one in each direction) in a =
> session. Is my understanding = correct?

Gonzalo Camarillo wrote:

>No. What you want to do can be done = using the=20 SDP fid attribute (I will
>be releasing=20 the new version of the draft today or tomorrow). Here we =
>are dealing with plain SDP.


Let me give an example. Using codec '0' = the caller=20 can only send and the
callee = can send and=20 receive.

The caller sends out codec 3, 4, 5 in = the INVITE.=20 The callee responds with
0, 3, = 4, 5 in the=20 200 OK.
If the caller choses to = send its=20 media stream using codec '0' (since it's
included in 200 OK), it has to use *another codec* =
to receive the media stream as it cannot receive = using codec=20 '0'. This would
give rise to = two codecs,=20 one for transmission and another for reception.

This fits the model of transmitting = DTMF tones,=20 where PCM codecs will be
used = to transmit=20 it rather than speech codecs.

Warm regards,

--victor





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

------=_NextPart_000_000A_01C0BC2C.AE8E5400-- _______________________________________________ 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 Tue Apr 3 11:47:04 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 LAA04958 for ; Tue, 3 Apr 2001 11:47:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95B1C44338; Tue, 3 Apr 2001 11:47:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lists.bell-labs.com (Postfix) with ESMTP id 59B4044337 for ; Tue, 3 Apr 2001 11:46:19 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 3 Apr 2001 08:47:05 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Apr 2001 07:47:21 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 3 Apr 2001 08:47:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: Thread-Topic: [SIP] SDP: Sub-set or not in the 200 OK? Thread-Index: AcC7nmo1AVEZ+YWARmS3ctBRkYFgUgAsoV2g From: "Christian Huitema" To: "Michael Thomas" , "Fairlie-Cuninghame, Robert" Cc: "Jonathan Rosenberg" , "Gonzalo Camarillo" , "sip" , "Robert Sparks" X-OriginalArrivalTime: 03 Apr 2001 15:47:21.0101 (UTC) FILETIME=[5E8E73D0:01C0BC55] 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 Apr 2001 08:47:20 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04958 Michael, There are several issues with SDP, and with the way it is used in SIP. Most of these issues have their root in the first usage of SDP: document the encoding of multicast sessions, for which negotiation does not make any sense. In the multicast case, the SDP describes the encodings used by the source, and the receiver is indeed supposed to "load its purple elephant receiver" -- or decline to attend the multicast conference. In the dominant view of the early 90's, "unicast was a special case of multicast." Well, it is not. In the unicast case, or even with the small group case, in which we expect senders and receivers to somehow negotiate a set of appropriate codecs -- codecs that are available at all ends of the connection, and that are compatible with the path's bandwidth, delay, and loss rate. In fact, we may want to allow several codecs in a single session, so that senders and receivers freely alternate between them if the link conditions vary. To make matter a bit more complex, we have overloaded our concept of codec to also allocate payload types to things like FEC. There are two basic ways to solve this problem. One is to adopt a convention on how we use SDP today, and another is to design an alternative encoding that enables negotiation. Since the latter is not in the SIP WG charter, we have to concentrate on the former, and we have to make simplifying assumption. In fact, we probably want to make one simplifying assumption: codec symmetry, the fact that announcing support for a specific payload type implies both a capability to send and a capability to receive. This assumption is well grounded in reality; the main limiting factor in codec availability tends to be the IPR strings attached to some algorithms, which does not differentiate between send and receive. If we assume symmetry, then we don't have to decide whether announcing several payload types for a media means send or receive: it means both. As a consequence, we get the negotiation capability: one party proposes a list of payload types; the responding party selects a subset of that list; both party use this subset; the sending of the ACK is a confirmation that the subset has been accepted. If the link conditions change, and the initial selection appears inadequate, we can always issue a re-invite and negotiate another subset. The last practical question is the number of payload types allowed in the resulting selections. Do we have to commit to exactly one, one plus FEC, or many simultaneous? This is not an issue for the responder, who can pick a subset of one in the proposed set, but it is an issue for the sender, who may have the contradictory goals of proposing several choices and using only one alternative. The classic way to solve this in SDP is to define an SDP attribute, such as: a:pick-only-one-payload-type-please I believe that the solutions that I outlined, to assume symmetry and perhaps to define an attribute that guides the negotiation, are well in the domain of "implementation agreements" and could be tested during a next bay-cough(tm). -- Christian Huitema > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, April 02, 2001 8:04 AM > To: Fairlie-Cuninghame, Robert > Cc: 'Jonathan Rosenberg'; 'Gonzalo Camarillo'; sip; 'Robert Sparks' > Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? > > > That's in line with the way I understand things. > I really don't know what send has to do with > anything. I can claim I'm going to send purple > elephants but when push comes to shove, the purple > elephants never seem to make it onto the wire. > The obnoxious thing for the receiver is that it > may have had to load its purple elephant receiver. > Unless the receiver can say that it doesn't want > to receive purple elephants, you're going to end > up with a situation where you can't communicate > at all, and that doesn't sound like it's headed > in the right direction. > > I believe that Gonzalo's proposal still misses one > property which I have always thought is at the > root of all of this: it doesn't allow us to > propose several alternatives, but the the receiver > picks one (or a subset) which is what is actually > loaded into both the sender's and receiver's DSP. > This obviously requires a three way handshake if > you want the "this is what I can receive" model > Robert is speaking of here. > > Maybe SIP too should look at Christian's proposal > for multiple SDP's (in MEGACO) when this is the > desired behavior. > > Mike > > Fairlie-Cuninghame, Robert writes: > > Hi, > > > > Robert Sparks was saying at the bakeoff that UA's should put the set of > > vocoders that they can _receive_ in the SDP. This not only seems to be > more > > in line with the SDP model but also cover a greater number of cases > (such as > > playing RFC2833 DTMF but not detecting it). > > > > Perhaps you would be able to re-iterate what problems the send and > receive > > approach solves that receive only does not ? > > > > Cheers, > > > > Robert. > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, April 02, 2001 9:25 AM > > To: 'Gonzalo Camarillo'; sip > > Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? > > > > > > > > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Saturday, March 31, 2001 10:18 PM > > > To: sip > > > Subject: [SIP] SDP: Sub-set or not in the 200 OK? > > > > > > > > > Hello, > > > > > > There have been already several mails showing certain confusion about > > > SDP usage in SIP. > > > In the last IETF the conclusion was: > > > For sendrecv flows (uni-directional flows are easy), the > > > caller puts in > > > the INVITe the codecs that he can both send AND receive. > > > > > > The open issue is what the callee returns: > > > 1) a sub-set of the codecs listed in the INVITE that he can send AND > > > receive. > > > 2) all the codecs that he can send AND receive. > > > > > > Note that caller and callee have reversed roles if the SDP from the > > > client to the server is sent in the ACK instead of in the INVITE. > > > > > > I would like to ask folks not to mix this open issue with another > > > similar issue: I have a DSP that cannot change codecs > > > on-the-fly, and I > > > want to pick up just one codec. Let us discuss this issue at > > > other time. > > > > > > My proposal is to go for solution number 2. This gives a symmetrical > > > negotiation. Besides, it covers more cases than solution number 1). > It > > > can happen that for a particular codec, the callee can send > > > AND receive > > > it but the caller can just send it. Therefore, the caller does not > > > include it in the INVITE. However, if the callee lists it in > > > the 200 OK, > > > the caller will be able to send it. > > > > > > Opinions? > > > > I like it. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.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. > > > > > > > > > > > > RE: [SIP] SDP: Sub-set or not in the 200 OK? > > > > > > > >

Hi, > >

> > > >

Robert Sparks was saying at the bakeoff > that UA's should put the set of vocoders that they can _ SIZE=2 FACE="Arial">receive_ in the > SDP. This not only seems to be more in line with the SDP model but also > cover a greater number of cases (such as playing RFC2833 DTMF but not > detecting it).

> > > >

Perhaps you would be able to re-iterate > what problems the send and receive approach solves that receive only does > not ? > >

> > > >

Cheers, > >

> > > >

Robert. > >

> > > >

-----Original Message- > ---- > >
From:   Jonathan Rosenberg > [ HREF="mailto:jdrosen@dynamicsoft.com">mailto:jdrosen@dynamicsoft.com ]< > /FONT> > >
Sent:   SIZE=2 FACE="Arial">Monday, April 02, 2001 9:25 AM > >
To:     > 'Gonzalo Camarillo'; sip > >
FACE="Arial">Subject:        > RE: [SIP] SDP: Sub-set or not in the 200 > OK? > >

> >
> >
> > > >

  > >

> > > >

> -----Original Message----- > >
> From: Gonzalo Camarillo [ HREF="mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camarillo @l > mf.ericsson.se] > >
> Sent: Saturday, March 31, 2001 10:18 > PM > >
> To: sip > >
> Subject: [SIP] SDP: Sub-set or not > in the 200 OK? > >
> > >
> > >
> Hello, > >
> > >
> There have been already several > mails showing certain confusion about > >
> SDP usage in SIP. > >
> In the last IETF the conclusion > was: > >
> For sendrecv flows (uni-directional > flows are easy), the > >
> caller puts in > >
> the INVITe the codecs that he can > both send AND receive. > >
> > >
> The open issue is what the callee > returns: > >
> 1) a sub-set of the codecs listed in > the INVITE that he can send AND > >
> receive. > >
> 2) all the codecs that he can send > AND receive. > >
> > >
> Note that caller and callee have > reversed roles if the SDP from the > >
> client to the server is sent in the > ACK instead of in the INVITE. > >
> > >
> I would like to ask folks not to mix > this open issue with another > >
> similar issue: I have a DSP that > cannot change codecs > >
> on-the-fly, and I > >
> want to pick up just one codec. Let > us discuss this issue at > >
> other time. > >
> > >
> My proposal is to go for solution > number 2. This gives a symmetrical > >
> negotiation. Besides, it covers more > cases than solution number 1). It > >
> can happen that for a particular > codec, the callee can send > >
> AND receive > >
> it but the caller can just send it. > Therefore, the caller does not > >
> include it in the INVITE. However, > if the callee lists it in > >
> the 200 OK, > >
> the caller will be able to send > it. > >
> > >
> Opinions? > >

> > > >

I like it. > >

> > > >

-Jonathan R. > >

> > > >

--- > >
Jonathan D. > Rosenberg          &nb sp > ;            72 > Eagle Rock Ave. > >
Chief > Scientist          &nb sp > ;             ;& > nbsp;     First Floor > >
FACE="Arial">dynamicsoft         &n > bsp;           &n bs > p;            East > Hanover, NJ 07936 > >
FACE="Arial">jdrosen@dynamicsoft.com       &n > bsp;           &n bs > p;  FAX:   (973) 952-5050 > >
HREF="http://www.cs.columbia.edu/~jdrosen" > TARGET="_blank">http://www.cs.columbia.edu/~jdrosen    ;& > nbsp;     PHONE: (973) 952-5000 > >
TARGET="_blank">http://www.dynamicsoft.com > >

> >
> > > >

FACE="Arial">_______________________________________________ > >
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@lists.bell-labs.com Tue Apr 3 12:58:05 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 MAA08006 for ; Tue, 3 Apr 2001 12:58:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A3B244338; Tue, 3 Apr 2001 12:58:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from baqaqi.chi.il.us (rm05-24-167-185-206.ce.mediaone.net [24.167.185.206]) by lists.bell-labs.com (Postfix) with ESMTP id 26EC544337 for ; Tue, 3 Apr 2001 12:49:16 -0400 (EDT) Received: from baqaqi.chi.il.us (piggy@localhost) by baqaqi.chi.il.us (8.11.0/8.11.0) with ESMTP id f33Gn6S03606; Tue, 3 Apr 2001 11:49:10 -0500 Message-Id: <200104031649.f33Gn6S03606@baqaqi.chi.il.us> To: "Fairlie-Cuninghame, Robert" Cc: "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" From: "La Monte Henry Piggy Yarroll" Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP In-reply-to: Your message of Mon, 02 Apr 2001 03:00:11 -0700. 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, 03 Apr 2001 11:49:05 -0500 The purpose of streams in SCTP is to avoid head-of-line blocking. A single streams should ONLY be used for messages which have a strict ordering requirement. Standalone messages should travel via an unordered stream. The UA's DO allow multiple independant complex exchanges over separate streams. In many situations (e.g. telephony switching) it is important to share congestion and flow-control information. If you DIDN'T use streams over a single SCTP association, you'd have to pay the slow-start penalty for every new exchange. "Fairlie-Cuninghame, Robert" writes: > Hi Matt, > > I'm not convinced that SIP needs to use ordered delivery of messages across > multiple streams. If we are not using stream specification within SIP (and I > think I agree with you now Jonathan) then I believe SIP should be using a > single unordered reliable stream rather than any/all the streams. > > - This is simpler and as has been said before, a more complicated SIP > adaptation layer may cause more complexity in transport-ignorant systems > (whatever that might be ). This is also closer to the model used by > the existing SIGTRAN adaptation layers (ie, one link => one stream). > - The process of enforcing that an application must accept packets on > all streams may force implementations on the API and design of the SCTP > stack. The stack uses the concept of "used" and "unused" streams - what > effect does using 64K streams on an association have on memory requirements. > This may not be a relevant concern but I think SIP should try to be more > conservative in its use of SCTP. > - The sending of different call legs to different streams does not > help much in my opinion. A single stream must still be able to accept > packets for multiple call legs. > - Using arbitrary streams does not allow the use of other streams for > any future purpose. > > I'm also not convinced that the bundling of SIP messages is that useful - > SIP messages are usually quite large anyway. However, an interesting > application for SCTP with SIP might be on low bandwidth point to point > connections. The SIP application controls the association and so it is not > too unreasonable that the SIP application may negotiate the use of other > streams in the same association for media use. Now the fragmentation > properties of SCTP could reduce any delay/jitter in the media carried on the > same SCTP association. This is not possible if SIP and media are carried in > separate streams. [This is probably not a main-stream application and maybe > not even useful/desirable but I don't think it should be impossible.] > > Jonathan, I see you think that SCTP is not worth the trouble for SIP. I > think that SCTP becomes more attractive to SIP when the media also uses SCTP > such that SCTP becomes the only transport protocol needed (although not > necessarily on the same association). SCTP has the interesting property that > it makes the normally connectionless unreliable UDP media become > connection-oriented unreliable U-SCTP media. I can even foresee that in the > future, SCTP associations could be linked to hardware routing and resource > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any > work in this field although the stream-based flow-limiting extension is > useful - sounds like a good thesis/paper to me.] Anyway, the only piece > missing is an SDP profile for SCTP (which I'm still in the process of > proposing something - input welcome). > > Comments please. > > Cheers, > > Robert. > > -- My opinions should not be taken as necessarily representing those of > Nuera Communications, Inc. -- > > -----Original Message----- > From: Matt Holdrege [mailto:matt@ipverse.com] > Sent: Wednesday, March 28, 2001 3:39 AM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] RE: SCTP as transport for SIP > > (from the SCTP AS) > > For SIP, considering the use of a reliable transport protocol (i.e. not > UDP) the features of SCTP would be: > > - acknowledged error-free non-duplicated transfer of user data, > > - data fragmentation to conform to discovered path MTU size, > > - sequenced delivery of user messages within multiple streams, > with an option for order-of-arrival delivery of individual user > messages, > > - optional bundling of multiple user messages into a single SCTP packet, > > - network-level fault tolerance through supporting of multi-homing at > either or both ends of an association. > > Applications that require framing of reliable data streams can get that > feature from SCTP. > > Applications which transfer independent message sequences that are > unrelated (sometimes called transactions) can benefit from the partial > ordering provided by SCTP streams. > > Applications that wish to transfer messages that hold no particular > sequence or relationship to one another can benefit from the unordered > service provided by SCTP. > > Finally for those applications seeking network layer redundancy with > multiple Network Interface cards can use SCTP's multi-homing feature. > > Is there any misunderstanding or disagreement with the above? > > > _______________________________________________ > 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_01C0BB5B.B4B51C00 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Diso-8859-1"> > 5.5.2653.12"> > RE: [SIP] RE: SCTP as transport for SIP > > > >

Hi Matt, >

> >

Hi Matt, >

> >

I'm not convinced that SIP needs to = > use ordered delivery of messages across multiple streams. If we are not = > using stream specification within SIP (and I think I agree with you now = > Jonathan) then I believe SIP should be using a single unordered = > reliable stream rather than any/all the streams.

> >
  • This is simpler and as has been = > said before, a more complicated SIP adaptation layer may cause more = > complexity in transport-ignorant systems (whatever that might be = > <grin>). This is also closer to the model used by the existing = > SIGTRAN adaptation layers (ie, one link =3D> one = > stream).
    • >
  • The process of enforcing that an = > application must accept packets on all streams may force = > implementations on the API and design of the SCTP stack. The stack uses = > the concept of "used" and "unused" streams - what effect does using 64K = > streams on an association have on memory requirements. This may not be = > a relevant concern but I think SIP should try to be more conservative = > in its use of SCTP.
    • >
  • The sending of  different call = > legs to different streams does not help much in my opinion. A single = > stream must still be able to accept packets for multiple call = > legs.
    • >
  • Using arbitrary streams does not = > allow the use of other streams for any future purpose.
    • >
    >
>

I'm also not convinced that the = > bundling of SIP messages is that useful - SIP messages are usually = > quite large anyway. However, an interesting application for SCTP with = > SIP might be on low bandwidth point to point connections. The SIP = > application controls the association and so it is not too unreasonable = > that the SIP application may negotiate the use of other streams in the = > same association for media use. Now the fragmentation properties of = > SCTP could reduce any delay/jitter in the media carried on the same = > SCTP association. This is not possible if SIP and media are carried in = > separate streams. [This is probably not a main-stream application and = > maybe not even useful/desirable but I don't think it should be = > impossible.]

> >

Jonathan, I see you think that SCTP is = > not worth the trouble for SIP. I think that SCTP becomes more = > attractive to SIP when the media also uses SCTP such that SCTP becomes = > the only transport protocol needed (although not necessarily on the = > same association). SCTP has the interesting property that it makes the = > normally connectionless unreliable UDP media become connection-oriented = > unreliable U-SCTP media. I can even foresee that in the future, SCTP = > associations could be linked to hardware routing and resource = > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of = > any work in this field although the stream-based flow-limiting = > extension is useful - sounds like a good thesis/paper to me.] Anyway, = > the only piece missing is an SDP profile for SCTP (which I'm still in = > the process of proposing something - input welcome).

> >

Comments please. >

> >

Cheers, >

> >

Robert. >

> >

-- My opinions should not be taken as = > necessarily representing those of Nuera Communications, Inc. -- >

> >

-----Original = > Message----- >
From:   Matt Holdrege = > [ HREF=3D"mailto:matt@ipverse.com">mailto:matt@ipverse.com]= > >
Sent:   SIZE=3D2 FACE=3D"Arial">Wednesday, March 28, 2001 3:39 AM >
FACE=3D"Arial">To:     FACE=3D"Arial">sip@lists.bell-labs.com >
FACE=3D"Arial">Subject:       = > Re: [SIP] RE: SCTP as transport for = > SIP >

> >

(from the SCTP AS) >

> >

For SIP, considering the use of a = > reliable transport protocol (i.e. not >
UDP) the features of SCTP would = > be: >

> >

- acknowledged error-free = > non-duplicated transfer of user data, >

> >

- data fragmentation to conform to = > discovered path MTU size, >

> >

- sequenced delivery of user messages = > within multiple streams, >
   with an option for = > order-of-arrival delivery of individual user >
   messages, >

> >

- optional bundling of multiple user = > messages into a single SCTP packet, >

> >

- network-level fault tolerance = > through supporting of multi-homing at >
either or both ends of an = > association. >

> >

Applications that require framing of = > reliable data streams can get that >
feature from SCTP. >

> >

Applications which transfer = > independent message sequences that are >
unrelated (sometimes called = > transactions) can benefit from the partial >
ordering provided by SCTP = > streams. >

> >

Applications that wish to transfer = > messages that hold no particular >
sequence or relationship to one = > another can benefit from the unordered >
service provided by SCTP. >

> >

Finally for those applications seeking = > network layer redundancy with >
multiple Network Interface cards can = > use SCTP's multi-homing feature. >

> >

Is there any misunderstanding or = > disagreement with the above? >

>
> >

FACE=3D"Arial">_______________________________________________ >
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 = > >
FACE=3D"Arial">sip-implementors-request@cs.columbia.edu with = > "subscribe" in the body. >

> > > > ------_=_NextPart_001_01C0BB5B.B4B51C00-- > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ 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 Tue Apr 3 14:36:05 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 OAA12382 for ; Tue, 3 Apr 2001 14:36:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31C1A44338; Tue, 3 Apr 2001 14:36:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id 3B14344337 for ; Tue, 3 Apr 2001 14:35:32 -0400 (EDT) Received: from DDCW6701 [63.113.183.106] by edgeconnect.com with ESMTP (SMTPD32-6.06) id A54418DA00C0; Tue, 03 Apr 2001 11:24:04 -0700 From: "Victor A Paulsamy" To: "Gonzalo Camarillo" Cc: "SIP" , "Victor A Paulsamy" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3AC69DDE.7A1EDC38@lmf.ericsson.se> 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 Apr 2001 14:37:53 -0400 Content-Transfer-Encoding: 7bit Hi, Gonzalo Camarillo wrote: >In the last IETF the conclusion was: >For sendrecv flows (uni-directional flows are easy), the caller puts in >the INVITe the codecs that he can both send AND receive. >The open issue is what the callee returns: >1) a sub-set of the codecs listed in the INVITE that he can send AND >receive. >2) all the codecs that he can send AND receive. In first place, it's not clear to me why a callee should put down *entire* list of codecs that can send and receive while responding to an INVITE? Just pick the first (*one*) codec if it could be supported, second if the first cannot be supported and so on from the (entire) list given by the caller (and return it in a 200 OK). In this case it would signal end of media format (codec) negotiation. Secondly, codecs are to be used for both transmission and reception. Why should a codec be designated as send only or receive only? Warm regards, --victor _______________________________________________ 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 Tue Apr 3 15:04:04 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 PAA13480 for ; Tue, 3 Apr 2001 15:04:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B3A74436E; Tue, 3 Apr 2001 15:04:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 5548E4436B for ; Tue, 3 Apr 2001 15:03:41 -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 f33J3es20364; Tue, 3 Apr 2001 21:03:40 +0200 (MEST) Received: from lmf.ericsson.se (EWUwsp001692wss.sd.us.am.ericsson.se [142.133.141.108]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA24104; Tue, 3 Apr 2001 21:03:36 +0200 (MET DST) Message-ID: <3ACA1DF3.AA201298@lmf.ericsson.se> 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: Victor A Paulsamy Cc: SIP Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? 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: Tue, 03 Apr 2001 22:01:07 +0300 Content-Transfer-Encoding: 7bit Hello, Victor A Paulsamy wrote: > > Hi, > > Gonzalo Camarillo wrote: > > >In the last IETF the conclusion was: > >For sendrecv flows (uni-directional flows are easy), the caller puts in > >the INVITe the codecs that he can both send AND receive. > > >The open issue is what the callee returns: > >1) a sub-set of the codecs listed in the INVITE that he can send AND > >receive. > >2) all the codecs that he can send AND receive. > > In first place, it's not clear to me why a callee should put down *entire* > list of codecs that can send and receive while responding to an INVITE? Just > pick the first (*one*) codec if it could be supported, second if the first > cannot be supported and so on from the (entire) list given by the caller > (and return it in a 200 OK). In this case it would signal end of media > format (codec) negotiation. > It is called change of codec on-the-fly, and you have the RTP payload for that. I insist once more (and it is the 3rd time that I do it in this thread) that we do not want to mix the issue we are discussing with the issue of picking up one single codec. > Secondly, codecs are to be used for both transmission and reception. Why > should a codec be designated as send only or receive only? To do this you have to use fid. With plain SDP you cannot mark a codec as reconly in a sendrecv stream. Gonzalo > > Warm regards, > > --victor -- 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 _______________________________________________ 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 Tue Apr 3 15:22:05 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 PAA14092 for ; Tue, 3 Apr 2001 15:22:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C603844338; Tue, 3 Apr 2001 15:22:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id D20C444337 for ; Tue, 3 Apr 2001 15:21:59 -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 f33JLmI17558; Tue, 3 Apr 2001 21:21:49 +0200 (MEST) Received: from lmf.ericsson.se (EWUwsp001692wss.sd.us.am.ericsson.se [142.133.141.108]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA25416; Tue, 3 Apr 2001 21:21:41 +0200 (MET DST) Message-ID: <3ACA222F.C128BB41@lmf.ericsson.se> 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: La Monte Henry Piggy Yarroll Cc: "Fairlie-Cuninghame, Robert" , "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP References: <200104031649.f33Gn6S03606@baqaqi.chi.il.us> 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: Tue, 03 Apr 2001 22:19:11 +0300 Content-Transfer-Encoding: 7bit Hello, You can check the following link out: http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf It compares advantages and disadvantages of using a single unordered stream over using multiple ordered streams to transport SIP. Best regards, Gonzalo La Monte Henry Piggy Yarroll wrote: > > The purpose of streams in SCTP is to avoid head-of-line blocking. A > single streams should ONLY be used for messages which have a strict > ordering requirement. Standalone messages should travel via an > unordered stream. > > The UA's DO allow multiple independant complex exchanges over separate > streams. In many situations (e.g. telephony switching) it is > important to share congestion and flow-control information. If you > DIDN'T use streams over a single SCTP association, you'd have to pay > the slow-start penalty for every new exchange. > > "Fairlie-Cuninghame, Robert" writes: > > Hi Matt, > > > > I'm not convinced that SIP needs to use ordered delivery of messages across > > multiple streams. If we are not using stream specification within SIP (and I > > think I agree with you now Jonathan) then I believe SIP should be using a > > single unordered reliable stream rather than any/all the streams. > > > > - This is simpler and as has been said before, a more complicated SIP > > adaptation layer may cause more complexity in transport-ignorant systems > > (whatever that might be ). This is also closer to the model used by > > the existing SIGTRAN adaptation layers (ie, one link => one stream). > > - The process of enforcing that an application must accept packets on > > all streams may force implementations on the API and design of the SCTP > > stack. The stack uses the concept of "used" and "unused" streams - what > > effect does using 64K streams on an association have on memory requirements. > > This may not be a relevant concern but I think SIP should try to be more > > conservative in its use of SCTP. > > - The sending of different call legs to different streams does not > > help much in my opinion. A single stream must still be able to accept > > packets for multiple call legs. > > - Using arbitrary streams does not allow the use of other streams for > > any future purpose. > > > > I'm also not convinced that the bundling of SIP messages is that useful - > > SIP messages are usually quite large anyway. However, an interesting > > application for SCTP with SIP might be on low bandwidth point to point > > connections. The SIP application controls the association and so it is not > > too unreasonable that the SIP application may negotiate the use of other > > streams in the same association for media use. Now the fragmentation > > properties of SCTP could reduce any delay/jitter in the media carried on the > > same SCTP association. This is not possible if SIP and media are carried in > > separate streams. [This is probably not a main-stream application and maybe > > not even useful/desirable but I don't think it should be impossible.] > > > > Jonathan, I see you think that SCTP is not worth the trouble for SIP. I > > think that SCTP becomes more attractive to SIP when the media also uses SCTP > > such that SCTP becomes the only transport protocol needed (although not > > necessarily on the same association). SCTP has the interesting property that > > it makes the normally connectionless unreliable UDP media become > > connection-oriented unreliable U-SCTP media. I can even foresee that in the > > future, SCTP associations could be linked to hardware routing and resource > > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any > > work in this field although the stream-based flow-limiting extension is > > useful - sounds like a good thesis/paper to me.] Anyway, the only piece > > missing is an SDP profile for SCTP (which I'm still in the process of > > proposing something - input welcome). > > > > Comments please. > > > > Cheers, > > > > Robert. > > > > -- My opinions should not be taken as necessarily representing those of > > Nuera Communications, Inc. -- > > > > -----Original Message----- > > From: Matt Holdrege [mailto:matt@ipverse.com] > > Sent: Wednesday, March 28, 2001 3:39 AM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] RE: SCTP as transport for SIP > > > > (from the SCTP AS) > > > > For SIP, considering the use of a reliable transport protocol (i.e. not > > UDP) the features of SCTP would be: > > > > - acknowledged error-free non-duplicated transfer of user data, > > > > - data fragmentation to conform to discovered path MTU size, > > > > - sequenced delivery of user messages within multiple streams, > > with an option for order-of-arrival delivery of individual user > > messages, > > > > - optional bundling of multiple user messages into a single SCTP packet, > > > > - network-level fault tolerance through supporting of multi-homing at > > either or both ends of an association. > > > > Applications that require framing of reliable data streams can get that > > feature from SCTP. > > > > Applications which transfer independent message sequences that are > > unrelated (sometimes called transactions) can benefit from the partial > > ordering provided by SCTP streams. > > > > Applications that wish to transfer messages that hold no particular > > sequence or relationship to one another can benefit from the unordered > > service provided by SCTP. > > > > Finally for those applications seeking network layer redundancy with > > multiple Network Interface cards can use SCTP's multi-homing feature. > > > > Is there any misunderstanding or disagreement with the above? > > > > > > _______________________________________________ > > 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_01C0BB5B.B4B51C00 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > charset=3Diso-8859-1"> > > > 5.5.2653.12"> > > RE: [SIP] RE: SCTP as transport for SIP > > > > > > > >

Hi Matt, > >

> > > >

Hi Matt, > >

> > > >

I'm not convinced that SIP needs to = > > use ordered delivery of messages across multiple streams. If we are not = > > using stream specification within SIP (and I think I agree with you now = > > Jonathan) then I believe SIP should be using a single unordered = > > reliable stream rather than any/all the streams.

> > > >
  • This is simpler and as has been = > > said before, a more complicated SIP adaptation layer may cause more = > > complexity in transport-ignorant systems (whatever that might be = > > <grin>). This is also closer to the model used by the existing = > > SIGTRAN adaptation layers (ie, one link =3D> one = > > stream).
    • > >
  • The process of enforcing that an = > > application must accept packets on all streams may force = > > implementations on the API and design of the SCTP stack. The stack uses = > > the concept of "used" and "unused" streams - what effect does using 64K = > > streams on an association have on memory requirements. This may not be = > > a relevant concern but I think SIP should try to be more conservative = > > in its use of SCTP.
    • > >
  • The sending of  different call = > > legs to different streams does not help much in my opinion. A single = > > stream must still be able to accept packets for multiple call = > > legs.
    • > >
  • Using arbitrary streams does not = > > allow the use of other streams for any future purpose.
    • > >
    > >
> >

I'm also not convinced that the = > > bundling of SIP messages is that useful - SIP messages are usually = > > quite large anyway. However, an interesting application for SCTP with = > > SIP might be on low bandwidth point to point connections. The SIP = > > application controls the association and so it is not too unreasonable = > > that the SIP application may negotiate the use of other streams in the = > > same association for media use. Now the fragmentation properties of = > > SCTP could reduce any delay/jitter in the media carried on the same = > > SCTP association. This is not possible if SIP and media are carried in = > > separate streams. [This is probably not a main-stream application and = > > maybe not even useful/desirable but I don't think it should be = > > impossible.]

> > > >

Jonathan, I see you think that SCTP is = > > not worth the trouble for SIP. I think that SCTP becomes more = > > attractive to SIP when the media also uses SCTP such that SCTP becomes = > > the only transport protocol needed (although not necessarily on the = > > same association). SCTP has the interesting property that it makes the = > > normally connectionless unreliable UDP media become connection-oriented = > > unreliable U-SCTP media. I can even foresee that in the future, SCTP = > > associations could be linked to hardware routing and resource = > > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of = > > any work in this field although the stream-based flow-limiting = > > extension is useful - sounds like a good thesis/paper to me.] Anyway, = > > the only piece missing is an SDP profile for SCTP (which I'm still in = > > the process of proposing something - input welcome).

> > > >

Comments please. > >

> > > >

Cheers, > >

> > > >

Robert. > >

> > > >

-- My opinions should not be taken as = > > necessarily representing those of Nuera Communications, Inc. -- > >

> > > >

-----Original = > > Message----- > >
From:   Matt Holdrege = > > [ > HREF=3D"mailto:matt@ipverse.com">mailto:matt@ipverse.com]= > > > >
Sent:   > SIZE=3D2 FACE=3D"Arial">Wednesday, March 28, 2001 3:39 AM > >
> FACE=3D"Arial">To:     > FACE=3D"Arial">sip@lists.bell-labs.com > >
> FACE=3D"Arial">Subject:       = > > Re: [SIP] RE: SCTP as transport for = > > SIP > >

> > > >

(from the SCTP AS) > >

> > > >

For SIP, considering the use of a = > > reliable transport protocol (i.e. not > >
UDP) the features of SCTP would = > > be: > >

> > > >

- acknowledged error-free = > > non-duplicated transfer of user data, > >

> > > >

- data fragmentation to conform to = > > discovered path MTU size, > >

> > > >

- sequenced delivery of user messages = > > within multiple streams, > >
   with an option for = > > order-of-arrival delivery of individual user > >
   messages, > >

> > > >

- optional bundling of multiple user = > > messages into a single SCTP packet, > >

> > > >

- network-level fault tolerance = > > through supporting of multi-homing at > >
either or both ends of an = > > association. > >

> > > >

Applications that require framing of = > > reliable data streams can get that > >
feature from SCTP. > >

> > > >

Applications which transfer = > > independent message sequences that are > >
unrelated (sometimes called = > > transactions) can benefit from the partial > >
ordering provided by SCTP = > > streams. > >

> > > >

Applications that wish to transfer = > > messages that hold no particular > >
sequence or relationship to one = > > another can benefit from the unordered > >
service provided by SCTP. > >

> > > >

Finally for those applications seeking = > > network layer redundancy with > >
multiple Network Interface cards can = > > use SCTP's multi-homing feature. > >

> > > >

Is there any misunderstanding or = > > disagreement with the above? > >

> >
> > > >

> FACE=3D"Arial">_______________________________________________ > >
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 = > > > >
> FACE=3D"Arial">sip-implementors-request@cs.columbia.edu with = > > "subscribe" in the body. > >

> > > > > > > > ------_=_NextPart_001_01C0BB5B.B4B51C00-- > > > > _______________________________________________ > > tsvwg mailing list > > tsvwg@ietf.org > > http://www1.ietf.org/mailman/listinfo/tsvwg > > _______________________________________________ > 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. -- 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 _______________________________________________ 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 Tue Apr 3 16:11:04 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 QAA15497 for ; Tue, 3 Apr 2001 16:11:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 170BC44357; Tue, 3 Apr 2001 16:11:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by lists.bell-labs.com (Postfix) with ESMTP id 28AF244338 for ; Tue, 3 Apr 2001 16:10:48 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by tonnant.cnchost.com id QAA24410; Tue, 3 Apr 2001 16:10:47 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <3ACA2FA1.4030803@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sip Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal References: <3AC69DDE.7A1EDC38@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed 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: Tue, 03 Apr 2001 16:16:33 -0400 Content-Transfer-Encoding: 7bit Hi, Before we come up with any solution, let's first understand what the problems are and what we want out of SDP. Problems: When more than more audio codecs are listed in "m=" line, SDP lacks mechanism to indicate: 1. sendrecv, sendonly, or recvonly for each codec; 2. packetization size supported for each codec ; 3. simultaneous capabilities. (e.g., a UA can support audio codecs A, B, and C, but when video codec X is used, can only support audio codec A.) Desirable functions of SDP: 1. To indicate to the other side the full capabilities of a UA 2. To indicate to the other side the media types (codec, pack. size, uni. or bi-directional) that will be used for a particular session in an unequivocal way. As an implementor, I can testify firsthand that I can not appreciate the last point enough. Here is why: In the real world, most DSP based codec implementations can ONLY support symmetric operation. If tx uses codec A, rx must also use codec A. So if the first SDP (INVITE or 200 OK) lists codecs A, B and C, and second SDP (200 OK or ACK) responds with codecs A and B, one UA may start use codec A and the other may pick codec B, which results in either dead silence or garbled speech. We have seen this happen at the bake-offs. And packetization size is another issue. Take G.729 for example. The base frame size is 10ms. But due to resource restrictions, many implementations can only support a fixed, integer multiple of the base frame, say 20ms or 30 ms. On some implementations, packetization size is either a runtime or configuration parameter. In any case, a 20 ms won't talk to 30 ms G.729. We heard quite a few distorted conversations because of codec size mismatch at SIP bake-offs and at H323 Interoperability Events. Hence, I'd like to propose the following: 1. Assume all audio codecs (not including DTMF) are send and recv, and require symmetric operation; 2. Originating SDP lists packetization size for each codec unless default value is used; 3. If supported, origination SDP lists explicitly whether DTMF is send or recv, with sendrecv being default; 4. Responding SDP lists one and ONLY one codec for each media (if, of course, there exists overlap) and, when applicable, includes packetization size and send/recv attribute; 5. The side that originates SDP uses OPTIONS to query the other side's capability after call setup, if necessary. Example: UA1 supports codecs A (20ms), B (30ms), and C (20ms), and can transmit and recv DTMF; UA2 supports codecs A(10 ms), B (30ms), and D( 20ms) and can transmit DTMF (but not recv). Here's the SDP exchange: UA1->UA2 (INVITE) m=audio 40000 RTP/AVP 100 101 102 a=rtpmap: 100 A/8000 a=ptime: 20 a=rtpmap:101 B/8000 a=ptime: 30 a=rtpmap:102 C/8000 a=ptime: 20 m=audio 40000 RTP/AVP 103 a=fmtp:103 0-15 a=sendrecv UA2->UA1 (200 OK) m=audio 30000 RTP/AVP 101 a=rtpmap:101 B/8000 a=ptime: 30 m=audio 30000 RTP/AVP 103 a=fmtp:103 0-15 a=sendonly Note that there are two "m=" lines in each SDP because the DTMF and codec are really simultaneous capabilities. The usage of "a=ptime" is a little bit stretch here at codec level and may cause problem for existing implementations. But I haven't seen it used very much. Regards, Shan Lu NexTone Communications Gonzalo Camarillo wrote: > Hello, > > There have been already several mails showing certain confusion about > SDP usage in SIP. > In the last IETF the conclusion was: > For sendrecv flows (uni-directional flows are easy), the caller puts in > the INVITe the codecs that he can both send AND receive. > > The open issue is what the callee returns: > 1) a sub-set of the codecs listed in the INVITE that he can send AND > receive. > 2) all the codecs that he can send AND receive. > > Note that caller and callee have reversed roles if the SDP from the > client to the server is sent in the ACK instead of in the INVITE. > > I would like to ask folks not to mix this open issue with another > similar issue: I have a DSP that cannot change codecs on-the-fly, and I > want to pick up just one codec. Let us discuss this issue at other time. > > My proposal is to go for solution number 2. This gives a symmetrical > negotiation. Besides, it covers more cases than solution number 1). It > can happen that for a particular codec, the callee can send AND receive > it but the caller can just send it. Therefore, the caller does not > include it in the INVITE. However, if the callee lists it in the 200 OK, > the caller will be able to send it. > > Opinions? > > Gonzalo _______________________________________________ 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 Tue Apr 3 16:50:04 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 QAA16568 for ; Tue, 3 Apr 2001 16:50:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8049744370; Tue, 3 Apr 2001 16:50:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by lists.bell-labs.com (Postfix) with SMTP id 4EA6144370 for ; Tue, 3 Apr 2001 16:17:26 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Tue Apr 3 13:17:14 2001 To: "La Monte Henry Piggy Yarroll" , "Gonzalo Camarillo" From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 Cc: "Fairlie-Cuninghame, Robert" , "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" , mankin@isi.edu X-Sent-Mail: off Reply-To: lyndon_ong@eudoramail.com X-Mailer: MailCity Service Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP X-Sender-Ip: 63.96.78.20 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en 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: Tue, 03 Apr 2001 13:17:14 -0700 Content-Transfer-Encoding: 7bit Gonzalo, Thanks for the link, this looks like a very nice paper. In fact, some of the points might be good to incorporate/reference in the SCTP AS :o), esp. re: UDP vs. SCTP and the use of unordered service for some applications rather than multiple streams. The AS authors are still working on the AS to make it more complete and clear (and unbiased). Cheers, Lyndon -- On Tue, 03 Apr 2001 22:19:11 Gonzalo Camarillo wrote: >Hello, > >You can check the following link out: >http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf > >It compares advantages and disadvantages of using a single unordered >stream over using multiple ordered streams to transport SIP. > >Best regards, > >Gonzalo > >La Monte Henry Piggy Yarroll wrote: >> >> The purpose of streams in SCTP is to avoid head-of-line blocking. A >> single streams should ONLY be used for messages which have a strict >> ordering requirement. Standalone messages should travel via an >> unordered stream. >> >> The UA's DO allow multiple independant complex exchanges over separate >> streams. In many situations (e.g. telephony switching) it is >> important to share congestion and flow-control information. If you >> DIDN'T use streams over a single SCTP association, you'd have to pay >> the slow-start penalty for every new exchange. >> >> "Fairlie-Cuninghame, Robert" writes: >> > Hi Matt, >> > >> > I'm not convinced that SIP needs to use ordered delivery of messages across >> > multiple streams. If we are not using stream specification within SIP (and I >> > think I agree with you now Jonathan) then I believe SIP should be using a >> > single unordered reliable stream rather than any/all the streams. >> > >> > - This is simpler and as has been said before, a more complicated SIP >> > adaptation layer may cause more complexity in transport-ignorant systems >> > (whatever that might be ). This is also closer to the model used by >> > the existing SIGTRAN adaptation layers (ie, one link => one stream). >> > - The process of enforcing that an application must accept packets on >> > all streams may force implementations on the API and design of the SCTP >> > stack. The stack uses the concept of "used" and "unused" streams - what >> > effect does using 64K streams on an association have on memory requirements. >> > This may not be a relevant concern but I think SIP should try to be more >> > conservative in its use of SCTP. >> > - The sending of different call legs to different streams does not >> > help much in my opinion. A single stream must still be able to accept >> > packets for multiple call legs. >> > - Using arbitrary streams does not allow the use of other streams for >> > any future purpose. >> > >> > I'm also not convinced that the bundling of SIP messages is that useful - >> > SIP messages are usually quite large anyway. However, an interesting >> > application for SCTP with SIP might be on low bandwidth point to point >> > connections. The SIP application controls the association and so it is not >> > too unreasonable that the SIP application may negotiate the use of other >> > streams in the same association for media use. Now the fragmentation >> > properties of SCTP could reduce any delay/jitter in the media carried on the >> > same SCTP association. This is not possible if SIP and media are carried in >> > separate streams. [This is probably not a main-stream application and maybe >> > not even useful/desirable but I don't think it should be impossible.] >> > >> > Jonathan, I see you think that SCTP is not worth the trouble for SIP. I >> > think that SCTP becomes more attractive to SIP when the media also uses SCTP >> > such that SCTP becomes the only transport protocol needed (although not >> > necessarily on the same association). SCTP has the interesting property that >> > it makes the normally connectionless unreliable UDP media become >> > connection-oriented unreliable U-SCTP media. I can even foresee that in the >> > future, SCTP associations could be linked to hardware routing and resource >> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any >> > work in this field although the stream-based flow-limiting extension is >> > useful - sounds like a good thesis/paper to me.] Anyway, the only piece >> > missing is an SDP profile for SCTP (which I'm still in the process of >> > proposing something - input welcome). >> > >> > Comments please. >> > >> > Cheers, >> > >> > Robert. >> > >> > -- My opinions should not be taken as necessarily representing those of >> > Nuera Communications, Inc. -- >> > >> > -----Original Message----- >> > From: Matt Holdrege [mailto:matt@ipverse.com] >> > Sent: Wednesday, March 28, 2001 3:39 AM >> > To: sip@lists.bell-labs.com >> > Subject: Re: [SIP] RE: SCTP as transport for SIP >> > >> > (from the SCTP AS) >> > >> > For SIP, considering the use of a reliable transport protocol (i.e. not >> > UDP) the features of SCTP would be: >> > >> > - acknowledged error-free non-duplicated transfer of user data, >> > >> > - data fragmentation to conform to discovered path MTU size, >> > >> > - sequenced delivery of user messages within multiple streams, >> > with an option for order-of-arrival delivery of individual user >> > messages, >> > >> > - optional bundling of multiple user messages into a single SCTP packet, >> > >> > - network-level fault tolerance through supporting of multi-homing at >> > either or both ends of an association. >> > >> > Applications that require framing of reliable data streams can get that >> > feature from SCTP. >> > >> > Applications which transfer independent message sequences that are >> > unrelated (sometimes called transactions) can benefit from the partial >> > ordering provided by SCTP streams. >> > >> > Applications that wish to transfer messages that hold no particular >> > sequence or relationship to one another can benefit from the unordered >> > service provided by SCTP. >> > >> > Finally for those applications seeking network layer redundancy with >> > multiple Network Interface cards can use SCTP's multi-homing feature. >> > >> > Is there any misunderstanding or disagreement with the above? >> > >> > >> > _______________________________________________ >> > 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_01C0BB5B.B4B51C00 >> > Content-Type: text/html; >> > charset="iso-8859-1" >> > Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > > > charset=3Diso-8859-1"> >> > > > 5.5.2653.12"> >> > RE: [SIP] RE: SCTP as transport for SIP >> > >> > >> > >> >

Hi Matt, >> >

>> > >> >

Hi Matt, >> >

>> > >> >

I'm not convinced that SIP needs to = >> > use ordered delivery of messages across multiple streams. If we are not = >> > using stream specification within SIP (and I think I agree with you now = >> > Jonathan) then I believe SIP should be using a single unordered = >> > reliable stream rather than any/all the streams.

>> > >> >
  • This is simpler and as has been = >> > said before, a more complicated SIP adaptation layer may cause more = >> > complexity in transport-ignorant systems (whatever that might be = >> > ). This is also closer to the model used by the existing = >> > SIGTRAN adaptation layers (ie, one link =3D> one = >> > stream).
    • >> >
  • The process of enforcing that an = >> > application must accept packets on all streams may force = >> > implementations on the API and design of the SCTP stack. The stack uses = >> > the concept of "used" and "unused" streams - what effect does using 64K = >> > streams on an association have on memory requirements. This may not be = >> > a relevant concern but I think SIP should try to be more conservative = >> > in its use of SCTP.
    • >> >
  • The sending of different call = >> > legs to different streams does not help much in my opinion. A single = >> > stream must still be able to accept packets for multiple call = >> > legs.
    • >> >
  • Using arbitrary streams does not = >> > allow the use of other streams for any future purpose.
    • >> >
    >> >
>> >

I'm also not convinced that the = >> > bundling of SIP messages is that useful - SIP messages are usually = >> > quite large anyway. However, an interesting application for SCTP with = >> > SIP might be on low bandwidth point to point connections. The SIP = >> > application controls the association and so it is not too unreasonable = >> > that the SIP application may negotiate the use of other streams in the = >> > same association for media use. Now the fragmentation properties of = >> > SCTP could reduce any delay/jitter in the media carried on the same = >> > SCTP association. This is not possible if SIP and media are carried in = >> > separate streams. [This is probably not a main-stream application and = >> > maybe not even useful/desirable but I don't think it should be = >> > impossible.]

>> > >> >

Jonathan, I see you think that SCTP is = >> > not worth the trouble for SIP. I think that SCTP becomes more = >> > attractive to SIP when the media also uses SCTP such that SCTP becomes = >> > the only transport protocol needed (although not necessarily on the = >> > same association). SCTP has the interesting property that it makes the = >> > normally connectionless unreliable UDP media become connection-oriented = >> > unreliable U-SCTP media. I can even foresee that in the future, SCTP = >> > associations could be linked to hardware routing and resource = >> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of = >> > any work in this field although the stream-based flow-limiting = >> > extension is useful - sounds like a good thesis/paper to me.] Anyway, = >> > the only piece missing is an SDP profile for SCTP (which I'm still in = >> > the process of proposing something - input welcome).

>> > >> >

Comments please. >> >

>> > >> >

Cheers, >> >

>> > >> >

Robert. >> >

>> > >> >

-- My opinions should not be taken as = >> > necessarily representing those of Nuera Communications, Inc. -- >> >

>> > >> >

-----Original = >> > Message----- >> >
From: Matt Holdrege = >> > [> > HREF=3D"mailto:matt@ipverse.com">mailto:matt@ipverse.com]= >> > >> >
Sent: > > SIZE=3D2 FACE=3D"Arial">Wednesday, March 28, 2001 3:39 AM >> >
> > FACE=3D"Arial">To: > > FACE=3D"Arial">sip@lists.bell-labs.com >> >
> > FACE=3D"Arial">Subject: = >> > Re: [SIP] RE: SCTP as transport for = >> > SIP >> >

>> > >> >

(from the SCTP AS) >> >

>> > >> >

For SIP, considering the use of a = >> > reliable transport protocol (i.e. not >> >
UDP) the features of SCTP would = >> > be: >> >

>> > >> >

- acknowledged error-free = >> > non-duplicated transfer of user data, >> >

>> > >> >

- data fragmentation to conform to = >> > discovered path MTU size, >> >

>> > >> >

- sequenced delivery of user messages = >> > within multiple streams, >> >
with an option for = >> > order-of-arrival delivery of individual user >> >
messages, >> >

>> > >> >

- optional bundling of multiple user = >> > messages into a single SCTP packet, >> >

>> > >> >

- network-level fault tolerance = >> > through supporting of multi-homing at >> >
either or both ends of an = >> > association. >> >

>> > >> >

Applications that require framing of = >> > reliable data streams can get that >> >
feature from SCTP. >> >

>> > >> >

Applications which transfer = >> > independent message sequences that are >> >
unrelated (sometimes called = >> > transactions) can benefit from the partial >> >
ordering provided by SCTP = >> > streams. >> >

>> > >> >

Applications that wish to transfer = >> > messages that hold no particular >> >
sequence or relationship to one = >> > another can benefit from the unordered >> >
service provided by SCTP. >> >

>> > >> >

Finally for those applications seeking = >> > network layer redundancy with >> >
multiple Network Interface cards can = >> > use SCTP's multi-homing feature. >> >

>> > >> >

Is there any misunderstanding or = >> > disagreement with the above? >> >

>> >
>> > >> >

> > FACE=3D"Arial">_______________________________________________ >> >
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 = >> > >> >
> > FACE=3D"Arial">sip-implementors-request@cs.columbia.edu with = >> > "subscribe" in the body. >> >

>> > >> > >> > >> > ------_=_NextPart_001_01C0BB5B.B4B51C00-- >> > >> > _______________________________________________ >> > tsvwg mailing list >> > tsvwg@ietf.org >> > http://www1.ietf.org/mailman/listinfo/tsvwg >> >> _______________________________________________ >> 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. > >-- >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 > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >http://www1.ietf.org/mailman/listinfo/tsvwg > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.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@lists.bell-labs.com Tue Apr 3 16:51:29 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 QAA16617 for ; Tue, 3 Apr 2001 16:51:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DF6644395; Tue, 3 Apr 2001 16:50:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from shared1-mail.whowhere.com (shared1-batch.whowhere.com [209.185.123.82]) by lists.bell-labs.com (Postfix) with SMTP id 47E6044357 for ; Tue, 3 Apr 2001 16:42:04 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Tue Apr 3 13:41:49 2001 To: "La Monte Henry Piggy Yarroll" , "Gonzalo Camarillo" From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 Cc: "Fairlie-Cuninghame, Robert" , "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" , sigtran@standards.nortelnetworks.com, loede.coene@siemens.atea.be X-Sent-Mail: off Reply-To: lyndon_ong@eudoramail.com X-Mailer: MailCity Service Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP X-Sender-Ip: 63.96.78.20 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en 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: Tue, 03 Apr 2001 13:41:49 -0700 Content-Transfer-Encoding: 7bit BTW, I'm suggesting we might incorporate some of the points made in Gonzalo's paper, e.g., use of unordered service for applications that do their own message correlation, ability to do transport level fragmentation, etc., not the overall conclusion of whether to use SCTP for SIP, which is out of scope. Cheers, Lyndon -- On Tue, 03 Apr 2001 22:19:11 Gonzalo Camarillo wrote: >Hello, > >You can check the following link out: >http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf > >It compares advantages and disadvantages of using a single unordered >stream over using multiple ordered streams to transport SIP. > >Best regards, > >Gonzalo > >La Monte Henry Piggy Yarroll wrote: >> >> The purpose of streams in SCTP is to avoid head-of-line blocking. A >> single streams should ONLY be used for messages which have a strict >> ordering requirement. Standalone messages should travel via an >> unordered stream. >> >> The UA's DO allow multiple independant complex exchanges over separate >> streams. In many situations (e.g. telephony switching) it is >> important to share congestion and flow-control information. If you >> DIDN'T use streams over a single SCTP association, you'd have to pay >> the slow-start penalty for every new exchange. >> >> "Fairlie-Cuninghame, Robert" writes: >> > Hi Matt, >> > >> > I'm not convinced that SIP needs to use ordered delivery of messages across >> > multiple streams. If we are not using stream specification within SIP (and I >> > think I agree with you now Jonathan) then I believe SIP should be using a >> > single unordered reliable stream rather than any/all the streams. >> > >> > - This is simpler and as has been said before, a more complicated SIP >> > adaptation layer may cause more complexity in transport-ignorant systems >> > (whatever that might be ). This is also closer to the model used by >> > the existing SIGTRAN adaptation layers (ie, one link => one stream). >> > - The process of enforcing that an application must accept packets on >> > all streams may force implementations on the API and design of the SCTP >> > stack. The stack uses the concept of "used" and "unused" streams - what >> > effect does using 64K streams on an association have on memory requirements. >> > This may not be a relevant concern but I think SIP should try to be more >> > conservative in its use of SCTP. >> > - The sending of different call legs to different streams does not >> > help much in my opinion. A single stream must still be able to accept >> > packets for multiple call legs. >> > - Using arbitrary streams does not allow the use of other streams for >> > any future purpose. >> > >> > I'm also not convinced that the bundling of SIP messages is that useful - >> > SIP messages are usually quite large anyway. However, an interesting >> > application for SCTP with SIP might be on low bandwidth point to point >> > connections. The SIP application controls the association and so it is not >> > too unreasonable that the SIP application may negotiate the use of other >> > streams in the same association for media use. Now the fragmentation >> > properties of SCTP could reduce any delay/jitter in the media carried on the >> > same SCTP association. This is not possible if SIP and media are carried in >> > separate streams. [This is probably not a main-stream application and maybe >> > not even useful/desirable but I don't think it should be impossible.] >> > >> > Jonathan, I see you think that SCTP is not worth the trouble for SIP. I >> > think that SCTP becomes more attractive to SIP when the media also uses SCTP >> > such that SCTP becomes the only transport protocol needed (although not >> > necessarily on the same association). SCTP has the interesting property that >> > it makes the normally connectionless unreliable UDP media become >> > connection-oriented unreliable U-SCTP media. I can even foresee that in the >> > future, SCTP associations could be linked to hardware routing and resource >> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any >> > work in this field although the stream-based flow-limiting extension is >> > useful - sounds like a good thesis/paper to me.] Anyway, the only piece >> > missing is an SDP profile for SCTP (which I'm still in the process of >> > proposing something - input welcome). >> > >> > Comments please. >> > >> > Cheers, >> > >> > Robert. >> > >> > -- My opinions should not be taken as necessarily representing those of >> > Nuera Communications, Inc. -- >> > >> > -----Original Message----- >> > From: Matt Holdrege [mailto:matt@ipverse.com] >> > Sent: Wednesday, March 28, 2001 3:39 AM >> > To: sip@lists.bell-labs.com >> > Subject: Re: [SIP] RE: SCTP as transport for SIP >> > >> > (from the SCTP AS) >> > >> > For SIP, considering the use of a reliable transport protocol (i.e. not >> > UDP) the features of SCTP would be: >> > >> > - acknowledged error-free non-duplicated transfer of user data, >> > >> > - data fragmentation to conform to discovered path MTU size, >> > >> > - sequenced delivery of user messages within multiple streams, >> > with an option for order-of-arrival delivery of individual user >> > messages, >> > >> > - optional bundling of multiple user messages into a single SCTP packet, >> > >> > - network-level fault tolerance through supporting of multi-homing at >> > either or both ends of an association. >> > >> > Applications that require framing of reliable data streams can get that >> > feature from SCTP. >> > >> > Applications which transfer independent message sequences that are >> > unrelated (sometimes called transactions) can benefit from the partial >> > ordering provided by SCTP streams. >> > >> > Applications that wish to transfer messages that hold no particular >> > sequence or relationship to one another can benefit from the unordered >> > service provided by SCTP. >> > >> > Finally for those applications seeking network layer redundancy with >> > multiple Network Interface cards can use SCTP's multi-homing feature. >> > >> > Is there any misunderstanding or disagreement with the above? >> > >> > >> > _______________________________________________ >> > 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_01C0BB5B.B4B51C00 >> > Content-Type: text/html; >> > charset="iso-8859-1" >> > Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > > > charset=3Diso-8859-1"> >> > > > 5.5.2653.12"> >> > RE: [SIP] RE: SCTP as transport for SIP >> > >> > >> > >> >

Hi Matt, >> >

>> > >> >

Hi Matt, >> >

>> > >> >

I'm not convinced that SIP needs to = >> > use ordered delivery of messages across multiple streams. If we are not = >> > using stream specification within SIP (and I think I agree with you now = >> > Jonathan) then I believe SIP should be using a single unordered = >> > reliable stream rather than any/all the streams.

>> > >> >
  • This is simpler and as has been = >> > said before, a more complicated SIP adaptation layer may cause more = >> > complexity in transport-ignorant systems (whatever that might be = >> > ). This is also closer to the model used by the existing = >> > SIGTRAN adaptation layers (ie, one link =3D> one = >> > stream).
    • >> >
  • The process of enforcing that an = >> > application must accept packets on all streams may force = >> > implementations on the API and design of the SCTP stack. The stack uses = >> > the concept of "used" and "unused" streams - what effect does using 64K = >> > streams on an association have on memory requirements. This may not be = >> > a relevant concern but I think SIP should try to be more conservative = >> > in its use of SCTP.
    • >> >
  • The sending of different call = >> > legs to different streams does not help much in my opinion. A single = >> > stream must still be able to accept packets for multiple call = >> > legs.
    • >> >
  • Using arbitrary streams does not = >> > allow the use of other streams for any future purpose.
    • >> >
    >> >
>> >

I'm also not convinced that the = >> > bundling of SIP messages is that useful - SIP messages are usually = >> > quite large anyway. However, an interesting application for SCTP with = >> > SIP might be on low bandwidth point to point connections. The SIP = >> > application controls the association and so it is not too unreasonable = >> > that the SIP application may negotiate the use of other streams in the = >> > same association for media use. Now the fragmentation properties of = >> > SCTP could reduce any delay/jitter in the media carried on the same = >> > SCTP association. This is not possible if SIP and media are carried in = >> > separate streams. [This is probably not a main-stream application and = >> > maybe not even useful/desirable but I don't think it should be = >> > impossible.]

>> > >> >

Jonathan, I see you think that SCTP is = >> > not worth the trouble for SIP. I think that SCTP becomes more = >> > attractive to SIP when the media also uses SCTP such that SCTP becomes = >> > the only transport protocol needed (although not necessarily on the = >> > same association). SCTP has the interesting property that it makes the = >> > normally connectionless unreliable UDP media become connection-oriented = >> > unreliable U-SCTP media. I can even foresee that in the future, SCTP = >> > associations could be linked to hardware routing and resource = >> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of = >> > any work in this field although the stream-based flow-limiting = >> > extension is useful - sounds like a good thesis/paper to me.] Anyway, = >> > the only piece missing is an SDP profile for SCTP (which I'm still in = >> > the process of proposing something - input welcome).

>> > >> >

Comments please. >> >

>> > >> >

Cheers, >> >

>> > >> >

Robert. >> >

>> > >> >

-- My opinions should not be taken as = >> > necessarily representing those of Nuera Communications, Inc. -- >> >

>> > >> >

-----Original = >> > Message----- >> >
From: Matt Holdrege = >> > [> > HREF=3D"mailto:matt@ipverse.com">mailto:matt@ipverse.com]= >> > >> >
Sent: > > SIZE=3D2 FACE=3D"Arial">Wednesday, March 28, 2001 3:39 AM >> >
> > FACE=3D"Arial">To: > > FACE=3D"Arial">sip@lists.bell-labs.com >> >
> > FACE=3D"Arial">Subject: = >> > Re: [SIP] RE: SCTP as transport for = >> > SIP >> >

>> > >> >

(from the SCTP AS) >> >

>> > >> >

For SIP, considering the use of a = >> > reliable transport protocol (i.e. not >> >
UDP) the features of SCTP would = >> > be: >> >

>> > >> >

- acknowledged error-free = >> > non-duplicated transfer of user data, >> >

>> > >> >

- data fragmentation to conform to = >> > discovered path MTU size, >> >

>> > >> >

- sequenced delivery of user messages = >> > within multiple streams, >> >
with an option for = >> > order-of-arrival delivery of individual user >> >
messages, >> >

>> > >> >

- optional bundling of multiple user = >> > messages into a single SCTP packet, >> >

>> > >> >

- network-level fault tolerance = >> > through supporting of multi-homing at >> >
either or both ends of an = >> > association. >> >

>> > >> >

Applications that require framing of = >> > reliable data streams can get that >> >
feature from SCTP. >> >

>> > >> >

Applications which transfer = >> > independent message sequences that are >> >
unrelated (sometimes called = >> > transactions) can benefit from the partial >> >
ordering provided by SCTP = >> > streams. >> >

>> > >> >

Applications that wish to transfer = >> > messages that hold no particular >> >
sequence or relationship to one = >> > another can benefit from the unordered >> >
service provided by SCTP. >> >

>> > >> >

Finally for those applications seeking = >> > network layer redundancy with >> >
multiple Network Interface cards can = >> > use SCTP's multi-homing feature. >> >

>> > >> >

Is there any misunderstanding or = >> > disagreement with the above? >> >

>> >
>> > >> >

> > FACE=3D"Arial">_______________________________________________ >> >
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 = >> > >> >
> > FACE=3D"Arial">sip-implementors-request@cs.columbia.edu with = >> > "subscribe" in the body. >> >

>> > >> > >> > >> > ------_=_NextPart_001_01C0BB5B.B4B51C00-- >> > >> > _______________________________________________ >> > tsvwg mailing list >> > tsvwg@ietf.org >> > http://www1.ietf.org/mailman/listinfo/tsvwg >> >> _______________________________________________ >> 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. > >-- >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 > >_______________________________________________ >tsvwg mailing list >tsvwg@ietf.org >http://www1.ietf.org/mailman/listinfo/tsvwg > Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.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@lists.bell-labs.com Tue Apr 3 18:24:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18915 for ; Tue, 3 Apr 2001 18:24:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14A1E44338; Tue, 3 Apr 2001 18:24:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lists.bell-labs.com (Postfix) with ESMTP id 9665944337 for ; Tue, 3 Apr 2001 18:10:50 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA17507 for ; Tue, 3 Apr 2001 15:05:19 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA10638 for ; Tue, 3 Apr 2001 15:05:34 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id <2G808XMA>; Tue, 3 Apr 2001 17:10:45 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451F7@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Bob Penfield'" , Jonathan Rosenberg , Baniel Uri-CUB001 , "'Dean Willis'" , bidulock@openss7.org Cc: Sriram Parameswar , "'Romeo Zwart'" , "'Stephen Terrill'" , Igor Slepchin , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Tue, 3 Apr 2001 17:10:43 -0500 Bob I think I said it already, but just in case, I totally agree! Another way of doing it is per Jonathan's suggestion, which is... any other way, which would not affect the existing spec. Specifically in a world of subscriptions and users/subscribers profiles (such as for instance the cellular 3G world) the subscription for notification in the event of unregisteration (deregistration in the 3GPP Nomen clature) may be done in profile update time, for instance when the admin happens to be also your local neighborhood bar tender. (No one has laughed before, so I have no choice but to repeat my silly joke) I am trying to push this (with Bonnie Chen and Mimi Xu) through the 3GPP channels, so there will be alignment with the 'pure' SIP. Thanks, Uri. =========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Monday, April 02, 2001 12:46 PM > To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; 'Dean Willis'; > bidulock@openss7.org > Cc: Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; Igor > Slepchin; > 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip > Subject: Re: [SIP] Informing UA after network initiated > deregistration? > > > I don't think that it is necessary to add more headers. The > Event header > should be used for implicit subscription just like it is used > for explicit > subscriptions. > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > (781) 933-6166 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "'Baniel Uri-CUB001'" ; "'Dean Willis'" > ; > Cc: "'Bob Penfield'" ; "Sriram Parameswar" > ; "'Romeo Zwart'" ; > "'Stephen Terrill'" ; "Igor Slepchin" > ; "'William Marshall'" > ; > "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" > ; "sip" > Sent: Monday, April 02, 2001 3:36 AM > Subject: RE: [SIP] Informing UA after network initiated > deregistration? > > > > > > > > > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > > Sent: Sunday, April 01, 2001 9:34 AM > > > To: 'Dean Willis'; bidulock@openss7.org > > > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > > > 'Romeo Zwart'; > > > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > > > Bonnie-BCHEN1; Xu Lang-LXU1; sip > > > Subject: RE: [SIP] Informing UA after network initiated > > > deregistration? > > > > > > [4]My understanding is that in Minneapolis it has been > > > decided/approved to > > > Inform a UA after network initiated deregistration. My > > > questions to you guys > > > are: > > > [4.1] Has it been decided to go for implicit subscription for > > > notification > > > in the Registration request? or to specify it in a > dedicated header? > > > > More headers in registrations. I love it. When are we going > to get the "by > > the way, I am interested in knowing when I have exactly 15 > dollars left > in > > my account, the one I set up with Mastercard". I propose: > > > > Mastercard-Balance-Subscription: 15;currency=dollar > > > > Just in case there are those who like this idea (and since > sarcasm by > email > > is sometimes missed) - no, we are NOT having a new header in > registrations. > > > > Some have debated whether or not the presence spec allows > or disallows > > "implicit" registrations. This fits into the growing > category of things > that > > "the SIP spec doesn't, nor shouldn't, say". SIP for > presence specifies a > way > > to create subscriptions, and a way to generate notifications for > > subscriptions. It does not say that when you build a > system, the ONLY way > to > > get subscriptions in there is to use the SUBSRIBE method. I > think a web > form > > is a perfectly fine way to create subscriptions. We then use our > > notification mechanisms to generate notifies for them. How > the lifetimes > of > > these subscriptions are managed is also an implementation issue. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.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. > > > > > _______________________________________________ > 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 Tue Apr 3 23:49:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25585 for ; Tue, 3 Apr 2001 23:49:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 761C64433A; Tue, 3 Apr 2001 23:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 9723044337 for ; Tue, 3 Apr 2001 23:48:14 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id XAA01016; Tue, 3 Apr 2001 23:48:14 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] Response if user not registered? Message-ID: <000201c0bcba$49c06b60$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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 Apr 2001 23:49:44 -0400 Content-Transfer-Encoding: 7bit > I believe this issue in 3gpp arises because for them, they > have "extended" > register to do more than create bindings. They use it to > assign the proxy > which will handle both incoming and outgoing calls for the user, and > basically do not allow outgoing calls until such a selection > is made. So, > we're really not talking about registrations in the sip sense. We are > talking about a new function. As the function is one of > policy, its also one > which, arguably, is an implementation decision, not a > protocol one. There is > no reason why I cannot build proxies that refuse outgoing > calls unless this > assignment function has taken place. Again, whether or not > this is a good > thing, is an entirely separate question. For outbound proxies in general, it would be nice to communicate that a call is being rejected because the calling party is unknown. Currently the 403 Forbidden appears to be the best SIP response. However it doesn't specify if the response is being rejected by the called party or outbound proxy. [Note: modifying the 403 reason phrase or including the Warning header with warn-text would be useful to the user; however the actual devices could not really act upon the text unless standardized. The same would be true if a Contact contained a link to web page or it the call was connected to treatments.] The 401 Unauthorized sounds like a potential candidate, but it has the same ambiguity as the 403 and may actually be interpreted as being from the called party. When a REGISTER is desired and target is unknown, another solution would be to send REFER with method=REGISTER if Refer-To without a host was valid. However since a 3GPP gateway would most likely drop the host address anyway, I assume that the Refer-To could be "sip:localhost;method=REGISTER". [ :) That wasn't a stab, I was referring to the fact that translations or something from the mobile would actually be used to identify the real target address of the REGISTER.] _______________________________________________ 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 Wed Apr 4 01:53:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02291 for ; Wed, 4 Apr 2001 01:53:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC1BB4433D; Wed, 4 Apr 2001 01:53:01 -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 6003244337 for ; Wed, 4 Apr 2001 01:52:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07957; Wed, 4 Apr 2001 01:56:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 01:52:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'aravindan shanmugam'" , Gonzalo Camarillo , "Fairlie-Cuninghame, Robert" Cc: Jonathan Rosenberg , sip , Robert Sparks , dov , Michael Thomas , Victor A Paulsamy Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 4 Apr 2001 01:52:49 -0400 > -----Original Message----- > From: aravindan shanmugam [mailto:saravindan@yahoo.com] > Sent: Tuesday, April 03, 2001 10:48 AM > To: Gonzalo Camarillo; Fairlie-Cuninghame, Robert > Cc: 'Jonathan Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas; > Victor A Paulsamy > Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? > > > > Following your suggestion, the caller lists the > > codecs he can receive in > > the INVITE. The callee now does not know if a > > bi-directional stream can > > be established, because he does not know which > > codecs the caller is able > > to send. > > > > Example: both caller and callee can receive codecs 1 > > and 2, but not send > > them. The INVITE would contain codecs 1 and 2, and > > the 200 OK will also > > contain both codecs. The INVITE-200 OK-ACK is > > successful, but the > > session cannot be established. > > > The callee will check if he can support either codec 1 > or 2 before sending 200 OK with his codec. You are missing the point. IF the semantics in the SDP in the INVITE are "these are the codecs I can receive",the callee may be able to send codecs 1 and 2, but that doesn't mean that a session can be established, because we don't know if the caller can SEND 1 and 2. The caller > is supposed to check if he can support either of the > listed codecs before responding with ACK. That is incorrect. ACK is always sent, without SDP, if there was SDP in the INVITE. I hope by now that Gonzalo has repeated the relevant points in this thread enough that we can come to some agreement. I still believe his proposal is a sound one, and that the issue of "I can support only one codec at a time", is a separate issue. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Wed Apr 4 02:04:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05671 for ; Wed, 4 Apr 2001 02:04:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 893DB4438B; Wed, 4 Apr 2001 02:04: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 B244044355 for ; Wed, 4 Apr 2001 02:03:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA07995; Wed, 4 Apr 2001 02:06:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 02:03:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'bidulock@openss7.org'" , Jonathan Rosenberg Cc: "'Roy, Radhika R, ALCOO'" , Michael Thomas , sip@lists.bell-labs.com Subject: RE: [SIP] Response if user not registered? 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: Wed, 4 Apr 2001 02:03:23 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA05671 > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, April 02, 2001 6:22 AM > To: Jonathan Rosenberg > Cc: 'Roy, Radhika R, ALCOO'; Michael Thomas; sip@lists.bell-labs.com > Subject: Re: [SIP] Response if user not registered? > > > Jonathan, > > Good points. However, moving this exended registration function > outside of SIP reduces SIP to no better than a connection > establishment > protocol which is ignorant of the service which is being provided > by it. In that case, why not move SIP's inbound registration function > outside the protocol as well... Well, to be honest, if I could do SIP over again from scratch, I would make this a separate protocol. It more or less is, being an exception to a whole bunch of rules as it stands now anyway. That aside, I still find the process of assigning an S-CSCF at registration to be a funny thing. I agree completely that you will ultimately want to segment the servers in your domain, with users being assigned to a specific server. THis segmentation is a common practice today, even, in email systems. However, there, they make the segmentations algorithmic in nature. I believe its common to assign users to mail servers based on the first letter of their username. The algorithmic mappings are a lot easier to deal with, and don't require any of these additional databases to hold the "user to S-CSCF" mappings themselves. Perhaps someone can clarify for me why it was decided to do it this way in 3gpp. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > > --Brian > > Jonathan Rosenberg wrote: (Mon, 02 Apr > 2001 04:07:49) > > > > I have to agree with Dean that this thread is awfully > confused and sometimes > > frightening. > > > > People want to charge for outgoing calls through proxies. > Whether I think > > thats a good idea or not is irrelevant. To do that, these > people need to > > identify the person or phone making the call. Thats OK. In > SIP, we have > > mechanisms for allowing outbound proxies to authenticate > the caller, and > > determine exactly who they are. Just dandy. I am totally > baffled as to what > > this has to do with SIP registrations. SIP registrations > don't establish > > identity, they don't upload authorizations, or anything > like that. They > > create address bindings. Creating address bindings has > nothing to do with > > making outbound calls. > > > > I believe this issue in 3gpp arises because for them, they > have "extended" > > register to do more than create bindings. They use it to > assign the proxy > > which will handle both incoming and outgoing calls for the user, and > > basically do not allow outgoing calls until such a > selection is made. So, > > we're really not talking about registrations in the sip > sense. We are > > talking about a new function. As the function is one of > policy, its also one > > which, arguably, is an implementation decision, not a > protocol one. There is > > no reason why I cannot build proxies that refuse outgoing > calls unless this > > assignment function has taken place. Again, whether or not > this is a good > > thing, is an entirely separate question. > > > > -Jonathan R. > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > > _______________________________________________ > 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 Wed Apr 4 02:25:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10167 for ; Wed, 4 Apr 2001 02:25:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AEC8544386; Wed, 4 Apr 2001 02:25: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 0ACFA44337 for ; Wed, 4 Apr 2001 02:24:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA08096; Wed, 4 Apr 2001 02:28:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 02:24:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" Cc: "'brett@broadsoft.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf- sip-session-timer: refresh rate) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 4 Apr 2001 02:24:37 -0400 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, March 21, 2001 2:51 AM > To: Jonathan Rosenberg > Cc: 'brett@broadsoft.com'; sip@lists.bell-labs.com > Subject: Re: [SIP] Session timer considered harmful (was RE: > draft-ietf-sip-session-timer: refresh rate) > > > > > > > >My proposal to fix this is a bit radical, but here goes. I'd > > > like to put > > > >into the spec a minimum session timer value. A client never > > > runs session > > > >timer more frequently than this interval. I would propose > > > that this value be > > > >on the order of 30 minutes. > > > > > > I am not sure if that is needed (it could be RECOMMENDED, > > > though), if we > > > define the "timer too low" header. Then the proxy > administrator can > > > choose to use a minimum value of 30 minutes, 60 minutes > or whatever he > > > wants. > > > >No, that doesn't help. A rogue proxy could still reduce the > value of the > >"minimum timer value" header, even though its not supposed > to. Mandating > >that the clients never send faster than X, means that no > rogue proxy or UA > >could ever cause a session timer refresh to be used as an attack. > > As much as a proxy can reduce the value, even it it's not > supposed to, a > client can send faster than X, even it it's not supposed to... You are totally missing the point. I am not debating that a misbehaving client can send faster than the minimum. My point is that a normal client won't misbehave, and an attacker can make use of standardized behavior to launch an amplification attack. Thats bad. I am trying to describe standardized behavior which cannot be used to launch an amplification attack. > > I do belive, however, than an operator will not have this > problem in his > network, since he will control all his proxies. The problem is that a proxy in another network can cause the attack. Let me be specific. I sign up for service with sip provider foo. foo is an origination service provider, which means I can get a phone number, and calls for that phone number are routed to a gateway owned by foo, converted to SIP, and sent to my softphone. Now, once I get this number, I use a hacked client that pretends to be a proxy. I call myself on a PSTN phone. THe call goes to the gateways of provider foo, through its proxies, and to my hacked softphone. It answers 200 OK with a session timer of 1ms. Now, the perfectly compliant gateway of provider foo starts sending re-INVITEs at a rate of 1000 per second. It floods my softphone, but I don't care. It also floods the gateway, and the proxies of the provider. Thats more interesting. I make a bunch more calls, and I can take the gateway and all proxies along the path out of commission. This problem will only > come up if I plug my phone to the internet and call someone "directly" > via some "public" proxy server, or something. And, if that > proxy starts > to do strange things people will probably stop using it... In other > words, I personally don't think that I am going to reach unwanted and > unknown proxies - instead I think that "hacker" clients will > be a bigger > problem. As I have demonstrated above, there are realistic attacks possible. > > >>Because, no matter if there is a minimum value or not, one can > >>hack his/her client to send re-INVITEs every second... > > > >That is not the point. The point is whether an attacking device can > >introduce an amplification attack against existing, > compliant devices. With > >current session timer, they can. > > Yes, but are you sure that introducing a minimum value will > solve this? Yes. Consider the attack above. The gateway will refuse to honor the 1ms timer, and instead run at 30 seconds. Attack prevented. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Wed Apr 4 02:29:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10201 for ; Wed, 4 Apr 2001 02:29:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 928DE44395; Wed, 4 Apr 2001 02:29: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 8CDBD4434A for ; Wed, 4 Apr 2001 02:28:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA08132; Wed, 4 Apr 2001 02:31:58 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 02:28:31 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , Jonathan Rosenberg , brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-si p-session- timer: refresh rate) 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: Wed, 4 Apr 2001 02:28:30 -0400 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 27, 2001 4:23 PM > To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com > Subject: Re: [SIP] Session timer considered harmful (was RE: > draft-ietf-sip-session- timer: refresh rate) > > > > I would suggest an even simpler approach -- guidance to > implementors that > suggests they implement a configuration variable to treat > session-timer > values below that variable's value as having that value, and > guidance to > operators on the tuning of that value. As session-timer is > only intended as > a guideline for how long state should be kept on an inactive > call, there's > no real harm in (beyond state preservation load) in keeping > it a little > longer. This allows the lower-bound in effect to be defined on a a > per-network, per device basis and adjusted for operator requirements. The problem is that session timers affect the proxies and UA's in other networks. So, if foo.com owns a gateway, and for it, a session timer of 1ms was OK, since it uses OC-192 interface cards and a 100 processor box, other proxies on the path may not have such compute and I/O power, in which case 1ms is not OK for them. > > If someone's rogue UAC decides to start resending INVITES every few > milliseconds, no specification can stop it from doing so. > That's like trying > to legislate rainfall . . . Of course. The case I am concerned about is using a regular UA, compliant to session timer, as a point of amplification for a DoS attack. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Wed Apr 4 02:31:30 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10267 for ; Wed, 4 Apr 2001 02:31:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB10F443B3; Wed, 4 Apr 2001 02:31: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 66C4244393 for ; Wed, 4 Apr 2001 02:30:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA08156; Wed, 4 Apr 2001 02:34:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 02:30:41 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mayank Sharma'" , "Chen, Xin (Xin)" , sip@lists.bell-labs.com Subject: RE: [SIP] A question about Cancel request 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: Wed, 4 Apr 2001 02:30:40 -0400 > -----Original Message----- > From: Mayank Sharma [mailto:mayanks@mindtree.com] > Sent: Tuesday, April 03, 2001 1:46 AM > To: Chen, Xin (Xin); sip@lists.bell-labs.com > Subject: RE: [SIP] A question about Cancel request > > > > I have a basic question about sip. > > Cancel request is used to cancel a pending INVITE. > > In sip signalling establishment procedure, if the callee > > agent for some > > reason fails, it can't receive anything from its proxy, after > > the proxy > > server of the callee retransmittes 6 times INVITE messges, it > > should give up > > sending INVITE. My quesiton is whether the Cancel request is > > needed to send > > out by the proxy server to the callee, if so, it will cause > > another 11 times > > cancle request beeing sent. > > The Cancel is required to be sent to the callee. Simple > reason being that the > > proxy does not know weather the callee UA is down or is > simply not responding > for the time being. Sending Cancel ensures that in case UA is > not down this > Cancel > will cancel the previous Invite, and the UA is not supposed > to respond to > that Invite > at a later stage. Actually, I have debated whether or not CANCEL is useful in the case where you never received any provisional response at all, not even a 100. This is likely a sign that the device or the network has failed, in which case the CANCEL is not useful. I would tend to think that the best answer is to say that if you never receive a provisional response, you MAY send a CANCEL, but its not mandatory. If you do get a provisional response, you SHOULD CANCEL upon timeout. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Wed Apr 4 03:17:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10610 for ; Wed, 4 Apr 2001 03:17:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F40B4433F; Wed, 4 Apr 2001 03:17:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 4DDC644337 for ; Wed, 4 Apr 2001 03:16:12 -0400 (EDT) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f341F4P20167; Tue, 3 Apr 2001 20:15:04 -0500 Message-ID: <006b01c0bcd7$115445e0$5e041cac@dynamicsoft.com> From: "Dean Willis" To: "Jonathan Rosenberg" , , References: Subject: Re: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate) 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 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: Wed, 4 Apr 2001 02:15:43 -0500 Content-Transfer-Encoding: 7bit Yes, but if each of the proxies along the path knows what its safe "lower bound" on retransmits is and refuses to pass a session timer with a value lower than the safety threshold, the attack can be avoided. This isn't a protocol change. And if the carrier-operated gateway at the other end of the attack call is configured with a lower-bound on session timer values, it won't respect session timer settings below this threshold and won't cause the retransmit storm an attacker is attemping to induce. It all comes down to the "good guys" systems 1) being configured reasonably, and 2) being able to reject unreasonable requests. What the "bad guy" does we can't control . . . -- Dean ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Dean Willis'" ; "Jonathan Rosenberg" ; ; Sent: Wednesday, April 04, 2001 1:28 AM Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate) > > > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, March 27, 2001 4:23 PM > > To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com > > Subject: Re: [SIP] Session timer considered harmful (was RE: > > draft-ietf-sip-session- timer: refresh rate) > > > > > > > > I would suggest an even simpler approach -- guidance to > > implementors that > > suggests they implement a configuration variable to treat > > session-timer > > values below that variable's value as having that value, and > > guidance to > > operators on the tuning of that value. As session-timer is > > only intended as > > a guideline for how long state should be kept on an inactive > > call, there's > > no real harm in (beyond state preservation load) in keeping > > it a little > > longer. This allows the lower-bound in effect to be defined on a a > > per-network, per device basis and adjusted for operator requirements. > > The problem is that session timers affect the proxies and UA's in other > networks. So, if foo.com owns a gateway, and for it, a session timer of 1ms > was OK, since it uses OC-192 interface cards and a 100 processor box, other > proxies on the path may not have such compute and I/O power, in which case > 1ms is not OK for them. > > > > > > If someone's rogue UAC decides to start resending INVITES every few > > milliseconds, no specification can stop it from doing so. > > That's like trying > > to legislate rainfall . . . > > Of course. The case I am concerned about is using a regular UA, compliant to > session timer, as a point of amplification for a DoS attack. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.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. > _______________________________________________ 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 Wed Apr 4 06:28:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12745 for ; Wed, 4 Apr 2001 06:28: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 6956744373; Wed, 4 Apr 2001 06:28:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09F6344337 for ; Wed, 4 Apr 2001 06:27:37 -0400 (EDT) Received: from juanita.um.es (alu.um.es [155.54.1.248]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id MAA08991 for ; Wed, 4 Apr 2001 12:27:52 +0200 (MEST) From: jpp1@alu.um.es Received: from teo.alu.um.es (teo.dif.um.es [155.54.210.26]) by juanita.um.es (8.9.3+Sun/8.9.3) with ESMTP id KAA01546 for ; Wed, 4 Apr 2001 10:27:34 GMT Message-Id: <5.0.2.1.2.20010404122352.00a09ca0@alu.um.es> X-Sender: jpp1@alu.um.es X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Subject: [SIP] sip cgi 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: Wed, 04 Apr 2001 12:24:31 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA12745 Anyone could point me to any tutorial, examples or anything interesting about SIP CGI´s? _______________________________________________ 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 Wed Apr 4 06:42:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12901 for ; Wed, 4 Apr 2001 06:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49DEE4439B; Wed, 4 Apr 2001 06:42:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 5E5F644392 for ; Wed, 4 Apr 2001 06:41:03 -0400 (EDT) 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 f34AfqL08127; Wed, 4 Apr 2001 16:11:52 +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 f34Ans729558; Wed, 4 Apr 2001 16:19:59 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256A24.003A9303 ; Wed, 4 Apr 2001 16:09:47 +0530 X-Lotus-FromDomain: HSSBLR From: seshashayi@hss.hns.com To: jpp1@alu.um.es Cc: sip@lists.bell-labs.com Message-ID: <65256A24.003A929A.00@sampark.hss.hns.com> Subject: Re: [SIP] sip cgi Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=FSOzZzajFRunSwk3A8H1YAWqiP64ULQIUENUdnhyUy8wsgo2FVP5oaDK" Content-Disposition: inline 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: Wed, 4 Apr 2001 16:09:45 +0530 --0__=FSOzZzajFRunSwk3A8H1YAWqiP64ULQIUENUdnhyUy8wsgo2FVP5oaDK Content-type: text/plain; charset=us-ascii Content-Disposition: inline You can go through the internet draft on sip--cgi available at http://community.roxen.com/developers/idocs/drafts/draft-lennox-sip-cgi-02. txt or http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-02.txt Regds Seshu Anyone could point me to any tutorial, examples or anything interesting about SIP CGI --0__=FSOzZzajFRunSwk3A8H1YAWqiP64ULQIUENUdnhyUy8wsgo2FVP5oaDK Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =B4s? _______________________________________________ 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. = --0__=FSOzZzajFRunSwk3A8H1YAWqiP64ULQIUENUdnhyUy8wsgo2FVP5oaDK-- _______________________________________________ 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 Wed Apr 4 06:47:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13050 for ; Wed, 4 Apr 2001 06:47:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 45115443A7; Wed, 4 Apr 2001 06:47: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 D544244392 for ; Wed, 4 Apr 2001 06:46:33 -0400 (EDT) Received: from dynamicsoft.com (ip103.honxr3.ras.tele.dk [195.215.228.103]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA09059; Wed, 4 Apr 2001 06:49:57 -0400 (EDT) Message-ID: <3ACAFB84.8B11EA1@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: seshashayi@hss.hns.com Cc: jpp1@alu.um.es, sip@lists.bell-labs.com Subject: Re: [SIP] sip cgi References: <65256A24.003A929A.00@sampark.hss.hns.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: Wed, 04 Apr 2001 12:46:28 +0200 Content-Transfer-Encoding: 7bit Or you could, of course, skip the old drafts and go straight to RFC 3050 :) Anders seshashayi@hss.hns.com wrote: > > You can go through the internet draft on sip--cgi > available at > http://community.roxen.com/developers/idocs/drafts/draft-lennox-sip-cgi-02. > txt > or > http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-02.txt > > Regds > Seshu > > Anyone could point me to any tutorial, examples or anything interesting > about SIP CGI _______________________________________________ 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 Wed Apr 4 08:07:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14964 for ; Wed, 4 Apr 2001 08:07:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 963F444392; Wed, 4 Apr 2001 08:07:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from unimur.um.es (unimur.um.es [155.54.1.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DA0644337 for ; Wed, 4 Apr 2001 08:06:01 -0400 (EDT) Received: from juanita.um.es (alu.um.es [155.54.1.248]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id OAA12035 for ; Wed, 4 Apr 2001 14:06:16 +0200 (MEST) From: jpp1@alu.um.es Received: from teo.alu.um.es (teo.dif.um.es [155.54.210.26]) by juanita.um.es (8.9.3+Sun/8.9.3) with ESMTP id MAA04870 for ; Wed, 4 Apr 2001 12:05:59 GMT Message-Id: <5.0.2.1.2.20010404135806.00a11a40@alu.um.es> X-Sender: jpp1@alu.um.es X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Subject: [SIP] sip cgi (2) 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: Wed, 04 Apr 2001 14:02:56 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14964 I ´ve already read RFC 3050, but thanks anyway. I´d like to get links to people who are working on that or examples of SIP scripts cos my intention is to write a simple SIP CGI script for the Columbia University SIP server. Thanks in advance, Javier _______________________________________________ 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 Wed Apr 4 08:37:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16064 for ; Wed, 4 Apr 2001 08:37:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF2C2443A8; Wed, 4 Apr 2001 08:37:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hrtades6.atea.be (mailhost2.atea.be [194.78.143.126]) by lists.bell-labs.com (Postfix) with ESMTP id 5D2A644383 for ; Wed, 4 Apr 2001 05:00:02 -0400 (EDT) Received: from hrtades3.atea.be (siemens.atea.be [139.10.143.68]) by hrtades6.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FP0W8CQT; Wed, 4 Apr 2001 10:59:12 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id <21D19Z98>; Wed, 4 Apr 2001 10:59:31 +0200 Message-ID: From: Coene Lode To: "'sigtran@standards.nortelnetworks.com'" , sigtran Cc: "Fairlie-Cuninghame, Robert" , "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" , sigtran@marvin.corpeast.baynetworks.com, Coene Lode Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Wed, 4 Apr 2001 10:59:22 +0200 Well, I agree with the points made in the paper(certainly the conclusion that SCTP is best used between SIP entities that handle large amounts of traffics(example proxy-gateway)) The case is indeed wmuch weaker for low amounts of traffic between user agen and proxy). They have made the point. Enough said. > -----Original Message----- > From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com] > Sent: dinsdag 3 april 2001 22:42 > To: sigtran > Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege'; > sip@lists.bell-labs.com; tsvwg@ietf.org; 'Jonathan Rosenberg'; > sigtran@marvin.corpeast.baynetworks.com; loede.coene@SIEMENS.ATEA.BE > Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP > > > BTW, I'm suggesting we might incorporate some of the points > made in Gonzalo's paper, e.g., use of unordered service for > applications that do their own message correlation, ability > to do transport level fragmentation, etc., not the overall > conclusion of whether to use SCTP for SIP, which is out of scope. This suggestion in gladly taken into account (as Scot mentioned something about seeing something about UDP also in the draft). I'll try to hammer out something along those lines later this day or tomorrow. In the mean time, Thank you to Gonzalo and his coauthors. > > Cheers, > > Lyndon BTW Lyndon, that Loede guy showed up once again in the mail header. :-) > -- > > On Tue, 03 Apr 2001 22:19:11 Gonzalo Camarillo wrote: > >Hello, > > > >You can check the following link out: > >http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf > > > >It compares advantages and disadvantages of using a single unordered > >stream over using multiple ordered streams to transport SIP. > > > >Best regards, > > > >Gonzalo > > yours sincerly, Lode Siemens Atea ICN D CS D Software Development Atealaan 34 B-2200 Herentals Belgium Tel +32-14-25-2081 / Fax +32-14-25-3212 E-mail: lode.coene@siemens.atea.be _______________________________________________ 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 Wed Apr 4 08:56:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16887 for ; Wed, 4 Apr 2001 08:56:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0456C443CD; Wed, 4 Apr 2001 08:56:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 64F01443CC for ; Wed, 4 Apr 2001 08:55:12 -0400 (EDT) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id SAA20209 for ; Wed, 4 Apr 2001 18:35:02 GMT Received: from ranjith ([10.200.0.141]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GB9QIQ00.MR3; Wed, 4 Apr 2001 18:24:26 +0530 Received: by localhost with Microsoft MAPI; Wed, 4 Apr 2001 18:27:22 -0000 Message-ID: <01C0BD34.E3F92940.ranjith.mukundan@wipro.com> From: "RANJITH MUKUNDAN" Reply-To: "ranjith.mukundan@wipro.com" To: "'Coene Lode'" , "'sigtran@standards.nortelnetworks.com'" , sigtran Cc: "Fairlie-Cuninghame Robert" , "'Matt Holdrege'" , "sip@lists.bell-labs.com" , "tsvwg@ietf.org" , "'Jonathan Rosenberg'" , "sigtran@marvin.corpeast.baynetworks.com" Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP Organization: Wipro X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 87 TEXT 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: Wed, 4 Apr 2001 18:27:21 -0000 ..but isn't there an mechanism/option to toggle between transport(sctp/udp...) on a per service basis OR based on the traffic characteristics available at the servers (OAM parms) for new sessions? thanks, ranjith.. -----Original Message----- From: Coene Lode [SMTP:Lode.Coene@siemens.atea.be] Sent: Wednesday, April 04, 2001 2:29 PM To: 'sigtran@standards.nortelnetworks.com'; sigtran Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege'; sip@lists.bell-labs.com; tsvwg@ietf.org; 'Jonathan Rosenberg'; sigtran@marvin.corpeast.baynetworks.com; Coene Lode Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP Well, I agree with the points made in the paper(certainly the conclusion that SCTP is best used between SIP entities that handle large amounts of traffics(example proxy-gateway)) The case is indeed wmuch weaker for low amounts of traffic between user agen and proxy). They have made the point. Enough said. > -----Original Message----- > From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com] > Sent: dinsdag 3 april 2001 22:42 > To: sigtran > Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege'; > sip@lists.bell-labs.com; tsvwg@ietf.org; 'Jonathan Rosenberg'; > sigtran@marvin.corpeast.baynetworks.com; loede.coene@SIEMENS.ATEA.BE > Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP > > > BTW, I'm suggesting we might incorporate some of the points > made in Gonzalo's paper, e.g., use of unordered service for > applications that do their own message correlation, ability > to do transport level fragmentation, etc., not the overall > conclusion of whether to use SCTP for SIP, which is out of scope. This suggestion in gladly taken into account (as Scot mentioned something about seeing something about UDP also in the draft). I'll try to hammer out something along those lines later this day or tomorrow. In the mean time, Thank you to Gonzalo and his coauthors. > > Cheers, > > Lyndon BTW Lyndon, that Loede guy showed up once again in the mail header. :-) > -- > > On Tue, 03 Apr 2001 22:19:11 Gonzalo Camarillo wrote: > >Hello, > > > >You can check the following link out: > >http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf > > > >It compares advantages and disadvantages of using a single unordered > >stream over using multiple ordered streams to transport SIP. > > > >Best regards, > > > >Gonzalo > > yours sincerly, Lode Siemens Atea ICN D CS D Software Development Atealaan 34 B-2200 Herentals Belgium Tel +32-14-25-2081 / Fax +32-14-25-3212 E-mail: lode.coene@siemens.atea.be _______________________________________________ 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 Wed Apr 4 09:03:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17247 for ; Wed, 4 Apr 2001 09:03: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 6C542443D6; Wed, 4 Apr 2001 08:59:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A589D443D5 for ; Wed, 4 Apr 2001 08:58:51 -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 IAA21100; Wed, 4 Apr 2001 08:58:51 -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 IAA28506; Wed, 4 Apr 2001 08:58:50 -0400 (EDT) Message-ID: <3ACB1A69.F7960E60@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'bidulock@openss7.org'" , "'Roy, Radhika R, ALCOO'" , Michael Thomas , sip@lists.bell-labs.com Subject: Re: [SIP] Response if user not registered? 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: Wed, 04 Apr 2001 08:58:17 -0400 Content-Transfer-Encoding: 7bit > Well, to be honest, if I could do SIP over again from scratch, I would make > this a separate protocol. It more or less is, being an exception to a whole > bunch of rules as it stands now anyway. Beyond addressing and Contact? > > That aside, I still find the process of assigning an S-CSCF at registration > to be a funny thing. I agree completely that you will ultimately want to > segment the servers in your domain, with users being assigned to a specific > server. THis segmentation is a common practice today, even, in email > systems. However, there, they make the segmentations algorithmic in nature. > I believe its common to assign users to mail servers based on the first > letter of their username. The algorithmic mappings are a lot easier to deal > with, and don't require any of these additional databases to hold the "user > to S-CSCF" mappings themselves. The problem is that it is hard to convey the algorithmic mapping to users. DHCP is specific to a device, not a user (and doesn't work for remote configuration). So, you need *some* means of proxying registrations based on registration identity. Since you want to be able to change the number of servers without re-assigning users, doing this dynamically is also helpful. Most email servers I know of (AOL being an exception) just do randomized load balancing, with a common datastore across all of them. I agree with Jonathan that a database seems overkill. You want something that is static and very fast, so that you don't run into scaling problems on the lookup side. Since fine-grained allocation of users makes no sense, I believe 3GPP (if it needs to specify this at all, given that it's a local implementation issue), should just have a magic mapping function, which can translate either into "twenty-six entry in-memory table based on first letter of user name" or "triple-redundant database running on a cluster of mainframes". However, for redundancy, it is also not clear that having segregated servers (by address or some fancy database) works well. You would have to propagate registration information to all other servers in any event, in which case you might as well have a single back-end database and a bunch of randomly picked servers that handle the front-end processing. One case might be if the subscriber transaction volume is too large for a single database, so that you need a number of such clusters. > > Perhaps someone can clarify for me why it was decided to do it this way in > 3gpp. > > -Jonathan R. > _______________________________________________ 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 Wed Apr 4 10:05:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19738 for ; Wed, 4 Apr 2001 10:05: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 26C39443B8; Wed, 4 Apr 2001 10:05:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id B9EF344337 for ; Wed, 4 Apr 2001 09:46:47 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 4 Apr 2001 08:29:57 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Apr 2001 08:35:08 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411B0F@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'Baniel Uri-CUB001'" , "'Bob Penfield'" , Jonathan Rosenberg , "'Dean Willis'" , bidulock@openss7.org Cc: "'Romeo Zwart'" , "'Stephen Terrill'" , Igor Slepchin , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BD0C.0AD607F0" X-Orig: 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: Wed, 4 Apr 2001 08:34:58 -0500 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_01C0BD0C.0AD607F0 Content-Type: text/plain; charset="iso-8859-1" Uri, Interesting! sorry for being a little dense - what exactly are you looking to push in 3GPP? I ask because the implicit registration stuff (see my original email) is already in 3GPP via a contribution from Nokia. (By the way I did get the joke - the first time!). Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Tuesday, April 03, 2001 5:11 PM To: 'Bob Penfield'; Jonathan Rosenberg; Baniel Uri-CUB001; 'Dean Willis'; bidulock@openss7.org Cc: Parameswar, Sriram [NGB:B658:EXCH]; 'Romeo Zwart'; 'Stephen Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip Subject: RE: [SIP] Informing UA after network initiated deregistration? Bob I think I said it already, but just in case, I totally agree! Another way of doing it is per Jonathan's suggestion, which is... any other way, which would not affect the existing spec. Specifically in a world of subscriptions and users/subscribers profiles (such as for instance the cellular 3G world) the subscription for notification in the event of unregisteration (deregistration in the 3GPP Nomen clature) may be done in profile update time, for instance when the admin happens to be also your local neighborhood bar tender. (No one has laughed before, so I have no choice but to repeat my silly joke) I am trying to push this (with Bonnie Chen and Mimi Xu) through the 3GPP channels, so there will be alignment with the 'pure' SIP. Thanks, Uri. =========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Monday, April 02, 2001 12:46 PM > To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; 'Dean Willis'; > bidulock@openss7.org > Cc: Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; Igor > Slepchin; > 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip > Subject: Re: [SIP] Informing UA after network initiated > deregistration? > > > I don't think that it is necessary to add more headers. The > Event header > should be used for implicit subscription just like it is used > for explicit > subscriptions. > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > (781) 933-6166 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "'Baniel Uri-CUB001'" ; "'Dean Willis'" > ; > Cc: "'Bob Penfield'" ; "Sriram Parameswar" > ; "'Romeo Zwart'" ; > "'Stephen Terrill'" ; "Igor Slepchin" > ; "'William Marshall'" > ; > "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" > ; "sip" > Sent: Monday, April 02, 2001 3:36 AM > Subject: RE: [SIP] Informing UA after network initiated > deregistration? > > > > > > > > > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > > Sent: Sunday, April 01, 2001 9:34 AM > > > To: 'Dean Willis'; bidulock@openss7.org > > > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > > > 'Romeo Zwart'; > > > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > > > Bonnie-BCHEN1; Xu Lang-LXU1; sip > > > Subject: RE: [SIP] Informing UA after network initiated > > > deregistration? > > > > > > [4]My understanding is that in Minneapolis it has been > > > decided/approved to > > > Inform a UA after network initiated deregistration. My > > > questions to you guys > > > are: > > > [4.1] Has it been decided to go for implicit subscription for > > > notification > > > in the Registration request? or to specify it in a > dedicated header? > > > > More headers in registrations. I love it. When are we going > to get the "by > > the way, I am interested in knowing when I have exactly 15 > dollars left > in > > my account, the one I set up with Mastercard". I propose: > > > > Mastercard-Balance-Subscription: 15;currency=dollar > > > > Just in case there are those who like this idea (and since > sarcasm by > email > > is sometimes missed) - no, we are NOT having a new header in > registrations. > > > > Some have debated whether or not the presence spec allows > or disallows > > "implicit" registrations. This fits into the growing > category of things > that > > "the SIP spec doesn't, nor shouldn't, say". SIP for > presence specifies a > way > > to create subscriptions, and a way to generate notifications for > > subscriptions. It does not say that when you build a > system, the ONLY way > to > > get subscriptions in there is to use the SUBSRIBE method. I > think a web > form > > is a perfectly fine way to create subscriptions. We then use our > > notification mechanisms to generate notifies for them. How > the lifetimes > of > > these subscriptions are managed is also an implementation issue. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.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. > > > > > _______________________________________________ > 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_01C0BD0C.0AD607F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Informing UA after network initiated = deregistration?

Uri,

Interesting! sorry for being a little dense - what = exactly are you looking to push in 3GPP? I ask because the implicit = registration stuff (see my original email) is already in 3GPP via a = contribution from Nokia. (By the way I did get the joke - the first = time!).

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
Sent: Tuesday, April 03, 2001 5:11 PM
To: 'Bob Penfield'; Jonathan Rosenberg; Baniel = Uri-CUB001; 'Dean
Willis'; bidulock@openss7.org
Cc: Parameswar, Sriram [NGB:B658:EXCH]; 'Romeo = Zwart'; 'Stephen
Terrill'; Igor Slepchin; 'William Marshall'; Chen = Bonnie-BCHEN1; Xu
Lang-LXU1; sip
Subject: RE: [SIP] Informing UA after network = initiated deregistration?


Bob

I think I said it already, but just in case, I = totally agree!
Another way of doing it is per Jonathan's = suggestion, which is... any other
way, which would not affect the existing = spec.
Specifically in a world of subscriptions and = users/subscribers profiles
(such as for instance the cellular 3G world) the = subscription for
notification in the event of unregisteration = (deregistration in the 3GPP
Nomen clature) may be done in profile update time, = for instance when the
admin happens to be also your local neighborhood bar = tender. (No one has
laughed before, so I have no choice but to repeat my = silly joke)

I am trying to push this (with Bonnie Chen and Mimi = Xu) through the 3GPP
channels, so there will be alignment with the 'pure' = SIP.

Thanks,

Uri.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Uri.Baniel@motorola.com,
Tel: (847) 632 4616; Fax: (847) 632 3963;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> Sent: Monday, April 02, 2001 12:46 PM
> To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; = 'Dean Willis';
> bidulock@openss7.org
> Cc: Sriram Parameswar; 'Romeo Zwart'; 'Stephen = Terrill'; Igor
> Slepchin;
> 'William Marshall'; Chen Bonnie-BCHEN1; Xu = Lang-LXU1; sip
> Subject: Re: [SIP] Informing UA after network = initiated
> deregistration?
>
>
> I don't think that it is necessary to add more = headers. The
> Event header
> should be used for implicit subscription just = like it is used
> for explicit
> subscriptions.
>
> Bob
> d:-)
>
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> (781) 933-6166
> bpenfield@acmepacket.com
>
> ----- Original Message -----
> From: "Jonathan Rosenberg" = <jdrosen@dynamicsoft.com>
> To: "'Baniel Uri-CUB001'" = <Uri.Baniel@motorola.com>; "'Dean Willis'"
> <dean.willis@softarmor.com>; = <bidulock@openss7.org>
> Cc: "'Bob Penfield'" = <bpenfield@acmepacket.com>; "Sriram Parameswar"
> <sriramp@nortelnetworks.com>; = "'Romeo Zwart'" <Romeo.Zwart@att.com>;
> "'Stephen Terrill'" = <stephen.terrill@ericsson.com>; "Igor Slepchin"
> <ISlepchin@dynamicsoft.com>; = "'William Marshall'"
> <wtm@research.att.com>;
> "Chen Bonnie-BCHEN1" = <BCHEN1@motorola.com>; "Xu Lang-LXU1"
> <Mimi.Xu@motorola.com>; "sip" = <sip@lists.bell-labs.com>
> Sent: Monday, April 02, 2001 3:36 AM
> Subject: RE: [SIP] Informing UA after network = initiated
> deregistration?
>
>
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> > > Sent: Sunday, April 01, 2001 9:34 = AM
> > > To: 'Dean Willis'; = bidulock@openss7.org
> > > Cc: Baniel Uri-CUB001; 'Bob = Penfield'; Sriram Parameswar;
> > > 'Romeo Zwart';
> > > 'Stephen Terrill'; 'Igor Slepchin'; = 'William Marshall'; Chen
> > > Bonnie-BCHEN1; Xu Lang-LXU1; = sip
> > > Subject: RE: [SIP] Informing UA after = network initiated
> > > deregistration?
> > >
> > > [4]My understanding is that in = Minneapolis it has been
> > > decided/approved to
> > > Inform a UA after network initiated = deregistration. My
> > > questions to you guys
> > > are:
> > > [4.1] Has it been decided to go for = implicit subscription for
> > > notification
> > > in the Registration request? or to = specify it in a
> dedicated header?
> >
> > More headers in registrations. I love it. = When are we going
> to get the "by
> > the way, I am interested in knowing when I = have exactly  15
> dollars left
> in
> > my account, the one I set up with = Mastercard". I propose:
> >
> > Mastercard-Balance-Subscription: = 15;currency=3Ddollar
> >
> > Just in case there are those who like this = idea (and since
> sarcasm by
> email
> > is sometimes missed) - no, we are NOT = having a new header in
> registrations.
> >
> > Some have debated whether or not the = presence spec allows
> or disallows
> > "implicit" registrations. This = fits into the growing
> category of things
> that
> > "the SIP spec doesn't, nor shouldn't, = say". SIP for
> presence specifies a
> way
> > to create subscriptions, and a way to = generate notifications for
> > subscriptions. It does not say that when = you build a
> system, the ONLY way
> to
> > get subscriptions in there is to use the = SUBSRIBE method. I
> think a web
> form
> > is a perfectly fine way to create = subscriptions. We then use our
> > notification mechanisms to generate = notifies for them. How
> the lifetimes
> of
> > these subscriptions are managed is also an = implementation issue.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> > http://www.dynamicsoft.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.
> >
>
>
> = _______________________________________________
> 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_01C0BD0C.0AD607F0-- _______________________________________________ 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 Wed Apr 4 10:08:19 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19942 for ; Wed, 4 Apr 2001 10:08: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 4FF7A443D3; Wed, 4 Apr 2001 10:06: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 0D2D8443D1 for ; Wed, 4 Apr 2001 10:05:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA10791; Wed, 4 Apr 2001 10:08:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 10:04:58 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , Jonathan Rosenberg , brett@broadsoft.com, sip@lists.bell-labs.com Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-si p-session- timer: refresh rate) 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: Wed, 4 Apr 2001 10:04:57 -0400 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 04, 2001 3:16 AM > To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com > Subject: Re: [SIP] Session timer considered harmful (was RE: > draft-ietf-sip-session- timer: refresh rate) > > > > Yes, but if each of the proxies along the path knows what its > safe "lower > bound" on retransmits is and refuses to pass a session timer > with a value > lower than the safety threshold, the attack can be avoided. > This isn't a > protocol change. No, thats not true. Consider the case of: UA1 -> P1 -> P2 -> P3 -> UA2 UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it too low. P2 increases it. Now the request goes to P3, which reduces it to an even lower value. This is forwarded to UA2, which reflects it in the response, and its forwarded upstream towards UA1. I guess P2 could discard the response, but thats not really a good thing, since the transaction will end up timing out. Even then, rogue P1 could reduce the timer value in the response once its passed P2. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.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@lists.bell-labs.com Wed Apr 4 10:21:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20527 for ; Wed, 4 Apr 2001 10:21:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC74C443E4; Wed, 4 Apr 2001 10:21:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr2.ericy.com (unknown [12.34.240.68]) by lists.bell-labs.com (Postfix) with ESMTP id 12630443E3 for ; Wed, 4 Apr 2001 10:20:20 -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 f34EKJ810368 for ; Wed, 4 Apr 2001 09:20:19 -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 f34EKJa09307 for ; Wed, 4 Apr 2001 09:20:19 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Apr 04 09:20:18 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <21WLNSTJ>; Wed, 4 Apr 2001 09:20:18 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'brett@broadsoft.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Response if user not registered? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BD12.5ECD55B0" 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: Wed, 4 Apr 2001 09:20:16 -0500 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_01C0BD12.5ECD55B0 Content-Type: text/plain; charset="iso-8859-1" >> I believe this issue in 3gpp arises because for them, they >> have "extended" >> register to do more than create bindings. They use it to >> assign the proxy >> which will handle both incoming and outgoing calls for the user, and >> basically do not allow outgoing calls until such a selection >> is made. This is incorrect. The REGISTER process in 3GPP is used for address bindings. The selection of a local outbound proxy is done BEFORE the registration occurs. Barring an outbound request because a terminal is not registered at the local outbound proxy is a reasonable thing to do. Letting the user know that this is the case is also a reasonable thing to do. 403 seems appropriate. /sean ------_=_NextPart_001_01C0BD12.5ECD55B0 Content-Type: text/html; charset="iso-8859-1" RE: [SIP] Response if user not registered?

>> I believe this issue in 3gpp arises because for them, they
>> have "extended"
>> register to do more than create bindings. They use it to
>> assign the proxy
>> which will handle both incoming and outgoing calls for the user, and
>> basically do not allow outgoing calls until such a selection
>> is made.

This is incorrect. The REGISTER process in 3GPP is used
for address bindings. The selection of a local outbound
proxy is done BEFORE the registration occurs. Barring
an outbound request because a terminal is not registered
at the local outbound proxy is a reasonable thing to do.
Letting the user know that this is the case is also
a reasonable thing to do. 403 seems appropriate.

/sean

------_=_NextPart_001_01C0BD12.5ECD55B0-- _______________________________________________ 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 Wed Apr 4 10:36:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21044 for ; Wed, 4 Apr 2001 10:36:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70A4E44348; Wed, 4 Apr 2001 10:36:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id 844BC44339 for ; Wed, 4 Apr 2001 10:35:20 -0400 (EDT) Received: from DDCW6701 [63.113.183.106] by edgeconnect.com with ESMTP (SMTPD32-6.06) id AE7012B00140; Wed, 04 Apr 2001 07:23:44 -0700 From: "Victor A Paulsamy" To: "Gonzalo Camarillo" Cc: "SIP" , "Victor A Paulsamy" Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3ACA1DF3.AA201298@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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: Wed, 4 Apr 2001 10:37:35 -0400 Content-Transfer-Encoding: 7bit Hi, > Gonzalo Camarillo wrote: > >It is called change of codec on-the-fly, and you have the RTP payload >for that. Where can I find this and available literature? Thanks in advance. Warm regards, --victor _______________________________________________ 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 Wed Apr 4 10:50:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21518 for ; Wed, 4 Apr 2001 10:50:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6439D443E0; Wed, 4 Apr 2001 10:50:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28]) by lists.bell-labs.com (Postfix) with SMTP id 67AAF443D0 for ; Wed, 4 Apr 2001 10:49:06 -0400 (EDT) Message-ID: <20010404144905.38976.qmail@web13902.mail.yahoo.com> Received: from [149.112.117.3] by web13902.mail.yahoo.com; Wed, 04 Apr 2001 07:49:05 PDT From: aravindan shanmugam Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal To: Shan Lu , sip In-Reply-To: <3ACA2FA1.4030803@nextone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 4 Apr 2001 07:49:05 -0700 (PDT) Hi, Handling different packet size is not a difficult problem as long as the packet size is an integer multiple of codec frame size. Let us not add more variables to the problem. Making DTMF, CN etc. as separate streams will create more issues with many existing systems. Aravindan --- Shan Lu wrote: > Hi, > > Before we come up with any solution, let's first > understand what the > problems are and what we want out of SDP. > > Problems: > > When more than more audio codecs are listed in "m=" > line, SDP lacks > mechanism to indicate: > 1. sendrecv, sendonly, or recvonly for each codec; > 2. packetization size supported for each codec ; > 3. simultaneous capabilities. (e.g., a UA can > support audio codecs A, B, > and C, but when video codec X is used, can only > support audio codec A.) > > Desirable functions of SDP: > > 1. To indicate to the other side the full > capabilities of a UA > 2. To indicate to the other side the media types > (codec, pack. size, > uni. or bi-directional) that will be used for a > particular session in an > unequivocal way. > > As an implementor, I can testify firsthand that I > can not appreciate the > last point enough. Here is why: In the real world, > most DSP based codec > implementations can ONLY support symmetric > operation. If tx uses codec > A, rx must also use codec A. So if the first SDP > (INVITE or 200 OK) > lists codecs A, B and C, and second SDP (200 OK or > ACK) responds with > codecs A and B, one UA may start use codec A and the > other may pick > codec B, which results in either dead silence or > garbled speech. We have > seen this happen at the bake-offs. > > And packetization size is another issue. Take G.729 > for example. The > base frame size is 10ms. But due to resource > restrictions, many > implementations can only support a fixed, integer > multiple of the base > frame, say 20ms or 30 ms. On some implementations, > packetization size is > either a runtime or configuration parameter. In any > case, a 20 ms won't > talk to 30 ms G.729. We heard quite a few distorted > conversations > because of codec size mismatch at SIP bake-offs and > at H323 > Interoperability Events. > > Hence, I'd like to propose the following: > > 1. Assume all audio codecs (not including DTMF) are > send and recv, and > require symmetric operation; > 2. Originating SDP lists packetization size for each > codec unless > default value is used; > 3. If supported, origination SDP lists explicitly > whether DTMF is send > or recv, with sendrecv being default; > 4. Responding SDP lists one and ONLY one codec for > each media (if, of > course, there exists overlap) and, when applicable, > includes > packetization size and send/recv attribute; > 5. The side that originates SDP uses OPTIONS to > query the other side's > capability after call setup, if necessary. > > Example: UA1 supports codecs A (20ms), B (30ms), and > C (20ms), and can > transmit and recv DTMF; UA2 supports codecs A(10 > ms), B (30ms), and D( > 20ms) and can transmit DTMF (but not recv). Here's > the SDP exchange: > > UA1->UA2 (INVITE) > > m=audio 40000 RTP/AVP 100 101 102 > a=rtpmap: 100 A/8000 > a=ptime: 20 > a=rtpmap:101 B/8000 > a=ptime: 30 > a=rtpmap:102 C/8000 > a=ptime: 20 > m=audio 40000 RTP/AVP 103 > a=fmtp:103 0-15 > a=sendrecv > > UA2->UA1 (200 OK) > m=audio 30000 RTP/AVP 101 > a=rtpmap:101 B/8000 > a=ptime: 30 > m=audio 30000 RTP/AVP 103 > a=fmtp:103 0-15 > a=sendonly > > Note that there are two "m=" lines in each SDP > because the DTMF and > codec are really simultaneous capabilities. The > usage of "a=ptime" is a > little bit stretch here at codec level and may cause > problem for > existing implementations. But I haven't seen it used > very much. > > Regards, > > Shan Lu > > NexTone Communications > > Gonzalo Camarillo wrote: > > > Hello, > > > > There have been already several mails showing > certain confusion about > > SDP usage in SIP. > > In the last IETF the conclusion was: > > For sendrecv flows (uni-directional flows are > easy), the caller puts in > > the INVITe the codecs that he can both send AND > receive. > > > > The open issue is what the callee returns: > > 1) a sub-set of the codecs listed in the INVITE > that he can send AND > > receive. > > 2) all the codecs that he can send AND receive. > > > > Note that caller and callee have reversed roles if > the SDP from the > > client to the server is sent in the ACK instead of > in the INVITE. > > > > I would like to ask folks not to mix this open > issue with another > > similar issue: I have a DSP that cannot change > codecs on-the-fly, and I > > want to pick up just one codec. Let us discuss > this issue at other time. > > > > My proposal is to go for solution number 2. This > gives a symmetrical > > negotiation. Besides, it covers more cases than > solution number 1). It > > can happen that for a particular codec, the callee > can send AND receive > > it but the caller can just send it. Therefore, the > caller does not > > include it in the INVITE. However, if the callee > lists it in the 200 OK, > > the caller will be able to send it. > > > > Opinions? > > > > Gonzalo > > > > _______________________________________________ > 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. __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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@lists.bell-labs.com Wed Apr 4 11:20:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22793 for ; Wed, 4 Apr 2001 11:20:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3195044397; Wed, 4 Apr 2001 11:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id CBA2E443F4 for ; Wed, 4 Apr 2001 10:52:16 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA10980 for ; Wed, 4 Apr 2001 07:52:16 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA06328 for ; Wed, 4 Apr 2001 07:52:15 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Wed, 4 Apr 2001 09:52:15 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B451FA@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Sriram Parameswar'" , Baniel Uri-CUB001 , "'Bob Penfield'" , Jonathan Rosenberg , "'Dean Willis'" , bidulock@openss7.org Cc: "'Romeo Zwart'" , "'Stephen Terrill'" , Igor Slepchin , "'William Marshall'" , Chen Bonnie-BCHEN1 , Xu Lang-LXU1 , sip Subject: RE: [SIP] Informing UA after network initiated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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: Wed, 4 Apr 2001 09:52:13 -0500 Well, sadly I am not perfectly familiar with the spec process, but there were few things there I did not like in the Nokia contribution, and I am proposing some changes. I think Nortel customers would be happier as well if they get a product, which is based on specifications, which make sense. Bonnie is our spec person, and she is the one who will make sure that things which should be heard and viewed will. I am aware of having a well organized process for contributions, reviews etc. Thus I am trying to get my proposals via this process with Bonnie's help. Uri ========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Wednesday, April 04, 2001 8:35 AM To: 'Baniel Uri-CUB001'; 'Bob Penfield'; Jonathan Rosenberg; 'Dean Willis'; bidulock@openss7.org Cc: 'Romeo Zwart'; 'Stephen Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip Subject: RE: [SIP] Informing UA after network initiated deregistration? Uri, Interesting! sorry for being a little dense - what exactly are you looking to push in 3GPP? I ask because the implicit registration stuff (see my original email) is already in 3GPP via a contribution from Nokia. (By the way I did get the joke - the first time!). Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Baniel Uri-CUB001 [ mailto:Uri.Baniel@motorola.com ] Sent: Tuesday, April 03, 2001 5:11 PM To: 'Bob Penfield'; Jonathan Rosenberg; Baniel Uri-CUB001; 'Dean Willis'; bidulock@openss7.org Cc: Parameswar, Sriram [NGB:B658:EXCH]; 'Romeo Zwart'; 'Stephen Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip Subject: RE: [SIP] Informing UA after network initiated deregistration? Bob I think I said it already, but just in case, I totally agree! Another way of doing it is per Jonathan's suggestion, which is... any other way, which would not affect the existing spec. Specifically in a world of subscriptions and users/subscribers profiles (such as for instance the cellular 3G world) the subscription for notification in the event of unregisteration (deregistration in the 3GPP Nomen clature) may be done in profile update time, for instance when the admin happens to be also your local neighborhood bar tender. (No one has laughed before, so I have no choice but to repeat my silly joke) I am trying to push this (with Bonnie Chen and Mimi Xu) through the 3GPP channels, so there will be alignment with the 'pure' SIP. Thanks, Uri. =========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== > -----Original Message----- > From: Bob Penfield [ mailto:bpenfield@acmepacket.com ] > Sent: Monday, April 02, 2001 12:46 PM > To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; 'Dean Willis'; > bidulock@openss7.org > Cc: Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; Igor > Slepchin; > 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip > Subject: Re: [SIP] Informing UA after network initiated > deregistration? > > > I don't think that it is necessary to add more headers. The > Event header > should be used for implicit subscription just like it is used > for explicit > subscriptions. > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > (781) 933-6166 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "'Baniel Uri-CUB001'" ; "'Dean Willis'" > ; > Cc: "'Bob Penfield'" ; "Sriram Parameswar" > ; "'Romeo Zwart'" ; > "'Stephen Terrill'" ; "Igor Slepchin" > ; "'William Marshall'" > ; > "Chen Bonnie-BCHEN1" ; "Xu Lang-LXU1" > ; "sip" > Sent: Monday, April 02, 2001 3:36 AM > Subject: RE: [SIP] Informing UA after network initiated > deregistration? > > > > > > > > > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [ mailto:Uri.Baniel@motorola.com ] > > > Sent: Sunday, April 01, 2001 9:34 AM > > > To: 'Dean Willis'; bidulock@openss7.org > > > Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; > > > 'Romeo Zwart'; > > > 'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen > > > Bonnie-BCHEN1; Xu Lang-LXU1; sip > > > Subject: RE: [SIP] Informing UA after network initiated > > > deregistration? > > > > > > [4]My understanding is that in Minneapolis it has been > > > decided/approved to > > > Inform a UA after network initiated deregistration. My > > > questions to you guys > > > are: > > > [4.1] Has it been decided to go for implicit subscription for > > > notification > > > in the Registration request? or to specify it in a > dedicated header? > > > > More headers in registrations. I love it. When are we going > to get the "by > > the way, I am interested in knowing when I have exactly 15 > dollars left > in > > my account, the one I set up with Mastercard". I propose: > > > > Mastercard-Balance-Subscription: 15;currency=dollar > > > > Just in case there are those who like this idea (and since > sarcasm by > email > > is sometimes missed) - no, we are NOT having a new header in > registrations. > > > > Some have debated whether or not the presence spec allows > or disallows > > "implicit" registrations. This fits into the growing > category of things > that > > "the SIP spec doesn't, nor shouldn't, say". SIP for > presence specifies a > way > > to create subscriptions, and a way to generate notifications for > > subscriptions. It does not say that when you build a > system, the ONLY way > to > > get subscriptions in there is to use the SUBSRIBE method. I > think a web > form > > is a perfectly fine way to create subscriptions. We then use our > > notification mechanisms to generate notifies for them. How > the lifetimes > of > > these subscriptions are managed is also an implementation issue. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.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. > > > > > _______________________________________________ > 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 Wed Apr 4 12:11:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24493 for ; Wed, 4 Apr 2001 12:11:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D87EE44341; Wed, 4 Apr 2001 12:11:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by lists.bell-labs.com (Postfix) with ESMTP id 718AF44337 for ; Wed, 4 Apr 2001 11:59:34 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f34Fx4g24709; Wed, 4 Apr 2001 18:59:04 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.17608.217056.987028@lohi.eng.telia.fi> To: "Sean Olson (EUS)" Cc: "'brett@broadsoft.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Response if user not registered? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.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: Wed, 4 Apr 2001 18:59:04 +0300 (EEST) Content-Transfer-Encoding: 7bit Sean Olson (EUS) writes: > Barring > an outbound request because a terminal is not registered > at the local outbound proxy is a reasonable thing to do. no it isn't. as has been mentioned many times, sip registration is not for that kind of purpose. it must be enough that the outboud proxy is (a) able to authenticate the calling sip ua and that (b) the authenticated (and thus known) user has via subscription or otherwise the right to make outboud calls via this outbound proxy. -- juha _______________________________________________ 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 Wed Apr 4 12:22:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24766 for ; Wed, 4 Apr 2001 12:22:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B90A443CB; Wed, 4 Apr 2001 12:22:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by lists.bell-labs.com (Postfix) with ESMTP id 7738B443C7 for ; Wed, 4 Apr 2001 12:21:40 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by wellington.cnchost.com id MAA23862; Wed, 4 Apr 2001 12:21:31 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <3ACB4B5C.8090409@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: aravindan shanmugam Cc: sip Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal References: <20010404144905.38976.qmail@web13902.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------010404020402060504090003" 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: Wed, 04 Apr 2001 12:27:08 -0400 --------------010404020402060504090003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit aravindan shanmugam wrote: > Hi, > > Handling different packet size is not a difficult > problem as long as the packet size is an integer > multiple of codec frame size. Let us not add more > variables to the problem. Can you tell me how if neither side indicates the packet size ? Shan Lu > > > Making DTMF, CN etc. as separate streams will create > more issues with many existing systems. > > Aravindan > --- Shan Lu wrote: > >> Hi, >> >> Before we come up with any solution, let's first >> understand what the >> problems are and what we want out of SDP. >> >> Problems: >> >> When more than more audio codecs are listed in "m=" >> line, SDP lacks >> mechanism to indicate: >> 1. sendrecv, sendonly, or recvonly for each codec; >> 2. packetization size supported for each codec ; >> 3. simultaneous capabilities. (e.g., a UA can >> support audio codecs A, B, >> and C, but when video codec X is used, can only >> support audio codec A.) >> >> Desirable functions of SDP: >> >> 1. To indicate to the other side the full >> capabilities of a UA >> 2. To indicate to the other side the media types >> (codec, pack. size, >> uni. or bi-directional) that will be used for a >> particular session in an >> unequivocal way. >> >> As an implementor, I can testify firsthand that I >> can not appreciate the >> last point enough. Here is why: In the real world, >> most DSP based codec >> implementations can ONLY support symmetric >> operation. If tx uses codec >> A, rx must also use codec A. So if the first SDP >> (INVITE or 200 OK) >> lists codecs A, B and C, and second SDP (200 OK or >> ACK) responds with >> codecs A and B, one UA may start use codec A and the >> other may pick >> codec B, which results in either dead silence or >> garbled speech. We have >> seen this happen at the bake-offs. >> >> And packetization size is another issue. Take G.729 >> for example. The >> base frame size is 10ms. But due to resource >> restrictions, many >> implementations can only support a fixed, integer >> multiple of the base >> frame, say 20ms or 30 ms. On some implementations, >> packetization size is >> either a runtime or configuration parameter. In any >> case, a 20 ms won't >> talk to 30 ms G.729. We heard quite a few distorted >> conversations >> because of codec size mismatch at SIP bake-offs and >> at H323 >> Interoperability Events. >> >> Hence, I'd like to propose the following: >> >> 1. Assume all audio codecs (not including DTMF) are >> send and recv, and >> require symmetric operation; >> 2. Originating SDP lists packetization size for each >> codec unless >> default value is used; >> 3. If supported, origination SDP lists explicitly >> whether DTMF is send >> or recv, with sendrecv being default; >> 4. Responding SDP lists one and ONLY one codec for >> each media (if, of >> course, there exists overlap) and, when applicable, >> includes >> packetization size and send/recv attribute; >> 5. The side that originates SDP uses OPTIONS to >> query the other side's >> capability after call setup, if necessary. >> >> Example: UA1 supports codecs A (20ms), B (30ms), and >> C (20ms), and can >> transmit and recv DTMF; UA2 supports codecs A(10 >> ms), B (30ms), and D( >> 20ms) and can transmit DTMF (but not recv). Here's >> the SDP exchange: >> >> UA1->UA2 (INVITE) >> >> m=audio 40000 RTP/AVP 100 101 102 >> a=rtpmap: 100 A/8000 >> a=ptime: 20 >> a=rtpmap:101 B/8000 >> a=ptime: 30 >> a=rtpmap:102 C/8000 >> a=ptime: 20 >> m=audio 40000 RTP/AVP 103 >> a=fmtp:103 0-15 >> a=sendrecv >> >> UA2->UA1 (200 OK) >> m=audio 30000 RTP/AVP 101 >> a=rtpmap:101 B/8000 >> a=ptime: 30 >> m=audio 30000 RTP/AVP 103 >> a=fmtp:103 0-15 >> a=sendonly >> >> Note that there are two "m=" lines in each SDP >> because the DTMF and >> codec are really simultaneous capabilities. The >> usage of "a=ptime" is a >> little bit stretch here at codec level and may cause >> problem for >> existing implementations. But I haven't seen it used >> very much. >> >> Regards, >> >> Shan Lu >> >> NexTone Communications >> >> Gonzalo Camarillo wrote: >> >>> Hello, >>> >>> There have been already several mails showing >> >> certain confusion about >> >>> SDP usage in SIP. >>> In the last IETF the conclusion was: >>> For sendrecv flows (uni-directional flows are >> >> easy), the caller puts in >> >>> the INVITe the codecs that he can both send AND >> >> receive. >> >>> The open issue is what the callee returns: >>> 1) a sub-set of the codecs listed in the INVITE >> >> that he can send AND >> >>> receive. >>> 2) all the codecs that he can send AND receive. >>> >>> Note that caller and callee have reversed roles if >> >> the SDP from the >> >>> client to the server is sent in the ACK instead of >> >> in the INVITE. >> >>> I would like to ask folks not to mix this open >> >> issue with another >> >>> similar issue: I have a DSP that cannot change >> >> codecs on-the-fly, and I >> >>> want to pick up just one codec. Let us discuss >> >> this issue at other time. >> >>> My proposal is to go for solution number 2. This >> >> gives a symmetrical >> >>> negotiation. Besides, it covers more cases than >> >> solution number 1). It >> >>> can happen that for a particular codec, the callee >> >> can send AND receive >> >>> it but the caller can just send it. Therefore, the >> >> caller does not >> >>> include it in the INVITE. However, if the callee >> >> lists it in the 200 OK, >> >>> the caller will be able to send it. >>> >>> Opinions? >>> >>> Gonzalo >> >> >> >> _______________________________________________ >> 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. > > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > > --------------010404020402060504090003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

aravindan shanmugam wrote:
Hi,

Handling different packet size is not a difficult
problem as long as the packet size is an integer
multiple of codec frame size. Let us not add more
variables to the problem.
Can you tell me how if neither side indicates the packet size ?

Shan Lu


Making DTMF, CN etc. as separate streams will create
more issues with many existing systems. 

Aravindan
--- Shan Lu <slu@nextone.com> wrote:
Hi,

Before we come up with any solution, let's first
understand what the 
problems are and what we want out of SDP.

Problems:

When more than more audio codecs are listed in "m="
line, SDP lacks 
mechanism to indicate:
1. sendrecv, sendonly, or recvonly for each codec;
2. packetization size supported for each codec ;
3. simultaneous capabilities. (e.g., a UA can
support audio codecs A, B, 
and C, but when video codec X is used, can only
support audio codec A.)

Desirable functions of SDP:

1. To indicate to the other side the full
capabilities of a UA
2. To indicate to the other side the media types
(codec, pack. size, 
uni. or bi-directional) that will be used for a
particular session in an 
unequivocal way.

As an implementor, I can testify firsthand that I
can not appreciate the 
last point enough. Here is why: In the real world,
most DSP based codec 
implementations can ONLY support symmetric
operation. If tx uses codec 
A, rx must also use codec A. So if the first SDP
(INVITE or 200 OK)  
lists codecs A, B and C, and second SDP (200 OK or
ACK) responds with 
codecs A and B, one UA may start use codec A and the
other may pick 
codec B, which results in either dead silence or
garbled speech. We have 
seen this happen at the bake-offs.

And packetization size is another issue. Take G.729
for example. The 
base frame size is 10ms. But due to resource
restrictions, many 
implementations can only support a fixed, integer
multiple of the base 
frame, say 20ms or 30 ms. On some implementations,
packetization size is 
either a runtime or configuration parameter. In any
case, a 20 ms won't 
talk to 30 ms G.729. We heard quite a few distorted
conversations 
because of codec size mismatch at SIP bake-offs and
at H323 
Interoperability Events.

Hence, I'd like to propose the following:

1. Assum
e all audio codecs (not including DTMF) are
send and recv, and 
require symmetric operation;
2. Originating SDP lists packetization size for each
codec unless 
default value is used;
3. If supported, origination SDP lists explicitly
whether DTMF is send 
or recv, with sendrecv being default;
4. Responding SDP lists one and ONLY one codec for
each media (if, of 
course, there exists overlap) and, when applicable,
includes 
packetization size and send/recv attribute;
5. The side that originates SDP uses OPTIONS to
query the other side's 
capability after call setup, if necessary.

Example: UA1 supports codecs A (20ms), B (30ms), and
C (20ms), and can 
transmit and recv DTMF; UA2 supports codecs A(10
ms), B (30ms), and D( 
20ms) and can transmit DTMF (but not recv). Here's
the SDP exchange:

UA1->UA2 (INVITE)

m=audio 40000 RTP/AVP 100 101 102
a=rtpmap: 100 A/8000
a=ptime: 20
a=rtpmap:101 B/8000
a=ptime: 30
a=rtpmap:102 C/8000
a=ptime: 20
m=audio 40000 RTP/AVP 103
a=fmtp:103 0-15
a=sendrecv

UA2->UA1 (200 OK)
m=audio 30000 RTP/AVP 101
a=rtpmap:101 B/8000
a=ptime: 30
m=audio 30000 RTP/AVP 103
a=fmtp:103 0-15
a=sendonly

Note that there are two "m=" lines in each SDP
because the DTMF and 
codec are really simultaneous capabilities. The
usage of "a=ptime" is a 
little bit stretch here at codec level and may cause
problem for 
existing implementations. But I haven't seen it used
very much.

Regards,

Shan Lu

NexTone Communications

Gonzalo Camarillo wrote:

Hello,

There have been already several mails showing
certain confusion about
SDP usage in SIP.
In the last IETF the conclusion was:
For sendrecv flows (uni-directional flows are
easy), the caller puts in<
br>
the INVITe the codecs that he can both send AND
receive.
The open issue is what the callee returns:
1) a sub-set of the codecs listed in the INVITE
that he can send AND
receive.
2) all the codecs that he can send AND receive.

Note that caller and callee have reversed roles if
the SDP from the
client to the server is sent in the ACK instead of
in the INVITE.
I would like to ask folks not to mix this open
issue with another
similar issue: I have a DSP that cannot change
codecs on-the-fly, and I
want to pick up just one codec. Let us discuss
this issue at other time.
My proposal is to go for solution number 2. This
gives a symmetrical
negotiation. Besides, it covers more cases than
solution number 1). It
can happen that for a particular codec, the callee
can send AND receive
it but the caller can just send it. Therefore, the
caller does not
include it in the INVITE. However, if the callee
lists it in the 200 OK,
the caller will be able to send it.

Opinions?

Gonzalo


_______________________________________________
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.


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/




--------------010404020402060504090003-- _______________________________________________ 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 Wed Apr 4 12:40:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25358 for ; Wed, 4 Apr 2001 12:40: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 CACE5443DF; Wed, 4 Apr 2001 12:40:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hrtades6.atea.be (mailhost2.atea.be [194.78.143.126]) by lists.bell-labs.com (Postfix) with ESMTP id 0CC6E443E6 for ; Wed, 4 Apr 2001 12:31:18 -0400 (EDT) Received: from hrtades3.atea.be (siemens.atea.be [139.10.143.68]) by hrtades6.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FP0W8HKF; Wed, 4 Apr 2001 18:30:36 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id <21D10B2T>; Wed, 4 Apr 2001 18:30:55 +0200 Message-ID: From: Coene Lode To: "'ranjith.mukundan@wipro.com'" , Coene Lode , "'sigtran@standards.nortelnetworks.com'" , sigtran Cc: Fairlie-Cuninghame Robert , "'Matt Holdrege'" , sip@lists.bell-labs.com, tsvwg@ietf.org, "'Jonathan Rosenberg'" , sigtran@marvin.corpeast.baynetworks.com Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Wed, 4 Apr 2001 18:30:49 +0200 Header is getting a bit overloaded :-) See my comment below. yours sincerly, Lode Siemens Atea ICN D CS D Software Development Atealaan 34 B-2200 Herentals Belgium Tel +32-14-25-2081 / Fax +32-14-25-3212 E-mail: lode.coene@siemens.atea.be > -----Original Message----- > From: RANJITH MUKUNDAN [mailto:ranjith.mukundan@wipro.com] > Sent: woensdag 4 april 2001 20:27 > To: 'Coene Lode'; 'sigtran@standards.nortelnetworks.com'; sigtran > Cc: Fairlie-Cuninghame Robert; 'Matt Holdrege'; > sip@lists.bell-labs.com; > tsvwg@ietf.org; 'Jonathan Rosenberg'; > sigtran@marvin.corpeast.baynetworks.com > Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP > > > ..but isn't there an mechanism/option to toggle between > transport(sctp/udp...) on a per service basis OR based on the traffic > characteristics available at the servers (OAM parms) for new sessions? That looks like a implementation issue to me. In any case, there is little use in having it in one server if other servers do not support that transport protcol. Thus toggling it off or on won't make a difference. yours sincerly Lode > > thanks, > ranjith.. > > -----Original Message----- > From: Coene Lode [SMTP:Lode.Coene@siemens.atea.be] > Sent: Wednesday, April 04, 2001 2:29 PM > To: 'sigtran@standards.nortelnetworks.com'; sigtran > Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege'; > sip@lists.bell-labs.com; > tsvwg@ietf.org; 'Jonathan Rosenberg'; > sigtran@marvin.corpeast.baynetworks.com; Coene Lode > Subject: RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP > > Well, I agree with the points made in the paper(certainly the > conclusion > that SCTP is best used between SIP entities that handle large > amounts of > traffics(example proxy-gateway)) The case is indeed wmuch > weaker for low > amounts of traffic between user agen and proxy). They have > made the point. > Enough said. > > > > -----Original Message----- > > From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com] > > Sent: dinsdag 3 april 2001 22:42 > > To: sigtran > > Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege'; > > sip@lists.bell-labs.com; tsvwg@ietf.org; 'Jonathan Rosenberg'; > > sigtran@marvin.corpeast.baynetworks.com; loede.coene@SIEMENS.ATEA.BE > > Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP > > > > > > BTW, I'm suggesting we might incorporate some of the points > > made in Gonzalo's paper, e.g., use of unordered service for > > applications that do their own message correlation, ability > > to do transport level fragmentation, etc., not the overall > > conclusion of whether to use SCTP for SIP, which is out of scope. > > > This suggestion in gladly taken into account (as Scot > mentioned something > about seeing something about UDP also in the draft). I'll try > to hammer out > something along those lines later this day or tomorrow. > In the mean time, Thank you to Gonzalo and his coauthors. > > > > > > Cheers, > > > > Lyndon > > BTW Lyndon, that Loede guy showed up once again in the mail > header. :-) > > -- > > > > On Tue, 03 Apr 2001 22:19:11 Gonzalo Camarillo wrote: > > >Hello, > > > > > >You can check the following link out: > > >http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf > > > > > >It compares advantages and disadvantages of using a single > unordered > > >stream over using multiple ordered streams to transport SIP. > > > > > >Best regards, > > > > > >Gonzalo > > > > > > > yours sincerly, > Lode > > Siemens Atea ICN D CS D > Software Development > Atealaan 34 > B-2200 Herentals Belgium > Tel +32-14-25-2081 / Fax +32-14-25-3212 > E-mail: lode.coene@siemens.atea.be > > > _______________________________________________ > 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 Wed Apr 4 12:43:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25444 for ; Wed, 4 Apr 2001 12:43:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C59E9443F5; Wed, 4 Apr 2001 12:43:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com [216.136.175.29]) by lists.bell-labs.com (Postfix) with SMTP id 51A30443F0 for ; Wed, 4 Apr 2001 12:42:03 -0400 (EDT) Message-ID: <20010404164202.30724.qmail@web13903.mail.yahoo.com> Received: from [149.112.117.3] by web13903.mail.yahoo.com; Wed, 04 Apr 2001 09:42:02 PDT From: aravindan shanmugam Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal To: Shan Lu Cc: sip In-Reply-To: <3ACB4B5C.8090409@nextone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 4 Apr 2001 09:42:02 -0700 (PDT) --- Shan Lu wrote: > > > aravindan shanmugam wrote: > > > Hi, > > > > Handling different packet size is not a difficult > > problem as long as the packet size is an integer > > multiple of codec frame size. Let us not add more > > variables to the problem. > > Can you tell me how if neither side indicates the > packet size ? > > Shan Lu > You know the payload size of RTP packet when you receive a packet after protocol processing and you know the codec frame size from the codec type. Thus, you can estimate the number of codec frames in the packet. For more details refer to draft-ietf-avt-profile document. Aravindan > > > > > > Making DTMF, CN etc. as separate streams will > create > > more issues with many existing systems. > > > > Aravindan > > --- Shan Lu wrote: > > > >> Hi, > >> > >> Before we come up with any solution, let's first > >> understand what the > >> problems are and what we want out of SDP. > >> > >> Problems: > >> > >> When more than more audio codecs are listed in > "m=" > >> line, SDP lacks > >> mechanism to indicate: > >> 1. sendrecv, sendonly, or recvonly for each > codec; > >> 2. packetization size supported for each codec ; > >> 3. simultaneous capabilities. (e.g., a UA can > >> support audio codecs A, B, > >> and C, but when video codec X is used, can only > >> support audio codec A.) > >> > >> Desirable functions of SDP: > >> > >> 1. To indicate to the other side the full > >> capabilities of a UA > >> 2. To indicate to the other side the media types > >> (codec, pack. size, > >> uni. or bi-directional) that will be used for a > >> particular session in an > >> unequivocal way. > >> > >> As an implementor, I can testify firsthand that I > >> can not appreciate the > >> last point enough. Here is why: In the real > world, > >> most DSP based codec > >> implementations can ONLY support symmetric > >> operation. If tx uses codec > >> A, rx must also use codec A. So if the first SDP > >> (INVITE or 200 OK) > >> lists codecs A, B and C, and second SDP (200 OK > or > >> ACK) responds with > >> codecs A and B, one UA may start use codec A and > the > >> other may pick > >> codec B, which results in either dead silence or > >> garbled speech. We have > >> seen this happen at the bake-offs. > >> > >> And packetization size is another issue. Take > G.729 > >> for example. The > >> base frame size is 10ms. But due to resource > >> restrictions, many > >> implementations can only support a fixed, integer > >> multiple of the base > >> frame, say 20ms or 30 ms. On some > implementations, > >> packetization size is > >> either a runtime or configuration parameter. In > any > >> case, a 20 ms won't > >> talk to 30 ms G.729. We heard quite a few > distorted > >> conversations > >> because of codec size mismatch at SIP bake-offs > and > >> at H323 > >> Interoperability Events. > >> > >> Hence, I'd like to propose the following: > >> > >> 1. Assume all audio codecs (not including DTMF) > are > >> send and recv, and > >> require symmetric operation; > >> 2. Originating SDP lists packetization size for > each > >> codec unless > >> default value is used; > >> 3. If supported, origination SDP lists explicitly > >> whether DTMF is send > >> or recv, with sendrecv being default; > >> 4. Responding SDP lists one and ONLY one codec > for > >> each media (if, of > >> course, there exists overlap) and, when > applicable, > >> includes > >> packetization size and send/recv attribute; > >> 5. The side that originates SDP uses OPTIONS to > >> query the other side's > >> capability after call setup, if necessary. > >> > >> Example: UA1 supports codecs A (20ms), B (30ms), > and > >> C (20ms), and can > >> transmit and recv DTMF; UA2 supports codecs A(10 > >> ms), B (30ms), and D( > >> 20ms) and can transmit DTMF (but not recv). > Here's > >> the SDP exchange: > >> > >> UA1->UA2 (INVITE) > >> > >> m=audio 40000 RTP/AVP 100 101 102 > >> a=rtpmap: 100 A/8000 > >> a=ptime: 20 > >> a=rtpmap:101 B/8000 > >> a=ptime: 30 > >> a=rtpmap:102 C/8000 > >> a=ptime: 20 > >> m=audio 40000 RTP/AVP 103 > >> a=fmtp:103 0-15 > >> a=sendrecv > >> > >> UA2->UA1 (200 OK) > >> m=audio 30000 RTP/AVP 101 > >> a=rtpmap:101 B/8000 > >> a=ptime: 30 > >> m=audio 30000 RTP/AVP 103 > >> a=fmtp:103 0-15 > >> a=sendonly > >> > >> Note that there are two "m=" lines in each SDP > >> because the DTMF and > >> codec are really simultaneous capabilities. The > >> usage of "a=ptime" is a > >> little bit stretch here at codec level and may > cause > >> problem for > >> existing implementations. But I haven't seen it > used > >> very much. > >> > >> Regards, > >> > >> Shan Lu > >> > >> NexTone Communications > >> > >> Gonzalo Camarillo wrote: > >> > >>> Hello, > >>> > >>> There have been already several mails showing > >> > >> certain confusion about > >> > >>> SDP usage in SIP. > >>> In the last IETF the conclusion was: > >>> For sendrecv flows (uni-directional flows are > >> > >> easy), the caller puts in > >> > >>> the INVITe the codecs that he can both send AND > >> > >> receive. > >> > >>> The open issue is what the callee returns: > >>> 1) a sub-set of the codecs listed in the INVITE > >> > >> that he can send AND > >> > >>> receive. > >>> 2) all the codecs that he can send AND receive. > >>> > >>> Note that caller and callee have reversed roles > if > >> > >> the SDP from the > >> > >>> client to the server is sent in the ACK instead > of > >> > >> in the INVITE. > >> > >>> I would like to ask folks not to mix this open > >> > >> issue with another > >> > >>> similar issue: I have a DSP that cannot change > >> > >> codecs on-the-fly, and I > >> > >>> want to pick up just one codec. Let us discuss > >> > >> this issue at other time. > >> > >>> My proposal is to go for solution number 2. This > >> > >> gives a symmetrical > >> > >>> negotiation. Besides, it covers more cases than > >> > >> solution number 1). It > >> > >>> can happen that for a particular codec, the > callee > >> > >> can send AND receive > >> > >>> it but the caller can just send it. Therefore, > the > >> > >> caller does not > >> > >>> include it in the INVITE. However, if the callee > >> > >> lists it in the 200 OK, > >> > >>> the caller will be able to send it. > >>> > >>> Opinions? > >>> > >>> Gonzalo > >> > >> > >> > >> _______________________________________________ > >> 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. > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get email at your own domain with Yahoo! Mail. > > http://personal.mail.yahoo.com/ > > > > > > > > __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.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@lists.bell-labs.com Wed Apr 4 13:44:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27095 for ; Wed, 4 Apr 2001 13:44:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77F124433A; Wed, 4 Apr 2001 13:44:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lists.bell-labs.com (Postfix) with ESMTP id 68EB34433A for ; Wed, 4 Apr 2001 13:43:48 -0400 (EDT) Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f34HhpS06937 for ; Wed, 4 Apr 2001 20:43:51 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 4 Apr 2001 20:43:47 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 4 Apr 2001 20:43:47 +0300 Message-ID: From: Markus.Isomaki@nokia.com To: jdrosen@dynamicsoft.com, bidulock@openss7.org Cc: rrroy@att.com, mat@cisco.com, sip@lists.bell-labs.com Subject: RE: [SIP] Response if user not registered? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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: Wed, 4 Apr 2001 20:43:46 +0300 Hi, Jonathan Rosenberg: > > That aside, I still find the process of assigning an S-CSCF > at registration > to be a funny thing. I agree completely that you will > ultimately want to > segment the servers in your domain, with users being assigned > to a specific > server. THis segmentation is a common practice today, even, in email > systems. However, there, they make the segmentations > algorithmic in nature. > I believe its common to assign users to mail servers based on > the first > letter of their username. The algorithmic mappings are a lot > easier to deal > with, and don't require any of these additional databases to > hold the "user > to S-CSCF" mappings themselves. > > Perhaps someone can clarify for me why it was decided to do > it this way in > 3gpp. > I agree that "user to S-CSCF" mapping based on first letter etc. would be much easier than the current process. I have heard of two reasons for why it is done the way it is now: - If S-CSCFs have different capabilities (I guess this relates to service execution) and users have different preferences, these have to be mapped together, so static provisioning (at least a simple one) would not be enough. - Reliability: I'm not sure if there is any benefit from dynamic mapping, but it probably makes load balancing and failure recovery easier. (I don't know how e-mail systems do it, perhaps they just have some redundancy to keep the one statically mapped server up.) > -Jonathan R. Markus _______________________________________________ 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 Wed Apr 4 13:52:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27323 for ; Wed, 4 Apr 2001 13:52:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE1B444341; Wed, 4 Apr 2001 13:52:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by lists.bell-labs.com (Postfix) with ESMTP id 7416E44338 for ; Wed, 4 Apr 2001 13:51:29 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by sheffield.cnchost.com id NAA22802; Wed, 4 Apr 2001 13:51:27 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <3ACB606F.7090905@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: aravindan shanmugam Cc: sip Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal References: <20010404164202.30724.qmail@web13903.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------060106000309030501060700" 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: Wed, 04 Apr 2001 13:57:03 -0400 --------------060106000309030501060700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit aravindan shanmugam wrote: > --- Shan Lu wrote: > >> >> aravindan shanmugam wrote: >> >>> Hi, >>> >>> Handling different packet size is not a difficult >>> problem as long as the packet size is an integer >>> multiple of codec frame size. Let us not add more >>> variables to the problem. >> >> Can you tell me how if neither side indicates the >> packet size ? >> >> Shan Lu >> > > You know the payload size of RTP packet when you > receive a packet after protocol processing and you > know the codec frame size from the codec type. Thus, > you can estimate the number of codec frames in the > packet. For more details refer to > draft-ietf-avt-profile document. > > Aravindan I see. You want to leave the burden to RTP PT. Let's consider the following two scenarios: 1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can switch packetization size "on-the-fly". But the default configuration is 20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should refrain from transmitting RTP packets till packets arrive from UA2 at which time UA1 can figure out the packet size the other side wants to use and switch to that size? Of course, both UAs may start transmit at the same time. But for sure the first moments of speech won't be as clear as a user would like to hear due to packetization size mismatch. And how do you make sure that the two UAs do not switch simultaneously which will again lead to packet size mismatch? Let's not forget that even "on-the-fly" switch takes time and a user can definitely tell it. 2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec A. UA1 calls UA2. UA2 rings and user picks up the phone. Then what? Dead silence, garbled speech, or busy/reorder tone, or LED display "packet size mismatch"? What you want in this case is for UA2 to send 415 "unsupported media type" response because the two UAs can never have a media connection. This of course assumes UAs have a way to list packetization size. Hope this is enough to convince you. A protocol has to be designed based on reality. And the reality is many codec implementations use DSPs and DSPs have limitations. If we have super-fast DSPs with super-large on-chip RAM, packetization size is not a problem Nor is codec type. Regards, Shan Lu > >>> >>> Making DTMF, CN etc. as separate streams will >> >> create >> >>> more issues with many existing systems. >>> >>> Aravindan >>> --- Shan Lu wrote: >>> >>>> Hi, >>>> >>>> Before we come up with any solution, let's first >>>> understand what the >>>> problems are and what we want out of SDP. >>>> >>>> Problems: >>>> >>>> When more than more audio codecs are listed in >>> >> "m=" >> >>>> line, SDP lacks >>>> mechanism to indicate: >>>> 1. sendrecv, sendonly, or recvonly for each >>> >> codec; >> >>>> 2. packetization size supported for each codec ; >>>> 3. simultaneous capabilities. (e.g., a UA can >>>> support audio codecs A, B, >>>> and C, but when video codec X is used, can only >>>> support audio codec A.) >>>> >>>> Desirable functions of SDP: >>>> >>>> 1. To indicate to the other side the full >>>> capabilities of a UA >>>> 2. To indicate to the other side the media types >>>> (codec, pack. size, >>>> uni. or bi-directional) that will be used for a >>>> particular session in an >>>> unequivocal way. >>>> >>>> As an implementor, I can testify firsthand that I >>>> can not appreciate the >>>> last point enough. Here is why: In the real >>> >> world, >> >>>> most DSP based codec >>>> implementations can ONLY support symmetric >>>> operation. If tx uses codec >>>> A, rx must also use codec A. So if the first SDP >>>> (INVITE or 200 OK) >>>> lists codecs A, B and C, and second SDP (200 OK >>> >> or >> >>>> ACK) responds with >>>> codecs A and B, one UA may start use codec A and >>> >> the >> >>>> other may pick >>>> codec B, which results in either dead silence or >>>> garbled speech. We have >>>> seen this happen at the bake-offs. >>>> >>>> And packetization size is another issue. Take >>> >> G.729 >> >>>> for example. The >>>> base frame size is 10ms. But due to resource >>>> restrictions, many >>>> implementations can only support a fixed, integer >>>> multiple of the base >>>> frame, say 20ms or 30 ms. On some >>> >> implementations, >> >>>> packetization size is >>>> either a runtime or configuration parameter. In >>> >> any >> >>>> case, a 20 ms won't >>>> talk to 30 ms G.729. We heard quite a few >>> >> distorted >> >>>> conversations >>>> because of codec size mismatch at SIP bake-offs >>> >> and >> >>>> at H323 >>>> Interoperability Events. >>>> >>>> Hence, I'd like to propose the following: >>>> >>>> 1. Assume all audio codecs (not including DTMF) >>> >> are >> >>>> send and recv, and >>>> require symmetric operation; >>>> 2. Originating SDP lists packetization size for >>> >> each >> >>>> codec unless >>>> default value is used; >>>> 3. If supported, origination SDP lists explicitly >>>> whether DTMF is send >>>> or recv, with sendrecv being default; >>>> 4. Responding SDP lists one and ONLY one codec >>> >> for >> >>>> each media (if, of >>>> course, there exists overlap) and, when >>> >> applicable, >> >>>> includes >>>> packetization size and send/recv attribute; >>>> 5. The side that originates SDP uses OPTIONS to >>>> query the other side's >>>> capability after call setup, if necessary. >>>> >>>> Example: UA1 supports codecs A (20ms), B (30ms), >>> >> and >> >>>> C (20ms), and can >>>> transmit and recv DTMF; UA2 supports codecs A(10 >>>> ms), B (30ms), and D( >>>> 20ms) and can transmit DTMF (but not recv). >>> >> Here's >> >>>> the SDP exchange: >>>> >>>> UA1->UA2 (INVITE) >>>> >>>> m=audio 40000 RTP/AVP 100 101 102 >>>> a=rtpmap: 100 A/8000 >>>> a=ptime: 20 >>>> a=rtpmap:101 B/8000 >>>> a=ptime: 30 >>>> a=rtpmap:102 C/8000 >>>> a=ptime: 20 >>>> m=audio 40000 RTP/AVP 103 >>>> a=fmtp:103 0-15 >>>> a=sendrecv >>>> >>>> UA2->UA1 (200 OK) >>>> m=audio 30000 RTP/AVP 101 >>>> a=rtpmap:101 B/8000 >>>> a=ptime: 30 >>>> m=audio 30000 RTP/AVP 103 >>>> a=fmtp:103 0-15 >>>> a=sendonly >>>> >>>> Note that there are two "m=" lines in each SDP >>>> because the DTMF and >>>> codec are really simultaneous capabilities. The >>>> usage of "a=ptime" is a >>>> little bit stretch here at codec level and may >>> >> cause >> >>>> problem for >>>> existing implementations. But I haven't seen it >>> >> used >> >>>> very much. >>>> >>>> Regards, >>>> >>>> Shan Lu >>>> >>>> NexTone Communications >>>> >>>> Gonzalo Camarillo wrote: >>>> >>>>> Hello, >>>>> >>>>> There have been already several mails showing >>>> >>>> certain confusion about >>>> >>>>> SDP usage in SIP. >>>>> In the last IETF the conclusion was: >>>>> For sendrecv flows (uni-directional flows are >>>> >>>> easy), the caller puts in >>>> >>>>> the INVITe the codecs that he can both send AND >>>> >>>> receive. >>>> >>>>> The open issue is what the callee returns: >>>>> 1) a sub-set of the codecs listed in the INVITE >>>> >>>> that he can send AND >>>> >>>>> receive. >>>>> 2) all the codecs that he can send AND receive. >>>>> >>>>> Note that caller and callee have reversed roles >>>> >> if >> >>>> the SDP from the >>>> >>>>> client to the server is sent in the ACK instead >>>> >> of >> >>>> in the INVITE. >>>> >>>>> I would like to ask folks not to mix this open >>>> >>>> issue with another >>>> >>>>> similar issue: I have a DSP that cannot change >>>> >>>> codecs on-the-fly, and I >>>> >>>>> want to pick up just one codec. Let us discuss >>>> >>>> this issue at other time. >>>> >>>>> My proposal is to go for solution number 2. This >>>> >>>> gives a symmetrical >>>> >>>>> negotiation. Besides, it covers more cases than >>>> >>>> solution number 1). It >>>> >>>>> can happen that for a particular codec, the >>>> >> callee >> >>>> can send AND receive >>>> >>>>> it but the caller can just send it. Therefore, >>>> >> the >> >>>> caller does not >>>> >>>>> include it in the INVITE. However, if the callee >>>> >>>> lists it in the 200 OK, >>>> >>>>> the caller will be able to send it. >>>>> >>>>> Opinions? >>>>> >>>>> Gonzalo >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Get email at your own domain with Yahoo! Mail. >>> http://personal.mail.yahoo.com/ >>> >>> >>> > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.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. > > > --------------060106000309030501060700 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
aravindan shanmugam wrote:
--- Shan Lu <slu@nextone.com> wrote:

aravindan shanmugam wrote:

Hi,

Handling different packet size is not a difficult
problem as long as the packet size is an integer
multiple of codec frame size. Let us not add more
variables to the problem.
Can you tell me how if neither side indicates the
packet size ?

Shan Lu


You know the payload size of RTP packet when you
receive a packet after protocol processing and you
know the codec frame size from the codec type. Thus,
you can estimate the number of codec frames in the
packet. For more details refer to
draft-ietf-avt-profile document.

Aravindan
I see. You want to leave the burden to RTP PT. Let's consider the following two scenarios:

1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can switch packetization size "on-the-fly". But the default configuration is 20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should refrain from transmitting RTP packets till packets arrive from UA2 at which time UA1 can figure out the packet size the other side wants to use and switch to that size? Of course, both UAs may start transmit at the same time. But for sure the first moments of speech won't be as clear as a user would like to hear due to packetization size mismatch. And how do you make sure that the two UAs do not switch simultaneously which will again lead to packet size mismatch? Let's  not forget that even "on-the-fly" switch takes time and a user can definitely tell it.

2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec A. UA1 calls UA2. UA2 rings and user picks up the phone. Then what? Dead silence, garbled speech, or busy/reorder tone, or LED display "packet size mismatch"?  What you want in this case is for UA2 to send 415 "unsupported media type" response because the two UAs can never have a media connection. This of course assumes UAs have a way to list packetization size.

Hope this is enough to convince you. A protocol has to be designed based on reality. And the reality is many codec implementations use DSPs and DSPs have limitations. If we have super-fast DSPs with super-large on-chip RAM, packetization size is not a problem  Nor is codec type.

Regards,

Shan Lu
 ------_=_NextPart_001_01C0C753.50CA1D90-- _______________________________________________ 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 Tue Apr 17 11:45:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10536 for ; Tue, 17 Apr 2001 11:45: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 215D1443A2; Tue, 17 Apr 2001 11:45:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from brahma01.netbrahma.com (unknown [164.164.70.67]) by lists.bell-labs.com (Postfix) with ESMTP id AE89D443A0 for ; Tue, 17 Apr 2001 11:44:45 -0400 (EDT) Received: from netbrahma.com (SUNILK [172.16.72.151]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 23F75YYD; Tue, 17 Apr 2001 21:15:14 +0530 Message-ID: <3ADC6538.E91F86C4@netbrahma.com> From: "T.Sunil Kumar" Organization: Netbrahma Technologies Pvt. Ltd X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Vovida - SIP , Bell - SIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Retransmission of responses in TCP, but not in UDP? 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, 17 Apr 2001 21:16:00 +0530 Content-Transfer-Encoding: 7bit Hi, Can someone help me understand why is it that requests need not be retransmitted while using TCP, but responses need to be. -- Thanks, --Sunil _____________________________________ T.SUNIL KUMAR Net Brahma Technologies Internext Networking Software A Microland Group Venture sunilk@netbrahma.com http://www.netbrahma.com Tel : 91.80. 552 1451/5011/5012/5014 Ext : 269/270 Fax : 91.80. 553 7233 e-card: http://www.ecardfile.com/tskr _____________________________________ _______________________________________________ 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 Tue Apr 17 12:44:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11592 for ; Tue, 17 Apr 2001 12:44:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9940144386; Tue, 17 Apr 2001 12:44:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 0D13344382 for ; Tue, 17 Apr 2001 12:43:33 -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.9.3/8.9.1) with ESMTP id JAA15543 for ; Tue, 17 Apr 2001 09:43:36 -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 f3HGhV902892 for ; Tue, 17 Apr 2001 09:43:31 -0700 (PDT) Received: from chsharp-w2k.cisco.com (rtp-vpn-288.cisco.com [10.82.193.32]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA24873 for ; Tue, 17 Apr 2001 09:43:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20010417123145.01dc15c8@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: sip@lists.bell-labs.com From: Chip Sharp Subject: Help ease Internet congestion (was RE: [SIP] Request-uri does not match record-route header...) 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: Tue, 17 Apr 2001 12:43:22 -0400 Judicious editing of this thread would cut down on the number of megabytes consumed. Also, it doesn't help that someone has their mailer configured to send a duplicate of the email as an html attachment, thus doubling the size of the email with no value added. Please consider not doing this. Thanks, Chip At 11:30 AM 4/17/2001, xxx wrote: ...snip... >WARNING: The remainder of this message has not been transferred. >The estimated size of this message is 140204 bytes. >Click on the Retrieve From Server icon above and check mail again to get >the whole thing. (If you're reading this in the preview pane, you'll need >to open the message to see the icon.) If the Retrieve From Server icon is >not showing, then this message is no longer on the server. ------------------------------------------------------------------- Chip Sharp Consulting Engineering 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@lists.bell-labs.com Tue Apr 17 14:52:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13324 for ; Tue, 17 Apr 2001 14:52:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8003844338; Tue, 17 Apr 2001 14:52:03 -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 49EF044337 for ; Tue, 17 Apr 2001 14:51:57 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GBY001529O5U1@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 17 Apr 2001 18:50:29 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GBY00H019NZQ8@dgismtp04.wcomnet.com>; Tue, 17 Apr 2001 18:50:29 +0000 (GMT) Received: from wcom.com ([166.44.59.235]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GBY00DK09N8ZL@dgismtp04.wcomnet.com>; Tue, 17 Apr 2001 18:49:58 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] 183 in call flows. To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.bell-labs.com'" Message-id: <3ADC9052.AAF89331@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: multipart/alternative; boundary="Boundary_(ID_1wsrIlSYwxs7TP0uOjiXuA)" X-Accept-Language: en References: 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, 17 Apr 2001 13:49:55 -0500 --Boundary_(ID_1wsrIlSYwxs7TP0uOjiXuA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert, See my comments below. Thanks, Alan Johnston sip:alanjohnston@siptest.wcom.com "Fairlie-Cuninghame, Robert" wrote: > > > Hi, > > I recently noticed in the call flow documents that it states that > early media sessions can be established by simply returning a 183 > without SDP (giving the argument that the early media is > unidirectional and thus only needs the caller's SDP). > > I don't remember this change being discussed on the list and I have > not seen this behavior stated in any of the bis or old-183 drafts. > Where did it come from and why? > It was discussed at the interim meeting in Plano and also at Minneapolis. I did not agree with the conclusion, but I have updated the call flows draft to reflect the consensus. The consensus was that early media is problematic, and as a result the 183 Session Progress approach described in the expired 183 draft (http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-183-00.txt) will be abandoned in favor of a yet to be designed early media approach that is friendly to forking, hold, etc. As a result, 2543bis will list the 183 code, but without any requirements. Also, putting SDP in a 183 also becomes undefined by any SIP WG document. > > Although strictly speaking, the SDP is not required I still think it > should still be required in the 183 response because: > > a. it now forms a response-code specific behavior that is in > contrast to the general early media handling for other > provisional responses, eg SDP in 180. > b. Does not allow symmetric RTP or any other type of NAT friendly > processing to occur (because the source address is unknown). > c. Is an unnecessary "saving". Why not send the SDP? Sending the > reverse SDP doesn't hurt and is in line with processing for other > early media sessions (eg 180 with SDP). Just because the both SDP > are specified, does not mean that the UAS need accept any media > in the forward direction. > > I agree that the 183 with SDP is useful, however, others were insistent that it not be standardized. > > > What do other people think? I know we all hate early media but at > least let's make the handling of what we have consistent across all > response codes. > > Cheers, > > Robert. --Boundary_(ID_1wsrIlSYwxs7TP0uOjiXuA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Robert,

See my comments below.

Thanks,
Alan Johnston
sip:alanjohnston@siptest.wcom.com

"Fairlie-Cuninghame, Robert" wrote:

 

Hi,

I recently noticed in the call flow documents that it states that early media sessions can be established by simply returning a 183 without SDP (giving the argument that the early media is unidirectional and thus only needs the caller's SDP).

I don't remember this change being discussed on the list and I have not seen this behavior stated in any of the bis or old-183 drafts. Where did it come from  and why?
 

It was discussed at the interim meeting in Plano and also at Minneapolis.  I did not agree with the conclusion, but I have updated the call flows draft to reflect the consensus.  The consensus was that early media is problematic, and as a result the 183 Session Progress approach described in the expired 183 draft (http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-183-00.txt) will be abandoned in favor of a yet to be designed early media approach that is friendly to forking, hold, etc.  As a result, 2543bis will list the 183 code, but without any requirements.  Also, putting SDP in a 183 also becomes undefined by any SIP WG document.
 
Although strictly speaking, the SDP is not required I still think it should still be required in the 183 response because:
  1. it  now forms a response-code specific behavior that is in contrast to the general early media handling for other provisional responses, eg SDP in 180.
  2. Does not allow symmetric RTP or any other type of NAT friendly processing to occur (because the source address is unknown).
  3. Is an unnecessary "saving". Why not send the SDP? Sending the reverse SDP doesn't hurt and is in line with processing for other early media sessions (eg 180 with SDP). Just because the both SDP are specified, does not mean that the UAS need accept any media in the forward direction.

    4.  
I agree that the 183 with SDP is useful, however, others were insistent that it not be standardized.
     
What do other people think? I know we all hate early media but at least let's make the handling of what we have consistent across all response codes.

Cheers,

Robert.

--Boundary_(ID_1wsrIlSYwxs7TP0uOjiXuA)-- _______________________________________________ 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 Tue Apr 17 14:58:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13501 for ; Tue, 17 Apr 2001 14:58:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DE8E4436C; Tue, 17 Apr 2001 14:58:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 2C51244338 for ; Tue, 17 Apr 2001 14:57:53 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GBY00H1VA0AR9@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 17 Apr 2001 18:57:47 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GBY00F01A06SM@dgismtp02.wcomnet.com>; Tue, 17 Apr 2001 18:57:46 +0000 (GMT) Received: from wcom.com ([166.44.59.235]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GBY00F3G9ZWG7@dgismtp02.wcomnet.com>; Tue, 17 Apr 2001 18:57:34 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] A question about Cancel request To: "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" Message-id: <3ADC9214.6F893FF@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: <475FF955A05DD411980D00508B6D5FB001AC318B@en0033exch001u.uk.lucent.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: Tue, 17 Apr 2001 13:57:25 -0500 Content-Transfer-Encoding: 7bit Keith, Of course nothing in the Call Flows draft is normative - in any conflict between it and the RFC, the RFC holds. Having said that, I'm not sure I understand your concern here. How many retransmissions the stateful proxy 2 does is an implementation issue - it could choose to give up at any time. Also, if the proxy wishes to terminate the call, its only option is to send a CANCEL - it can not originate a BYE. The caller User A could send either a BYE or a CANCEL to terminate the call. How and when a proxy initiates a CANCEL doesn't seem to need to be spelled out in the SIP standard. Thanks, Alan Johnston sip:alanjohnston@siptest.wcom.com "Drage, Keith (Keith)" wrote: > We have a clear incompatibility in the SIP drafts here. > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 implies that the > expected action is to send a CANCEL, we have been unable to find any text in > the bis-02 draft indicating any special use of CANCEL from a proxy in this > case. > > The only text we have found is text that says anybody can send a CANCEL at > any time. > > Whether it is MUST, MAY or MUST NOT I believe we do need some text on this > subject. > > My view is that it would say MAY, possibly followed by some guidance > comments on conditions when it might be more appropriate than others. > > by the way, the signalling flows draft says the CANCEL is sent 7 times. I > thought 11 was the more appropriate number in this case, using both T1 and > T2. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > Sent: 04 April 2001 7:30 > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > -----Original Message----- > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > I have a basic question about sip. > > > > Cancel request is used to cancel a pending INVITE. > > > > In sip signalling establishment procedure, if the callee > > > > agent for some > > > > reason fails, it can't receive anything from its proxy, after > > > > the proxy > > > > server of the callee retransmittes 6 times INVITE messges, it > > > > should give up > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > needed to send > > > > out by the proxy server to the callee, if so, it will cause > > > > another 11 times > > > > cancle request beeing sent. > > > > > > The Cancel is required to be sent to the callee. Simple > > > reason being that the > > > > > > proxy does not know weather the callee UA is down or is > > > simply not responding > > > for the time being. Sending Cancel ensures that in case UA is > > > not down this > > > Cancel > > > will cancel the previous Invite, and the UA is not supposed > > > to respond to > > > that Invite > > > at a later stage. > > > > Actually, I have debated whether or not CANCEL is useful in the case where > > you never received any provisional response at all, not even a 100. This > > is > > likely a sign that the device or the network has failed, in which case the > > CANCEL is not useful. > > > > I would tend to think that the best answer is to say that if you never > > receive a provisional response, you MAY send a CANCEL, but its not > > mandatory. If you do get a provisional response, you SHOULD CANCEL upon > > timeout. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.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. > > > > _______________________________________________ > 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 Tue Apr 17 15:04:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13673 for ; Tue, 17 Apr 2001 15:04:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC6944436C; Tue, 17 Apr 2001 15:04:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3F70944337 for ; Tue, 17 Apr 2001 13:24:19 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA28085; Tue, 17 Apr 2001 10:24:23 -0700 (PDT) Received: from cisco.com (sunithak-lnx.cisco.com [128.107.140.122]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACB04658 (AUTH sunithak); Tue, 17 Apr 2001 10:23:26 -0700 (PDT) Message-ID: <3ADC7C0C.2E18003A@cisco.com> From: Sunitha Kumar Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-23.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: "T.Sunil Kumar" Cc: Vovida - SIP , Bell - SIP Subject: Re: [SIP] Retransmission of responses in TCP, but not in UDP? References: <3ADC6538.E91F86C4@netbrahma.com> Content-Type: multipart/alternative; boundary="------------F7C1BE0735050B207B67AC67" 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, 17 Apr 2001 10:23:24 -0700 --------------F7C1BE0735050B207B67AC67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit First of all, we still need retransmissions in TCP, since, the messages may traverse through unreliable links. However, we only need to perform for responses, and not for requests. This is because, if the request goes through an unreliable link, the proxies b/w those unreliable link, will take care of retransmission. (retransmission of INVITE stops, once the proxy gets an informational response, which is hop by hop) But, this cannot be said for final responses, since these are end to end, so, it is the responsibility of the caller and the callee to perform retransmission. Hope that helps sunitha "T.Sunil Kumar" wrote: > Hi, > > Can someone help me understand why is it that requests need not be > retransmitted while using TCP, but responses need to be. > > -- > Thanks, > --Sunil > _____________________________________ > T.SUNIL KUMAR > Net Brahma Technologies > Internext Networking Software > A Microland Group Venture > sunilk@netbrahma.com > http://www.netbrahma.com > Tel : 91.80. 552 1451/5011/5012/5014 > Ext : 269/270 > Fax : 91.80. 553 7233 > > e-card: http://www.ecardfile.com/tskr > _____________________________________ > > _______________________________________________ > 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. -- Sunitha Kumar http://www.cisco.com --------------F7C1BE0735050B207B67AC67 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit First of all, we still need retransmissions in TCP, since, the messages may traverse through unreliable links.
However, we only need to perform for responses, and not for requests.
This is because, if the request goes through an unreliable link, the proxies b/w those unreliable link, will
take care of retransmission. (retransmission of INVITE stops, once the proxy gets an informational
response, which is hop by hop)
But, this cannot be said for final responses, since these are end to end,
so, it is the responsibility of the caller and the callee to perform retransmission.

Hope that helps
sunitha
 
 
 
 

"T.Sunil Kumar" wrote:

Hi,

Can someone help me understand why is it that requests need not be
retransmitted while using TCP, but responses need to be.

--
Thanks,
--Sunil
_____________________________________
T.SUNIL KUMAR
Net Brahma Technologies
Internext Networking Software
A Microland Group Venture
sunilk@netbrahma.com
http://www.netbrahma.com
Tel :  91.80. 552 1451/5011/5012/5014
              Ext : 269/270
Fax :  91.80. 553 7233

e-card: http://www.ecardfile.com/tskr
_____________________________________

_______________________________________________
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.

-- 
Sunitha Kumar
http://www.cisco.com
  --------------F7C1BE0735050B207B67AC67-- _______________________________________________ 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 Tue Apr 17 15:36:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14682 for ; Tue, 17 Apr 2001 15:36:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 200EC443B4; Tue, 17 Apr 2001 15:04:10 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 2310F44337 for ; Tue, 17 Apr 2001 13:50:21 -0400 (EDT) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3HBnpP03120 for ; Tue, 17 Apr 2001 06:49:51 -0500 Message-ID: <008401c0c766$dc188540$e7036e3f@dynamicsoft.com> From: "Dean Willis" To: References: Subject: Re: [SIP] 183 in call flows. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C0C73C.F2E0AE30" 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@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, 17 Apr 2001 12:50:15 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C0C73C.F2E0AE30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 183 in call flows. I believe that your model illustrates a common fallacy about SIP (that = some might say is a problem with SIP). The conventional usage of SDP says NOTHING about the source of the media = streams -- it describes only the DESTINATION of the media. So, waiting = until one receives SDP before listening for RTP accomplishes very little = (except for perhaps chopping the first few words of the conversation). A UA can in general not assume that it will be receiving RTP from the = same place it sends RTP. Once can envision a two part "phone" where the earpiece has a different = IP address than the mouthpiece. This is perfectly legal in SIP. This is part of why it is so hard to make SIP NAT-and-firewall friendly. = On the other hand, it's still more tractable than H.323 . . . There is hope that the work being done with secure RTP will resolve the = obvious difficulties. -- Dean ----- Original Message -----=20 From: Ryner, Jerry=20 To: Fairlie-Cuninghame, Robert ; 'sip@lists.bell-labs.com'=20 Sent: Monday, April 16, 2001 2:48 PM Subject: RE: [SIP] 183 in call flows. Another point to consider on this is that allowing media to be = processed in the absence of a remote SDP is a serious security risk. = Without a remote SDP to verify received packets, (assuming no = encryption), the gateway could possibly play out ANYTHING that comes = into it on that RTP port. Hackers will be able to inject audio into any = call during the early media phase simply by sending RTP packets. A more = likely failure case, however, is when the previous call's media was not = terminated properly for any number of reasons. A "stuck" channel on a = remote gateway from a previous call will corrupt the audio on the new = call attempt.=20 =20 Nuera has been requested by multiple carriers to never accept media = without a valid SDP in place. =20 Regards, Jerry Ryner Nuera Communications, Inc. =20 =20 -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Friday, April 13, 2001 4:45 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] 183 in call flows. =20 =20 Hi,=20 I recently noticed in the call flow documents that it states that = early media sessions can be established by simply returning a 183 = without SDP (giving the argument that the early media is unidirectional = and thus only needs the caller's SDP). I don't remember this change being discussed on the list and I have = not seen this behavior stated in any of the bis or old-183 drafts. Where = did it come from and why? Although strictly speaking, the SDP is not required I still think it = should still be required in the 183 response because: a. it now forms a response-code specific behavior that is in = contrast to the general early media handling for other provisional = responses, eg SDP in 180.=20 b. Does not allow symmetric RTP or any other type of NAT friendly = processing to occur (because the source address is unknown). c. Is an unnecessary "saving". Why not send the SDP? Sending the = reverse SDP doesn't hurt and is in line with processing for other early = media sessions (eg 180 with SDP). Just because the both SDP are = specified, does not mean that the UAS need accept any media in the = forward direction. =20 What do other people think? I know we all hate early media but at = least let's make the handling of what we have consistent across all = response codes. Cheers,=20 Robert.=20 ------=_NextPart_000_0081_01C0C73C.F2E0AE30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 183 in call = flows.
 
I believe that your model illustrates a = common=20 fallacy about SIP (that some might say is a problem with = SIP).
 
The conventional usage of SDP says = NOTHING about=20 the source of the media streams -- it describes only the DESTINATION of = the=20 media. So, waiting until one receives SDP before listening for RTP = accomplishes=20 very little (except for perhaps chopping the first few words of the=20 conversation).
 
A UA can in general not assume = that it will be=20 receiving RTP from the same place it sends RTP.
 
Once can envision a two part "phone" = where the=20 earpiece has a different IP address than the mouthpiece. This = is=20 perfectly legal in SIP.
 
This is part of why it is so hard to = make SIP=20 NAT-and-firewall friendly. On the other hand, it's still more tractable = than=20 H.323  . . .
 
There is hope that the work being done = with secure=20 RTP will resolve the obvious difficulties.
 
--
Dean
 
 
----- Original Message -----
From:=20 Ryner, = Jerry=20
Sent: Monday, April 16, 2001 = 2:48=20 PM
Subject: RE: [SIP] 183 in call=20 flows.

Another=20 point to consider on this is that allowing media to be processed in = the=20 absence of a remote SDP is a serious security risk.  Without a remote SDP to = verify=20 received packets, (assuming no encryption), the gateway could possibly = play=20 out ANYTHING that comes into it on that RTP port.  Hackers will be able to = inject audio=20 into any call during the early media phase simply by sending RTP = packets.  A more likely failure case, = however,=20 is when the previous call’s media was not terminated properly = for any number=20 of reasons.  A = “stuck” channel on=20 a remote gateway from a previous call will corrupt the audio on the = new call=20 attempt.

 

Nuera=20 has been requested by multiple carriers to never accept media without = a valid=20 SDP in place.

 

Regards,

Jerry=20 Ryner

Nuera=20 Communications, Inc.

 

 

-----Original=20 Message-----
From:=20 Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 13, 2001 = 4:45=20 AM
To:=20 'sip@lists.bell-labs.com'
Subject: [SIP] 183 in call=20 flows.

 

 

Hi,

I recently = noticed=20 in the call flow documents that it states that early media sessions = can be=20 established by simply returning a 183 without SDP (giving the argument = that=20 the early media is unidirectional and thus only needs the caller's=20 SDP).

I don't = remember=20 this change being discussed on the list and I have not seen this = behavior=20 stated in any of the bis or old-183 drafts. Where did it come = from  and=20 why?

Although = strictly=20 speaking, the SDP is not required I still think it should still be = required in=20 the 183 response because:

a.      =20 it  = now forms a=20 response-code specific behavior that is in contrast to the general = early media=20 handling for other provisional responses, eg SDP in 180. =

b.     =20 Does=20 not allow symmetric RTP or any other type of NAT friendly processing = to occur=20 (because the source address is unknown).

c.      =20 Is an=20 unnecessary "saving". Why not send the SDP? Sending the reverse SDP = doesn't=20 hurt and is in line with processing for other early media sessions (eg = 180=20 with SDP). Just because the both SDP are specified, does not mean that = the UAS=20 need accept any media in the forward direction.

 

What do = other people=20 think? I know we all hate early media but at least let's make the = handling of=20 what we have consistent across all response codes.

Cheers,

Robert.

------=_NextPart_000_0081_01C0C73C.F2E0AE30-- _______________________________________________ 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 Tue Apr 17 15:38:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14715 for ; Tue, 17 Apr 2001 15:38:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5903A44338; Tue, 17 Apr 2001 15:38:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 76CA644337 for ; Tue, 17 Apr 2001 15:37:59 -0400 (EDT) Received: by dnspri.npac.com; id OAA16150; Tue, 17 Apr 2001 14:37:58 -0500 (CDT) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma016082; Tue, 17 Apr 01 14:37:27 -0500 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id <29YW1MVH>; Tue, 17 Apr 2001 14:36:46 -0500 Message-ID: From: "Yu, James" To: "'Alan Johnston'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request 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: Tue, 17 Apr 2001 14:36:28 -0500 Alan, CANCEL is to cancel a pending a request. If the call has been established and there is no pending request to be cancelled, sending a cancel will not result in call termination. A 3G wireless caller may be put on hold (e.g., call to service center) but mobile phone is out of radio contact with the network (e.g., in the tunnel or outside coverage area). The 3G network knows about the situation; therefore, may need a way to terminate the call (instead of waiting for the UA at the other side to terminate the call). There is also a potential fraud case where the proxy servers want to stay in the signaling path by using the record-route and route mechanism but the UAs ignore the route and one of them sends the BYE directly to the other side to terminate the call (the UAs can ignore the protocol rules if they are programmed to do so). A mechanism may be needed for the proxies in the "route" to terminate the call - something like "proxy initiated disconnect." James > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Tuesday, April 17, 2001 2:57 PM > To: Drage, Keith (Keith) > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] A question about Cancel request > > > Keith, > > Of course nothing in the Call Flows draft is normative - in > any conflict between > it and the RFC, the RFC holds. > > Having said that, I'm not sure I understand your concern > here. How many > retransmissions the stateful proxy 2 does is an > implementation issue - it could > choose to give up at any time. Also, if the proxy wishes to > terminate the call, > its only option is to send a CANCEL - it can not originate a > BYE. The caller > User A could send either a BYE or a CANCEL to terminate the call. > > How and when a proxy initiates a CANCEL doesn't seem to need > to be spelled out > in the SIP standard. > > Thanks, > Alan Johnston > sip:alanjohnston@siptest.wcom.com > > "Drage, Keith (Keith)" wrote: > > > We have a clear incompatibility in the SIP drafts here. > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > implies that the > > expected action is to send a CANCEL, we have been unable to > find any text in > > the bis-02 draft indicating any special use of CANCEL from > a proxy in this > > case. > > > > The only text we have found is text that says anybody can > send a CANCEL at > > any time. > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > some text on this > > subject. > > > > My view is that it would say MAY, possibly followed by some guidance > > comments on conditions when it might be more appropriate > than others. > > > > by the way, the signalling flows draft says the CANCEL is > sent 7 times. I > > thought 11 was the more appropriate number in this case, > using both T1 and > > T2. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > ---------- > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > Sent: 04 April 2001 7:30 > > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > I have a basic question about sip. > > > > > Cancel request is used to cancel a pending INVITE. > > > > > In sip signalling establishment procedure, if the callee > > > > > agent for some > > > > > reason fails, it can't receive anything from its proxy, after > > > > > the proxy > > > > > server of the callee retransmittes 6 times INVITE messges, it > > > > > should give up > > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > > needed to send > > > > > out by the proxy server to the callee, if so, it will cause > > > > > another 11 times > > > > > cancle request beeing sent. > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > reason being that the > > > > > > > > proxy does not know weather the callee UA is down or is > > > > simply not responding > > > > for the time being. Sending Cancel ensures that in case UA is > > > > not down this > > > > Cancel > > > > will cancel the previous Invite, and the UA is not supposed > > > > to respond to > > > > that Invite > > > > at a later stage. > > > > > > Actually, I have debated whether or not CANCEL is useful > in the case where > > > you never received any provisional response at all, not > even a 100. This > > > is > > > likely a sign that the device or the network has failed, > in which case the > > > CANCEL is not useful. > > > > > > I would tend to think that the best answer is to say that > if you never > > > receive a provisional response, you MAY send a CANCEL, but its not > > > mandatory. If you do get a provisional response, you > SHOULD CANCEL upon > > > timeout. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.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. > > > > > > > _______________________________________________ > > 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@lists.bell-labs.com Wed Apr 18 04:32:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08079 for ; Wed, 18 Apr 2001 04:32:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44C6F4433C; Wed, 18 Apr 2001 04:32:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tweb.telcoware.com (unknown [211.237.132.181]) by lists.bell-labs.com (Postfix) with ESMTP id 93C0D44338 for ; Wed, 18 Apr 2001 04:31:29 -0400 (EDT) Received: from jmjung (twclnt153.telcoware.co.kr [211.237.132.153]) by tweb.telcoware.com (8.11.2/8.11.2) with SMTP id f3I8TH320657 for ; Wed, 18 Apr 2001 17:29:17 +0900 (KST) From: =?ks_c_5601-1987?B?waTBpLmu?= To: "SIP mailing list" 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [SIP] why should proxy servers use "maddr" at Record-Route? 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: Wed, 18 Apr 2001 17:30:21 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA08079 i'm beginner... help me please. what does the following paragraph mean? 6.29 Record-Route ..... Proxy servers SHOULD use the "maddr" URL parameter containing their address to ensure that subsequent requests are guaranteed to reach exactly the same server. if a proxy address is written at Record-Route without maddr, is there any case of working improperly. let me know that case and the reason. thank you in advance. Jungmoon JungÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ From sip-admin@lists.bell-labs.com Wed Apr 18 05:14:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08465 for ; Wed, 18 Apr 2001 05:14: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 3BA294433A; Wed, 18 Apr 2001 05:14:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 323E044337 for ; Wed, 18 Apr 2001 05:13:57 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Apr 18 05:12:39 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 11C7144380; Wed, 18 Apr 2001 04:59:26 -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 377D94437D for ; Wed, 18 Apr 2001 04:59:25 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 09:59:23 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31B0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Alan Johnston'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request 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: Wed, 18 Apr 2001 09:59:13 +0100 My concern is that primarily we have a hole in the bis draft about what the proxy should do in this case. Having transmitted the INVITE, and failed to receive a response (despite retransmitting according to the fairly fully specified algorithm), is it required to send a CANCEL forward in order to cancel the INVITE, as indicated by the call-flows draft, but with no supporting text in the bis draft, or is it permissable, or even required, to do nothing further in the forward direction, and merely provide a response in the backward direction. As specifications by absence of procedures normally imply that one should not do such a procedure, my reading of the current bis draft would be that I would normally do nothing in the forward direction in this case, whereas the call-flows draft indicates that CANCEL in the forward direction would be the normal operation. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Alan Johnston[SMTP:alan.johnston@wcom.com] > Sent: 17 April 2001 19:57 > To: Drage, Keith (Keith) > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] A question about Cancel request > > Keith, > > Of course nothing in the Call Flows draft is normative - in any conflict > between > it and the RFC, the RFC holds. > > Having said that, I'm not sure I understand your concern here. How many > retransmissions the stateful proxy 2 does is an implementation issue - it > could > choose to give up at any time. Also, if the proxy wishes to terminate the > call, > its only option is to send a CANCEL - it can not originate a BYE. The > caller > User A could send either a BYE or a CANCEL to terminate the call. > > How and when a proxy initiates a CANCEL doesn't seem to need to be spelled > out > in the SIP standard. > > Thanks, > Alan Johnston > sip:alanjohnston@siptest.wcom.com > > "Drage, Keith (Keith)" wrote: > > > We have a clear incompatibility in the SIP drafts here. > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 implies that the > > expected action is to send a CANCEL, we have been unable to find any > text in > > the bis-02 draft indicating any special use of CANCEL from a proxy in > this > > case. > > > > The only text we have found is text that says anybody can send a CANCEL > at > > any time. > > > > Whether it is MUST, MAY or MUST NOT I believe we do need some text on > this > > subject. > > > > My view is that it would say MAY, possibly followed by some guidance > > comments on conditions when it might be more appropriate than others. > > > > by the way, the signalling flows draft says the CANCEL is sent 7 times. > I > > thought 11 was the more appropriate number in this case, using both T1 > and > > T2. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > ---------- > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > Sent: 04 April 2001 7:30 > > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > I have a basic question about sip. > > > > > Cancel request is used to cancel a pending INVITE. > > > > > In sip signalling establishment procedure, if the callee > > > > > agent for some > > > > > reason fails, it can't receive anything from its proxy, after > > > > > the proxy > > > > > server of the callee retransmittes 6 times INVITE messges, it > > > > > should give up > > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > > needed to send > > > > > out by the proxy server to the callee, if so, it will cause > > > > > another 11 times > > > > > cancle request beeing sent. > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > reason being that the > > > > > > > > proxy does not know weather the callee UA is down or is > > > > simply not responding > > > > for the time being. Sending Cancel ensures that in case UA is > > > > not down this > > > > Cancel > > > > will cancel the previous Invite, and the UA is not supposed > > > > to respond to > > > > that Invite > > > > at a later stage. > > > > > > Actually, I have debated whether or not CANCEL is useful in the case > where > > > you never received any provisional response at all, not even a 100. > This > > > is > > > likely a sign that the device or the network has failed, in which case > the > > > CANCEL is not useful. > > > > > > I would tend to think that the best answer is to say that if you never > > > receive a provisional response, you MAY send a CANCEL, but its not > > > mandatory. If you do get a provisional response, you SHOULD CANCEL > upon > > > timeout. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.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. > > > > > > > _______________________________________________ > > 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@lists.bell-labs.com Wed Apr 18 06:25:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08847 for ; Wed, 18 Apr 2001 06:25:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5FAF4433C; Wed, 18 Apr 2001 06:25: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 DBB7944337 for ; Wed, 18 Apr 2001 06:24:18 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 18 06:21:28 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 19AC444380; Wed, 18 Apr 2001 06:10:36 -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 8121A4437D for ; Wed, 18 Apr 2001 06:10:35 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 11:10:34 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E3BC@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request 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: Wed, 18 Apr 2001 11:10:28 +0100 I couldn't find a way in sip rfc that a proxy can initate disconnect to a call if the call is established. UAS will ignore Cancel becuase it has sent 200 OK. And Bye can only been sent by UA not by proxy. So it seems that there is no way for the network to release a call if it is established already. Please point out what I missed in that rfc. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Yu, James [mailto:james.yu@neustar.com] Sent: 17 April 2001 19:36 To: 'Alan Johnston' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] A question about Cancel request Alan, CANCEL is to cancel a pending a request. If the call has been established and there is no pending request to be cancelled, sending a cancel will not result in call termination. A 3G wireless caller may be put on hold (e.g., call to service center) but mobile phone is out of radio contact with the network (e.g., in the tunnel or outside coverage area). The 3G network knows about the situation; therefore, may need a way to terminate the call (instead of waiting for the UA at the other side to terminate the call). There is also a potential fraud case where the proxy servers want to stay in the signaling path by using the record-route and route mechanism but the UAs ignore the route and one of them sends the BYE directly to the other side to terminate the call (the UAs can ignore the protocol rules if they are programmed to do so). A mechanism may be needed for the proxies in the "route" to terminate the call - something like "proxy initiated disconnect." James > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Tuesday, April 17, 2001 2:57 PM > To: Drage, Keith (Keith) > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] A question about Cancel request > > > Keith, > > Of course nothing in the Call Flows draft is normative - in > any conflict between > it and the RFC, the RFC holds. > > Having said that, I'm not sure I understand your concern > here. How many > retransmissions the stateful proxy 2 does is an > implementation issue - it could > choose to give up at any time. Also, if the proxy wishes to > terminate the call, > its only option is to send a CANCEL - it can not originate a > BYE. The caller > User A could send either a BYE or a CANCEL to terminate the call. > > How and when a proxy initiates a CANCEL doesn't seem to need > to be spelled out > in the SIP standard. > > Thanks, > Alan Johnston > sip:alanjohnston@siptest.wcom.com > > "Drage, Keith (Keith)" wrote: > > > We have a clear incompatibility in the SIP drafts here. > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > implies that the > > expected action is to send a CANCEL, we have been unable to > find any text in > > the bis-02 draft indicating any special use of CANCEL from > a proxy in this > > case. > > > > The only text we have found is text that says anybody can > send a CANCEL at > > any time. > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > some text on this > > subject. > > > > My view is that it would say MAY, possibly followed by some guidance > > comments on conditions when it might be more appropriate > than others. > > > > by the way, the signalling flows draft says the CANCEL is > sent 7 times. I > > thought 11 was the more appropriate number in this case, > using both T1 and > > T2. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > ---------- > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > Sent: 04 April 2001 7:30 > > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > I have a basic question about sip. > > > > > Cancel request is used to cancel a pending INVITE. > > > > > In sip signalling establishment procedure, if the callee > > > > > agent for some > > > > > reason fails, it can't receive anything from its proxy, after > > > > > the proxy > > > > > server of the callee retransmittes 6 times INVITE messges, it > > > > > should give up > > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > > needed to send > > > > > out by the proxy server to the callee, if so, it will cause > > > > > another 11 times > > > > > cancle request beeing sent. > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > reason being that the > > > > > > > > proxy does not know weather the callee UA is down or is > > > > simply not responding > > > > for the time being. Sending Cancel ensures that in case UA is > > > > not down this > > > > Cancel > > > > will cancel the previous Invite, and the UA is not supposed > > > > to respond to > > > > that Invite > > > > at a later stage. > > > > > > Actually, I have debated whether or not CANCEL is useful > in the case where > > > you never received any provisional response at all, not > even a 100. This > > > is > > > likely a sign that the device or the network has failed, > in which case the > > > CANCEL is not useful. > > > > > > I would tend to think that the best answer is to say that > if you never > > > receive a provisional response, you MAY send a CANCEL, but its not > > > mandatory. If you do get a provisional response, you > SHOULD CANCEL upon > > > timeout. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.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. > > > > > > > _______________________________________________ > > 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@lists.bell-labs.com Wed Apr 18 06:33:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08932 for ; Wed, 18 Apr 2001 06:33:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93DAA4435B; Wed, 18 Apr 2001 06:33: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 E5B674433C for ; Wed, 18 Apr 2001 06:32:18 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 18 06:29:18 EDT 2001 Received: by lists.bell-labs.com (Postfix) id B58DD44384; Wed, 18 Apr 2001 06:18:25 -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 327044437D for ; Wed, 18 Apr 2001 06:18:25 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 11:18:24 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31B2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Parolkar Satish , "'Mart Nurmet'" Cc: "'Medhavi'" , Sharath Rajasekar , sip list , jdrosen@dynamicsoft.com Subject: RE: [SIP] Delivering Caller-ID through SIP 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: Wed, 18 Apr 2001 11:18:18 +0100 Part of the answer to this depends on who owns the gateway. If the gateway is essentially part of a PBX, then you will be presenting the call, and the called id, to the network using the procedures of ITU-T Recommendations Q.931 and Q.951.3. At this point you have two options, special arrangement or no special arrangement. In the first, the public network relies on the private network infrastructure to ensure that it is a meaningful number. How this is dones is outside the scope of the ITU-T Recommendations, and in many countries this option is not readily available. In the no special arrangement, the public network will screen the supplied number to see if it believes it is meaningful. If the gateway is part of the public network, then the rules for any screening that is performed are implementation dependent, but the public network is looking to transport either one fully screened number which it knows it can trust, or two numbers, one of which is generated at the input port to the public network (which could be in the SIP domain) and is trusted, and another which was generated by user equipment. The trusted number is used for emergency calls, and malicious call identification, and charging, and so on. The user equipment generated one may be used additionally for the above, and is used for calling line identification presentation. While it is possible to use the From header in SIP to give very basic caller id, only use of the privacy draft will give you all the capabilities that also exist in the PSTN, and therefore can be readily mapped into the PSTN capabilities. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Mart Nurmet[SMTP:mart.nurmet@inet.com] > Sent: 11 April 2001 16:08 > To: Parolkar Satish > Cc: 'Medhavi'; Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com > Subject: Re: [SIP] Delivering Caller-ID through SIP > > <> > Further, how will the PSTNs treat this if it was a possibly ported number > when > presented to them? And let's not forget, that Area 1, dialing plans don't > necessarily hold for the rest of the world. Will 15 digit dialing be > standardized soon? Or other plans. > > "Parolkar, Satish" wrote: > > > I wonder if one could use the optional Display Name to deliver the > public > > number associated with the SIP phone. > > > > When a call is initiated by the SIP phone with public number > 444-555-6666, > > to a PSTN number 4085551111, the following > > INVITE will be sent out... > > > > INVITE sip:4085551111@gateway.company.com SIP/2.0 > > From : 4445556666 > > To : Unknown > > ... > > > > However, the issue remains > > Who is responsible to authenticate the number delivered to the PSTN? > > A user can put any number desired. Is the IP/PSTN gateway responsible to > > authenticate the Delivered Number? > > > > Comments. > > > > Satish > > > > -----Original Message----- > > From: Medhavi [mailto:mbhatia@nextone.com] > > Sent: Monday, April 09, 2001 8:38 PM > > To: Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com > > Subject: RE: [SIP] Delivering Caller-ID through SIP > > > > I think you can use the p= in SDP, as one option. > > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar > > Sent: Monday, April 09, 2001 9:16 PM > > To: sip list; jdrosen@dynamicsoft.com > > Subject: [SIP] Delivering Caller-ID through SIP > > > > Consider a SIP UA with a SIP URL userA@example.com which is associated > > with a SIP Phone. This SIP Phone has a public number (444-555-6666). > > > > When a call is initiated by the phone, to a PSTN number, the following > > INVITE will be sent out... > > > > INVITE sip:4085551111@gateway.company.com SIP/2.0 > > From : UserA > > To : Unknown > > ... > > > > How can one deliver the calling public number(444-555-6666 in this case) > > to the PSTN as caller-id through the gateway ? > > > > Some generic tag may be used say..."pstn-number: 444-555-6666" in the > > >From header, but this will mean that all gateways must support this > tag. > > Is there some other solution to this problem. > > > > Regards > > Sharath > > > > _______________________________________________ > > 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@lists.bell-labs.com Wed Apr 18 08:34:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10010 for ; Wed, 18 Apr 2001 08:34: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 82DA744343; Wed, 18 Apr 2001 08:34:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.siemenscomms.co.uk (mailgate.sgcs.co.uk [194.129.217.115]) by lists.bell-labs.com (Postfix) with ESMTP id 2B8F54433A for ; Wed, 18 Apr 2001 08:33:25 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GBZ00001MTDJF@siemenscomms.co.uk> for sip@lists.bell-labs.com; Wed, 18 Apr 2001 13:32:01 +0100 (BST) Received: from beex10.siemenscomms.co.uk (beex10.siemenscomms.co.uk [137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GBZ00MCSMT4CL@siemenscomms.co.uk>; Wed, 18 Apr 2001 13:31:52 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id <29J91Q52>; Wed, 18 Apr 2001 13:33:14 +0100 Content-return: allowed From: "Elwell, John" Subject: RE: [SIP] transfer call flows To: "'Mo Zonoun'" , sip@lists.bell-labs.com Message-id: <5AC7D3F55147D311AA1700A0C99583ED027D09AC@beex03.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 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: Wed, 18 Apr 2001 13:34:29 +0100 Content-Transfer-Encoding: 7BIT Mo, I have been out of the office, which accounts for my lateness in responding. From the responses and other documents there would seem to be a number of proposals: 1. Accept-Contact (mentioned by Tom Taylor and Alan Johnstone, included in Service-Examples by Robert Sparks). 2. Replaces header. Mentioned by Alan Johnstone and used in flows from Rohan Mahy. 3. Refer-to with preloaded route (mentioned by Brett Tate). 4. Refer with all required headers (mentioned by Brett Tate). I don't know exactly what this is, but it sounds similar to the Replaces header. One observation I would make is that in addition to making sure that a new INVITE in a Call Transfer gets to the correct UA-C, it is also necessary to ensure that the INVITE from B to C links up with/replaces the existing call from A to C. The Replaces header looks a good candidate for doing this, as well as solving your original problem. ------------------------------------------------------------- John Elwell (john.elwell@siemenscomms.co.uk) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. -----Original Message----- From: Mo Zonoun [mailto:mzonoun@nortelnetworks.com] Sent: 09 April 2001 22:00 To: sip@lists.bell-labs.com Subject: RE: [SIP] transfer call flows I posted the following question while back but I didn't get any response. How do you make sure that a new INVITE in a Call Transfer gets to the correct UA-C when there are multiple UA candidates, including the case where the UA-C is a gateway to another network. Mo Zonoun _______________________________________________ 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 Wed Apr 18 09:00:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10329 for ; Wed, 18 Apr 2001 09:00:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8012744371; Wed, 18 Apr 2001 09:00:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 2EA6344337 for ; Wed, 18 Apr 2001 08:59:15 -0400 (EDT) Received: by dnspri.npac.com; id HAA01669; Wed, 18 Apr 2001 07:59:14 -0500 (CDT) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma001623; Wed, 18 Apr 01 07:58:38 -0500 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id <29YW1PTP>; Wed, 18 Apr 2001 07:57:57 -0500 Message-ID: From: "Yu, James" To: "'Chen, Xin (Xin)'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request 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: Wed, 18 Apr 2001 07:57:35 -0500 Xin, Only the UA can send BYE, not the proxy server. That is why in my earlier e-mail I indicated that there might be a need for a "proxy initiated disconnect." James > -----Original Message----- > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > Sent: Wednesday, April 18, 2001 6:10 AM > To: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > > > I couldn't find a way in sip rfc that a proxy can initate > disconnect to a > call if the call is established. UAS will ignore Cancel > becuase it has sent > 200 OK. And Bye can only been sent by UA not by proxy. So it > seems that > there is no way for the network to release a call if it is established > already. Please point out what I missed in that rfc. > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.com] > Sent: 17 April 2001 19:36 > To: 'Alan Johnston' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > Alan, > > CANCEL is to cancel a pending a request. If the call has > been established > and there is no pending request to be cancelled, sending a > cancel will not > result in call termination. A 3G wireless caller may be put > on hold (e.g., > call to service center) but mobile phone is out of radio > contact with the > network (e.g., in the tunnel or outside coverage area). The > 3G network > knows about the situation; therefore, may need a way to > terminate the call > (instead of waiting for the UA at the other side to terminate > the call). > > There is also a potential fraud case where the proxy servers > want to stay in > the signaling path by using the record-route and route > mechanism but the UAs > ignore the route and one of them sends the BYE directly to > the other side to > terminate the call (the UAs can ignore the protocol rules if they are > programmed to do so). A mechanism may be needed for the > proxies in the > "route" to terminate the call - something like "proxy > initiated disconnect." > > James > > > > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > Sent: Tuesday, April 17, 2001 2:57 PM > > To: Drage, Keith (Keith) > > Cc: 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] A question about Cancel request > > > > > > Keith, > > > > Of course nothing in the Call Flows draft is normative - in > > any conflict between > > it and the RFC, the RFC holds. > > > > Having said that, I'm not sure I understand your concern > > here. How many > > retransmissions the stateful proxy 2 does is an > > implementation issue - it could > > choose to give up at any time. Also, if the proxy wishes to > > terminate the call, > > its only option is to send a CANCEL - it can not originate a > > BYE. The caller > > User A could send either a BYE or a CANCEL to terminate the call. > > > > How and when a proxy initiates a CANCEL doesn't seem to need > > to be spelled out > > in the SIP standard. > > > > Thanks, > > Alan Johnston > > sip:alanjohnston@siptest.wcom.com > > > > "Drage, Keith (Keith)" wrote: > > > > > We have a clear incompatibility in the SIP drafts here. > > > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > > implies that the > > > expected action is to send a CANCEL, we have been unable to > > find any text in > > > the bis-02 draft indicating any special use of CANCEL from > > a proxy in this > > > case. > > > > > > The only text we have found is text that says anybody can > > send a CANCEL at > > > any time. > > > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > > some text on this > > > subject. > > > > > > My view is that it would say MAY, possibly followed by > some guidance > > > comments on conditions when it might be more appropriate > > than others. > > > > > > by the way, the signalling flows draft says the CANCEL is > > sent 7 times. I > > > thought 11 was the more appropriate number in this case, > > using both T1 and > > > T2. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > ---------- > > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > > Sent: 04 April 2001 7:30 > > > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > I have a basic question about sip. > > > > > > Cancel request is used to cancel a pending INVITE. > > > > > > In sip signalling establishment procedure, if the callee > > > > > > agent for some > > > > > > reason fails, it can't receive anything from its > proxy, after > > > > > > the proxy > > > > > > server of the callee retransmittes 6 times INVITE > messges, it > > > > > > should give up > > > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > > > needed to send > > > > > > out by the proxy server to the callee, if so, it will cause > > > > > > another 11 times > > > > > > cancle request beeing sent. > > > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > > reason being that the > > > > > > > > > > proxy does not know weather the callee UA is down or is > > > > > simply not responding > > > > > for the time being. Sending Cancel ensures that in case UA is > > > > > not down this > > > > > Cancel > > > > > will cancel the previous Invite, and the UA is not supposed > > > > > to respond to > > > > > that Invite > > > > > at a later stage. > > > > > > > > Actually, I have debated whether or not CANCEL is useful > > in the case where > > > > you never received any provisional response at all, not > > even a 100. This > > > > is > > > > likely a sign that the device or the network has failed, > > in which case the > > > > CANCEL is not useful. > > > > > > > > I would tend to think that the best answer is to say that > > if you never > > > > receive a provisional response, you MAY send a CANCEL, > but its not > > > > mandatory. If you do get a provisional response, you > > SHOULD CANCEL upon > > > > timeout. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East > Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.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. > > > > > > > > > > _______________________________________________ > > > 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. > _______________________________________________ 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 Wed Apr 18 09:05:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10416 for ; Wed, 18 Apr 2001 09:05:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 344E244389; Wed, 18 Apr 2001 09:05:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id EC33544352 for ; Wed, 18 Apr 2001 09:04:27 -0400 (EDT) Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Wed, 18 Apr 2001 14:58:25 +0200 (W. Europe Daylight Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id <26Z3RCPX>; Wed, 18 Apr 2001 15:04:13 +0200 Message-ID: From: "Agboh, Charles" To: "'Yu, James'" , "'Chen, Xin (Xin)'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Wed, 18 Apr 2001 15:04:13 +0200 The proxy could use a session timeout of zero with an invite (re-invite) request for the same session. -Charles Hi james;-) > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.com] > Sent: Wednesday, April 18, 2001 2:58 PM > To: 'Chen, Xin (Xin)' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > Xin, > > Only the UA can send BYE, not the proxy server. That is why > in my earlier > e-mail I indicated that there might be a need for a "proxy initiated > disconnect." > > James > > > -----Original Message----- > > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > > Sent: Wednesday, April 18, 2001 6:10 AM > > To: 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > I couldn't find a way in sip rfc that a proxy can initate > > disconnect to a > > call if the call is established. UAS will ignore Cancel > > becuase it has sent > > 200 OK. And Bye can only been sent by UA not by proxy. So it > > seems that > > there is no way for the network to release a call if it is > established > > already. Please point out what I missed in that rfc. > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.com] > > Sent: 17 April 2001 19:36 > > To: 'Alan Johnston' > > Cc: 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] A question about Cancel request > > > > > > Alan, > > > > CANCEL is to cancel a pending a request. If the call has > > been established > > and there is no pending request to be cancelled, sending a > > cancel will not > > result in call termination. A 3G wireless caller may be put > > on hold (e.g., > > call to service center) but mobile phone is out of radio > > contact with the > > network (e.g., in the tunnel or outside coverage area). The > > 3G network > > knows about the situation; therefore, may need a way to > > terminate the call > > (instead of waiting for the UA at the other side to terminate > > the call). > > > > There is also a potential fraud case where the proxy servers > > want to stay in > > the signaling path by using the record-route and route > > mechanism but the UAs > > ignore the route and one of them sends the BYE directly to > > the other side to > > terminate the call (the UAs can ignore the protocol rules > if they are > > programmed to do so). A mechanism may be needed for the > > proxies in the > > "route" to terminate the call - something like "proxy > > initiated disconnect." > > > > James > > > > > > > > > -----Original Message----- > > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > > Sent: Tuesday, April 17, 2001 2:57 PM > > > To: Drage, Keith (Keith) > > > Cc: 'sip@lists.bell-labs.com' > > > Subject: Re: [SIP] A question about Cancel request > > > > > > > > > Keith, > > > > > > Of course nothing in the Call Flows draft is normative - in > > > any conflict between > > > it and the RFC, the RFC holds. > > > > > > Having said that, I'm not sure I understand your concern > > > here. How many > > > retransmissions the stateful proxy 2 does is an > > > implementation issue - it could > > > choose to give up at any time. Also, if the proxy wishes to > > > terminate the call, > > > its only option is to send a CANCEL - it can not originate a > > > BYE. The caller > > > User A could send either a BYE or a CANCEL to terminate the call. > > > > > > How and when a proxy initiates a CANCEL doesn't seem to need > > > to be spelled out > > > in the SIP standard. > > > > > > Thanks, > > > Alan Johnston > > > sip:alanjohnston@siptest.wcom.com > > > > > > "Drage, Keith (Keith)" wrote: > > > > > > > We have a clear incompatibility in the SIP drafts here. > > > > > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > > > implies that the > > > > expected action is to send a CANCEL, we have been unable to > > > find any text in > > > > the bis-02 draft indicating any special use of CANCEL from > > > a proxy in this > > > > case. > > > > > > > > The only text we have found is text that says anybody can > > > send a CANCEL at > > > > any time. > > > > > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > > > some text on this > > > > subject. > > > > > > > > My view is that it would say MAY, possibly followed by > > some guidance > > > > comments on conditions when it might be more appropriate > > > than others. > > > > > > > > by the way, the signalling flows draft says the CANCEL is > > > sent 7 times. I > > > > thought 11 was the more appropriate number in this case, > > > using both T1 and > > > > T2. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > ---------- > > > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > > > Sent: 04 April 2001 7:30 > > > > > To: 'Mayank Sharma'; Chen, Xin (Xin); > sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > I have a basic question about sip. > > > > > > > Cancel request is used to cancel a pending INVITE. > > > > > > > In sip signalling establishment procedure, if the callee > > > > > > > agent for some > > > > > > > reason fails, it can't receive anything from its > > proxy, after > > > > > > > the proxy > > > > > > > server of the callee retransmittes 6 times INVITE > > messges, it > > > > > > > should give up > > > > > > > sending INVITE. My quesiton is whether the Cancel > request is > > > > > > > needed to send > > > > > > > out by the proxy server to the callee, if so, it > will cause > > > > > > > another 11 times > > > > > > > cancle request beeing sent. > > > > > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > > > reason being that the > > > > > > > > > > > > proxy does not know weather the callee UA is down or is > > > > > > simply not responding > > > > > > for the time being. Sending Cancel ensures that in > case UA is > > > > > > not down this > > > > > > Cancel > > > > > > will cancel the previous Invite, and the UA is not supposed > > > > > > to respond to > > > > > > that Invite > > > > > > at a later stage. > > > > > > > > > > Actually, I have debated whether or not CANCEL is useful > > > in the case where > > > > > you never received any provisional response at all, not > > > even a 100. This > > > > > is > > > > > likely a sign that the device or the network has failed, > > > in which case the > > > > > CANCEL is not useful. > > > > > > > > > > I would tend to think that the best answer is to say that > > > if you never > > > > > receive a provisional response, you MAY send a CANCEL, > > but its not > > > > > mandatory. If you do get a provisional response, you > > > SHOULD CANCEL upon > > > > > timeout. > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.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. > > > > > > > > > > > > > _______________________________________________ > > > > 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. > > > > _______________________________________________ > 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 Wed Apr 18 09:25:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10819 for ; Wed, 18 Apr 2001 09:25:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 701E944346; Wed, 18 Apr 2001 09:25: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 6BCA344343 for ; Wed, 18 Apr 2001 09:24:19 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 18 09:20:06 EDT 2001 Received: by lists.bell-labs.com (Postfix) id E3AE044380; Wed, 18 Apr 2001 09:09: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 5F6744437D for ; Wed, 18 Apr 2001 09:09:13 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 14:09:12 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31B7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sghosh1@telcordia.com, Dean Willis , "'Steve Levy'" Cc: "IETF SIP (E-mail)" Subject: RE: Fw: [SIP] Delivering Caller-ID through SIP 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: Wed, 18 Apr 2001 14:09:01 +0100 Alternatively use the privacy draft, which gives all the capabilities for this support. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Steve Levy[SMTP:stlevy@cisco.com] > Sent: 11 April 2001 17:36 > To: sghosh1@telcordia.com; Dean Willis > Cc: IETF SIP (E-mail) > Subject: Re: Fw: [SIP] Delivering Caller-ID through SIP > > > Check Section 6.26 (From Header) of 2543.bis-02. There it states: > > A system SHOULD use the display name "Anonymous" if the > identity of the client is to remain hidden. > > The 'Anonymous' should be converted into presentation restricted for > ISUP/ISDN > > Steve > > At 06:22 PM 4/10/01 -0400, sghosh1@telcordia.com wrote: > > > > > >How does SIP convey the "privacy indicator" (presentation restriction > >information) to the ISUP/ISDN implementation > >on the gateway when the outgoing IAM/SETUP is built ? What if I dial *67 > >and want to supress my Caller-ID ? > > > >/somit > > > > > > > > > > > >"Dean Willis" on 04/10/2001 06:02:14 PM > > > >To: "IETF SIP (E-mail)" > >cc: (bcc: Somit Ghosh/Telcordia) > >Subject: Fw: [SIP] Delivering Caller-ID through SIP > > > > > > > >whoops, forgot to copy the list here . . . > > > >Sorry! > > > >-- > >Dean > > > >----- Original Message ----- > >From: "Dean Willis" > >To: "Sharath Rajasekar" > >Sent: Tuesday, April 10, 2001 11:56 AM > >Subject: Re: [SIP] Delivering Caller-ID through SIP > > > > > >> Personally, I set my From: field to: sip:9724735455@dfw.dynamicsoft.com > >when > >> placing a call through a gateway. All the gateway's I've worked with > >happily > >> strip off the domain part and copy 9724735455 into the Calling Party > ID. > >> > >> This is facilitated by the phone on my desk, which supports multiple > user > >> profiles (lines). I have the line1 button set up to use my phone number > >in > >> the From:, and line 2 set to use my username in the From:. I pick the > >> appropriate "line" for an outbound call manually. Works dandy with no > new > >> headers. > >> > >> One might also envision a user outbound proxy or application server (or > a > >> smart UA) performing this service automatically on behlaf of the user. > >> > >> -- > >> Dean > >> > >> > >> ----- Original Message ----- > >> From: "Sharath Rajasekar" > >> To: "sip list" ; > >> Sent: Monday, April 09, 2001 8:15 PM > >> Subject: [SIP] Delivering Caller-ID through SIP > >> > >> > >> > > >> > Consider a SIP UA with a SIP URL userA@example.com which is > associated > >> > with a SIP Phone. This SIP Phone has a public number (444-555-6666). > >> > > >> > When a call is initiated by the phone, to a PSTN number, the > following > >> > INVITE will be sent out... > >> > > >> > INVITE sip:4085551111@gateway.company.com SIP/2.0 > >> > From : UserA > >> > To : Unknown > >> > ... > >> > > >> > How can one deliver the calling public number(444-555-6666 in this > >case) > >> > to the PSTN as caller-id through the gateway ? > >> > > >> > Some generic tag may be used say..."pstn-number: 444-555-6666" in the > >> > >From header, but this will mean that all gateways must support this > >tag. > >> > Is there some other solution to this problem. > >> > > >> > > >> > Regards > >> > Sharath > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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. > _______________________________________________ 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 Wed Apr 18 10:15:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11629 for ; Wed, 18 Apr 2001 10:15:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB11144346; Wed, 18 Apr 2001 10:15:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id BAD0D44337 for ; Tue, 17 Apr 2001 20:27:54 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id <27SBCDT3>; Tue, 17 Apr 2001 17:27:27 -0700 Message-ID: From: "Ryner, Jerry" To: "'Christer Holmberg'" , "Fairlie-Cuninghame, Robert" Cc: "Ryner, Jerry" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] 183 in call flows. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C79E.5829ABA0" 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, 17 Apr 2001 17:27:26 -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_01C0C79E.5829ABA0 Content-Type: text/plain; charset="iso-8859-1" I think there has been some confusion here. I sent the email raising the security issue and not Robert. What I meant by "valid" was simply a well formed SDP. My point is that processing packets before an SDP is received can lead to very poor performance, especially if a new call is attempted very quickly after a previous call was terminated. You can imagine a scenario where the SIP BYE sequence fails due to a network failure to a particular proxy say. After timing out and returning to Idle, the SIP endpoint initiates a new call to a different SIP endpoint or proxy. If the first call's remote endpoint did not hang up, the new call will be receiving RTP packets from both endpoints. Hackers sending RTP (not sophisticated imposters) and "stuck" channels will also cause problems in this early media phase. I realize that the bis currently allows for early media without an SDP but I thought I would share with the forum that we have been requested by major international carriers to never allow our gateways to do that. Jerry Ryner Nuera Communications, Inc. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Tuesday, April 17, 2001 3:38 AM To: Fairlie-Cuninghame, Robert Cc: Ryner, Jerry; 'sip@lists.bell-labs.com' Subject: Re: [SIP] 183 in call flows. << File: Card for Christer Holmberg >> Hi Robert, First, I guess this is related to the discussion about when the UAC should be able to receive media in the first place. It has been proposed (I guess this is also what the bis currently says) that a UAC should be able to receive media as soon as the INVITE has been sent, ie. it may receive early media even without a 183 provisional response. Or, even if a 183 provisional response is sent the media may "reach" the UAC before the 183 (which is the main reason that the media channel should be opened after the INVITE). >Additionally, I do not think it is unreasonable that if you are about >to send media then you know the address it will be sent from (assuming >that it will be sent from the same address that you specify in the >reverse SDP). Are you saying that you shouldn't include SDP in a 200 >OK because it might be behind a NAT? Of course you aren't - the SDP in >the 183 can only help an ALG resolve this situation not prevent it. You have to include the SDP in the 200 OK response, but my issue was more about your proposal to add the SDP as a MUST in the 183 provisional response, and how you can ensure that it is a "valid" SDP. Also, I guess the SDP may even change in the 200 OK. Would you then allow the new SDP? Regards, Christer Holmberg Ericsson Finland > Regards, > > Robert. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, April 17, 2001 7:43 AM > To: Ryner, Jerry > Cc: Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com' > Subject: Re: [SIP] 183 in call flows. > > << File: Card for Christer Holmberg >> > Hi Robert, > > What do you consider as a "valid" SDP? > > For example, if dynamic IP address allocation is used, or if one party > > is behind a firewall, or in a VPN, it is very difficult to make the > validity test based on the media IP address. And, if it's only about > sending any SDP in the 183 message, I think the hacker can also do > that > as well. > > Regards, > > Christer Holmberg > Ericsson Finland ------_=_NextPart_001_01C0C79E.5829ABA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] 183 in call flows.

I think there has been some confusion here.  I = sent the email raising the security issue and not Robert.  What I = meant by "valid" was simply a well formed SDP.

My point is that processing packets before an SDP is = received can lead to very poor performance, especially if a new call is = attempted very quickly after a previous call was terminated.  You = can imagine a scenario where the SIP BYE sequence fails due to a = network failure to a particular proxy say.  After timing out and = returning to Idle, the SIP endpoint initiates a new call to a different = SIP endpoint or proxy.  If the first call's remote endpoint did = not hang up, the new call will be receiving RTP packets from both = endpoints.

Hackers sending RTP (not sophisticated imposters) and = "stuck" channels will also cause problems in this early media = phase.

I realize that the bis currently allows for early = media without an SDP but I thought I would share with the forum that we = have been requested by major international carriers to never allow our = gateways to do that.


Jerry Ryner
Nuera Communications, Inc.




 -----Original Message-----
From:   Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent:   Tuesday, April 17, 2001 3:38 = AM
To:     Fairlie-Cuninghame, = Robert
Cc:     Ryner, Jerry; = 'sip@lists.bell-labs.com'
Subject:        = Re: [SIP] 183 in call flows.

 << File: Card for Christer Holmberg = >>
Hi Robert,

First, I guess this is related to the discussion = about when the UAC
should be able to receive media in the first = place.

It has been proposed (I guess this is also what the = bis currently says)
that a UAC should be able to receive media as soon = as the INVITE has
been sent, ie. it may receive early media even = without a 183 provisional
response. Or, even if a 183 provisional response is = sent the media may
"reach" the UAC before the 183 (which is = the main reason that the media
channel should be opened after the INVITE).

>Additionally, I do not think it is unreasonable = that if you are about
>to send media then you know the address it will = be sent from (assuming
>that it will be sent from the same address that = you specify in the
>reverse SDP). Are you saying that you shouldn't = include SDP in a 200
>OK because it might be behind a NAT? Of course = you aren't - the SDP in
>the 183 can only help an ALG resolve this = situation not prevent it.

You have to include the SDP in the 200 OK response, = but my issue was
more about your proposal to add the SDP as a MUST in = the 183 provisional
response, and how you can ensure that it is a = "valid" SDP.

Also, I guess the SDP may even change in the 200 OK. = Would you then
allow the new SDP?


Regards,

Christer Holmberg
Ericsson Finland

 


 
> Regards,
>
> Robert.
>
> -----Original Message-----
> From:   Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent:   Tuesday, April 17, 2001 7:43 = AM
> To:     Ryner, Jerry
> Cc:     Fairlie-Cuninghame, = Robert; 'sip@lists.bell-labs.com'
> = Subject:        Re: [SIP] 183 in = call flows.
>
>  << File: Card for Christer Holmberg = >>
> Hi Robert,
>
> What do you consider as a "valid" = SDP?
>
> For example, if dynamic IP address allocation = is used, or if one party
>
> is behind a firewall, or in a VPN, it is very = difficult to make the
> validity test based on the media IP address. = And, if it's only about
> sending any SDP in the 183 message, I think the = hacker can also do
> that
> as well.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland

------_=_NextPart_001_01C0C79E.5829ABA0-- _______________________________________________ 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 Wed Apr 18 10:41:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12032 for ; Wed, 18 Apr 2001 10:41:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15A22443A1; Wed, 18 Apr 2001 10:41:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by lists.bell-labs.com (Postfix) with ESMTP id 002CE44377 for ; Wed, 18 Apr 2001 10:40:14 -0400 (EDT) Received: from pqm-cons.demon.co.uk ([158.152.93.237] helo=P162U) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 14pt7t-000LDh-0Y; Wed, 18 Apr 2001 15:40:14 +0100 From: "Alex Hardisty" To: "Elwell, John" , "Mo Zonoun" Cc: Subject: RE: [SIP] transfer call flows 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 In-Reply-To: <5AC7D3F55147D311AA1700A0C99583ED027D09AC@beex03.siemenscomms.co.uk> 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: Wed, 18 Apr 2001 15:42:52 +0100 Content-Transfer-Encoding: 7bit John Elwell wrote: > ... > One observation I would make is that in addition to making sure that a new > INVITE in a Call Transfer gets to the correct UA-C, it is also > necessary to ensure that the INVITE from B to C links up with/replaces the > existing call from A to C. The Replaces header looks a good candidate for > doing this, as well as solving your original problem. What if UA-C is a set of geographically dispersed gateways to another network? Consider the following scenario: The Transferring and the Transferred Users are in the SIP network and the Transferred-to User (represented by UA-C1) is in the other network. The shortest route between the Transferred User and the Transferred-to User may be via a different gateway (another instance of UA-C, UA-C2) than the session (secondary call) between the Transferring User and the Transferred-to User. In this case, how does UA-C1 know that the re-routed call has been successful via UA-C2 and that the replaced original call can now be cleared? I think this can only be achieved at the Transferred-to User in the other network. It would involve the use of a "correlation identity", obtained from the Transferred-to User prior to REFER and carried in the re-routed call so that on receipt the Transferred-To User could correlate the two calls and initiate clearing of the original call. Regards -- Alex Hardisty PQM Consultants _______________________________________________ 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 Wed Apr 18 11:01:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12400 for ; Wed, 18 Apr 2001 11:01:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F80144352; Wed, 18 Apr 2001 11:01: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 699C24433A for ; Wed, 18 Apr 2001 11:00:19 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 18 10:56:24 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 7A4AB44380; Wed, 18 Apr 2001 10:45:31 -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 D64464437D for ; Wed, 18 Apr 2001 10:45:30 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 15:45:30 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E3BF@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Agboh, Charles'" , "'Yu, James'" , "Chen, Xin (Xin)" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request 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: Wed, 18 Apr 2001 15:45:21 +0100 James, Yes, I agree that we need "proxy iniated disconnct". But how? Charles, Is this standardized in sip bis? What happens if the UA donesn't support session timer header? If proxy can send invite, so it actually acts as a B2BUA, so why not just sends a Bye to caller and callee both? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@ebone.com] Sent: 18 April 2001 13:04 To: 'Yu, James'; 'Chen, Xin (Xin)' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] A question about Cancel request The proxy could use a session timeout of zero with an invite (re-invite) request for the same session. -Charles Hi james;-) > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.com] > Sent: Wednesday, April 18, 2001 2:58 PM > To: 'Chen, Xin (Xin)' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > Xin, > > Only the UA can send BYE, not the proxy server. That is why > in my earlier > e-mail I indicated that there might be a need for a "proxy initiated > disconnect." > > James > > > -----Original Message----- > > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > > Sent: Wednesday, April 18, 2001 6:10 AM > > To: 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > I couldn't find a way in sip rfc that a proxy can initate > > disconnect to a > > call if the call is established. UAS will ignore Cancel > > becuase it has sent > > 200 OK. And Bye can only been sent by UA not by proxy. So it > > seems that > > there is no way for the network to release a call if it is > established > > already. Please point out what I missed in that rfc. > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.com] > > Sent: 17 April 2001 19:36 > > To: 'Alan Johnston' > > Cc: 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] A question about Cancel request > > > > > > Alan, > > > > CANCEL is to cancel a pending a request. If the call has > > been established > > and there is no pending request to be cancelled, sending a > > cancel will not > > result in call termination. A 3G wireless caller may be put > > on hold (e.g., > > call to service center) but mobile phone is out of radio > > contact with the > > network (e.g., in the tunnel or outside coverage area). The > > 3G network > > knows about the situation; therefore, may need a way to > > terminate the call > > (instead of waiting for the UA at the other side to terminate > > the call). > > > > There is also a potential fraud case where the proxy servers > > want to stay in > > the signaling path by using the record-route and route > > mechanism but the UAs > > ignore the route and one of them sends the BYE directly to > > the other side to > > terminate the call (the UAs can ignore the protocol rules > if they are > > programmed to do so). A mechanism may be needed for the > > proxies in the > > "route" to terminate the call - something like "proxy > > initiated disconnect." > > > > James > > > > > > > > > -----Original Message----- > > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > > Sent: Tuesday, April 17, 2001 2:57 PM > > > To: Drage, Keith (Keith) > > > Cc: 'sip@lists.bell-labs.com' > > > Subject: Re: [SIP] A question about Cancel request > > > > > > > > > Keith, > > > > > > Of course nothing in the Call Flows draft is normative - in > > > any conflict between > > > it and the RFC, the RFC holds. > > > > > > Having said that, I'm not sure I understand your concern > > > here. How many > > > retransmissions the stateful proxy 2 does is an > > > implementation issue - it could > > > choose to give up at any time. Also, if the proxy wishes to > > > terminate the call, > > > its only option is to send a CANCEL - it can not originate a > > > BYE. The caller > > > User A could send either a BYE or a CANCEL to terminate the call. > > > > > > How and when a proxy initiates a CANCEL doesn't seem to need > > > to be spelled out > > > in the SIP standard. > > > > > > Thanks, > > > Alan Johnston > > > sip:alanjohnston@siptest.wcom.com > > > > > > "Drage, Keith (Keith)" wrote: > > > > > > > We have a clear incompatibility in the SIP drafts here. > > > > > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > > > implies that the > > > > expected action is to send a CANCEL, we have been unable to > > > find any text in > > > > the bis-02 draft indicating any special use of CANCEL from > > > a proxy in this > > > > case. > > > > > > > > The only text we have found is text that says anybody can > > > send a CANCEL at > > > > any time. > > > > > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > > > some text on this > > > > subject. > > > > > > > > My view is that it would say MAY, possibly followed by > > some guidance > > > > comments on conditions when it might be more appropriate > > > than others. > > > > > > > > by the way, the signalling flows draft says the CANCEL is > > > sent 7 times. I > > > > thought 11 was the more appropriate number in this case, > > > using both T1 and > > > > T2. > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > ---------- > > > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > > > Sent: 04 April 2001 7:30 > > > > > To: 'Mayank Sharma'; Chen, Xin (Xin); > sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > I have a basic question about sip. > > > > > > > Cancel request is used to cancel a pending INVITE. > > > > > > > In sip signalling establishment procedure, if the callee > > > > > > > agent for some > > > > > > > reason fails, it can't receive anything from its > > proxy, after > > > > > > > the proxy > > > > > > > server of the callee retransmittes 6 times INVITE > > messges, it > > > > > > > should give up > > > > > > > sending INVITE. My quesiton is whether the Cancel > request is > > > > > > > needed to send > > > > > > > out by the proxy server to the callee, if so, it > will cause > > > > > > > another 11 times > > > > > > > cancle request beeing sent. > > > > > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > > > reason being that the > > > > > > > > > > > > proxy does not know weather the callee UA is down or is > > > > > > simply not responding > > > > > > for the time being. Sending Cancel ensures that in > case UA is > > > > > > not down this > > > > > > Cancel > > > > > > will cancel the previous Invite, and the UA is not supposed > > > > > > to respond to > > > > > > that Invite > > > > > > at a later stage. > > > > > > > > > > Actually, I have debated whether or not CANCEL is useful > > > in the case where > > > > > you never received any provisional response at all, not > > > even a 100. This > > > > > is > > > > > likely a sign that the device or the network has failed, > > > in which case the > > > > > CANCEL is not useful. > > > > > > > > > > I would tend to think that the best answer is to say that > > > if you never > > > > > receive a provisional response, you MAY send a CANCEL, > > but its not > > > > > mandatory. If you do get a provisional response, you > > > SHOULD CANCEL upon > > > > > timeout. > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.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. > > > > > > > > > > > > > _______________________________________________ > > > > 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. > > > > _______________________________________________ > 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 Wed Apr 18 15:05:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16164 for ; Wed, 18 Apr 2001 15:05:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AE2B44366; Wed, 18 Apr 2001 15:05:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id 4BF1F44352 for ; Wed, 18 Apr 2001 15:04:19 -0400 (EDT) Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Wed, 18 Apr 2001 20:58:24 +0200 (W. Europe Daylight Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id <26Z3RKK4>; Wed, 18 Apr 2001 21:04:12 +0200 Message-ID: From: "Agboh, Charles" To: "'Chen, Xin (Xin)'" , "'Yu, James'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Wed, 18 Apr 2001 21:04:10 +0200 My description was not quiet clear; The SIP FAQ explains that better.... http://www.cs.columbia.edu/~hgs/sip/faq.cgi?_highlightWords=timer&file=40 .....However, state might be useful for certain applications (e.g., when billing is involved, when firewall permissions need to be set etc.). Session timer extension has been defined to solve this. The draft can be found at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-session-timer-01.t xt and it basically allows the servers indicate a desired refresh interval. The call is considered terminated if a re-INVITE is not received within that interval It is not a standard way of terminating a session. -Charles > -----Original Message----- > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > Sent: Wednesday, April 18, 2001 4:45 PM > To: Agboh, Charles; 'Yu, James'; Chen, Xin (Xin) > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > James, > Yes, I agree that we need "proxy iniated disconnct". But how? > > Charles, > Is this standardized in sip bis? What happens if the UA > donesn't support > session timer header? If proxy can send invite, so it > actually acts as a > B2BUA, so why not just sends a Bye to caller and callee both? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@ebone.com] > Sent: 18 April 2001 13:04 > To: 'Yu, James'; 'Chen, Xin (Xin)' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] A question about Cancel request > > > The proxy could use a session timeout of zero with an invite > (re-invite) > request for the same session. > > -Charles > Hi james;-) > > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.com] > > Sent: Wednesday, April 18, 2001 2:58 PM > > To: 'Chen, Xin (Xin)' > > Cc: 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] A question about Cancel request > > > > > > Xin, > > > > Only the UA can send BYE, not the proxy server. That is why > > in my earlier > > e-mail I indicated that there might be a need for a "proxy initiated > > disconnect." > > > > James > > > > > -----Original Message----- > > > From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] > > > Sent: Wednesday, April 18, 2001 6:10 AM > > > To: 'sip@lists.bell-labs.com' > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > I couldn't find a way in sip rfc that a proxy can initate > > > disconnect to a > > > call if the call is established. UAS will ignore Cancel > > > becuase it has sent > > > 200 OK. And Bye can only been sent by UA not by proxy. So it > > > seems that > > > there is no way for the network to release a call if it is > > established > > > already. Please point out what I missed in that rfc. > > > > > > Thanks > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Yu, James [mailto:james.yu@neustar.com] > > > Sent: 17 April 2001 19:36 > > > To: 'Alan Johnston' > > > Cc: 'sip@lists.bell-labs.com' > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > Alan, > > > > > > CANCEL is to cancel a pending a request. If the call has > > > been established > > > and there is no pending request to be cancelled, sending a > > > cancel will not > > > result in call termination. A 3G wireless caller may be put > > > on hold (e.g., > > > call to service center) but mobile phone is out of radio > > > contact with the > > > network (e.g., in the tunnel or outside coverage area). The > > > 3G network > > > knows about the situation; therefore, may need a way to > > > terminate the call > > > (instead of waiting for the UA at the other side to terminate > > > the call). > > > > > > There is also a potential fraud case where the proxy servers > > > want to stay in > > > the signaling path by using the record-route and route > > > mechanism but the UAs > > > ignore the route and one of them sends the BYE directly to > > > the other side to > > > terminate the call (the UAs can ignore the protocol rules > > if they are > > > programmed to do so). A mechanism may be needed for the > > > proxies in the > > > "route" to terminate the call - something like "proxy > > > initiated disconnect." > > > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > > > Sent: Tuesday, April 17, 2001 2:57 PM > > > > To: Drage, Keith (Keith) > > > > Cc: 'sip@lists.bell-labs.com' > > > > Subject: Re: [SIP] A question about Cancel request > > > > > > > > > > > > Keith, > > > > > > > > Of course nothing in the Call Flows draft is normative - in > > > > any conflict between > > > > it and the RFC, the RFC holds. > > > > > > > > Having said that, I'm not sure I understand your concern > > > > here. How many > > > > retransmissions the stateful proxy 2 does is an > > > > implementation issue - it could > > > > choose to give up at any time. Also, if the proxy wishes to > > > > terminate the call, > > > > its only option is to send a CANCEL - it can not originate a > > > > BYE. The caller > > > > User A could send either a BYE or a CANCEL to terminate > the call. > > > > > > > > How and when a proxy initiates a CANCEL doesn't seem to need > > > > to be spelled out > > > > in the SIP standard. > > > > > > > > Thanks, > > > > Alan Johnston > > > > sip:alanjohnston@siptest.wcom.com > > > > > > > > "Drage, Keith (Keith)" wrote: > > > > > > > > > We have a clear incompatibility in the SIP drafts here. > > > > > > > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > > > > implies that the > > > > > expected action is to send a CANCEL, we have been unable to > > > > find any text in > > > > > the bis-02 draft indicating any special use of CANCEL from > > > > a proxy in this > > > > > case. > > > > > > > > > > The only text we have found is text that says anybody can > > > > send a CANCEL at > > > > > any time. > > > > > > > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > > > > some text on this > > > > > subject. > > > > > > > > > > My view is that it would say MAY, possibly followed by > > > some guidance > > > > > comments on conditions when it might be more appropriate > > > > than others. > > > > > > > > > > by the way, the signalling flows draft says the CANCEL is > > > > sent 7 times. I > > > > > thought 11 was the more appropriate number in this case, > > > > using both T1 and > > > > > T2. > > > > > > > > > > Keith > > > > > > > > > > Keith Drage > > > > > Lucent Technologies > > > > > Tel: +44 1793 776249 > > > > > Email: drage@lucent.com > > > > > > > > > > > ---------- > > > > > > From: Jonathan > Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > > > > Sent: 04 April 2001 7:30 > > > > > > To: 'Mayank Sharma'; Chen, Xin (Xin); > > sip@lists.bell-labs.com > > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > I have a basic question about sip. > > > > > > > > Cancel request is used to cancel a pending INVITE. > > > > > > > > In sip signalling establishment procedure, if the callee > > > > > > > > agent for some > > > > > > > > reason fails, it can't receive anything from its > > > proxy, after > > > > > > > > the proxy > > > > > > > > server of the callee retransmittes 6 times INVITE > > > messges, it > > > > > > > > should give up > > > > > > > > sending INVITE. My quesiton is whether the Cancel > > request is > > > > > > > > needed to send > > > > > > > > out by the proxy server to the callee, if so, it > > will cause > > > > > > > > another 11 times > > > > > > > > cancle request beeing sent. > > > > > > > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > > > > reason being that the > > > > > > > > > > > > > > proxy does not know weather the callee UA is down or is > > > > > > > simply not responding > > > > > > > for the time being. Sending Cancel ensures that in > > case UA is > > > > > > > not down this > > > > > > > Cancel > > > > > > > will cancel the previous Invite, and the UA is > not supposed > > > > > > > to respond to > > > > > > > that Invite > > > > > > > at a later stage. > > > > > > > > > > > > Actually, I have debated whether or not CANCEL is useful > > > > in the case where > > > > > > you never received any provisional response at all, not > > > > even a 100. This > > > > > > is > > > > > > likely a sign that the device or the network has failed, > > > > in which case the > > > > > > CANCEL is not useful. > > > > > > > > > > > > I would tend to think that the best answer is to say that > > > > if you never > > > > > > receive a provisional response, you MAY send a CANCEL, > > > but its not > > > > > > mandatory. If you do get a provisional response, you > > > > SHOULD CANCEL upon > > > > > > timeout. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 > Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East > > > Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: > > > (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > > (973) 952-5000 > > > > > > http://www.dynamicsoft.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. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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. > > > > > > > _______________________________________________ > > 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 Wed Apr 18 15:08:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16225 for ; Wed, 18 Apr 2001 15:08:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 443BF443B8; Wed, 18 Apr 2001 15:08:04 -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 1A24E443AC for ; Wed, 18 Apr 2001 15:07:43 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA05724 for ; Wed, 18 Apr 2001 15:11:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Apr 2001 15:07:42 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C83A.D7C22D6F" Subject: [SIP] I need more email addresses. 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: Wed, 18 Apr 2001 15:07:41 -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_01C0C83A.D7C22D6F Content-Type: text/plain; charset="iso-8859-1" If anyone has the email addresses for the following people I would appreciate it: Zimmerer, E Ong, L Audet, F Watson, M Zonoun, M Regards, Rakesh _______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue 1st Floor East Hanover, N.J. 07936 (973) 952-5066 direct (201) 214-6084 cell (973) 952-5000 main (973) 952-5050 fax rshah@dynamicsoft.com ------_=_NextPart_001_01C0C83A.D7C22D6F Content-Type: text/html; charset="iso-8859-1"
If anyone has the email addresses for the following people I would appreciate it:
 
Zimmerer, E
Ong, L
Audet, F
Watson, M
Zonoun, M

Regards,

Rakesh
_______________________________
Mr. Rakesh C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
1st Floor
East Hanover, N.J. 07936
(973) 952-5066 direct
(201) 214-6084 cell
(973) 952-5000 main
(973) 952-5050 fax
rshah@dynamicsoft.com

 
------_=_NextPart_001_01C0C83A.D7C22D6F-- _______________________________________________ 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 Wed Apr 18 22:20:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21528 for ; Wed, 18 Apr 2001 22:20:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED4E74433F; Wed, 18 Apr 2001 22:20:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by lists.bell-labs.com (Postfix) with ESMTP id 30E9344337 for ; Wed, 18 Apr 2001 22:19:16 -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 f3J2IjA23004 for ; Wed, 18 Apr 2001 22:18:45 -0400 (EDT) Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59]) by iere.net.avaya.com (8.11.2/8.9.3) with SMTP id f3J2IiD23000; Wed, 18 Apr 2001 22:18:44 -0400 (EDT) Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2) id UAA04155; Wed, 18 Apr 2001 20:19:13 -0600 Message-ID: <3ADE4A28.F5F8967D@avaya.com> From: Joanne McMillen Organization: Avaya Inc. X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Hardisty Cc: "Elwell, John" , Mo Zonoun , sip@lists.bell-labs.com Subject: Re: [SIP] transfer call flows 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: Wed, 18 Apr 2001 20:15:04 -0600 Content-Transfer-Encoding: 7bit > What if UA-C is a set of geographically dispersed gateways to another > network? Consider the following scenario: Good point and I am happy to see discussion moving to this level. Joanne McMillen Avaya Inc. _______________________________________________ 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 Apr 19 02:03:17 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04328 for ; Thu, 19 Apr 2001 02:03:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9BAC4433A; Thu, 19 Apr 2001 01:56:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 7E9CF44337 for ; Thu, 19 Apr 2001 01:55:38 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3J5sp225137 for ; Thu, 19 Apr 2001 08:54:51 +0300 (EET DST) Received: from esebh12nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Apr 2001 08:55:06 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id GS54VZ0W; Thu, 19 Apr 2001 08:55:06 +0300 Received: from agni.research.nokia.com (IDENT:root@agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id IAA24402; Thu, 19 Apr 2001 08:55:06 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.0/8.11.0) id f3J5t6902212; Thu, 19 Apr 2001 08:55:06 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: "'sip@lists.bell-labs.com'" Cc: "Drage, Keith (Keith)" Subject: Re: [SIP] A question about Cancel request References: <475FF955A05DD411980D00508B6D5FB001AC31B0@en0033exch001u.uk.lucent.com> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: "Drage, Keith's message of "Wed, 18 Apr 2001 09:59:13 +0100" Message-ID: Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: 19 Apr 2001 08:55:05 +0300 In message <475FF955A05DD411980D00508B6D5FB001AC31B0@en0033exch001u.uk.lucent.com> "Drage, Keith (Keith)" writes: >My concern is that primarily we have a hole in the bis draft about what the >proxy should do in this case. >Having transmitted the INVITE, and failed to receive a response (despite >retransmitting according to the fairly fully specified algorithm), is it >required to send a CANCEL forward in order to cancel the INVITE, as >indicated by the call-flows draft, but with no supporting text in the bis >draft, or is it permissable, or even required, to do nothing further in the >forward direction, and merely provide a response in the backward direction. The section 12.4 in the bis-02 (Nov 2000) states that a forking proxy MAY send a CANCEL to all incomplete branches. A stateful proxy is a forking proxy with one fork. A reasonable approach would be to retransmit CANCEL only if a provisional response has been received for that transaction. Pekka _______________________________________________ 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 Apr 19 06:21:12 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09690 for ; Thu, 19 Apr 2001 06:21:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 256944433F; Thu, 19 Apr 2001 06:21:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 1F7604433A for ; Thu, 19 Apr 2001 06:20:00 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3JAJM205016 for ; Thu, 19 Apr 2001 13:19:23 +0300 (EET DST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Apr 2001 13:19:45 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh03nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 2LH631LN; Thu, 19 Apr 2001 13:19:44 +0300 Received: from agni.research.nokia.com (IDENT:root@agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA27986; Thu, 19 Apr 2001 13:19:44 +0300 (EETDST) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.0/8.11.0) id f3JAJhC03069; Thu, 19 Apr 2001 13:19:43 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: sip@lists.bell-labs.com Cc: "Fairlie-Cuninghame, Robert" Subject: Re: [SIP] Request-uri does not match record-route header... References: X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: "Fairlie-Cuninghame, Robert"'s message of "Fri, 13 Apr 2001 04:24:12 -0700" Message-ID: Lines: 31 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: 19 Apr 2001 13:19:43 +0300 In message "Fairlie-Cuninghame, Robert" writes: >For instance, when a UA or Proxy, puts the first Route header in the >Request-URI but then sends the message to an outbound proxy because the >UA lacks DNS capability. The outbound proxy may not have Record-Route'd >but it must not remove/process the next Route header either. Jonathan's record-route text does not address the UAC behaviour when it is using outbound proxy. The last paragraph in the section 11.4 of bis-02 defines the procedure when the UAC is sending everything to the outbound proxy. It states that UAC "MUST include all Route header fields, i.e., the UAC does not remove the first Route header field." The example run from Sherman Gong did exactly that. Somehow I think that the SIP spec could be better organized. >At risk of reopening this discussion, did we reach at conclusion on this >point, that is, when a proxy should use the next Route header and when >should it not (if the Request-URI is does not resolve to the proxy's >address)? Proxies should always use the next route header. However, there is a problem if the initial RequestURI and the first url in the route are identical (sans maddr and other transport parameters, which are removed by sender). If the outbound proxy has record-routed the initial request, it will cause a loop and 482 unless it somehow notices that the first entry in route points to itself. BR, Pekka _______________________________________________ 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 Apr 19 06:28:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09750 for ; Thu, 19 Apr 2001 06:28:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C66FB4435A; Thu, 19 Apr 2001 06:28:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.siemenscomms.co.uk (mailgate.sgcs.co.uk [194.129.217.115]) by lists.bell-labs.com (Postfix) with ESMTP id F0FFA4433F for ; Thu, 19 Apr 2001 06:27:02 -0400 (EDT) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0GC100401BLS1U@siemenscomms.co.uk> for sip@lists.bell-labs.com; Thu, 19 Apr 2001 11:25:31 +0100 (BST) Received: from beex10.siemenscomms.co.uk (beex10.siemenscomms.co.uk [137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0GC1000PABKXBR@siemenscomms.co.uk>; Thu, 19 Apr 2001 11:24:33 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id <29J91X0Z>; Thu, 19 Apr 2001 11:25:55 +0100 Content-return: allowed From: "Elwell, John" Subject: RE: [SIP] transfer call flows To: "'Alex Hardisty'" Cc: sip@lists.bell-labs.com Message-id: <5AC7D3F55147D311AA1700A0C99583ED027D09C1@beex03.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 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: Thu, 19 Apr 2001 11:27:10 +0100 Content-Transfer-Encoding: 7BIT Alex Hardisty wrote: > What if UA-C is a set of geographically dispersed gateways to another > network? Consider the following scenario: > > The Transferring and the Transferred Users are in the SIP > network and the > Transferred-to User (represented by UA-C1) is in the other > network. The > shortest route between the Transferred User and the > Transferred-to User may > be via a different gateway (another instance of UA-C, UA-C2) than the > session (secondary call) between the Transferring User and the > Transferred-to User. In this case, how does UA-C1 know that > the re-routed > call has been successful via UA-C2 and that the replaced > original call can > now be cleared? I think this can only be achieved at the > Transferred-to User > in the other network. > It would involve the use of a "correlation identity", > obtained from the > Transferred-to User prior to REFER and carried in the > re-routed call so that > on receipt the Transferred-To User could correlate the two calls and > initiate clearing of the original call. I agree there is a problem here and it needs to be solved, but I am not convinced Alex's solution is the only one. Alex's solution depends on the other network having the capability of linking the new call with the original call. This is not the case for some legacy networks. An alternative solution would be to force the new call to be routed to UA-C1, even though in normal circumstances it might be routed through UA-C2. It is not clear to me whether current proposals can accomplish this. Any thoughts? -------------------------------------------------------------- John Elwell (john.elwell@siemenscomms.co.uk) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4989 Fax: +44 115 943 4969 -------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. _______________________________________________ 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 Apr 19 06:34:12 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09800 for ; Thu, 19 Apr 2001 06:34:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 077144439B; Thu, 19 Apr 2001 06:34:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4539944398 for ; Thu, 19 Apr 2001 06:33:43 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for [204.178.16.58]) with SMTP; 19 Apr 2001 10:33:43 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA18182; Thu, 19 Apr 2001 10:32:50 GMT From: "Jo Hornsby" To: "Pekka Pessi" , Cc: "Fairlie-Cuninghame, Robert" Subject: RE: [SIP] Request-uri does not match record-route header... Message-ID: <000601c0c8bc$1670ec40$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 In-Reply-To: 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: Thu, 19 Apr 2001 11:32:51 +0100 Content-Transfer-Encoding: 7bit > Proxies should always use the next route header. > > However, there is a problem if the initial RequestURI and > the first > url in the route are identical (sans maddr and other transport > parameters, which are removed by sender). Uh, at the risk that this is orthoganol to the issue at hand, why would these parameters be removed? Note that they're no- longer illegal in the Request-URI (I think they were in RFC). - Jo. _______________________________________________ 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 Apr 19 09:19:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10661 for ; Thu, 19 Apr 2001 09:19:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5704244346; Thu, 19 Apr 2001 09:19: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 EBA0F4433A for ; Thu, 19 Apr 2001 09:18:19 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 19 09:14:43 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 0D92F44380; Thu, 19 Apr 2001 09:03:51 -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 7F1FB4437D for ; Thu, 19 Apr 2001 09:03:50 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 14:03:49 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31C3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Editorial nit in bis draft 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, 19 Apr 2001 14:03:48 +0100 Looking at the -02 version of the bis draft. The text string associated with status-code 504 is inconsistent within the document. In figure 7 (the syntactic definition) it is given as | "504" ; Gateway Time-out In section 7.5.5, the semantic definition, it is given as: 7.5.5 504 Server Time-out The first usage is consistent with HTTP, but presumably introduces the term gateway in a form that is not completely consistent with SIP. Whatever happens, we need to align them one way or the other. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.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@lists.bell-labs.com Thu Apr 19 15:45:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17410 for ; Thu, 19 Apr 2001 15:45:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D339F4433A; Thu, 19 Apr 2001 15:45:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id E799D44337 for ; Thu, 19 Apr 2001 15:44:02 -0400 (EDT) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3JDhMP08184; Thu, 19 Apr 2001 08:43:22 -0500 Message-ID: <015f01c0c909$0beddb00$54d0723f@dynamicsoft.com> From: "Dean Willis" To: "Yu, James" , "'Alan Johnston'" Cc: References: Subject: Re: [SIP] A question about Cancel request 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 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, 19 Apr 2001 14:36:43 -0500 Content-Transfer-Encoding: 7bit The session-timer specification provides information to allow a stateful proxy to know when to discard state on a call. Bypassing the proxy is not really a "fraud" issue -- anybody billing on proxied call terminations without having some other mechanisms that enforce transiting the firewalls is just hoping that somebody will be nice to them. -- Dean ----- Original Message ----- From: "Yu, James" To: "'Alan Johnston'" Cc: Sent: Tuesday, April 17, 2001 2:36 PM Subject: RE: [SIP] A question about Cancel request > Alan, > > CANCEL is to cancel a pending a request. If the call has been established > and there is no pending request to be cancelled, sending a cancel will not > result in call termination. A 3G wireless caller may be put on hold (e.g., > call to service center) but mobile phone is out of radio contact with the > network (e.g., in the tunnel or outside coverage area). The 3G network > knows about the situation; therefore, may need a way to terminate the call > (instead of waiting for the UA at the other side to terminate the call). > > There is also a potential fraud case where the proxy servers want to stay in > the signaling path by using the record-route and route mechanism but the UAs > ignore the route and one of them sends the BYE directly to the other side to > terminate the call (the UAs can ignore the protocol rules if they are > programmed to do so). A mechanism may be needed for the proxies in the > "route" to terminate the call - something like "proxy initiated disconnect." > > James > > > > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > Sent: Tuesday, April 17, 2001 2:57 PM > > To: Drage, Keith (Keith) > > Cc: 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] A question about Cancel request > > > > > > Keith, > > > > Of course nothing in the Call Flows draft is normative - in > > any conflict between > > it and the RFC, the RFC holds. > > > > Having said that, I'm not sure I understand your concern > > here. How many > > retransmissions the stateful proxy 2 does is an > > implementation issue - it could > > choose to give up at any time. Also, if the proxy wishes to > > terminate the call, > > its only option is to send a CANCEL - it can not originate a > > BYE. The caller > > User A could send either a BYE or a CANCEL to terminate the call. > > > > How and when a proxy initiates a CANCEL doesn't seem to need > > to be spelled out > > in the SIP standard. > > > > Thanks, > > Alan Johnston > > sip:alanjohnston@siptest.wcom.com > > > > "Drage, Keith (Keith)" wrote: > > > > > We have a clear incompatibility in the SIP drafts here. > > > > > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 > > implies that the > > > expected action is to send a CANCEL, we have been unable to > > find any text in > > > the bis-02 draft indicating any special use of CANCEL from > > a proxy in this > > > case. > > > > > > The only text we have found is text that says anybody can > > send a CANCEL at > > > any time. > > > > > > Whether it is MUST, MAY or MUST NOT I believe we do need > > some text on this > > > subject. > > > > > > My view is that it would say MAY, possibly followed by some guidance > > > comments on conditions when it might be more appropriate > > than others. > > > > > > by the way, the signalling flows draft says the CANCEL is > > sent 7 times. I > > > thought 11 was the more appropriate number in this case, > > using both T1 and > > > T2. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > ---------- > > > > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > > > > Sent: 04 April 2001 7:30 > > > > To: 'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mayank Sharma [mailto:mayanks@mindtree.com] > > > > > Sent: Tuesday, April 03, 2001 1:46 AM > > > > > To: Chen, Xin (Xin); sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] A question about Cancel request > > > > > > > > > > > > > > > > I have a basic question about sip. > > > > > > Cancel request is used to cancel a pending INVITE. > > > > > > In sip signalling establishment procedure, if the callee > > > > > > agent for some > > > > > > reason fails, it can't receive anything from its proxy, after > > > > > > the proxy > > > > > > server of the callee retransmittes 6 times INVITE messges, it > > > > > > should give up > > > > > > sending INVITE. My quesiton is whether the Cancel request is > > > > > > needed to send > > > > > > out by the proxy server to the callee, if so, it will cause > > > > > > another 11 times > > > > > > cancle request beeing sent. > > > > > > > > > > The Cancel is required to be sent to the callee. Simple > > > > > reason being that the > > > > > > > > > > proxy does not know weather the callee UA is down or is > > > > > simply not responding > > > > > for the time being. Sending Cancel ensures that in case UA is > > > > > not down this > > > > > Cancel > > > > > will cancel the previous Invite, and the UA is not supposed > > > > > to respond to > > > > > that Invite > > > > > at a later stage. > > > > > > > > Actually, I have debated whether or not CANCEL is useful > > in the case where > > > > you never received any provisional response at all, not > > even a 100. This > > > > is > > > > likely a sign that the device or the network has failed, > > in which case the > > > > CANCEL is not useful. > > > > > > > > I would tend to think that the best answer is to say that > > if you never > > > > receive a provisional response, you MAY send a CANCEL, but its not > > > > mandatory. If you do get a provisional response, you > > SHOULD CANCEL upon > > > > timeout. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.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. > > > > > > > > > > _______________________________________________ > > > 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@lists.bell-labs.com Thu Apr 19 16:03:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17740 for ; Thu, 19 Apr 2001 16:03:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0D88443B0; Thu, 19 Apr 2001 16:03:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id D0E5C4439F for ; Thu, 19 Apr 2001 16:02:17 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA08186 for ; Thu, 19 Apr 2001 13:02:16 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA23891 for ; Thu, 19 Apr 2001 13:02:16 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id <28RVKFJY>; Thu, 19 Apr 2001 15:02:16 -0500 Message-ID: <557F0D0BBE89D411A085009027B0F741B5E62C@IL27EXM08.cig.mot.com> From: Ziyad Nigel-NZIYAD1 To: "Drage, Keith (Keith)" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Editorial nit in bis draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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, 19 Apr 2001 15:02:16 -0500 Keith, Looking at rfc2543bis and comparing it to rfc2616 would lead me to believe RFC2543bis should read "504 Gateway Time-out". The description of server actions would be consistent with the original definition and usage of the 504 status code. I suppose the next question is: Does the server acts as a "gateway or proxy" when the 504 is needed, as intended in the RFC2543bis? I believe that to be true. RFC2543bis reads: 7.5.5 504 Server Time-out The server did not receive a timely response from the server (e.g., a location server) it accessed in attempting to process the request. Note that 408 (Request Timeout) should be used if there was no response within the period specified in the Expires header field from the upstream server. RFC 2616 reads: 10.5.5 504 Gateway Timeout The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. Dr. Nigel A. Ziyad Senior Staff Engineer Motorola GTSS--Network Standards & Advanced Technology Phone: 847-632-2098 Fax: 847-632-7912 Pager (2-way): 888-478-0351 or 4780351@skytel.com -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Thursday, April 19, 2001 8:04 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] Editorial nit in bis draft Looking at the -02 version of the bis draft. The text string associated with status-code 504 is inconsistent within the document. In figure 7 (the syntactic definition) it is given as | "504" ; Gateway Time-out In section 7.5.5, the semantic definition, it is given as: 7.5.5 504 Server Time-out The first usage is consistent with HTTP, but presumably introduces the term gateway in a form that is not completely consistent with SIP. Whatever happens, we need to align them one way or the other. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.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. _______________________________________________ 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 Apr 19 16:35:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18075 for ; Thu, 19 Apr 2001 16:35:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 56646443AC; Thu, 19 Apr 2001 16:35:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id 586D844337 for ; Thu, 19 Apr 2001 16:34:40 -0400 (EDT) Received: from 207.77.231.73 by smtp1.gtsgroup.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 22:28:49 +0200 (W. Europe Daylight Time) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id <26Z3SCR7>; Thu, 19 Apr 2001 22:34:38 +0200 Message-ID: From: "Agboh, Charles" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] 400 bad request 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, 19 Apr 2001 22:34:37 +0200 Hi, For what reasons other than failed codec nogotiation will a UA send a 400 bad request without some appropriate warning? gw-to-7960 --------------- INVITE sip:+3000@10.1.1.105;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Date: Mon, 03 Jan 2000 04:30:14 GMT Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Cisco-Guid: 2416467364-982057087-0-185416476 User-Agent: Cisco-SIPGateway/IOS-12.x CSeq: 101 INVITE Max-Forwards: 6 Timestamp: 946870214 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 133 v=0 o=CiscoSystemsSIP-GW-UserAgent 5057 1112 IN IP4 10.1.1.90 s=SIP Call c=IN IP4 10.1.1.90 t=0 0 m=audio 20486 RTP/AVP 8 0 18 7960-to-gw ----------------- SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Server: Cisco IP Phone/ Rev. 1/ SIP enabled CSeq: 101 INVITE Content-Length: 0 gw-to-7960 ----------------- ACK sip:+3000@10.1.1.105;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Date: Mon, 03 Jan 2000 04:30:14 GMT Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Max-Forwards: 6 Content-Length: 0 CSeq: 101 ACK Best Regards, Charles ============== Charles Agboh Ebone M: +32 495 58 52 67 _______________________________________________ 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 Apr 20 09:27:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11724 for ; Fri, 20 Apr 2001 09:27:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78BCB4433A; Fri, 20 Apr 2001 09:27: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 BE75F44337 for ; Fri, 20 Apr 2001 09:26:18 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr 20 09:22:31 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 4850344380; Fri, 20 Apr 2001 09:11:38 -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 BD3414437D for ; Fri, 20 Apr 2001 09:11:37 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 14:11:36 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E3C6@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" 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] Questions about session timer 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, 20 Apr 2001 14:11:35 +0100 In session timer internet draft, it says: "Similarly, if a proxy doesn't receive a re-INVITE before expiration of the session, it MAY remove associated call state, and MAY free any resources associated with the call." The question is since proxy server might not be in the session traffic path, caller and callee can still talk each other. How can the proxy release the resource (such as RSVP) for traffic transmission between the caller and callee if it is not in the traffic path? According to my understanding, one way to achieve this is the proxy has to been in the traffic path, itself also has to been a NAT/Firewall, so that it can close the holes and release the address binding for traffic transmission on NAT/Firewall. If the proxy is not in the traffic path, there has to be an interface between the proxy and a NAT/Firewall which is in the path, so that the proxy can instruct the NAT/Firewall block the traffic. Who can please clean my confusion about this? Please give me some detail on how the proxy free ANY resources associated with the call. Also, is there a way that a proxy can release an established session when session timer is not supported in the proxy? Can the proxy act like a B2BUA and send Bye to both ends? 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@lists.bell-labs.com Fri Apr 20 13:49:19 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15365 for ; Fri, 20 Apr 2001 13:49: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 D94224438D; Fri, 20 Apr 2001 13:49:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id E636044346 for ; Fri, 20 Apr 2001 13:48:16 -0400 (EDT) Received: from roland (207.104.210.147 [207.104.210.147]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JJTY7ASL; Fri, 20 Apr 2001 10:51:43 -0700 Message-ID: <01b301c0c9c2$5e6fd680$93d268cf@netrue.com> From: "Roland" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B0_01C0C987.ACE2B340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] what is the detail meaning for Require, Support, Unsupport header 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, 20 Apr 2001 10:50:12 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_01B0_01C0C987.ACE2B340 Content-Type: text/plain; charset="hz-gb-2312" Content-Transfer-Encoding: quoted-printable Hello all, The Require header is described like this: Require =3D "Require" ":" 1#option-tag same as Support and unsupport header. I don't know what is the meaning of option-tag here.=20 does it represcent a header?=20 the example in 2543 shows Require: org.ietf.sip.encrypt-response so what is detail meaning of org.ietf.sip.encrypt-response,=20 how do I process this in the UAS . =20 Thanks very much =20 roland ------=_NextPart_000_01B0_01C0C987.ACE2B340 Content-Type: text/html; charset="hz-gb-2312" Content-Transfer-Encoding: quoted-printable
Hello all,
   The Require header is = described like=20 this:
     =  Require =3D "Require" ":"=20 1#option-tag
  same as Support and unsupport = header.
 
  I don't know what is the meaning of = option-tag=20 here.
  does it represcent a header? =
 
  the example in 2543 = shows    =20 Require:=20 org.ietf.sip.encrypt-response
  so what is  detail = meaning of=20 org.ietf.sip.encrypt-response,
  how do I process this in the UAS = .
 
Thanks very much
 
roland
------=_NextPart_000_01B0_01C0C987.ACE2B340-- _______________________________________________ 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 Sat Apr 21 12:01:23 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11052 for ; Sat, 21 Apr 2001 12:01: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 5D74C44369; Sat, 21 Apr 2001 12:01:07 -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 D50C2443AA for ; Fri, 20 Apr 2001 10:18:06 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GC30075JH0QQN@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 20 Apr 2001 14:17:15 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GC300E01H0MOA@dgismtp02.wcomnet.com>; Fri, 20 Apr 2001 14:17:14 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GC300D8CH0GTV@dgismtp02.wcomnet.com>; Fri, 20 Apr 2001 14:17:05 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 14:17:04 +0000 Content-return: allowed From: "Brierre, Jean Joseph" Subject: RE: [SIP] 400 bad request To: "'Agboh, Charles'" , sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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, 20 Apr 2001 14:17:03 +0000 Charles, In your below trace, if 3000 does not match a valid dial peer translation in your gateway, it will return 400 response. -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@ebone.com] Sent: Thursday, April 19, 2001 3:35 PM To: sip@lists.bell-labs.com Subject: [SIP] 400 bad request Hi, For what reasons other than failed codec nogotiation will a UA send a 400 bad request without some appropriate warning? gw-to-7960 --------------- INVITE sip:+3000@10.1.1.105;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Date: Mon, 03 Jan 2000 04:30:14 GMT Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Cisco-Guid: 2416467364-982057087-0-185416476 User-Agent: Cisco-SIPGateway/IOS-12.x CSeq: 101 INVITE Max-Forwards: 6 Timestamp: 946870214 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 133 v=0 o=CiscoSystemsSIP-GW-UserAgent 5057 1112 IN IP4 10.1.1.90 s=SIP Call c=IN IP4 10.1.1.90 t=0 0 m=audio 20486 RTP/AVP 8 0 18 7960-to-gw ----------------- SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Server: Cisco IP Phone/ Rev. 1/ SIP enabled CSeq: 101 INVITE Content-Length: 0 gw-to-7960 ----------------- ACK sip:+3000@10.1.1.105;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.1.1.90:52918 From: To: Date: Mon, 03 Jan 2000 04:30:14 GMT Call-ID: 90085DA4-3A890081-0-B0D3B24@10.1.3.1 Max-Forwards: 6 Content-Length: 0 CSeq: 101 ACK Best Regards, Charles ============== Charles Agboh Ebone M: +32 495 58 52 67 _______________________________________________ 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 Apr 23 01:12:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18826 for ; Mon, 23 Apr 2001 01:12:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3946F44337; Mon, 23 Apr 2001 01:12:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailweb8.rediffmail.com (unknown [202.54.124.153]) by lists.bell-labs.com (Postfix) with SMTP id 2A9E144336 for ; Mon, 23 Apr 2001 01:11:34 -0400 (EDT) Received: (qmail 27098 invoked by uid 510); 23 Apr 2001 05:05:52 -0000 Message-ID: <20010423050552.27097.qmail@mailweb8.rediffmail.com> Received: from unknown (203.197.74.150) by rediffmail.com via HTTP; 23 Apr 2001 05:05:52 -0000 MIME-Version: 1.0 To: "sip@vovida.org" , "sip@lists.bell-labs.com" From: "Manish S. Jalan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] Doubt in SDP negotiation while establishing a session in 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: 23 Apr 2001 05:05:52 -0000 Content-Transfer-Encoding: 7bit Hi, I need some more information on sdp. I want to use G.723 encoding for the rtp. Hence in the media description, I may give, m=audio 12345 RTP/AVP 4 a=rtpmap:4 G723/8000 My query is, G.723 is a dual rate encoding scheme. One at 5.3Kbps and another at 6.3 Kbps. Now, how to tell the destination, what bit-rate I am talking of? In the rtpmap, I read in the rfc on sdp, we can specify some encoding parameters, like the number of channels being used. Can we specify the bit rate being used in rtpmap itself? How? If not, then how to convey the bit-rate info? Eagerly waiting for your help. Thanks in advance. Regards, -Manish S. Jalan _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.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@lists.bell-labs.com Mon Apr 23 01:42:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22009 for ; Mon, 23 Apr 2001 01:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B86DC44348; Mon, 23 Apr 2001 01:42:01 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 0991A44341 for ; Mon, 23 Apr 2001 01:41:56 -0400 (EDT) Received: from dwillis (dwillis3.directlink.net [63.64.250.84]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3MNfKP22013; Sun, 22 Apr 2001 18:41:20 -0500 Message-ID: <002f01d856d4$2edb2940$54fa403f@directlink.net> From: "Dean Willis" To: "Chen, Xin (Xin)" , References: <475FF955A05DD411980D00508B6D5FB00192E3C6@en0033exch001u.uk.lucent.com> Subject: Re: [SIP] Questions about session timer 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: Sat, 23 Apr 2022 00:37:12 -0500 Content-Transfer-Encoding: 7bit If the endpoints have started ignoring record-route and started talking without the proxy in question, it's fairly clear that they don't really think they NEED the proxy to hang around and proxy messages for them anymore, so the proxy can probably just give up and go home. On the other hand, if they DO really need the proxy (because it controls resources they need) and they start ignoring record route, it's fairly clear that they're not exactly playing by the rules and may need this pointed out to them . . . The only "state" that a proxy can safely control is the state of signaling that has passed through that proxy -- in essence discarding state means knowing when it's OK to give up on the signaling because the clients don't appear to be using that proxy anymore. For example, a proxy which uses call state to maintain a set of pinholes in a firewall needs to know when it can safely close those pinholes. It normally does this when it sees a "BYE" on the call associated with those pinholes. Of course, it could also decide to close the pinholes because it hasn't seen media in a whiole, or because it hasn't seen signaling in a while, or because the credit for the call has been used up, etc. What the session-timer mechanism does is allow a proxy to inform clients that it WILL be giving up on them if they haven't sent signaling (the INVITE sequence) in some reasonable period of time. If a client fails to heed this warning, it's entirely possible that the network experience it receives won't be what it was hoping for. And yes, there is generally a am interface between a proxy and a middlebox (such as a firewall) which is working with that proxy to enforce some sort of network policy. -- Dean ----- Original Message ----- From: "Chen, Xin (Xin)" To: Sent: Friday, April 20, 2001 8:11 AM Subject: [SIP] Questions about session timer > > In session timer internet draft, it says: "Similarly, if a proxy doesn't > receive a re-INVITE before expiration of the session, it MAY remove > associated call state, and MAY free any resources associated with the call." > > > The question is since proxy server might not be in the session traffic path, > caller and callee can still talk each other. How can the proxy release the > resource (such as RSVP) for traffic transmission between the caller and > callee if it is not in the traffic path? According to my understanding, one > way to achieve this is the proxy has to been in the traffic path, itself > also has to been a NAT/Firewall, so that it can close the holes and release > the address binding for traffic transmission on NAT/Firewall. If the proxy > is not in the traffic path, there has to be an interface between the proxy > and a NAT/Firewall which is in the path, so that the proxy can instruct the > NAT/Firewall block the traffic. > > Who can please clean my confusion about this? Please give me some detail on > how the proxy free ANY resources associated with the call. > > Also, is there a way that a proxy can release an established session when > session timer is not supported in the proxy? Can the proxy act like a B2BUA > and send Bye to both ends? > > 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 Mon Apr 23 02:44:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02171 for ; Mon, 23 Apr 2001 02:44:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C19944348; Mon, 23 Apr 2001 02:44:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailweb4.rediffmail.com (unknown [202.54.124.149]) by lists.bell-labs.com (Postfix) with SMTP id A7AEC44337 for ; Mon, 23 Apr 2001 02:43:55 -0400 (EDT) Received: (qmail 12172 invoked by uid 510); 23 Apr 2001 06:37:54 -0000 Message-ID: <20010423063754.12171.qmail@mailweb4.rediffmail.com> Received: from unknown (203.197.74.150) by rediffmail.com via HTTP; 23 Apr 2001 06:37:54 -0000 MIME-Version: 1.0 To: "sip@vovida.org" , "sip@lists.bell-labs.com" , "Sip-implementors@cs.columbia.edu" From: "Manish S. Jalan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] doubt on using sdp 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: 23 Apr 2001 06:37:54 -0000 Content-Transfer-Encoding: 7bit Hello everyone, I have a query on using sdp while establishing a session using sip. I want to use G.723 encoding for the rtp. Hence in the media description, I'll give m=audio 12345 RTP/AVP 4 a=rtpmap:4 G723/8000 a=fmtp bitrate=6300 My query is: G.723 is a dual rate encoding scheme. One at 5.3Kbps and another at 6.3 Kbps. In the sdp definition above, I have specified, my capability for the 6.3 Kbps G.723 encoding. Say, if I have the capability of supporting 5.3 Kbps also. Then, how do i indicate that, i support both. Simply by an additional fmtp line, or some other mechanism. Eagerly waiting for your help. Thanks in advance. Regards, -Manish S. Jalan _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.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@lists.bell-labs.com Mon Apr 23 08:15:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03801 for ; Mon, 23 Apr 2001 08:15:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1D46044337; Mon, 23 Apr 2001 08:15:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailweb1.rediffmail.com (unknown [202.54.124.146]) by lists.bell-labs.com (Postfix) with SMTP id 8C20A44336 for ; Mon, 23 Apr 2001 08:14:49 -0400 (EDT) Received: (qmail 18192 invoked by uid 510); 23 Apr 2001 12:08:41 -0000 Message-ID: <20010423120841.18191.qmail@mailweb1.rediffmail.com> Received: from unknown (203.197.74.150) by rediffmail.com via HTTP; 23 Apr 2001 12:08:41 -0000 MIME-Version: 1.0 To: "sip@vovida.org" , "sip@lists.bell-labs.com" , "Sip-implementors@cs.columbia.edu" From: "Manish S. Jalan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] Clarification on sdp usage sought 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: 23 Apr 2001 12:08:41 -0000 Content-Transfer-Encoding: 7bit Hello, I am back to seek some more clarifications. Is the following sdp description ok: (the order of attribute definitions especially) m=audio 1234 RTP/AVP 4 0 a=rtpmap:4 G723/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=fmtp:4 bitrate=6300 or it should be, m=audio 1234 RTP/AVP 4 0 a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6300 a=rtpmap:0 PCMU/8000 a=ptime:20 Is the ptime definition ok? the ptime is media specific or format specific? Please help me in clarifying the concepts. Any help is highly appreciated. Regards, -Manish S. Jalan _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.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@lists.bell-labs.com Mon Apr 23 13:53:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08228 for ; Mon, 23 Apr 2001 13:53: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 F136144354; Mon, 23 Apr 2001 13:53:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id E693744337 for ; Mon, 23 Apr 2001 13:52:38 -0400 (EDT) Received: from DDCW6701 [216.119.231.55] by edgeconnect.com with ESMTP (SMTPD32-6.06) id A9089A9010E; Mon, 23 Apr 2001 10:40:24 -0700 From: "Victor A Paulsamy" To: "SIP" , Cc: "Victor A Paulsamy" Subject: [SIP] doubt on using sdp 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 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, 23 Apr 2001 13:55:09 -0400 Content-Transfer-Encoding: 7bit Hi Manish, *Both (5.3 kb/s and 6.3 kb/s) rates are a mandatory part of the encoder and decoder* and hence, supporting G723 would mean that, you are capable of supporting both the rates. Note: The least significant two bits of the first octet in the frame determine the frame size and codec type. 00 6.3 kb/s (24 octet frame) 01 5.3 kb/s (20 octet frame) 10 SID frame (4 octet frame) 11 reserved Warm regards, --victor -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Manish S. Jalan Sent: Monday, April 23, 2001 2:38 AM To: sip@vovida.org; sip@lists.bell-labs.com; Sip-implementors@cs.columbia.edu Subject: [SIP] doubt on using sdp Hello everyone, I have a query on using sdp while establishing a session using sip. I want to use G.723 encoding for the rtp. Hence in the media description, I'll give m=audio 12345 RTP/AVP 4 a=rtpmap:4 G723/8000 a=fmtp bitrate=6300 My query is: G.723 is a dual rate encoding scheme. One at 5.3Kbps and another at 6.3 Kbps. In the sdp definition above, I have specified, my capability for the 6.3 Kbps G.723 encoding. Say, if I have the capability of supporting 5.3 Kbps also. Then, how do i indicate that, i support both. Simply by an additional fmtp line, or some other mechanism. Eagerly waiting for your help. Thanks in advance. Regards, -Manish S. Jalan _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.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. _______________________________________________ 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 Apr 23 17:39:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13360 for ; Mon, 23 Apr 2001 17:39:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 539CE44338; Mon, 23 Apr 2001 17:39:03 -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.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 2077444336 for ; Mon, 23 Apr 2001 17:38:24 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA12956; Mon, 23 Apr 2001 14:38:48 -0700 (PDT) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id AFW09817; Mon, 23 Apr 2001 16:38:19 -0500 (CDT) Message-ID: <3AE4A0FA.349E6E80@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org Cc: IETF-Announce:@cisco.com, ";"@cisco.com, sip@lists.bell-labs.com, alan.johnston@wcom.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt References: <200103051146.GAA11286@ietf.org> Content-Type: multipart/alternative; boundary="------------194AC788C586C3AF2DDCB607" 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, 23 Apr 2001 16:39:07 -0500 --------------194AC788C586C3AF2DDCB607 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have question about Call Hold in SIP signaling. I assume that A and B are in different call control states after B holds A as as section 2.1 Call Hold of draft-ietf-sip-service-examples-01.txt. B is in hold state and ready to switch to operation on other sessions while A is in held state and waits for B to re-establish the media stream. Based on this, what is the proper SIP signaling for A to initiate a hold to B after B holds A first? What is the proper SIP call flows for one party to re-establish the media stream when both parties are in hold / held states? Thanks, Henry Internet-Drafts@ietf.org wrote: > 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 Service Examples > Author(s) : A. Johnston, R. Sparks, C. Cunningham, > S. Donovan, K. Summers > Filename : draft-ietf-sip-service-examples-01.txt > Pages : 96 > Date : 02-Mar-01 > > This informational document gives examples of SIP (Session Initiation > Protocol) services. This covers most features offered in so-called > Centrex offerings from local exchange carriers and PBX (Private > Branch Exchange) features. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-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-ietf-sip-service-examples-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-service-examples-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20010302132330.I-D@ietf.org> --------------194AC788C586C3AF2DDCB607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

    I have question about Call Hold in SIP signaling.
    I assume that A and B are in different call control states after B holds A as as section 2.1 Call Hold of
    draft-ietf-sip-service-examples-01.txt. B is in hold state and ready to switch to operation on other sessions
    while A is in held state and waits for B to re-establish the media stream.
    Based on this,  what is the proper SIP signaling for A to initiate a hold to B after B holds A first?
    What is the proper SIP call flows for one party to re-establish the media stream when both parties are in hold / held states?

    Thanks,

    Henry

Internet-Drafts@ietf.org wrote:

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 Service Examples
        Author(s)       : A. Johnston, R. Sparks, C. Cunningham,
                          S. Donovan, K. Summers
        Filename        : draft-ietf-sip-service-examples-01.txt
        Pages           : 96
        Date            : 02-Mar-01

This informational document gives examples of SIP (Session Initiation
Protocol) services.  This covers most features offered in so-called
Centrex offerings from local exchange carriers and PBX (Private
Branch Exchange) features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-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-ietf-sip-service-examples-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-sip-service-examples-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.

  ------------------------------------------------------------------------
Content-Type: text/plain
Content-ID:     <20010302132330.I-D@ietf.org>

--------------194AC788C586C3AF2DDCB607-- _______________________________________________ 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 Apr 23 18:33:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14128 for ; Mon, 23 Apr 2001 18:33:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0ED234434F; Mon, 23 Apr 2001 18:33:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id F40F044336 for ; Mon, 23 Apr 2001 18:32:58 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id SAA03336; Mon, 23 Apr 2001 18:32:58 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt Message-ID: <000901c0cc45$9e026260$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3AE4A0FA.349E6E80@cisco.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, 23 Apr 2001 18:34:53 -0400 Content-Transfer-Encoding: 7bit > what is the proper SIP signaling for A to > initiate a hold to B after B holds A first? The flow looks the same as a normal re-INVITE to put a call on hold; however both re-INVITE and 200 will contain hold SDP. > What is the proper SIP call flows for one > party to re-establish the media stream > when both parties are in hold / held states? A party can only offer itself off hold, the receiver can stay on hold if it desires. For instance if A put B on hold, A would likely want to return a 200 with hold SDP for a re-INVITE from B. Thus if two parties have really put each other on hold, it will most likely require a re-INVITE sequence initiated by A and a re-INVITE sequence initiated by B to actually get the call fully off hold. _______________________________________________ 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 Apr 23 21:42:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16934 for ; Mon, 23 Apr 2001 21:42: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 4B28944349; Mon, 23 Apr 2001 21:42:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id AA8FD44336 for ; Mon, 23 Apr 2001 21:41:53 -0400 (EDT) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id <2TPZQ5HP>; Mon, 23 Apr 2001 18:41:52 -0700 Message-ID: From: Sekhar Banerjee 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] Hop to Hop forwarding of Invite responses in the call flows docum ent 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, 23 Apr 2001 18:41:48 -0700 Hi All, I was going through the call flows in http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-call-flows-03.txt and the falure scenario under 3.2.1 is where I have a question. The Unsuccssful SIP to SIP no answer call flow seems to imply that not only is the CANCEL a hop to hop request but also the 487 response and the ACK are hop to hop. I thought that 487 and ACK were end to end. Am I missing something here ? Thanks Sekhar _______________________________________________ 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 Apr 23 22:16:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17187 for ; Mon, 23 Apr 2001 22:16: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 13BA744343; Mon, 23 Apr 2001 22:16:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 7A29544338 for ; Mon, 23 Apr 2001 22:15:41 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id WAA29931; Mon, 23 Apr 2001 22:15:41 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] Hop to Hop forwarding of Invite responses in the call flows docum ent Message-ID: <000a01c0cc64$bafca7d0$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: 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, 23 Apr 2001 22:17:36 -0400 Content-Transfer-Encoding: 7bit > I was going through the call flows in > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-call > -flows-03.txt > and the falure scenario under 3.2.1 is where I have a question. The > Unsuccssful SIP to SIP no answer call flow seems to imply > that not only is > the CANCEL a hop to hop request but also the 487 response and > the ACK are > hop to hop. I thought that 487 and ACK were end to end. Am I missing > something here ? As stated in third paragraph section 10.3.1 of rfc2543bis-02 November 24, 2000, "a proxy generates an ACK for non-2xx final responses." Similar text is in section 12.4. _______________________________________________ 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 Tue Apr 24 04:33:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04974 for ; Tue, 24 Apr 2001 04:33:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DEA644338; Tue, 24 Apr 2001 04:33:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id BA38B44336 for ; Tue, 24 Apr 2001 04:32:36 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 24 Apr 2001 08:32:36 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA18235; Tue, 24 Apr 2001 09:32:12 +0100 (BST) Message-ID: <3AE53A0E.6195AE4D@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Anand Vasudevan'" , Sip List References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [Sip-implementors] Query on PGP authentication scheme. 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, 24 Apr 2001 09:32:14 +0100 Content-Transfer-Encoding: 7bit moved to main SIP list as there is a suggested modification to the spec's wording here ... Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Anand Vasudevan [mailto:AnandV@netbrahma.com] > > Sent: Monday, April 23, 2001 10:07 AM > > To: 'sip-implementors@cs.columbia.edu'; 'Jonathan Rosenberg' > > Subject: RE: [Sip-implementors] Query on PGP authentication scheme. > > > > Hi, > > Thanks for your comments..If PGP authentication is > > deprecated (as per > > Jonathan),which authentication scheme > > is the better one to implement?Because,I know only three > > which are mentioned > > in RFC , > > 1.Basic scheme > > 2.Digest scheme > > 3.PGP > > > > And also RFC2617(HTTP : Basic & Digest Authentication > > schemes) says "Digest" > > is better than "Basic" but is never better than any > > Private-key crytography > > scheme(eg., PGP).. > > > > So,if PGP itself is not advisable to implement,which one can i go for? > > Most implementations are doing digest. I think there are a few that haven't > even bothered with basic. Which isn't a bad thing imho as this means you cannot negotiate down from a stronger authentication scheme to basic. Basic authentication is so badly flawed (clear text password transmitted over the network). Digest is not that hard to implement and provides for the same end user experience as basic whilst being more secure. In fact RFC 2316 states: "no protocol that relies on passwords sent over unencrypted channels is acceptable." So that this should be something we want to remove support for over time. For now I would certainly be in favour of motivating text to 14.2 stating basic authentication SHOULD NOT be used. I know this is clear in the referenced HTTP RFCs but people don't always seem to bother reading that far when compiling 'must have' feature lists for SIP Servers. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.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 Tue Apr 24 04:59:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05101 for ; Tue, 24 Apr 2001 04:59:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B7D944363; Tue, 24 Apr 2001 04:59: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 CAD5944336 for ; Tue, 24 Apr 2001 04:58:21 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 24 04:54:35 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 0BFB444380; Tue, 24 Apr 2001 04:43:47 -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 33EA74437D for ; Tue, 24 Apr 2001 04:43:46 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 09:43:44 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E3D4@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Dean Willis'" , "Chen, Xin (Xin)" , sip@lists.bell-labs.com Subject: RE: [SIP] Questions about session timer 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: Tue, 24 Apr 2001 09:43:40 +0100 Dean, Thanks for your answer. In the session timer draft, it says "a proxy MUST NOT send a BYE request once the session expires." Why? What do I miss here? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 23 April 2022 5:37 To: Chen, Xin (Xin); sip@lists.bell-labs.com Subject: Re: [SIP] Questions about session timer If the endpoints have started ignoring record-route and started talking without the proxy in question, it's fairly clear that they don't really think they NEED the proxy to hang around and proxy messages for them anymore, so the proxy can probably just give up and go home. On the other hand, if they DO really need the proxy (because it controls resources they need) and they start ignoring record route, it's fairly clear that they're not exactly playing by the rules and may need this pointed out to them . . . The only "state" that a proxy can safely control is the state of signaling that has passed through that proxy -- in essence discarding state means knowing when it's OK to give up on the signaling because the clients don't appear to be using that proxy anymore. For example, a proxy which uses call state to maintain a set of pinholes in a firewall needs to know when it can safely close those pinholes. It normally does this when it sees a "BYE" on the call associated with those pinholes. Of course, it could also decide to close the pinholes because it hasn't seen media in a whiole, or because it hasn't seen signaling in a while, or because the credit for the call has been used up, etc. What the session-timer mechanism does is allow a proxy to inform clients that it WILL be giving up on them if they haven't sent signaling (the INVITE sequence) in some reasonable period of time. If a client fails to heed this warning, it's entirely possible that the network experience it receives won't be what it was hoping for. And yes, there is generally a am interface between a proxy and a middlebox (such as a firewall) which is working with that proxy to enforce some sort of network policy. -- Dean ----- Original Message ----- From: "Chen, Xin (Xin)" To: Sent: Friday, April 20, 2001 8:11 AM Subject: [SIP] Questions about session timer > > In session timer internet draft, it says: "Similarly, if a proxy doesn't > receive a re-INVITE before expiration of the session, it MAY remove > associated call state, and MAY free any resources associated with the call." > > > The question is since proxy server might not be in the session traffic path, > caller and callee can still talk each other. How can the proxy release the > resource (such as RSVP) for traffic transmission between the caller and > callee if it is not in the traffic path? According to my understanding, one > way to achieve this is the proxy has to been in the traffic path, itself > also has to been a NAT/Firewall, so that it can close the holes and release > the address binding for traffic transmission on NAT/Firewall. If the proxy > is not in the traffic path, there has to be an interface between the proxy > and a NAT/Firewall which is in the path, so that the proxy can instruct the > NAT/Firewall block the traffic. > > Who can please clean my confusion about this? Please give me some detail on > how the proxy free ANY resources associated with the call. > > Also, is there a way that a proxy can release an established session when > session timer is not supported in the proxy? Can the proxy act like a B2BUA > and send Bye to both ends? > > 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@lists.bell-labs.com Tue Apr 24 05:55:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05488 for ; Tue, 24 Apr 2001 05:55:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35BE644350; Tue, 24 Apr 2001 05:55: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 3ECF144336 for ; Tue, 24 Apr 2001 05:54:22 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 24 05:50:10 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 9F67844380; Tue, 24 Apr 2001 05:39:21 -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 1B4E74437D for ; Tue, 24 Apr 2001 05:39:21 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 10:39:20 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001FF5B07@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Further editorial nit in the bis draft 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, 24 Apr 2001 10:39:20 +0100 Following on from my previous editorial nit, I notice the naming of status-code 487 is also inconsistent in the bis draft. In section 4.2.5, 5th and 6th paragraphs, and in section 7.4.24, and in section 15.5, the name is given as 487 (Request Terminated) However in figure 6, the syntactic definition we have: | "487" ; Request Cancelled In annex F (which will presumably disappear at IESG last call) we have 487 (Transaction Terminated) I believe this is a new status-code to SIP, therefore we are not tied to previous usage in HTTP. I propose that we stick to "Request Terminated" and change the two instances that are different from this. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.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@lists.bell-labs.com Tue Apr 24 09:24:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07667 for ; Tue, 24 Apr 2001 09:24: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 CAC0044338; Tue, 24 Apr 2001 09:24:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web14205.mail.yahoo.com (web14205.mail.yahoo.com [216.136.172.151]) by lists.bell-labs.com (Postfix) with SMTP id 336E444336 for ; Tue, 24 Apr 2001 09:23:23 -0400 (EDT) Message-ID: <20010424132318.32649.qmail@web14205.mail.yahoo.com> Received: from [202.177.130.179] by web14205.mail.yahoo.com; Tue, 24 Apr 2001 06:23:18 PDT From: kanumuri sreeram To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1760243555-988118598=:29561" Subject: [SIP] call hold ,call transfer in 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, 24 Apr 2001 06:23:18 -0700 (PDT) --0-1760243555-988118598=:29561 Content-Type: text/plain; charset=us-ascii hi all, can u tell me will sip support call-transfer and call hold?? if so how. my douth is like this A calls B Active state B will keep call hold call C attaches to A(i.e call transfer) i know that call transfer is there ok. i want call transfer/ can any one make me clear how these are done in sip thanks in advance sreeram --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1760243555-988118598=:29561 Content-Type: text/html; charset=us-ascii

hi all,



can u tell me will sip support call-transfer and call hold??


if so how.


my douth is like this


A calls B


Active state


B will keep call hold


call C


attaches to A(i.e call transfer)


i know that call transfer is there ok. i want call transfer/


can any one make me clear how these are done in sip


thanks in advance


sreeram


Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices --0-1760243555-988118598=:29561-- _______________________________________________ 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 Tue Apr 24 11:05:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08908 for ; Tue, 24 Apr 2001 11:05:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5294544343; Tue, 24 Apr 2001 11:05:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 0DBC84433F for ; Tue, 24 Apr 2001 11:04:54 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id LAA18541; Tue, 24 Apr 2001 11:04:53 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] Questions about session timer Message-ID: <001601c0ccd0$30ac8390$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00192E3D4@en0033exch001u.uk.lucent.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: Tue, 24 Apr 2001 11:06:49 -0400 Content-Transfer-Encoding: 7bit > Thanks for your answer. In the session timer draft, it says > "a proxy MUST > NOT send a BYE request once the session > expires." Why? What do I miss here? A proxy should not trample on the CSeq of a UA. Thus on a given call-leg, a proxy can only generate responses, ACKs and CANCELs. _______________________________________________ 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 Tue Apr 24 11:23:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09181 for ; Tue, 24 Apr 2001 11:23:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E9C64435F; Tue, 24 Apr 2001 11:23:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33]) by lists.bell-labs.com (Postfix) with ESMTP id F3A7244336 for ; Tue, 24 Apr 2001 11:22:02 -0400 (EDT) Received: from email.masconit.com ([12.41.17.214]) by mail.inetmail.att.net (mtiagic01) with ESMTP id <20010424152159gi128285ele>; Tue, 24 Apr 2001 15:21:59 +0000 Received: from ashok (RANJIT [12.41.17.196]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JB7P319Y; Tue, 24 Apr 2001 10:29:00 -0500 Message-ID: <007301c0ccd2$e923a640$c411290c@masconit.com> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "kanumuri sreeram" , References: <20010424132318.32649.qmail@web14205.mail.yahoo.com> Subject: Re: [SIP] call hold ,call transfer in sip? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C0CCA9.0002D9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, 24 Apr 2001 10:26:18 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01C0CCA9.0002D9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Call transfer in SIP takes place thru REFER method. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the method. A success response indicates that the recipient was able to contact the third party. Regards Ranjit Mascon Communication Technologies http://www.masconit.com ----- Original Message ----- From: kanumuri sreeram To: sip@lists.bell-labs.com Sent: Tuesday, April 24, 2001 8:23 AM Subject: [SIP] call hold ,call transfer in sip? hi all, can u tell me will sip support call-transfer and call hold?? if so how. my douth is like this A calls B Active state B will keep call hold call C attaches to A(i.e call transfer) i know that call transfer is there ok. i want call transfer/ can any one make me clear how these are done in sip thanks in advance sreeram ---------------------------------------------------------------------------- -- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices ------=_NextPart_000_006F_01C0CCA9.0002D9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi =
      Call = transfer in SIP=20 takes place thru REFER method. The REFER method indicates that the=20 recipient (identified by the Request-URI) should
   contact = a third=20 party using the contact information provided in the  method. A = success=20 response indicates that the recipient was able to
   = contact the=20 third party.

Regards
Ranjit
Mascon=20 Communication Technologies
http://www.masconit.com
 
 
 
 
 
 
----- Original Message -----
From:=20 kanumuri=20 sreeram
To: sip@lists.bell-labs.com
Sent: Tuesday, April 24, 2001 = 8:23=20 AM
Subject: [SIP] call hold ,call = transfer=20 in sip?

hi all,



can u tell me will sip support call-transfer and call = hold??


if so how.


my douth is like this


A calls B


Active state


B will keep call hold


call C


attaches to A(i.e call transfer)


i know that call transfer is there ok. i want call = transfer/


can any one make me clear how these are done in sip


thanks in advance


sreeram


Do You Yahoo!?
Yahoo! = Auctions - buy the things you want at great=20 prices ------=_NextPart_000_006F_01C0CCA9.0002D9A0-- _______________________________________________ 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 Tue Apr 24 11:43:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09552 for ; Tue, 24 Apr 2001 11:43:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB77944371; Tue, 24 Apr 2001 11:43:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 4079E4436E for ; Tue, 24 Apr 2001 11:42:38 -0400 (EDT) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3O9gEP26809; Tue, 24 Apr 2001 04:42:14 -0500 Message-ID: <007f01c0ccd5$2d07cc40$56fa403f@dynamicsoft.com> From: "Dean Willis" To: "Chen, Xin (Xin)" , References: <475FF955A05DD411980D00508B6D5FB00192E3D4@en0033exch001u.uk.lucent.com> Subject: Re: [SIP] Questions about session timer 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 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, 24 Apr 2001 10:42:31 -0500 Content-Transfer-Encoding: 7bit Right. The proxy doesn't send a BYE on the expiration of the session-timer. It just quietly cleans up and discards whatever call state it is holding. -- Dean ----- Original Message ----- From: "Chen, Xin (Xin)" To: "'Dean Willis'" ; "Chen, Xin (Xin)" ; Sent: Tuesday, April 24, 2001 3:43 AM Subject: RE: [SIP] Questions about session timer > Dean, > > Thanks for your answer. In the session timer draft, it says "a proxy MUST > NOT send a BYE request once the session > expires." Why? What do I miss here? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 23 April 2022 5:37 > To: Chen, Xin (Xin); sip@lists.bell-labs.com > Subject: Re: [SIP] Questions about session timer > > > If the endpoints have started ignoring record-route and started talking > without the proxy in question, it's fairly clear that they don't really > think they NEED the proxy to hang around and proxy messages for them > anymore, so the proxy can probably just give up and go home. On the other > hand, if they DO really need the proxy (because it controls resources they > need) and they start ignoring record route, it's fairly clear that they're > not exactly playing by the rules and may need this pointed out to them . . . > > The only "state" that a proxy can safely control is the state of signaling > that has passed through that proxy -- in essence discarding state means > knowing when it's OK to give up on the signaling because the clients don't > appear to be using that proxy anymore. > > For example, a proxy which uses call state to maintain a set of pinholes in > a firewall needs to know when it can safely close those pinholes. It > normally does this when it sees a "BYE" on the call associated with those > pinholes. Of course, it could also decide to close the pinholes because it > hasn't seen media in a whiole, or because it hasn't seen signaling in a > while, or because the credit for the call has been used up, etc. What the > session-timer mechanism does is allow a proxy to inform clients that it WILL > be giving up on them if they haven't sent signaling (the INVITE sequence) in > some reasonable period of time. If a client fails to heed this warning, it's > entirely possible that the network experience it receives won't be what it > was hoping for. > > And yes, there is generally a am interface between a proxy and a middlebox > (such as a firewall) which is working with that proxy to enforce some sort > of network policy. > > -- > Dean > > ----- Original Message ----- > From: "Chen, Xin (Xin)" > To: > Sent: Friday, April 20, 2001 8:11 AM > Subject: [SIP] Questions about session timer > > > > > > In session timer internet draft, it says: "Similarly, if a proxy doesn't > > receive a re-INVITE before expiration of the session, it MAY remove > > associated call state, and MAY free any resources associated with the > call." > > > > > > The question is since proxy server might not be in the session traffic > path, > > caller and callee can still talk each other. How can the proxy release the > > resource (such as RSVP) for traffic transmission between the caller and > > callee if it is not in the traffic path? According to my understanding, > one > > way to achieve this is the proxy has to been in the traffic path, itself > > also has to been a NAT/Firewall, so that it can close the holes and > release > > the address binding for traffic transmission on NAT/Firewall. If the proxy > > is not in the traffic path, there has to be an interface between the proxy > > and a NAT/Firewall which is in the path, so that the proxy can instruct > the > > NAT/Firewall block the traffic. > > > > Who can please clean my confusion about this? Please give me some detail > on > > how the proxy free ANY resources associated with the call. > > > > Also, is there a way that a proxy can release an established session when > > session timer is not supported in the proxy? Can the proxy act like a > B2BUA > > and send Bye to both ends? > > > > 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@lists.bell-labs.com Tue Apr 24 11:47:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09637 for ; Tue, 24 Apr 2001 11:47:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA5D244376; Tue, 24 Apr 2001 11:47: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 C75454436E for ; Tue, 24 Apr 2001 11:46:23 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Apr 24 11:42:20 EDT 2001 Received: by lists.bell-labs.com (Postfix) id B025F44380; Tue, 24 Apr 2001 11:31:31 -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 2C1FE4437D for ; Tue, 24 Apr 2001 11:31:31 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 16:31:30 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00192E3D8@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'brett@broadsoft.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Questions about session timer 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: Tue, 24 Apr 2001 16:31:07 +0100 But what the proxy is going to do if it wants to disconnect a call in a case that the user has run out of credit in his account during a call. What sip message will be sent to caller or callee by this proxy? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: 24 April 2001 15:07 To: sip@lists.bell-labs.com Subject: RE: [SIP] Questions about session timer > Thanks for your answer. In the session timer draft, it says > "a proxy MUST > NOT send a BYE request once the session > expires." Why? What do I miss here? A proxy should not trample on the CSeq of a UA. Thus on a given call-leg, a proxy can only generate responses, ACKs and CANCELs. _______________________________________________ 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 Tue Apr 24 12:35:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10258 for ; Tue, 24 Apr 2001 12:35:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14D704433F; Tue, 24 Apr 2001 12:35:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 3979644336 for ; Tue, 24 Apr 2001 12:34:37 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id MAA34549; Tue, 24 Apr 2001 12:34:36 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] Questions about session timer Message-ID: <001b01c0ccdc$b9609580$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00192E3D8@en0033exch001u.uk.lucent.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: Tue, 24 Apr 2001 12:36:32 -0400 Content-Transfer-Encoding: 7bit > But what the proxy is going to do if it wants to disconnect a > call in a case > that the user has run out of credit in his account during a > call. What sip > message will be sent to caller or callee by this proxy? The following FAQ link addresses such a question. http://www.cs.columbia.edu/sip/faq/cache/13.html > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 24 April 2001 15:07 > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Questions about session timer > > > > Thanks for your answer. In the session timer draft, it says > > "a proxy MUST > > NOT send a BYE request once the session > > expires." Why? What do I miss here? > > A proxy should not trample on the CSeq of a UA. > Thus on a given call-leg, a proxy can only > generate responses, ACKs and CANCELs. > _______________________________________________ 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 Tue Apr 24 12:58:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10531 for ; Tue, 24 Apr 2001 12:58:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7798544365; Tue, 24 Apr 2001 12:58: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 D00B444336 for ; Tue, 24 Apr 2001 12:57:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA22675 for ; Tue, 24 Apr 2001 13:00:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 12:57:17 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30B21@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Steve Donovan , Jonathan Rosenberg Cc: Rakesh Shah , "'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] First cut review of Session Timer draft. 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, 24 Apr 2001 12:57:17 -0400 Here are my first cut comments on session-timer for the upcoming last-call. Most of these are minor comments. Please forgive me if I am re-opening old discussions, as I did not follow the original session-timer work. Comments referring to specific parts of the document are prefixed with (page:paragraph) Global - We might need language (perhaps in security considerations) that recommends against using session-timer for billing purposes with out additional corroboration. I can imagine a theft-of-service attack where the UAs collude in letting the session expire, but maintain the RTP session. Any proxy in the middle would assume the call was over. This will not work if the timer controls a firewall, but it could if the timer was only used to establish end-of-call for billing purposes. Global - (nit) there are several sections where the normative language is not clear. For example, it often says "X does Y" instead of "X MUST|MAY|etc do Y." Most of these are in the early descriptions, so perhaps the intent is to reserve normative language for the specific behavior descriptions later in the draft. If that is so, then it is not consistent. 3:2-A proxy can lower but not increase the expiration time. Jonathan brought up the issue of a DoS attack using insanely small expirations. If a proxy cannot increase the expiration, it at least needs the option of rejecting requests with expiration values below a threshold. 3:4 - (Typo) Sentence "They UAS MAY..." should read "The UAS MAY..." 3:4 - (Minor) I am not sure I see the value in pushing responsibility back to a supporting UAC, if the UAC did not request the timer in the first place. Why not just let the UAS deal with it, if the UAS is the element that wishes to use a timer? At least it might make sense to say that the UAS must insert the Required header IF it wishes the UAC to handle the re-invites. 4:5 What happens if the UAC does _NOT_ include a Session-Expires header on the re-invite? I assume everyone resets their timers with the original values? Or does timer processing cease? 5:2 - Doesn't option of absolute time imply an assumption that all elements have their clocks reasonably synchronized? 5:3 - Again, we need to allow elements to reject expirations below a configured threshold. 10:2 - How can a proxy know that it is the closes proxy to the UAC that cares about the timer? Except in the trivial case where the proxy is the closest to the UAC period, this seems problematic. _______________________________________________ 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 Tue Apr 24 14:34:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12059 for ; Tue, 24 Apr 2001 14:34:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B9EF44338; Tue, 24 Apr 2001 14:34:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from rodney.cnchost.com (rodney.concentric.net [207.155.252.4]) by lists.bell-labs.com (Postfix) with ESMTP id 857DE44336 for ; Tue, 24 Apr 2001 14:33:22 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by rodney.cnchost.com id OAA01922; Tue, 24 Apr 2001 14:33:12 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <3AE5C748.4040202@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "'sip@lists.bell-labs.com'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [SIP] Question on Authentication in sip-call-flow-04.txt 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, 24 Apr 2001 14:34:48 -0400 Content-Transfer-Encoding: 7bit Moved to the SIP list. Got no response on sip-implementors. -------- Original Message -------- Subject: [Sip-implementors] Question on Authentication in sip-call-flow-04.txt Date: Fri, 20 Apr 2001 15:51:48 -0400 From: Shan Lu To: sip-implementors@cs.columbia.edu Section 2.1.1, Message F3: Why "Proxy-Authorization" header is used instead of "Authorization"? According to bis-02, "WWW-Authenticate" is inserted by a UAS or registrar in 401 which will lead to UAC responding with "Authorization" in a new request, and "Proxy-Authenticate" is inserted by a PS in 407 which will result in "Proxy-Authorization" in a new request from UAC. Is this understanding correct? Regards, Shan Lu _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ 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 Tue Apr 24 15:58:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14039 for ; Tue, 24 Apr 2001 15:58:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 260D344338; Tue, 24 Apr 2001 15:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id AAA5944336 for ; Tue, 24 Apr 2001 15:57:08 -0400 (EDT) Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3ODueP27501; Tue, 24 Apr 2001 08:56:40 -0500 Message-ID: <005301c0ccf8$b8cf4140$ad036e3f@dynamicsoft.com> From: "Dean Willis" To: "Chen, Xin (Xin)" , References: <475FF955A05DD411980D00508B6D5FB00192E3D8@en0033exch001u.uk.lucent.com> Subject: Re: [SIP] Questions about session timer 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 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, 24 Apr 2001 14:56:58 -0500 Content-Transfer-Encoding: 7bit Nothing. Conformant proxies can't enforce prepaid functions. You need an application that implements a back-to-back user agent to do this. I believe it is possible for a proxy to switch from proxy to B2BUA mode if it so desires, but it is a bit tricky. Switching BACK to proxy mode for a call is much harder. I believe this is addressed by the FAQ that Brett mentioned. If anyone wishes to discuss this further, I'll be happy to do so, but would rather not do so on the SIP list. -- Dean ----- Original Message ----- From: "Chen, Xin (Xin)" To: ; Sent: Tuesday, April 24, 2001 10:31 AM Subject: RE: [SIP] Questions about session timer > But what the proxy is going to do if it wants to disconnect a call in a case > that the user has run out of credit in his account during a call. What sip > message will be sent to caller or callee by this proxy? > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 24 April 2001 15:07 > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Questions about session timer > > > > Thanks for your answer. In the session timer draft, it says > > "a proxy MUST > > NOT send a BYE request once the session > > expires." Why? What do I miss here? > > A proxy should not trample on the CSeq of a UA. > Thus on a given call-leg, a proxy can only > generate responses, ACKs and CANCELs. > > > _______________________________________________ > 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@lists.bell-labs.com Tue Apr 24 17:23:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15585 for ; Tue, 24 Apr 2001 17:23:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95B3F44338; Tue, 24 Apr 2001 17:23:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id 0B42244336 for ; Tue, 24 Apr 2001 17:22:08 -0400 (EDT) Received: from roland (207.104.210.147 [207.104.210.147]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JR51NSL1; Tue, 24 Apr 2001 14:25:46 -0700 Message-ID: <02a001c0cd04$d2af9720$93d268cf@netrue.com> From: "Roland" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029D_01C0CCCA.21CA73B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] anyone study Vovida source? 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, 24 Apr 2001 14:23:28 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_029D_01C0CCCA.21CA73B0 Content-Type: text/plain; charset="hz-gb-2312" Content-Transfer-Encoding: quoted-printable I downloaded all the Vovida.com open source code for SIP,=20 but it's quite difficulty to read the source. any one knows some helpful document about that? for big picture, for relationship of the classes? any information about that , please tell me. Thanks!!!!!!!!!!!!!!!!!!!!!! Very Much!!!!!!! Roland ------=_NextPart_000_029D_01C0CCCA.21CA73B0 Content-Type: text/html; charset="hz-gb-2312" Content-Transfer-Encoding: quoted-printable
I downloaded all the Vovida.com open = source code=20 for SIP,
but it's quite difficulty to read the=20 source.
 any one knows some helpful document about that?
for big picture, for relationship of = the=20 classes?
any information about that , please = tell=20 me.
 
Thanks!!!!!!!!!!!!!!!!!!!!!!
Very Much!!!!!!!
 
Roland
 
 
 
 
------=_NextPart_000_029D_01C0CCCA.21CA73B0-- _______________________________________________ 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 Tue Apr 24 17:36:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15837 for ; Tue, 24 Apr 2001 17:36:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CAD744338; Tue, 24 Apr 2001 17:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from edgeconnect.com (unknown [207.171.0.7]) by lists.bell-labs.com (Postfix) with ESMTP id 7359544336 for ; Tue, 24 Apr 2001 17:35:18 -0400 (EDT) Received: from voicecore.com [216.119.231.50] by edgeconnect.com with ESMTP (SMTPD32-6.06) id AEB569050154; Tue, 24 Apr 2001 14:23:01 -0700 Message-ID: <3AE5F198.FA362A55@voicecore.com> From: Samir Chatterjee X-Mailer: Mozilla 4.72 [en] (Win98; I) 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 voicemail server 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, 24 Apr 2001 17:35:20 -0400 Content-Transfer-Encoding: 7bit Is anyone aware of a SIP-based voicemail server? Thanks Samir -- *************************************************************** Dr. Samir Chatterjee Chairman, Co-founder & CTO VoiceCore Technologies Inc. (Also) Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 **************************************************************** _______________________________________________ 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 Tue Apr 24 17:41:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15929 for ; Tue, 24 Apr 2001 17:41:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BEA644386; Tue, 24 Apr 2001 17:41:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id A305344384 for ; Tue, 24 Apr 2001 17:40:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA29817; Tue, 24 Apr 2001 17:40:13 -0400 (EDT) Message-ID: <3AE5F2BD.52C45C10@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Samir Chatterjee Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] SIP voicemail server References: <3AE5F198.FA362A55@voicecore.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: Tue, 24 Apr 2001 17:40:13 -0400 Content-Transfer-Encoding: 7bit Samir Chatterjee wrote: > > Is anyone aware of a SIP-based voicemail server? > Thanks Yes, but product discussions are not appropriate for this list. See http://www.cs.columbia.edu/sip for a listing of implementations. -- 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 Tue Apr 24 17:51:02 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16105 for ; Tue, 24 Apr 2001 17:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ABF244391; Tue, 24 Apr 2001 17:51:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from purepacket.com (pop.broadriver.com [63.96.44.51]) by lists.bell-labs.com (Postfix) with ESMTP id 62CB54438F for ; Tue, 24 Apr 2001 17:50:13 -0400 (EDT) Received: from EPIMENTEL1 ([192.168.1.123]) by purepacket.com (8.9.3/8.9.3) with SMTP id RAA13578; Tue, 24 Apr 2001 17:50:13 -0400 From: "Ed Pimentel" To: "Samir Chatterjee" , Subject: RE: [SIP] SIP voicemail server Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3AE5F198.FA362A55@voicecore.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: Tue, 24 Apr 2001 17:49:43 -0400 Content-Transfer-Encoding: 7bit Samir, Yes. Email and I will share with you what we did at BroadRiver. Ed Pimentel CTO BroadRiver Communications 13000 Deerfield Parkway suite 210 Alpharetta GA 30004 O: 678.566.1116 C: 678.522.8511 F: 678.566.1152 M: epimentel@broadriver.com P: pageepimentel@broadriver.com AOL IM: epimntl This message contains CONFIDENTIAL INFORMATION intended solely for the use of the addressees named above. Any review, disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Samir Chatterjee Sent: Tuesday, April 24, 2001 5:35 PM To: sip@lists.bell-labs.com Subject: [SIP] SIP voicemail server Is anyone aware of a SIP-based voicemail server? Thanks Samir -- *************************************************************** Dr. Samir Chatterjee Chairman, Co-founder & CTO VoiceCore Technologies Inc. (Also) Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 **************************************************************** _______________________________________________ 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 Tue Apr 24 18:14:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16628 for ; Tue, 24 Apr 2001 18:14:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8F7B44366; Tue, 24 Apr 2001 18:14:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 4766244338 for ; Tue, 24 Apr 2001 18:13:59 -0400 (EDT) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id <2TPZQ6QK>; Tue, 24 Apr 2001 15:13:53 -0700 Message-ID: From: Sekhar Banerjee To: "'brett@broadsoft.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Hop to Hop forwarding of Invite responses in the call f lows docum ent 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: Tue, 24 Apr 2001 15:13:52 -0700 Bret, Thanks for the response. The other question would be is the 200 OK response to the CANCEL supposed to be generated by the proxy too without waiting for a response to the CANCEL that was forwarded to the next hop. Thanks Sekhar > I was going through the call flows in > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-call > -flows-03.txt > and the falure scenario under 3.2.1 is where I have a question. The > Unsuccssful SIP to SIP no answer call flow seems to imply > that not only is > the CANCEL a hop to hop request but also the 487 response and > the ACK are > hop to hop. I thought that 487 and ACK were end to end. Am I missing > something here ? As stated in third paragraph section 10.3.1 of rfc2543bis-02 November 24, 2000, "a proxy generates an ACK for non-2xx final responses." Similar text is in section 12.4. _______________________________________________ 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 Tue Apr 24 19:17:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17469 for ; Tue, 24 Apr 2001 19:17:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB01244338; Tue, 24 Apr 2001 19:17:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0A87244336 for ; Tue, 24 Apr 2001 19:16:54 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA05575; Tue, 24 Apr 2001 19:16:53 -0400 (EDT) Message-ID: <3AE60965.BFBFD5BC@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Further editorial nit in the bis draft References: <475FF955A05DD411980D00508B6D5FB001FF5B07@en0033exch001u.uk.lucent.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: Tue, 24 Apr 2001 19:16:53 -0400 Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > > Following on from my previous editorial nit, I notice the naming of > status-code 487 is also inconsistent in the bis draft. > > In section 4.2.5, 5th and 6th paragraphs, and in section 7.4.24, and in > section 15.5, the name is given as > > 487 (Request Terminated) > > However in figure 6, the syntactic definition we have: > > | "487" ; Request Cancelled > > In annex F (which will presumably disappear at IESG last call) we have > > 487 (Transaction Terminated) > > I believe this is a new status-code to SIP, therefore we are not tied to > previous usage in HTTP. I propose that we stick to "Request Terminated" and > change the two instances that are different from this. > There is a side issue that I'd like to confirm before doing the edit: The status description mentions that 487 is also sent when a BYE terminates a pending request (presumably INVITE). This would indeed argue for "Request terminated" rather than "cancelled". -- 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 Tue Apr 24 21:13:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19344 for ; Tue, 24 Apr 2001 21:13:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 57A5844384; Tue, 24 Apr 2001 21:13:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6DE7144338 for ; Tue, 24 Apr 2001 21:12:12 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA11714; Tue, 24 Apr 2001 21:12:11 -0400 (EDT) Message-ID: <3AE6246B.CA874143@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Editorial nit in bis draft References: <475FF955A05DD411980D00508B6D5FB001AC31C3@en0033exch001u.uk.lucent.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: Tue, 24 Apr 2001 21:12:11 -0400 Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > > Looking at the -02 version of the bis draft. > > The text string associated with status-code 504 is inconsistent within the > document. > > In figure 7 (the syntactic definition) it is given as > > | "504" ; Gateway Time-out > > In section 7.5.5, the semantic definition, it is given as: > > 7.5.5 504 Server Time-out > > The first usage is consistent with HTTP, but presumably introduces the term > gateway in a form that is not completely consistent with SIP. Whatever > happens, we need to align them one way or the other. > Aligned to "server". Note, just in case, that nobody should be relying on a particular wording of a status response. If there's a strcmp(msg, "Server Time-out") in your code, you've been warned... -- 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 Tue Apr 24 22:26:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21036 for ; Tue, 24 Apr 2001 22:26:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09F8444338; Tue, 24 Apr 2001 22:26:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnvrpop3.dnvr.uswest.net (dnvrpop3.dnvr.uswest.net [206.196.128.5]) by lists.bell-labs.com (Postfix) with SMTP id 3305144336 for ; Tue, 24 Apr 2001 22:25:43 -0400 (EDT) Received: (qmail 11073 invoked by uid 0); 25 Apr 2001 02:25:38 -0000 Received: from unknown (HELO donlaptop) (63.229.230.222) by dnvrpop3.dnvr.uswest.net with SMTP; 25 Apr 2001 02:25:38 -0000 Message-ID: From: "Don Stanwyck" To: "Samir Chatterjee" , " " Subject: RE: [SIP] SIP voicemail server MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3AE5F198.FA362A55@voicecore.com> 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: Tue, 24 Apr 2001 20:20:49 -0600 Content-Transfer-Encoding: 7bit We have one - contact me offline for more information. Don Stanwyck VP Technologies, IP Unity (303) 883-6386 stanwyck@ipunity.com > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Samir Chatterjee > Sent: Tuesday, April 24, 2001 3:35 PM > To: sip@lists.bell-labs.com > Subject: [SIP] SIP voicemail server > > > Is anyone aware of a SIP-based voicemail server? > Thanks > Samir > > -- > *************************************************************** > Dr. Samir Chatterjee > Chairman, Co-founder & CTO > VoiceCore Technologies Inc. > (Also) Associate Professor > Computer Information Systems Department > J Mack Robinson College of Business > Georgia State University > Atlanta, GA 30303. > Ph: 404-651-3886 > **************************************************************** > > > > _______________________________________________ > 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 Wed Apr 25 05:53:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09908 for ; Wed, 25 Apr 2001 05:53:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B39C4433F; Wed, 25 Apr 2001 05:53:04 -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 E518E44336 for ; Wed, 25 Apr 2001 05:52:21 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 25 05:49:12 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 20A6944380; Wed, 25 Apr 2001 05:38:23 -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 4B4D34437D for ; Wed, 25 Apr 2001 05:38:22 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 10:38:21 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31D7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Further editorial nit in the bis draft 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: Wed, 25 Apr 2001 10:38:19 +0100 I agree there are indications in the current bis draft that suggest a BYE also terminates pending transactions. Assuming that people agree that this is correct behaviour, the the following considerations apply. I do note that if this is required behaviour, then there should be more text in section 4.2.4 (BYE) that specifies this behaviour. Section 4.2.5 (CANCEL) specifies the following for the 487 activity: The behavior of the user agent or redirect server on receiving a CANCEL request depends on whether the server has already sent a final response for the original request. If it has, the CANCEL request has no effect on the original request, any call state and on the responses generated for the original request. If the server has not issued a final response for the original request, it immediately sends a 487 (Request Terminated) for the original request. For INVITE requests, the UAC as usual sends an ACK request to confirm receipt of any final response. The CANCEL request itself is answered with a 200 (OK) response in either case. A proxy client or UAC cannot rely on receiving a 487 (Request Terminated) response, as a RFC 2543-compliant UAS will not generate such a response. If there has been no final response after 32 seconds, the client MAY consider the original transaction to have been cancelled. The only text in 4.2.4 that looks like this talks only about terminating INVITE requests, and does not mention the status-code to be used. A BYE request from either called or calling party terminates any pending INVITE at a UA, but the INVITE request transaction MUST be completed with a final response and ACK. Presumably BYE can also terminate other requests within the session (OPTIONS, PRACK, COMET) and this status-code should also be used for them. I would suggest that the implied behaviour for BYE requires some text in 4.2.4 based on that currently in 4.2.5 for CANCEL. Back to the subject of the associated text string value, I note the following text in 6.21 would imply that "cancelled" and "cancellation" can be done by BYE, so we may want to change the words there as well. Strictly speaking, CSeq header fields are needed for any SIP request that can be cancelled by a BYE or CANCEL request or where a client can issue several requests for the same Call-ID in close succession. Without a sequence number, the response to an INVITE could be mistaken for the response to the cancellation (BYE or CANCEL). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Henning G. Schulzrinne[SMTP:hgs@cs.columbia.edu] > Sent: 25 April 2001 0:16 > To: Drage, Keith (Keith) > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] Further editorial nit in the bis draft > > "Drage, Keith (Keith)" wrote: > > > > Following on from my previous editorial nit, I notice the naming of > > status-code 487 is also inconsistent in the bis draft. > > > > In section 4.2.5, 5th and 6th paragraphs, and in section 7.4.24, and in > > section 15.5, the name is given as > > > > 487 (Request Terminated) > > > > However in figure 6, the syntactic definition we have: > > > > | "487" ; Request Cancelled > > > > In annex F (which will presumably disappear at IESG last call) we have > > > > 487 (Transaction Terminated) > > > > I believe this is a new status-code to SIP, therefore we are not tied to > > previous usage in HTTP. I propose that we stick to "Request Terminated" > and > > change the two instances that are different from this. > > > > There is a side issue that I'd like to confirm before doing the edit: > The status description mentions that 487 is also sent when a BYE > terminates a pending request (presumably INVITE). This would indeed > argue for "Request terminated" rather than "cancelled". > > -- > 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 Wed Apr 25 06:17:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10052 for ; Wed, 25 Apr 2001 06:17:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B51C444366; Wed, 25 Apr 2001 06:17: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 5D83D44336 for ; Wed, 25 Apr 2001 06:16:22 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Apr 25 06:12:05 EDT 2001 Received: by lists.bell-labs.com (Postfix) id BC15B44380; Wed, 25 Apr 2001 06:01:16 -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 388C24437D for ; Wed, 25 Apr 2001 06:01:16 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 11:01:15 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC31D8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 25 Apr 2001 11:01:13 +0100 The initial enquiry and Brett's response assume that the result of hold is asymmetrical. While the service examples draft is an attempt to emulate PSTN services, the service result in this case is not the same. The service-examples draft contains the following key words . Note that either party can take the other party off of hold. SIP hold removes the media stream(s). They are removed at both ends. If A holds B, then both parties are in the state of having no media stream. Neither side is particularly holding or held. If B holds A, then both parties are still in the state of having no media stream, and therefore, while such a request is not invalid, it has zero impact on the overall state of the session. The process of coming out of hold requires merely adding a media stream and therefore either end can invoke this function. The only note I would make is that if A held B, then A presumably did it to release resources to perform some other function (this is the purpose of hold in both the PSTN and ISDN). If B tries to resume the call before A is ready, then those resources may still be unavailable, and A may reject the request (e.g. with "busy here" or "busy everywhere"). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Brett Tate[SMTP:brett@broadsoft.com] > Reply To: brett@broadsoft.com > Sent: 23 April 2001 23:34 > To: sip@lists.bell-labs.com > Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt > > > > > what is the proper SIP signaling for A to > > initiate a hold to B after B holds A first? > > The flow looks the same as a normal re-INVITE > to put a call on hold; however both re-INVITE > and 200 will contain hold SDP. > > > What is the proper SIP call flows for one > > party to re-establish the media stream > > when both parties are in hold / held states? > > A party can only offer itself off hold, the > receiver can stay on hold if it desires. > > For instance if A put B on hold, A would > likely want to return a 200 with hold SDP > for a re-INVITE from B. > > Thus if two parties have really put each > other on hold, it will most likely require > a re-INVITE sequence initiated by A and > a re-INVITE sequence initiated by B to > actually get the call fully off hold. > > > _______________________________________________ > 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 Wed Apr 25 08:19:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12390 for ; Wed, 25 Apr 2001 08:19: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 9CE714433F; Wed, 25 Apr 2001 08:19:03 -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.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 143D844336 for ; Wed, 25 Apr 2001 08:18:01 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [171.71.61.25]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA27965; Wed, 25 Apr 2001 05:18:26 -0700 (PDT) Received: from arunvenkpc ([10.96.3.83]) by sponge.cisco.com (Mirapoint) with SMTP id ACD04978; Wed, 25 Apr 2001 07:17:58 -0500 (CDT) Message-ID: <001601c0cd81$714fbbe0$5303600a@cisco.com> From: "Arunachalam Venkatraman" To: "Drage, Keith (Keith)" , "'Henning G. Schulzrinne'" Cc: References: <475FF955A05DD411980D00508B6D5FB001AC31D7@en0033exch001u.uk.lucent.com> Subject: Re: [SIP] :BYE for pending INVITE was Further editorial nit in the bis draft 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 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: Wed, 25 Apr 2001 07:15:39 -0500 Content-Transfer-Encoding: 7bit If the INVITE was responded to with 100 Trying (thus disabling retransmissions) and the BYE with 200 OK (since the INVITE has not completed), the UAS and the proxies en-route would have cleared the call on receipt of the 200 OK to the BYE. What is the value of the 487 to INVITE ? Other than the protocol rule that each transaction completes independently. Is there going to be any stack that will be upset if the 487 is not sent in this case? ----- Original Message ----- From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" ; "'Henning G. Schulzrinne'" Cc: Sent: Wednesday, April 25, 2001 4:38 AM Subject: RE: [SIP] Further editorial nit in the bis draft > I agree there are indications in the current bis draft that suggest a BYE > also terminates pending transactions. Assuming that people agree that this > is correct behaviour, the the following considerations apply. > > I do note that if this is required behaviour, then there should be more text > in section 4.2.4 (BYE) that specifies this behaviour. > > Section 4.2.5 (CANCEL) specifies the following for the 487 activity: > > The behavior of the user agent or redirect server on receiving a > CANCEL request depends on whether the server has already sent a final > response for the original request. If it has, the CANCEL request has > no effect on the original request, any call state and on the > responses generated for the original request. If the server has not > issued a final response for the original request, it immediately > sends a 487 (Request Terminated) for the original request. For INVITE > requests, the UAC as usual sends an ACK request to confirm receipt of > any final response. The CANCEL request itself is answered with a 200 > (OK) response in either case. > > A proxy client or UAC cannot rely on receiving a 487 (Request > Terminated) response, as a RFC 2543-compliant UAS will not generate > such a response. If there has been no final response after 32 > seconds, the client MAY consider the original transaction to have > been cancelled. > > The only text in 4.2.4 that looks like this talks only about terminating > INVITE requests, and does not mention the status-code to be used. > > A BYE request from either called or calling party terminates any > pending INVITE at a UA, but the INVITE request transaction MUST be > completed with a final response and ACK. > > Presumably BYE can also terminate other requests within the session > (OPTIONS, PRACK, COMET) and this status-code should also be used for them. > > I would suggest that the implied behaviour for BYE requires some text in > 4.2.4 based on that currently in 4.2.5 for CANCEL. > > Back to the subject of the associated text string value, I note the > following text in 6.21 would imply that "cancelled" and "cancellation" can > be done by BYE, so we may want to change the words there as well. > > Strictly speaking, CSeq header fields are needed for any > SIP request that can be cancelled by a BYE or CANCEL > request or where a client can issue several requests for > the same Call-ID in close succession. Without a sequence > number, the response to an INVITE could be mistaken for the > response to the cancellation (BYE or CANCEL). > > Keith > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Henning G. Schulzrinne[SMTP:hgs@cs.columbia.edu] > > Sent: 25 April 2001 0:16 > > To: Drage, Keith (Keith) > > Cc: 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] Further editorial nit in the bis draft > > > > "Drage, Keith (Keith)" wrote: > > > > > > Following on from my previous editorial nit, I notice the naming of > > > status-code 487 is also inconsistent in the bis draft. > > > > > > In section 4.2.5, 5th and 6th paragraphs, and in section 7.4.24, and in > > > section 15.5, the name is given as > > > > > > 487 (Request Terminated) > > > > > > However in figure 6, the syntactic definition we have: > > > > > > | "487" ; Request Cancelled > > > > > > In annex F (which will presumably disappear at IESG last call) we have > > > > > > 487 (Transaction Terminated) > > > > > > I believe this is a new status-code to SIP, therefore we are not tied to > > > previous usage in HTTP. I propose that we stick to "Request Terminated" > > and > > > change the two instances that are different from this. > > > > > > > There is a side issue that I'd like to confirm before doing the edit: > > The status description mentions that 487 is also sent when a BYE > > terminates a pending request (presumably INVITE). This would indeed > > argue for "Request terminated" rather than "cancelled". > > > > -- > > 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 Wed Apr 25 09:19:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14413 for ; Wed, 25 Apr 2001 09:19:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31D7844338; Wed, 25 Apr 2001 09:19:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7201644336 for ; Wed, 25 Apr 2001 09:18:13 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id <27SBCWVY>; Wed, 25 Apr 2001 06:17:46 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" 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_01C0CD8A.1C223A40" Subject: [SIP] Join as replacement for DTMF/voice-forking. 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: Wed, 25 Apr 2001 06:17:42 -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_01C0CD8A.1C223A40 Content-Type: text/plain; charset="iso-8859-1" If at first you don't succeed ..... Hi, I still didn't receive any comment back on using Join as a replacement to beleaguered SDP based DTMF-forking. I am not sure if this is because a) people don't see the problems with the existing DTMF forking scheme (that has not been standardized anywhere), or b) people see problems with using join to provide this service in a highly flexible and generic manner that is easy to implement, extend and handles cases where there are multiple media streams , or c) people don't understand what I am proposing. What is the status of the Join: header work ? Who is handling it? This approach in my mind seems so much cleaner (and in the spirit of SIP) than the current SDP based-approach. The concept is simple. A second is INVITE is sent from the joiner to the joinee (where the joinee already has an established SIP session). Rather than a Replaces header, the INVITE has a Join header. Other than that it is almost identical to the current Replaces process. The only addition required is perhaps a header parameter that specifies whether the Join is for full or only local media mixing at the Joinee. In local mixing only the media from the joinee is sent to the joiner and the joiner's media is only mixed with the joinee rather than full conference-bridge style mixing. A possible extension may also allow the joiner to be NOTIFIED when it is the last INVITE present in the session. This is of course compatible with the REFER draft which even further extends what can be achieved with this simple addition. The SDP handling is easy as the Joiner can simply put no SDP in the INVITE, the Joinee will then return the current session SDP in the 200OK. It is then a simple matter for the joiner to select what media streams are to be "forked" in the ACK. No complicated "SDP" guessing games and SDP manipulation by proxies (as for current forked-DTMF suggestions). It simply supports multiple media streams and the addition or deletion of media streams. Additionally, it is easy to determine if a UA supports the Join header and an application server can alternatively Require it in the initial INVITE. Lastly, a join fails it does not jeopardize the existing sessions (as it would in the existing forked DTMF proposal). This is especially important if there are more than one application servers that are requesting to be Join'ed. I'd like to hear other peoples thoughts on this approach to problem that really needs to be solve properly. At the last bakeoff there were many companies wanting to use/deploy these important features. Where there is a need without a specification then people often go off and implement their own solutions (such as forking media streams through heuristical interpretation of adding new SDP media streams). Regards, Robert. ------_=_NextPart_001_01C0CD8A.1C223A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Join as replacement for DTMF/voice-forking.

If at first you don't succeed = .....

Hi,

I still didn't receive any comment = back on using Join as a replacement to beleaguered SDP based = DTMF-forking. I am not sure if this is because

  1. people don't see the = problems with the existing DTMF forking scheme (that has not been = standardized anywhere), or
  2. people see problems with using join = to provide this service in a highly flexible and generic manner that is = easy to implement, extend and handles cases where there are multiple = media streams <grin>, or
  3. people don't understand what I am = proposing.

What is the status of the Join: header = work ? Who is handling it?

This approach in my mind seems so much = cleaner (and in the spirit of SIP) than the current SDP based-approach. =

The concept is simple. A second is = INVITE is sent from the joiner to the joinee (where the joinee already = has an established SIP session). Rather than a Replaces header, the = INVITE has a Join header. Other than that it is almost identical to the = current Replaces process. The only addition required is perhaps a = header parameter that specifies whether the Join is for full or only = local media mixing at the Joinee. In local mixing only the media from = the joinee is sent to the joiner and the joiner's media is only mixed = with the joinee rather than full conference-bridge style mixing. A = possible extension may also allow the joiner to be NOTIFIED when it is = the last INVITE present in the session.

This is of course compatible with the = REFER draft which even further extends what can be achieved with this = simple addition.

The SDP handling is easy as the Joiner = can simply put no SDP in the INVITE, the Joinee will then return the = current session SDP in the 200OK. It is then a simple matter for the = joiner  to select what media streams are to be "forked" in the = ACK. No complicated "SDP" guessing games and SDP manipulation by = proxies (as for current forked-DTMF suggestions). It simply supports = multiple media streams and the addition or deletion of media = streams.

Additionally, it is easy to determine = if a UA supports the Join header and an application server can = alternatively Require it in the initial INVITE. Lastly, a join fails it = does not jeopardize the existing sessions (as it would in the existing = forked DTMF proposal). This is especially important if there are more = than one application servers that are requesting to be = Join'ed.

I'd like to hear other peoples = thoughts on this approach to problem that really needs to = be solve properly. At the last bakeoff there were many companies = wanting to use/deploy these important features. Where there is a need = without a specification then people often go off and implement their = own solutions (such as forking media streams through heuristical = interpretation of adding new SDP media streams).

Regards,

Robert.


------_=_NextPart_001_01C0CD8A.1C223A40-- _______________________________________________ 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 Wed Apr 25 10:09:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16486 for ; Wed, 25 Apr 2001 10:09:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04CB644338; Wed, 25 Apr 2001 10:09:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 43BC544373 for ; Wed, 25 Apr 2001 06:54:56 -0400 (EDT) Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3PAsvB05422 for ; Wed, 25 Apr 2001 05:54:57 -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 f3PAssv18210 for ; Wed, 25 Apr 2001 05:54:54 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Apr 25 05:54:54 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 05:54:54 -0500 Message-ID: <61D824C63B99D311975E00508B0CC985021B9A48@eamrcnt717.exu.ericsson.se> From: "Adam Roach (EUS)" To: Ben Campbell , Steve Donovan , Jonathan Rosenberg Cc: Rakesh Shah , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] First cut review of Session Timer draft. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CD76.28688F70" 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: Wed, 25 Apr 2001 05:54:53 -0500 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_01C0CD76.28688F70 Content-Type: text/plain; charset="iso-8859-1" Comments on the comments... :) /a > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Here are my first cut comments on session-timer for the > upcoming last-call. > Most of these are minor comments. Please forgive me if I am > re-opening old > discussions, as I did not follow the original session-timer work. > > 5:2 - Doesn't option of absolute time imply an assumption > that all elements > have their clocks reasonably synchronized? 3:1 - "Any entity that inserts a Session-Expires header with an absolute time MUST also insert a Date header into the message. This ensures proper operation for devices that do not have access to absolute time." Perhaps this sentance doesn't have enough hoopla about it, since I've had to point it out numerous times to different people. To those of you who have overlooked it (or even those you who haven't): do you have any suggestions about how to make it stand out more? Does it need better proximity to the paragraph explictly allowing absolute times (in section 5)? > 10:2 - How can a proxy know that it is the closes proxy to > the UAC that > cares about the timer? Except in the trivial case where the > proxy is the > closest to the UAC period, this seems problematic. Because the *first* proxy that cares will *add* a "Session-Expires" header. Other proxies will merely notice (and occasionally adjust) it. So, if you see no "Session-Expires," you're the first node that cares. If you don't, you aren't. A clarification to this effect would probably be useful... /a ------_=_NextPart_001_01C0CD76.28688F70 Content-Type: text/html; charset="iso-8859-1" RE: [SIP] First cut review of Session Timer draft.

Comments on the comments... :)

/a

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
>
> Here are my first cut comments on session-timer for the
> upcoming last-call.
> Most of these are minor comments. Please forgive me if I am
> re-opening old
> discussions, as I did not follow the original session-timer work.
>
> 5:2 - Doesn't option of absolute time imply an assumption
> that all elements
> have their clocks reasonably synchronized?

3:1 - "Any entity that inserts
       a Session-Expires header with an absolute time MUST also insert a
       Date header into the message. This ensures proper operation for
       devices that do not have access to absolute time."

Perhaps this sentance doesn't have enough hoopla about it, since
I've had to point it out numerous times to different people. To those
of you who have overlooked it (or even those you who haven't): do you
have any suggestions about how to make it stand out more? Does it need
better proximity to the paragraph explictly allowing absolute times
(in section 5)?

> 10:2 - How can a proxy know that it is the closes proxy to
> the UAC that
> cares about the timer? Except in the trivial case where the
> proxy is the
> closest to the UAC period, this seems problematic.

Because the *first* proxy that cares will *add* a "Session-Expires"
header. Other proxies will merely notice (and occasionally
adjust) it. So, if you see no "Session-Expires," you're the first node
that cares. If you don't, you aren't.

A clarification to this effect would probably be useful...

/a

------_=_NextPart_001_01C0CD76.28688F70-- _______________________________________________ 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 Wed Apr 25 10:26:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17328 for ; Wed, 25 Apr 2001 10:26:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E2FA44352; Wed, 25 Apr 2001 10:26:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by lists.bell-labs.com (Postfix) with ESMTP id 4F0CC44338 for ; Wed, 25 Apr 2001 10:25:32 -0400 (EDT) Received: from beta.hut.fi (bhoeneis@beta.hut.fi [130.233.224.51]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id RAA13733 for ; Wed, 25 Apr 2001 17:25:31 +0300 (EET DST) From: Bernie Hoeneisen To: IETF SIP Mailinglist Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Retransmission detection and spirals 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: Wed, 25 Apr 2001 17:25:30 +0300 (EET DST) Hi! 1) In the current version of RFC2543bis-02, in section 11.5 it says: "2. If the Call-ID exists, the request is for an existing call. If the To, From, Call-ID, and CSeq values exactly match (including tags) those of any requests received previously, the request is a retransmission." On the other hand, according to section 6.47.6 visiting the same SIP proxy twice, but with different Request URIs is allowed, (called spiraling or legal loops). This leads to the situation, that when such a request is arriving the second time at the same SIP proxy (spiraling), is recognized as a retransmission according to section 11.5. Thus, we need to add in section 11.5.2 something, that also the Request URI is checked for retransimission detection. Or did I understand something wrongly? 2) Similar to this issue, I found something in the mailing archives: http://lists.bell-labs.com/pipermail/sip/2000q4/004567.html "The call leg is idenfitied with a tag, but the transaction is identified based on the To, From, Call-ID, CSeq, R-URI and top via. (the latter two being new since rfc2543, to handle spirals and request merging, respectively)." This statement of Jonathan seems to be not (yet?) reflected in the RFC2543bis-02 draft. Is this coming in the next version? Comments? cheers, Bernie _______________________________________________ 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 Wed Apr 25 10:54:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18497 for ; Wed, 25 Apr 2001 10:54:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1133C44344; Wed, 25 Apr 2001 10:54:03 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 47E3E44338 for ; Wed, 25 Apr 2001 10:53:56 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Apr 25 10:52:29 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 7E58144380; Wed, 25 Apr 2001 10:39:13 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156]) by lists.bell-labs.com (Postfix) with SMTP id 2D3844437D for ; Wed, 25 Apr 2001 10:39:13 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA14115; Wed, 25 Apr 2001 09:39:09 -0500 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA14108; Wed, 25 Apr 2001 09:39:08 -0500 Message-ID: <3AE6E18B.69E91E9@lucent.com> 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: Arunachalam Venkatraman Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] :BYE for pending INVITE was Further editorial nit in the bis draft References: <475FF955A05DD411980D00508B6D5FB001AC31D7@en0033exch001u.uk.lucent.com> <001601c0cd81$714fbbe0$5303600a@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: Wed, 25 Apr 2001 09:39:07 -0500 Content-Transfer-Encoding: 7bit Arunachalam Venkatraman wrote: > > If the INVITE was responded to with 100 Trying (thus disabling > retransmissions) and the BYE with 200 OK (since the INVITE has not > completed), the UAS and the proxies en-route would have cleared the call > on receipt of the 200 OK to the BYE. What is the value of the 487 to > INVITE ? Other than the protocol rule that each transaction completes > independently. Is there going to be any stack that will be upset if the > 487 is not sent in this case? I would be careful about making too many assumptions here. There maybe call-stateful proxies that may have allocated some resources on proxying the INVITE transaction. These proxies will need a final response (even a non-200 one) from the UAS in order to release the resources. These proxies may never see a BYE since they R-R but R-R does not take effect on a non-2xx response to the INVITE (except on certain 4xx responses -- namely 401 Un- authorized and 484 Address Incomplete; 487 is not one of them). I think you are safe if you stick with the dictum of always allowing each transaction to complete independently. - 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 _______________________________________________ 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 Wed Apr 25 11:45:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20323 for ; Wed, 25 Apr 2001 11:45:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21AF044344; Wed, 25 Apr 2001 11:45:04 -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 87ED944336 for ; Wed, 25 Apr 2001 11:44:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA05683; Wed, 25 Apr 2001 11:47:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 11:44:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shan Lu'" Cc: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] RE: [Sip-implementors] Clarification on sdp usage sought 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: Wed, 25 Apr 2001 11:44:00 -0400 Moving this to SIP, since its a bigger issue. > -----Original Message----- > From: Shan Lu [mailto:slu@nextone.com] > Sent: Tuesday, April 24, 2001 2:30 PM > Cc: Sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Clarification on sdp usage sought > > > > > > > However, it is JUST ADVISORY. > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Receivers need to be prepared to receive any number of > frames per packet. > > !!!!!!!!!!!!!!!!!!!!!!!!!!!! > > This is easier said than done. Take G.729 for example. If an > implementation supports the base frame size (10ms), then I agree that > any number of frames per packet can be supported because a > multi-frame > RTP packet can always be sliced up. However, the 10ms frame > size may not > be suitable for some implementations (due to, say, too many > interrupts > from the DSP. I assume DSPs here again.) So you may have an > implementation that can only support nx20ms, or nx30ms G.729. > In other > cases, you have implementations that can support nx10 ms > G.729 but the > size has to be preconfigured (because, say, trade-offs have > to be made > here and different DSP codes have to be loaded in the DSPs.) > We've seen > a lot of these cases in past SIP bake-offs and H323 events. Right. And these are causing interoperability failures. Thats why you need to deal with this properly, and be prepared to receive any number of frame sizes. If you want to get larger packetizations in order to reduce DSP interrupts, then send a ptime with some larger value in the SDP. But, its only advisory. You must be prepared to receive any number. Its what rfc1889 says. Its what the update to rfc1889 says. Its there for a reason. > > One may argue that the 20ms or 30ms G.729 is really not G.729 > compliant. > But let's be practical here. The only thing you lose by > doubling G.729 > frame size from 10ms to 20ms is additional 10ms one-way delay, which > obviously is not a big deal for VoIP applications. Apparently, the problem is that we are losing interoperability. > > What about non-frame based codecs -- G.711 A/u-law? I believe > the "frame > size" is defined (in RFC???) to be 1 ms. But I have yet to see one > DSP-based implementation that can operate G.711 on 1ms granularity. Realistically, no one is ever going to send that fast, and you can send ptime as an advisory to tell them not to send that fast. If they do anyway, hang up. But, your code must support any number of samples per packet. Thats not just a spec requirement, its good software design. > > All in all, let me repeat what I said above:We need something > in SDP to > support this application -- codec specific packetization size. No, what we need is for people to actually implement the specifications correctly. Supporting the various nuances of all the different constraints an implementation might introduce is a road to interoperability nightmares and complexity. What if some implementation can do 20ms G.729 when a video codec is running, but 10ms otherwise? Shall we support that? What if another implementation supports 30ms G.729 when H.263 with B frames is running, in conjunction with silence suppression, but if there is no video, and only silence suppression, it does 20ms, and if nothing else, 10ms. Shall we support that too? We have taken the approach with SIP to keep it simple, and keep it general. I think we should stick with that approach. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 12:10:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21198 for ; Wed, 25 Apr 2001 12:10:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8145B44363; Wed, 25 Apr 2001 12:10: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 B273144336 for ; Wed, 25 Apr 2001 12:09:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA06196 for ; Wed, 25 Apr 2001 12:13:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 12:09:40 -0400 Message-ID: From: Igor Slepchin 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] removing transport, maddr and port from request URI (was RE: [SIP ] Request-uri does not match record-route header...) 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: Wed, 25 Apr 2001 12:09:37 -0400 I actually wanted to discuss this for quite some time now so here it goes. I do believe that maddr, transport and port should be removed from the request URI unless they are intended to be used for routing by the downstream SIP entities. In other words, if you are forwarding a request based on the information supplied in maddr, port or transport, you should remove that information from the request URI before forwarding the request. Here is the motivation. All components of request URI may be used for routing by the downstream proxies. Keeping the parameters that should _never_ be used for routing seems to contradict that assumption and sounds rather weird to me; in the worst case scenario, this may even cause unintended loops (e.g., if a proxy somewhere downstream suddenly decides to honor an maddr pointing to the local outbound proxy of the UAC). On the other hand, removing them if they are no longer needed is always safe. What do people think? Thank you, Igor Slepchin > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Thursday, April 19, 2001 6:33 AM > To: Pekka Pessi; sip@lists.bell-labs.com > Cc: Fairlie-Cuninghame, Robert > Subject: RE: [SIP] Request-uri does not match record-route header... > > > > Proxies should always use the next route header. > > > > However, there is a problem if the initial RequestURI and > > the first > > url in the route are identical (sans maddr and > other transport > > parameters, which are removed by sender). > > Uh, at the risk that this is orthoganol to the issue at hand, > why would these parameters be removed? Note that they're no- > longer illegal in the Request-URI (I think they were in RFC). > > > - Jo. > > > _______________________________________________ > 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 Wed Apr 25 13:29:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23514 for ; Wed, 25 Apr 2001 13:29:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5118A44338; Wed, 25 Apr 2001 13:29: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 C457644336 for ; Wed, 25 Apr 2001 13:28:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA07288; Wed, 25 Apr 2001 13:32:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 13:28:36 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vijay Gurbani'" , Arunachalam Venkatraman Cc: sip@lists.bell-labs.com Subject: RE: [SIP] :BYE for pending INVITE was Further editorial nit in th e bis draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 25 Apr 2001 13:28:30 -0400 > -----Original Message----- > From: Vijay Gurbani [mailto:vkg@lucent.com] > Sent: Wednesday, April 25, 2001 10:39 AM > To: Arunachalam Venkatraman > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] :BYE for pending INVITE was Further > editorial nit in > the bis draft > > > Arunachalam Venkatraman wrote: > > > > If the INVITE was responded to with 100 Trying (thus disabling > > retransmissions) and the BYE with 200 OK (since the INVITE has not > > completed), the UAS and the proxies en-route would have > cleared the call > > on receipt of the 200 OK to the BYE. What is the value of > the 487 to > > INVITE ? Other than the protocol rule that each transaction > completes > > independently. Is there going to be any stack that will be > upset if the > > 487 is not sent in this case? > > I would be careful about making too many assumptions here. > There maybe > call-stateful proxies that may have allocated some resources > on proxying > the INVITE transaction. These proxies will need a final > response (even a > non-200 one) from the UAS in order to release the resources. > These proxies > may never see a BYE since they R-R but R-R does not take > effect on a non-2xx > response to the INVITE (except on certain 4xx responses -- > namely 401 Un- > authorized and 484 Address Incomplete; 487 is not one of them). Let me make a bit of a stronger statement than Vijay has. Arunachalam has made a statement above which I hear often, and which is a very, very wrong statement: >If the INVITE was responded to with 100 Trying (thus disabling >retransmissions) and the BYE with 200 OK (since the INVITE has not >completed), the UAS and the proxies en-route would have >cleared the call >on receipt of the 200 OK to the BYE Proxies as TRANSACTIONAL elements. Their default operation is to not know about calls or call state. There is nothing in rfc2543 about a proxy "clearing call state". Proxies are not the same as switches. THey are not the same as gatekeepers. Because of their transactional nature, and because of the transactional nature of SIP, we have the golden rule, or "mantra", of SIP, which is worth repeating three times for its importance: All transactions complete independently. All transactions complete independently. All transactions complete independently. Without this, state maintenance in proxies is a nightmare. Whenever in doubt about some aspect of SIP operation, recite this mantra, and see if it doesn't answer the question. Specifically, it is because of this golden rule that we now require a cancelled request to be responded to with a 487. Why? To clear transaction state in proxies. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 13:43:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24037 for ; Wed, 25 Apr 2001 13:43:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A5764435D; Wed, 25 Apr 2001 13:43: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 AB62244336 for ; Wed, 25 Apr 2001 13:42:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA07525; Wed, 25 Apr 2001 13:45:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 13:42:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bernie Hoeneisen'" , IETF SIP Mailinglist Subject: RE: [SIP] Retransmission detection and spirals MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 25 Apr 2001 13:42:16 -0400 > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@cc.hut.fi] > Sent: Wednesday, April 25, 2001 10:26 AM > To: IETF SIP Mailinglist > Subject: [SIP] Retransmission detection and spirals > > > Hi! > > 1) In the current version of RFC2543bis-02, in section 11.5 it says: > > "2. If the Call-ID exists, the request is for an existing call. > If the To, From, Call-ID, and CSeq values exactly match > (including tags) those of any requests received previously, > the request is a retransmission." > > On the other hand, according to section 6.47.6 visiting the same > SIP proxy twice, but with different Request URIs is allowed, > (called spiraling or legal loops). > > This leads to the situation, that when such a request is > arriving the > second time at the same SIP proxy (spiraling), is recognized as a > retransmission according to section 11.5. You are correct, although it may not matter in the context of this section. A request is mapped to a transaction through the combination of the Call-ID, to, from, Call-ID, CSeq, R-URI and top via, as you point out below. Thus, this text in section 11.5 is wrong, in that this is not sufficent to identify a retransmission. However, section 11.5 deals with UA behavior. Spirals are not of importance for a UA (although merged requests are, and those require attention be paid to the top via). Really, this statement doesn't even belong in section 11.5, since retransmissions should be handled at a transaction level, and thats not specific to a UA. So, this needs correcting by updating it and moving it somewhere else. > > > 2) Similar to this issue, I found something in the mailing archives: > http://lists.bell-labs.com/pipermail/sip/2000q4/004567.html > "The call leg is idenfitied with a tag, but the transaction is > identified based on the To, From, Call-ID, CSeq, R-URI and top via. > (the latter two being new since rfc2543, to handle spirals > and request > merging, respectively)." > This statement of Jonathan seems to be not (yet?) reflected in the > RFC2543bis-02 draft. Is this coming in the next version? Comments? It has already been corrected in the text I have for the next revision of the spec, due out very shortly. However, I still need to move it elsewhere. That will probably be part of a more extensive editing task for -04. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 13:52:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24304 for ; Wed, 25 Apr 2001 13:52: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 27FF844380; Wed, 25 Apr 2001 13:52:04 -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.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id CB3E544379 for ; Wed, 25 Apr 2001 13:51:53 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA05470; Wed, 25 Apr 2001 10:52:19 -0700 (PDT) Received: from cisco.com (wbreu-lnx.cisco.com [128.107.140.161]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAG01239; Wed, 25 Apr 2001 10:51:48 -0700 (PDT) Message-ID: <3AE70EB5.1CC093@cisco.com> From: Wendy Breu X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-23.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: Roland , sip@vovida.org Cc: sip@lists.bell-labs.com Subject: Re:[SIP] anyone study Vovida source? References: <20010425095401.70E5A44379@lists.bell-labs.com> Content-Type: multipart/alternative; boundary="------------AD7A4CF145B278C5CA0AF02D" 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: Wed, 25 Apr 2001 10:51:49 -0700 --------------AD7A4CF145B278C5CA0AF02D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there, It is not clear to me your question is for the sipstack or for the entire Vocal library. Regardless, you can use LXR to traverse all our source code. In the future, please post your question to sip@vovida.org or vocal@vovida.org for faster help. Thanks, [Vocal] where can i have the sequence diagram??? Wendy Breu wbreu@cisco.com Fri, 20 Apr 2001 10:55:43 -0700 Previous message: [Vocal] where can i have the sequence diagram??? Next message: [Vocal] compilation Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] --------------7892D4162E1CE1C550E9955C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there, One quick way to view which calls what, is to use the Linux Cross Reference. Please follow the link at http://www.vovida.org: SiteTools->LXR->sip->sipstack and follow the object/class of interest. The files are intrumented such that you can click on any identifier and you can find a detailed description on where a function is defined and where it is used. Hope this helps. If you have more specific questions, please let us know. kanumuri sreeram wrote: > hi sunitha kumar, > > i am going threw the vovida code of sip stack .i want to know which > class is calling which call and all the details > ............ snipped > > > sreeram > From Sip Digest Vol 1 - #983 I downloaded all the Vovida.com open source code for SIP, but it's quite difficulty to read the source. any one knows some helpful document about that? for big picture, for relationship of the classes? any information about that , please tell me. Thanks!!!!!!!!!!!!!!!!!!!!!! Very Much!!!!!!! Roland -- ****** -- Wendy | mailto:wbreu@cisco.com | http://www.vovida.org | --------------AD7A4CF145B278C5CA0AF02D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there,

It is not clear to me your question is for the sipstack or
for the entire Vocal library.  Regardless, you can use
LXR to traverse all our source code.

In the future, please post your question to sip@vovida.org
or vocal@vovida.org for faster help.  Thanks,
 

[Vocal] where can i have the sequence diagram???

Wendy Breu wbreu@cisco.com
Fri, 20 Apr 2001 10:55:43 -0700

       Previous message: [Vocal] where can i have the sequence diagram???
       Next message: [Vocal] compilation
       Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
 
 

--------------7892D4162E1CE1C550E9955C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi there,

One quick way to view which calls what, is to use the Linux Cross
Reference.
Please follow the link at http://www.vovida.org:

      SiteTools->LXR->sip->sipstack

and follow the object/class of interest.  The files are intrumented such
that
you can click on any identifier and you can find a detailed description
on
where a function is defined and where it is used.   Hope this helps.

If you have more specific questions, please let us know.

kanumuri sreeram wrote:

>  hi sunitha kumar,
>
> i am going threw the vovida code of sip stack .i want to know which
> class is calling which call and all the details
>
............ snipped
>
>
> sreeram
>
 

From Sip Digest Vol 1 - #983

I downloaded all the Vovida.com open source code for SIP,
but it's quite difficulty to read the source.
 any one knows some helpful document about that?
for big picture, for relationship of the classes?
any information about that , please tell me.
 
Thanks!!!!!!!!!!!!!!!!!!!!!!
Very Much!!!!!!!
 
Roland
 
 
 
  

-- 
******
-- Wendy  | mailto:wbreu@cisco.com | http://www.vovida.org  |
  --------------AD7A4CF145B278C5CA0AF02D-- _______________________________________________ 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 Wed Apr 25 13:55:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24404 for ; Wed, 25 Apr 2001 13:55:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1D8C4438B; Wed, 25 Apr 2001 13:55:04 -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 53F2544363 for ; Wed, 25 Apr 2001 13:54:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA07785; Wed, 25 Apr 2001 13:58:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 13:54:52 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 25 Apr 2001 13:54:51 -0400 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, April 25, 2001 6:01 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt > > > The initial enquiry and Brett's response assume that the > result of hold is > asymmetrical. While the service examples draft is an attempt > to emulate PSTN > services, the service result in this case is not the same. > > The service-examples draft contains the following key words > > . Note that either party can take the other party off > of hold. > > SIP hold removes the media stream(s). They are removed at > both ends. If A > holds B, then both parties are in the state of having no media stream. No, that is not true. If A sends B a re-INVITE with a stream held (meaning its connection address is 0.0.0.0), the only thing this means is that A does not wish to receive media from B. It does not mean that A should cease sending media to B, although it can always do that as a UI issue. The whole idea of the 0.0.0.0 "hack" was that it achieved call hold as a natural side-effect of an existing operation. By assigning it the meaning of "hold" as well, we allow UI's to take advantage of knowing about being on hold, yet allow for the service to work for devices that don't know anything about hold. All they know is that they cannot send packets to the nonexistent 0.0.0.0 address. As a consequence, no special behavior should be implied from SDP with 0.0.0.0 in the c line, beyond, "don't send me media". > The process of coming out of hold requires merely adding a > media stream and > therefore either end can invoke this function. No, a stream is not "added". Adding a stream implies the addition of a new m line in the SDP. That is not the case. One comes off of hold by sending a reinvite with the c line of the existing, held stream changed back to a valid IP address. The only note > I would make is > that if A held B, then A presumably did it to release > resources to perform > some other function (this is the purpose of hold in both the > PSTN and ISDN). > If B tries to resume the call before A is ready, then those > resources may > still be unavailable, and A may reject the request (e.g. with > "busy here" or > "busy everywhere"). This complication is non-existent with the correct, unidirectional interpretation of hold. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 13:58:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24504 for ; Wed, 25 Apr 2001 13:58:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5E3A44392; Wed, 25 Apr 2001 13:58:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 5FADE44369 for ; Wed, 25 Apr 2001 13:57:45 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id NAA37558; Wed, 25 Apr 2001 13:57:45 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt Message-ID: <004101c0cdb1$822d3480$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <475FF955A05DD411980D00508B6D5FB001AC31D8@en0033exch001u.uk.lucent.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: Wed, 25 Apr 2001 13:59:43 -0400 Content-Transfer-Encoding: 7bit > The initial enquiry and Brett's response assume that the > result of hold is > asymmetrical. While the service examples draft is an attempt > to emulate PSTN > services, the service result in this case is not the same. > > The service-examples draft contains the following key words > > . Note that either party can take the other party off > of hold. Then the text needs to be updated. Either party can send re-INVITE with non-hold SDP, however the receiver can return hold SDP if the party doesn't wish to come off hold. > > SIP hold removes the media stream(s). They are removed at > both ends. If A > holds B, then both parties are in the state of having no media stream. This isn't necessarily true in SIP. If A sends a re-INVITE with hold SDP to B, B can/should reply with non-hold SDP if B is willing to listen while on hold. > Neither side is particularly holding or held. > If B holds A, then both > parties are still in the state of having no media stream, and > therefore, > while such a request is not invalid, it has zero impact on > the overall state > of the session. > > The process of coming out of hold requires merely adding a > media stream and > therefore either end can invoke this function. The only note > I would make is > that if A held B, then A presumably did it to release > resources to perform > some other function (this is the purpose of hold in both the > PSTN and ISDN). > If B tries to resume the call before A is ready, then those > resources may > still be unavailable, and A may reject the request (e.g. with > "busy here" or > "busy everywhere"). > If the receiver accepts the re-INVITE but wishes to currently have the call on hold, returning a 200 with held SDP seems most appropriate. _______________________________________________ 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 Wed Apr 25 14:05:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24787 for ; Wed, 25 Apr 2001 14:05:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1C9344397; Wed, 25 Apr 2001 14:05:04 -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 AD00744365 for ; Wed, 25 Apr 2001 14:04:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08012; Wed, 25 Apr 2001 14:08:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:04:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Further editorial nit in the bis draft 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: Wed, 25 Apr 2001 14:04:29 -0400 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, April 25, 2001 5:38 AM > To: Drage, Keith (Keith); 'Henning G. Schulzrinne' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Further editorial nit in the bis draft > > > I agree there are indications in the current bis draft that > suggest a BYE > also terminates pending transactions. Assuming that people > agree that this > is correct behaviour, the the following considerations apply. I don't know that I'd phrase it as "BYE terminates pending transactions". The main issue is that if you send a BYE before INVITE completes, you must complete the INVITE transaction (this is because of the golden rule in sip, that all transactions complete independently). So, what response code? Really, it matters not one drop. But, the suggestion was made to use 487. Thats just as fine as anything else, and probably the most appropriate. But, it is not the same as saying BYE terminates pending transactions, just like CANCEL. > > I do note that if this is required behaviour, then there > should be more text > in section 4.2.4 (BYE) that specifies this behaviour. > > Section 4.2.5 (CANCEL) specifies the following for the 487 activity: > > The behavior of the user agent or redirect server on receiving a > CANCEL request depends on whether the server has already > sent a final > response for the original request. If it has, the CANCEL > request has > no effect on the original request, any call state and on the > responses generated for the original request. If the server has not > issued a final response for the original request, it immediately > sends a 487 (Request Terminated) for the original request. > For INVITE > requests, the UAC as usual sends an ACK request to confirm > receipt of > any final response. The CANCEL request itself is answered > with a 200 > (OK) response in either case. > > A proxy client or UAC cannot rely on receiving a 487 (Request > Terminated) response, as a RFC 2543-compliant UAS will not generate > such a response. If there has been no final response after 32 > seconds, the client MAY consider the original transaction to have > been cancelled. This text above is fine. Its talking about CANCEL, not BYE. > > The only text in 4.2.4 that looks like this talks only about > terminating > INVITE requests, and does not mention the status-code to be used. > > A BYE request from either called or calling party terminates any > pending INVITE at a UA, but the INVITE request transaction MUST be > completed with a final response and ACK. I would add text here that says, "It is RECOMMENDED that a 487 code be used in the final response to INVITE" > > Presumably BYE can also terminate other requests within the session > (OPTIONS, PRACK, COMET) and this status-code should also be > used for them. This is unlikely to be an issue, since these should be responded to immediately anyway. But, it is worth noting that any outstanding transactions for a call that is BYEd MUST be responded to. > > I would suggest that the implied behaviour for BYE requires > some text in > 4.2.4 based on that currently in 4.2.5 for CANCEL. > > Back to the subject of the associated text string value, I note the > following text in 6.21 would imply that "cancelled" and > "cancellation" can > be done by BYE, so we may want to change the words there as well. > > Strictly speaking, CSeq header fields are needed for any > SIP request that can be cancelled by a BYE or CANCEL > request or where a client can issue several requests for > the same Call-ID in close succession. Without a sequence > number, the response to an INVITE could be mistaken for the > response to the cancellation (BYE or CANCEL). Actually, I would rather remove the reference to cancelling a request with BYE. Thats legacy from the old days when, in fact, sending a BYE meant you didn't need to respond to the original INVITE. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 14:24:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25487 for ; Wed, 25 Apr 2001 14:24:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6288344380; Wed, 25 Apr 2001 14:24:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from imr2.ericy.com (unknown [12.34.240.68]) by lists.bell-labs.com (Postfix) with ESMTP id 9FB244435D for ; Wed, 25 Apr 2001 14:23:09 -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 f3PIN8804117 for ; Wed, 25 Apr 2001 13:23:08 -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 f3PIN8c09618 for ; Wed, 25 Apr 2001 13:23:08 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Apr 25 13:22:53 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Apr 2001 13:22:53 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'Drage, Keith (Keith)'" , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Further editorial nit in the bis draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDB4.BD9108A0" 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: Wed, 25 Apr 2001 13:22:52 -0500 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_01C0CDB4.BD9108A0 Content-Type: text/plain; charset="iso-8859-1" >Actually, I would rather remove the reference to cancelling a >request with >BYE. Thats legacy from the old days when, in fact, sending a >BYE meant you >didn't need to respond to the original INVITE. > Do you mean to remove the option of sending a BYE prior to the conclusion of the INVITE transaction signalling that the INVITE transaction should be "cancelled"? Or do you mean simply the idea that a BYE sent in this case means that the INVITE does not need to be responded to (with a 487)? >-Jonathan R. > >--- >Jonathan D. Rosenberg 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 /sean ------_=_NextPart_001_01C0CDB4.BD9108A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Further editorial nit in the bis draft

>Actually, I would rather remove the reference to = cancelling a
>request with
>BYE. Thats legacy from the old days when, in = fact, sending a
>BYE meant you
>didn't need to respond to the original = INVITE.
>

Do you mean to remove the option of sending a BYE = prior
to the conclusion of the INVITE transaction = signalling that
the INVITE transaction should be = "cancelled"? Or do you mean
simply the idea that a BYE sent in this case means = that the
INVITE does not need to be responded to (with a = 487)?

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

/sean

------_=_NextPart_001_01C0CDB4.BD9108A0-- _______________________________________________ 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 Wed Apr 25 14:27:28 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25682 for ; Wed, 25 Apr 2001 14:27:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D6A64438B; Wed, 25 Apr 2001 14:27: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 D4FB344385 for ; Wed, 25 Apr 2001 14:26:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08491; Wed, 25 Apr 2001 14:30:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:26:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sekhar Banerjee'" , "'brett@broadsoft.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] Hop to Hop forwarding of Invite responses in the call f lows docum ent 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: Wed, 25 Apr 2001 14:26:47 -0400 > -----Original Message----- > From: Sekhar Banerjee [mailto:SBanerjee@lboard.com] > Sent: Tuesday, April 24, 2001 6:14 PM > To: 'brett@broadsoft.com'; sip@lists.bell-labs.com > Subject: RE: [SIP] Hop to Hop forwarding of Invite responses > in the call > f lows docum ent > > > Bret, > Thanks for the response. The other question would be is > the 200 OK > response to the CANCEL supposed to be generated by the proxy > too without > waiting for a response to the CANCEL that was forwarded to > the next hop. Yes. From Section 10.2.1 (which is not the most intuitive place for this): Each server in a proxy chain generates its own final response to a CANCEL request. The server responds immediately upon receipt of the CANCEL request rather than waiting until it has received final responses from the CANCEL requests it generates. -Jonathan R. --- Jonathan D. Rosenberg 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 > > I was going through the call flows in > > http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-call > > -flows-03.txt > > and the falure scenario under 3.2.1 is where I have a question. The > > Unsuccssful SIP to SIP no answer call flow seems to imply > > that not only is > > the CANCEL a hop to hop request but also the 487 response and > > the ACK are > > hop to hop. I thought that 487 and ACK were end to end. Am I missing > > something here ? > > As stated in third paragraph section 10.3.1 > of rfc2543bis-02 November 24, 2000, > "a proxy generates an ACK for non-2xx final > responses." > > Similar text is in section 12.4. > > > _______________________________________________ > 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@lists.bell-labs.com Wed Apr 25 14:31:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25961 for ; Wed, 25 Apr 2001 14:31: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 A69974439E; Wed, 25 Apr 2001 14:31: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 D95D944385 for ; Wed, 25 Apr 2001 14:30:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08561; Wed, 25 Apr 2001 14:33:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:30:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ranjit Avasarala'" , kanumuri sreeram , sip@lists.bell-labs.com Subject: RE: [SIP] call hold ,call transfer in sip? 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: Wed, 25 Apr 2001 14:30:12 -0400 -----Original Message----- >From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com] >Sent: Tuesday, April 24, 2001 11:26 AM >To: kanumuri sreeram; sip@lists.bell-labs.com >Subject: Re: [SIP] call hold ,call transfer in sip? > > >Hi > Call transfer in SIP takes place thru REFER method. The REFER method indicates that >the recipient (identified by the Request-URI) should > contact a third party using the contact information provided in the method. A success >response indicates that the recipient was able to > contact the third party. No, thats not true. A success response just means that the REFER was accepted and acted upon. The transaction does not wait around until the third party has been contacted. Also, questions like these (and there answers) belong on the sip-implementors list, as the trailer in this message indicates. -Jonathan R. --- Jonathan D. Rosenberg 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: kanumuri sreeram To: sip@lists.bell-labs.com Sent: Tuesday, April 24, 2001 8:23 AM Subject: [SIP] call hold ,call transfer in sip? hi all, can u tell me will sip support call-transfer and call hold?? if so how. my douth is like this A calls B Active state B will keep call hold call C attaches to A(i.e call transfer) i know that call transfer is there ok. i want call transfer/ can any one make me clear how these are done in sip thanks in advance sreeram Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices _______________________________________________ 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 Wed Apr 25 14:36:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26176 for ; Wed, 25 Apr 2001 14:36:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FE18443AA; Wed, 25 Apr 2001 14:36: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 F1ECD44385 for ; Wed, 25 Apr 2001 14:35:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08666; Wed, 25 Apr 2001 14:38:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:34:51 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson (EUS)'" , "'Drage, Keith (Keith)'" , "'Henning G. Schulzrinne'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Further editorial nit in the bis draft 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: Wed, 25 Apr 2001 14:34:46 -0400 -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, April 25, 2001 2:23 PM To: 'Jonathan Rosenberg'; 'Drage, Keith (Keith)'; 'Henning G. Schulzrinne' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] Further editorial nit in the bis draft >>Actually, I would rather remove the reference to cancelling a >>request with >>BYE. Thats legacy from the old days when, in fact, sending a >>BYE meant you >>didn't need to respond to the original INVITE. >> >Do you mean to remove the option of sending a BYE prior >to the conclusion of the INVITE transaction signalling that >the INVITE transaction should be "cancelled"? Or do you mean >simply the idea that a BYE sent in this case means that the >INVITE does not need to be responded to (with a 487)? The idea that BYE in this case means that the INVITE doesn't need to be responded to. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 14:59:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27047 for ; Wed, 25 Apr 2001 14:59:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3210D4433F; Wed, 25 Apr 2001 14:59: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 1634C44336 for ; Wed, 25 Apr 2001 14:58:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA09082; Wed, 25 Apr 2001 15:02:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:58:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Drage, Keith (Keith)'" , "'Mayank Sharma'" , "Chen, Xin (Xin)" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] A question about Cancel request MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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: Wed, 25 Apr 2001 14:58:49 -0400 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, April 09, 2001 9:48 AM > To: 'Mayank Sharma'; Chen, Xin (Xin); 'sip@lists.bell-labs.com'; > 'Jonathan Rosenberg' > Subject: RE: [SIP] A question about Cancel request > > > We have a clear incompatibility in the SIP drafts here. > > While draft-ietf-sip-call-flows-03.txt section 3.2.3 implies that the > expected action is to send a CANCEL, we have been unable to > find any text in > the bis-02 draft indicating any special use of CANCEL from a > proxy in this > case. I agree that it is worthwhile discussing the usage of CANCEL in a proxy in more detail. Unless anyone objects, I will add some text (for -04) that says that a proxy SHOULD NOT send a CANCEL for a timed-out request for which it has not received any provisional response. The proxy is supposed to have gotten a 100 if the final response can't be answered within 500ms. So, the absence of a provisional response after 32s implies that there is either a malfunctioning, or non-existent server at the receiving end of the request. In either case, sending CANCEL is useless. -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 15:19:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27713 for ; Wed, 25 Apr 2001 15:19:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 759C64437D; Wed, 25 Apr 2001 15:19:02 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from web14206.mail.yahoo.com (web14206.mail.yahoo.com [216.136.173.70]) by lists.bell-labs.com (Postfix) with SMTP id 8DAFB44336 for ; Wed, 25 Apr 2001 15:18:47 -0400 (EDT) Message-ID: <20010425191847.3188.qmail@web14206.mail.yahoo.com> Received: from [202.177.130.180] by web14206.mail.yahoo.com; Wed, 25 Apr 2001 12:18:47 PDT From: kanumuri sreeram To: Jonathan Rosenberg , "'Drage, Keith (Keith)'" , "'Mayank Sharma'" , "Chen, Xin (Xin)" , "'sip@lists.bell-labs.com'" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1631518149-988226327=:99502" Subject: [SIP] 3gpp--controoler????? 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: Wed, 25 Apr 2001 12:18:47 -0700 (PDT) --0-1631518149-988226327=:99502 Content-Type: text/plain; charset=us-ascii hi all, i have a douth regarding the 3pcc in sip. i am clear that this is possible with the help of the controller. like it is what which will take care of the signalling and the medai will be transfer will be taking place among them selves "true" i.e A-------------CONTROLLER---------------------------B direct media transfer =================================== ok but i am not claer about this entity controller can any one make me clear likw what is ? if this is a different entity it should also be showm in the architecture of sip like sipua,proxy,rediect,CONTROLLER.... so i am clear with me douth can anu one help me sreeram --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1631518149-988226327=:99502 Content-Type: text/html; charset=us-ascii

hi all,

i have a douth regarding the 3pcc in sip.

i am clear that this is possible with the help of the controller.

like it is what which will take care of the signalling and the medai will be transfer will be taking place among them selves "true" i.e

A-------------CONTROLLER---------------------------B

  direct media transfer

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

 

ok but i am not claer about this entity controller can any one make me clear likw what is ?

if this is a different entity it should also be showm in the architecture of sip

like sipua,proxy,rediect,CONTROLLER....

so i am clear with me douth can anu one help me

sreeram


 

 


Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices --0-1631518149-988226327=:99502-- _______________________________________________ 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 Wed Apr 25 15:22:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27875 for ; Wed, 25 Apr 2001 15:22: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 025D6443BC; Wed, 25 Apr 2001 15:22: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 ED09B443BB for ; Wed, 25 Apr 2001 15:21:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA09424; Wed, 25 Apr 2001 15:24:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 15:20:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'Arunachalam Venkatraman'" , "Fairlie-Cuninghame, Robert" , Sherman Gong , sip@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] Request-uri does not match record-route header... 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: Wed, 25 Apr 2001 15:20:49 -0400 -----Original Message----- >From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] >Sent: Tuesday, April 17, 2001 11:14 AM >To: Fairlie-Cuninghame, Robert; Sherman Gong; sip@lists.bell-labs.com >Cc: 'Jonathan Rosenberg' >Subject: RE: [SIP] Request-uri does not match record-route header... > > >How does the proxy know if the client is DNS capable? If the proxy know it is the default >proxy and should not Record Route, it can then simply route the call based on the maddr in >the Route. Again, the name-addr in the Req-URI is irrelevant. As always with record-routing, there are multiple issues being mixed here. The issues are: 1. does the value of the userhost portion of the request URI in ACK matter to the proxy that receives it, given a Route header is present 2. how do we handle record-routing with local outbound proxies The original question raised by Sherman is (1). The 5300 seems to have correctly computed the Route set (flipped the order of RR, add Contact at the bottom). THen, it popped the top route set element, and placed that in the R-URI, but modified the host portion. Arunachalam has argued that it doesn't matter, since the request can be routed by the proxy without the correct userhost field, as a Route header is present. This is absolutely not correct. As others have pointed out, the Request URI is used for transaction identification. A UA MUST NOT modify the URI (stripping maddr/port is a separate issue that I don't want to intersperse here) when it places it into the R-URI. A separate issue (2) is whether the proxy will use the Route header or the R-URI to forward the request, when the domain (or maddr) in the request URI is not its own, as is the case for local outbound proxy. I think we are best off by starting a new thread on that topic, which I will do. -Jonathan R. > -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Friday, April 13, 2001 6:24 AM To: 'Arunachalam Venkatraman'; Sherman Gong; sip@lists.bell-labs.com Cc: 'Jonathan Rosenberg' Subject: RE: [SIP] Request-uri does not match record-route header... Hi, I believe the Record-Route test has been completely rewritten (message attached). I personally believe however Arunachalam's response should be qualified by the saying that a proxy should only use the next Route header if a. the proxy knows that it record-routed this call leg b. or the Request-URI resolves to the local proxy's address. I don't believe this is reflected in the new Record-Route text. It touches on an unresolved (or at least that was my feeling) discussion a long time about whether a Record-Routing's interaction with "Outbound Proxies". For instance, when a UA or Proxy, puts the first Route header in the Request-URI but then sends the message to an outbound proxy because the UA lacks DNS capability. The outbound proxy may not have Record-Route'd but it must not remove/process the next Route header either. At risk of reopening this discussion, did we reach at conclusion on this point, that is, when a proxy should use the next Route header and when should it not (if the Request-URI is does not resolve to the proxy's address)? Robert. <<[SIP] new record-route text!>> -----Original Message---- From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] Sent: Thursday, April 12, 2001 5:46 PM To: Sherman Gong; sip@lists.bell-labs.com Subject: RE: [SIP] Request-uri does not match record-route header... You are correct in that the REQ URI in ACK of your example should be 192.168.10.114. However, I don't know what is the value of copying the topmost route to the REQ URI . If the port of the UAS is different from that in the Route, it looks wrong! The fact is, the REQ URI is not used for routing when there is a ROUTE header in the message. I have found that the REQ URI in the ACK to a proxy I have been testing with, can be anything (so long as it parses ok) when there is a ROUTE header. The proxy uses the Route header for routing and not the REQ URI, when a ROUTE header is present. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com] On Behalf Of Sherman Gong Sent: Thursday, April 12, 2001 10:09 AM To: sip@lists.bell-labs.com Subject: [SIP] Request-uri does not match record-route header... Having a problem whereby the request-uri used in the ACK does not match that which was in the record-route header in the 200 OK. Per the SIP bis draft (section 6.39 in the 02 version), the first Route header (constructed from the record-route header) should be removed and used as the Request-URI. I included a couple of notes below asterisks (******). I have been getting conflicting arguments on which requirement this should follow. Need to determine which spec. is correct. 1) 6.29 Record-Route The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. It contains a globally reachable Request-URI that identifies the proxy server. Each proxy server adds its Request-URI to the beginning of the list. The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.) The calling user agent client copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order of requests, so that the first entry is closest to the user agent client. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry. The above describes building Route headers from the Record-Route headers, and sending subsequent requests to the first Route, removing that entry. 6.33 Route The Route request-header field determines the route taken by a request. Each host removes the first entry and then proxies the request to the host listed in that entry, also using it as the Request-URI. The operation is further described in Section 6.29. The above notes that the Route header used to proxy a request should also be used as the Request-URI. This is the part that is not being done correctly by the 5300. The 5300 is building it's own request URI based on the destination of the request, rather than using the URI in the Route header as the Request-URI. Note that the 5300 is sending the request to the correct destination, which in our case does not match that in the Route header (but they don't have to match). Or 2) from page 20 of the draft The maddr parameter indicates the server address to be contacted for this user, overriding the address supplied in the host field. This address is typically, but not necessarily, a multicast address. The maddr field can be used to force requests from traveling users to visit a home proxy even if an outbound proxy is used. c5300-3# *Jan 22 08:34:05.632: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0001 *Jan 22 08:34:05.632: Bearer Capability i = 0x8090A2 *Jan 22 08:34:05.636: Channel ID i = 0xA98381 *Jan 22 08:34:05.636: Calling Party Number i = 0x2180, '2062011001', Plan:ISDN, Type:National *Jan 22 08:34:05.636: Called Party Number i = 0xA1, '3032011001', Plan:ISDN, Type:National *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE) *Jan 22 08:34:05.652: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_call_setup *Jan 22 08:34:05.652: act_idle_call_setup:Not using Voice Class Codec *Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160 *Jan 22 08:34:05.652: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_CONNECTING) *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_IDLE, SUBSTATE_CONNECT ING) *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_connection_created *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 192.168.10.114:5060, local_p ort 50727 *Jan 22 08:34:05.656: CCSIP-SPI-CONTROL: sipSPIOutgoingCallSDP *Jan 22 08:34:05.656: sipSPIAddLocalContact *Jan 22 08:34:05.656: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE *Jan 22 08:34:05.656: CCSIP-SPI-CONTROL: sip_stats_method *Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_SENT_INVITE, SUBSTATE_ NONE) *Jan 22 08:34:05.660: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x8001 *Jan 22 08:34:05.660: Channel ID i = 0xA98381 *Jan 22 08:34:05.660: Sent: INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Date: Sat, 22 Jan 2000 01:34:05 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Cisco-Guid: 3954197371-3232041567-0-1845248076 User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x CSeq: 101 INVITE Max-Forwards: 6 Timestamp: 948530045 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 138 v=0 o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184 s=SIP Call c=IN IP4 192.168.66.184 t=0 0 m=audio 20492 RTP/AVP 0 *Jan 22 08:34:05.672: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 CSeq: 101 INVITE Content-Length: 0 *Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: act_sentinvite_new_message *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:05.672: Roundtrip delay 16 milliseconds for method INVITE *Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING, SUBS TATE_PROCEEDING_PROCEEDING) *Jan 22 08:34:05.852: Received: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Date:Sat, 22 Jan 2000 08:33:50 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Timestamp:948530045 Server:Cisco SIP Gateway (UAS)/IOS 12.x CSeq: 101 INVITE Content-Length: 0 *Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: act_recdproc_new_message *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:05.856: Roundtrip delay 200 milliseconds for method INVITE *Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would wait for 200OK to do negotiation. *Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200 OK *Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_ RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) *Jan 22 08:34:05.856: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x8001 *Jan 22 08:34:06.356: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: ;tag=6DFC2C58-820 Date:Sat, 22 Jan 2000 08:33:50 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Timestamp:948530045 Server:Cisco SIP Gateway (UAS)/IOS 12.x Contact: Record-Route: Record-Route: CSeq: 101 INVITE Content-Type:application/sdp Content-Length: 126 Session-Expires:300 v=0 o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2 s=SIP Call t=0 0 m=audio 4036 RTP/AVP 0 c=IN IP4 209.6.0.2 ************************************* Note **************************************** Note that the record route header: Record-Route: is the one that should be used for the subsequent ACK. *Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:06.356: CCSIP-SPI-CONTROL: act_recdproc_new_message *Jan 22 08:34:06.356: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:06.360: Roundtrip delay 704 milliseconds for method INVITE *Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description *Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x messages did not have SDP *Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful *Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information: Negotiated Codec : g711ulaw , bytes :160 Early Media : 0 Delayed Media : 0 Bridge Done : 0 New Media : 0 DSP DNLD Reqd : 0 Media Dest addr/Port : 209.6.0.2:4036 *Jan 22 08:34:06.360: sipSPIProcessMediaChanges *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIReconnectConnection *Jan 22 08:34:06.360: Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIProcess200OKforinvite *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIAddRouteHeaders status = TRUE Route , *Jan 22 08:34:06.360: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sip_stats_method *Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) to (STATE_AC TIVE, SUBSTATE_NONE) *Jan 22 08:34:06.360: The Call Setup Information is : Call Control Block (CCB) : 0x6221E11C State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 2062011001 Called Number : 3032011001 Negotiated Codec : g711ulaw Negotiated Codec Bytes : 160 Negotiated Dtmf-relay : 0 Source IP Address (Media): 192.168.66.184 Source IP Port (Media): 20492 Destn IP Address (Media): 209.6.0.2 Destn IP Port (Media): 4036 Destn SIP Req Addr:Port : 192.168.10.141:5060 Destn SIP Resp Addr:Port : 0.0.0.0:0 Destination Name : 192.168.10.114 *Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1 with 192.168.10.141:5060 *Jan 22 08:34:06.364: Sent: ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: ;tag=6DFC2C58-820 Date: Sat, 22 Jan 2000 01:34:05 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Route: , Max-Forwards: 6 Content-Length: 0 CSeq: 101 ACK ********************************* Note *********************************** Request-URI in above ACK has domain of 192.168.10.141, should have been 192.168.10.114 when the record-route was turned into a Route header, removed, and used as the Request-URI. *Jan 22 08:34:06.364: sipSPIRtcpUpdates No rtp session in bridge, create a new one *Jan 22 08:34:06.364: CCSIP-SPI-CONTROL: ccsip_caps_ind *Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES: ccCallID=1276, current_seq_num=0x217C *Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES: ccCallID=1276, current_seq_num=0x9EC *Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec : g711ulaw, Bytes=160 *Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE *Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw, Bytes=160 *Jan 22 08:34:06.368: CCSIP-SPI-CONTROL: ccsip_caps_ack *Jan 22 08:34:06.372: ISDN Se0:23: TX -> CONNECT pd = 8 callref = 0x8001 *Jan 22 08:34:06.372: Progress Ind i = 0x8182 - Destination address is non-ISDN *Jan 22 08:34:06.388: ISDN Se0:23: RX <- CONNECT_ACK pd = 8 callref = 0x0001 *Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id 0x227, bchan 0, dsl 0 3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001 c5300-3# Thanks SG _______________________________________________ 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. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 15:41:36 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28645 for ; Wed, 25 Apr 2001 15:41:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CD804437D; Wed, 25 Apr 2001 15:41:03 -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 29DB644365 for ; Wed, 25 Apr 2001 15:40:14 -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 PAA17621; Wed, 25 Apr 2001 15:39:20 -0400 (EDT) Message-ID: <3AE7281A.7750BF98@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: Samir Chatterjee Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] SIP voicemail server References: <3AE5F198.FA362A55@voicecore.com> Content-Type: multipart/alternative; boundary="------------BD4138D4B7196E35CC051FD3" 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: Wed, 25 Apr 2001 15:40:10 -0400 --------------BD4138D4B7196E35CC051FD3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Samir Cisco has a Unifed Messaging server which can take care of Voice mail needs also. Contact Priti Patil ( priti@cisco.com ) for Product details, if needed. thanks -manoj Samir Chatterjee wrote: > Is anyone aware of a SIP-based voicemail server? > Thanks > Samir > > -- > *************************************************************** > Dr. Samir Chatterjee > Chairman, Co-founder & CTO > VoiceCore Technologies Inc. > (Also) Associate Professor > Computer Information Systems Department > J Mack Robinson College of Business > Georgia State University > Atlanta, GA 30303. > Ph: 404-651-3886 > **************************************************************** > > _______________________________________________ > 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 --------------BD4138D4B7196E35CC051FD3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Samir

Cisco has a Unifed Messaging server which can take care of Voice
mail needs also.
Contact Priti Patil ( priti@cisco.com ) for Product details, if needed.

thanks
-manoj

Samir Chatterjee wrote:

Is anyone aware of a SIP-based voicemail server?
Thanks
Samir

--
***************************************************************
Dr. Samir Chatterjee
Chairman, Co-founder & CTO
VoiceCore Technologies Inc.
(Also) Associate Professor
Computer Information Systems Department
J Mack Robinson College of Business
Georgia State University
Atlanta, GA 30303.
Ph: 404-651-3886
****************************************************************

_______________________________________________
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
  --------------BD4138D4B7196E35CC051FD3-- _______________________________________________ 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 Wed Apr 25 15:48:13 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28794 for ; Wed, 25 Apr 2001 15:48: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 4A4E5443CE; Wed, 25 Apr 2001 15:48:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from commserver.iperia.com (unknown [63.84.167.3]) by lists.bell-labs.com (Postfix) with ESMTP id 12807443CD for ; Wed, 25 Apr 2001 15:47:26 -0400 (EDT) Received: by commserver.iperia.com with Internet Mail Service (5.5.2650.21) id <26LB1W9Y>; Wed, 25 Apr 2001 15:48:11 -0400 Message-ID: <5143F854B82ED211B05E00104B235F64807A77@commserver.iperia.com> From: Gordon Ledgard To: "'Manoj Bhatia'" , Samir Chatterjee Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP voicemail server MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDC0.A8816EB0" 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: Wed, 25 Apr 2001 15:48:10 -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_01C0CDC0.A8816EB0 Content-Type: text/plain; charset="iso-8859-1" IPeria makes one. Its does voicemail, email, pager/phone notification and Text-to-Speech translation of emails over the phone. Visit IPeria.com or call Christopher Berlutti -----Original Message----- From: Manoj Bhatia [mailto:manojb@cisco.com] Sent: Wednesday, April 25, 2001 3:40 PM To: Samir Chatterjee Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP voicemail server Samir Cisco has a Unifed Messaging server which can take care of Voice mail needs also. Contact Priti Patil ( priti@cisco.com ) for Product details, if needed. thanks -manoj Samir Chatterjee wrote: Is anyone aware of a SIP-based voicemail server? Thanks Samir -- *************************************************************** Dr. Samir Chatterjee Chairman, Co-founder & CTO VoiceCore Technologies Inc. (Also) Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 **************************************************************** _______________________________________________ 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_01C0CDC0.A8816EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IPeria=20 makes one. Its does voicemail, email, pager/phone=20 notification
and=20 Text-to-Speech translation of emails over the = phone.
 
Visit=20 IPeria.com or call Christopher Berlutti
-----Original Message-----
From: Manoj Bhatia=20 [mailto:manojb@cisco.com]
Sent: Wednesday, April 25, 2001 = 3:40=20 PM
To: Samir Chatterjee
Cc:=20 sip@lists.bell-labs.com
Subject: Re: [SIP] SIP voicemail=20 server

 
Samir=20

Cisco has a Unifed Messaging server which can take care of Voice =
mail=20 needs also.
Contact Priti Patil ( priti@cisco.com ) for Product = details,=20 if needed.=20

thanks
-manoj=20

Samir Chatterjee wrote:=20

Is anyone aware of a SIP-based voicemail = server?=20
Thanks
Samir=20

-- =
***************************************************************=20
Dr. Samir Chatterjee
Chairman, Co-founder & CTO =
VoiceCore=20 Technologies Inc.
(Also) Associate Professor
Computer = Information=20 Systems Department
J Mack Robinson College of Business =
Georgia State=20 University
Atlanta, GA 30303.
Ph: 404-651-3886=20 =
****************************************************************=20

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

-- 
Manoj =
Bhatia           =
            =
    |        =
|         |
manojb@cisco.com         &n=
bsp;           &n=
bsp; |       =
:|:       :|:
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
 =20
------_=_NextPart_001_01C0CDC0.A8816EB0-- _______________________________________________ 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 Wed Apr 25 15:51:24 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28921 for ; Wed, 25 Apr 2001 15:51: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 C8449443D4; Wed, 25 Apr 2001 15:48:10 -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 095A8443CD for ; Wed, 25 Apr 2001 15:47:28 -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 PAA17951; Wed, 25 Apr 2001 15:46:00 -0400 (EDT) Message-ID: <3AE729AA.458BCCC1@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: "Manish S. Jalan" Cc: "sip@vovida.org" , "sip@lists.bell-labs.com" , "Sip-implementors@cs.columbia.edu" Subject: Re: [SIP] Clarification on sdp usage sought References: <20010423120841.18191.qmail@mailweb1.rediffmail.com> Content-Type: multipart/alternative; boundary="------------BE70D202BB244530FED6F493" 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: Wed, 25 Apr 2001 15:46:50 -0400 --------------BE70D202BB244530FED6F493 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Manish See comments inline. thanks -manoj "Manish S. Jalan" wrote: > Hello, > > I am back to seek some more clarifications. > > Is the following sdp description ok: (the order of attribute definitions especially) > > m=audio 1234 RTP/AVP 4 0 > a=rtpmap:4 G723/8000 > a=rtpmap:0 PCMU/8000 > a=ptime:20 > a=fmtp:4 bitrate=6300 > This may not be illegal (given how loose the RFC is ) but I would think that it is not the preferred way. > > or it should be, > > m=audio 1234 RTP/AVP 4 0 > a=rtpmap:4 G723/8000 > a=fmtp:4 bitrate=6300 > a=rtpmap:0 PCMU/8000 > a=ptime:20 > This is the right definition. The ptime parameter would correspond to G.711ulaw (payload 0) . > > Is the ptime definition ok? > the ptime is media specific or format specific? > > Please help me in clarifying the concepts. > Any help is highly appreciated. > > Regards, > -Manish S. Jalan > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.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. -- 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 --------------BE70D202BB244530FED6F493 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Manish

See comments inline.

thanks
-manoj

"Manish S. Jalan" wrote:

Hello,

I am back to seek some more clarifications.

Is the following sdp description ok:  (the order of attribute definitions especially)

m=audio 1234 RTP/AVP 4 0
a=rtpmap:4 G723/8000
a=rtpmap:0 PCMU/8000
a=ptime:20
a=fmtp:4 bitrate=6300
 

This may not be illegal (given how loose the RFC is )
but I would think that it is  not the preferred way.
 
or it should be,

m=audio 1234 RTP/AVP 4 0
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6300
a=rtpmap:0 PCMU/8000
a=ptime:20
 

This is the right definition.
The ptime parameter would correspond to G.711ulaw (payload 0) .
 
Is the ptime definition ok?
the ptime is media specific or format specific?

Please help me in clarifying the concepts.
Any help is highly appreciated.

Regards,
-Manish S. Jalan

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.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.

-- 
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
  --------------BE70D202BB244530FED6F493-- _______________________________________________ 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 Wed Apr 25 15:53:58 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29004 for ; Wed, 25 Apr 2001 15:53:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F432443CE; Wed, 25 Apr 2001 15:53:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from commserver.iperia.com (unknown [63.84.167.3]) by lists.bell-labs.com (Postfix) with ESMTP id 5ECAA443BB for ; Wed, 25 Apr 2001 15:52:12 -0400 (EDT) Received: by commserver.iperia.com with Internet Mail Service (5.5.2650.21) id <26LB1W0H>; Wed, 25 Apr 2001 15:52:58 -0400 Message-ID: <5143F854B82ED211B05E00104B235F64807A78@commserver.iperia.com> From: Gordon Ledgard To: Gordon Ledgard , "'Manoj Bhatia'" , "'Samir Chatterjee'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] SIP voicemail server MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDC1.52703BA0" 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: Wed, 25 Apr 2001 15:52:56 -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_01C0CDC1.52703BA0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Gordon Ledgard Sent: Wednesday, April 25, 2001 3:48 PM To: 'Manoj Bhatia'; Samir Chatterjee Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP voicemail server [sorry - I hit the send button prematurely] IPeria makes one. Its does voicemail, email, pager/phone notification and Text-to-Speech translation of emails over the phone. Visit IPeria.com or call Christopher Berlutti at 781 993-3500 Gordon R. Ledgard Principal Software Engineer IPeria, Inc, Burlington MA. -----Original Message----- From: Manoj Bhatia [mailto:manojb@cisco.com] Sent: Wednesday, April 25, 2001 3:40 PM To: Samir Chatterjee Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP voicemail server Samir Cisco has a Unifed Messaging server which can take care of Voice mail needs also. Contact Priti Patil ( priti@cisco.com ) for Product details, if needed. thanks -manoj Samir Chatterjee wrote: Is anyone aware of a SIP-based voicemail server? Thanks Samir -- *************************************************************** Dr. Samir Chatterjee Chairman, Co-founder & CTO VoiceCore Technologies Inc. (Also) Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 **************************************************************** _______________________________________________ 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_01C0CDC1.52703BA0 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Gordon Ledgard
Sent: Wednesday, April 25, 2001 3:48 PM
To: 'Manoj Bhatia'; Samir Chatterjee
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] SIP voicemail server

[sorry - I hit the send button prematurely]
IPeria makes one. Its does voicemail, email, pager/phone notification
and Text-to-Speech translation of emails over the phone.
 
Visit IPeria.com or call Christopher Berlutti at 781 993-3500
 
Gordon R. Ledgard
Principal Software Engineer
IPeria, Inc,
Burlington MA.
 
-----Original Message-----
From: Manoj Bhatia [mailto:manojb@cisco.com]
Sent: Wednesday, April 25, 2001 3:40 PM
To: Samir Chatterjee
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP voicemail server

 
Samir

Cisco has a Unifed Messaging server which can take care of Voice
mail needs also.
Contact Priti Patil ( priti@cisco.com ) for Product details, if needed.

thanks
-manoj

Samir Chatterjee wrote:

Is anyone aware of a SIP-based voicemail server?
Thanks
Samir

--
***************************************************************
Dr. Samir Chatterjee
Chairman, Co-founder & CTO
VoiceCore Technologies Inc.
(Also) Associate Professor
Computer Information Systems Department
J Mack Robinson College of Business
Georgia State University
Atlanta, GA 30303.
Ph: 404-651-3886
****************************************************************

_______________________________________________
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_01C0CDC1.52703BA0-- _______________________________________________ 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 Wed Apr 25 16:01:59 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29340 for ; Wed, 25 Apr 2001 16:01:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CE9944379; Wed, 25 Apr 2001 16:01: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 2CC2144369 for ; Wed, 25 Apr 2001 16:00:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10242 for ; Wed, 25 Apr 2001 16:03:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 16:00:11 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDC2.55D9AA2F" Subject: [SIP] draft-ietf-sip-session-timer-04.txt Last Call 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: Wed, 25 Apr 2001 16:00:01 -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_01C0CDC2.55D9AA2F Content-Type: text/plain; charset="iso-8859-1" Please note that we are now doing a Last Call review for draft-ietf-sip-session-timer-04.txt. The schedule of the review is broken into two parts. The first cut was to have dedicated reviewers do a review and post them to the list. This begins the second part which opens up the review to everyone. The standard review time is for one week unless the debates require more time. The review is open until 1-May-01. Please post your issues to the SIP WG mailing list so that everyone can debate the issue. This also allows the authors to collect the information. Regards, Rakesh _______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue 1st Floor East Hanover, N.J. 07936 (973) 952-5066 direct (201) 214-6084 cell (973) 952-5000 main (973) 952-5050 fax rshah@dynamicsoft.com ------_=_NextPart_001_01C0CDC2.55D9AA2F Content-Type: text/html; charset="iso-8859-1"
    Please note that we are now doing a Last Call review for draft-ietf-sip-session-timer-04.txt. The schedule of the review is broken into two parts. The first cut was to have dedicated reviewers do a review and post them to the list. This begins the second part which opens up the review to everyone.
 
    The standard review time is for one week unless the debates require more time. The review is open until 1-May-01. Please post your issues to the SIP WG mailing list so that everyone can debate the issue. This also allows the authors to collect the information.
 
Regards,

Rakesh
_______________________________
Mr. Rakesh C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
1st Floor
East Hanover, N.J. 07936
(973) 952-5066 direct
(201) 214-6084 cell
(973) 952-5000 main
(973) 952-5050 fax
rshah@dynamicsoft.com
 
------_=_NextPart_001_01C0CDC2.55D9AA2F-- _______________________________________________ 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 Wed Apr 25 16:09:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29547 for ; Wed, 25 Apr 2001 16:09:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3C5644379; Wed, 25 Apr 2001 16:09: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 2F63B44369 for ; Wed, 25 Apr 2001 16:08:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10366 for ; Wed, 25 Apr 2001 16:12:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 16:08:31 -0400 Message-ID: From: Jonathan Rosenberg 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] precedence rules for Route, maddr, and R-URI hostname 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: Wed, 25 Apr 2001 16:08:29 -0400 Folks, We need to finally come to conclusion on this nagging problem of the precedence rules for the Route header, R-URI maddr, and R-URI hostname. Specifically, when a proxy receives a request, what is the processing it uses to determine how to route it? The issue is linked with a bunch of very related ones, such as how we handle local-outbound proxies for hosts that have no DNS. Like any problem, we need some requirements for this solution: 1. a proxy should not need to know that it is a local-outbound proxy for the upstream element (which can be a UA or proxy), for this to work 2. Ideally, a subsequent request in a call should follow the path of proxies which record routed. 3. the solution should work correctly in the face of spirals To proceed, I am going to make a strawman. Lets work from this, and proceed by having people point out issues or problems with this solution, rather than proposing completely new ones. Strawman -------- when a proxy receives a request, it checks for the existence of a Route header. If one exists, that Route header is popped, and placed into the request URI. It is then sent using the procedures of draft-ietf-sip-srv. If no route header is present, the proxy examines the request URI. If it contains an maddr, and this maddr is not an interface that the proxy is listening on, the proxy forwards the request using the procedures of draft-ietf-sip-srv on the request URI (this will cause it to be forwarded to the address in the maddr). If the maddr is present, but is an interface the proxy is listening on, the maddr is stripped, and processing proceeds as if it were never there. If there was no maddr, and the domain of the request URI is not a domain the proxy is managing, the procedures of draft-ietf-sip-srv are used to forward the request to that URI. If the domain is one the proxy is managing, the request is processed. Consider a UA which uses a pre-configured local outbound proxy. It sends an INVITE, and then wishes to send a request for the same call leg. If it has obtained a route set for this call leg, it SHOULD pop the top route entry, place it into the request URI, and use that to forward the request. If the proxy is not DNS capable, it MAY alternatively place the entire route set into Route headers (not popping the top URI). It sets the request URI to the same value it used for the initial INVITE, and sends it to its local outbound proxy. One more thing we would need for this to work. The URI placed into the RR header MUST be unique for each unique request URI in the incoming request, but must not equal the URI of the incoming request (adding an maddr is fine, for example. So, the current normal behavior of copying the R-URI userhost into RR, and adding your own port and maddr, meets the requirement). The important implication of this is that when a proxy record-routes through a spiral, the URI in the RR needs to be different each time through the spiral. This approach solves all of the problems that have been pointed out, I think: 1. Lets say proxy X is a local outbound proxy for some UA Y, and Y doesn't do DNS. So, when X sends a re-INVITE, it doesn't pop the top route header. This request shows up at X. Since there is a Route header, X pops it, and forwards it there. Of course, thats back to itself. However, this is a SPIRAL, since the incoming request URI is guaranteed not to be the same as the URI in the top Route. So, it looks at the request again, and if there is a Route, sends it on its way. Of course, a smart proxy could simply notice this condition and not actually send it to itself. 2. When using Route headers through a spiral, the request URI at each point in the spiral is guaranteed to be just as unique as the original request was through the set of proxies. This means that if the origina R-URI was different when received twice at the same proxy, the R-URI from Route will be different two. So, the case that Robert raised, where the requests will appear as loops, won't happen. Comments? -Jonathan R. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 16:15:00 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29791 for ; Wed, 25 Apr 2001 16:15:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D0E944379; Wed, 25 Apr 2001 16:14:04 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id A13C944353 for ; Wed, 25 Apr 2001 16:13:19 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [171.71.61.25]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3PKDLL20889; Wed, 25 Apr 2001 13:13:21 -0700 (PDT) Received: from arunvenkwin40 (dhcp-161-44-6-150.cisco.com [161.44.6.150]) by sponge.cisco.com (Mirapoint) with SMTP id ACJ01252; Wed, 25 Apr 2001 15:13:02 -0500 (CDT) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" , Subject: RE: [SIP] Request-uri does not match record-route header... 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: 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: Wed, 25 Apr 2001 15:18:15 -0500 Content-Transfer-Encoding: 7bit I am sorry I missed this but I did not know the Req_URI is used for transaction identification. As per the bis document in the definition of SIP transaction (Section 1.4), it says the transaction is identifed by the CSEQ number within a call leg and the Call Leg is defined as the combinationof Call_ID, FROM and TO headers. Please refer me to the relevant portion of the document so I can understand this better. Also, when the Req-URI is used to identify a transaction, what component of the REQ-URI are used? Since the port is modified in a Route set entry, it will not match the port of the Original Invite. Regards -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, April 25, 2001 2:21 PM To: 'Arunachalam Venkatraman'; Fairlie-Cuninghame, Robert; Sherman Gong; sip@lists.bell-labs.com Cc: Jonathan Rosenberg Subject: RE: [SIP] Request-uri does not match record-route header... -----Original Message----- >From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] >Sent: Tuesday, April 17, 2001 11:14 AM >To: Fairlie-Cuninghame, Robert; Sherman Gong; sip@lists.bell-labs.com >Cc: 'Jonathan Rosenberg' >Subject: RE: [SIP] Request-uri does not match record-route header... > > >How does the proxy know if the client is DNS capable? If the proxy know it is the default >proxy and should not Record Route, it can then simply route the call based on the maddr in >the Route. Again, the name-addr in the Req-URI is irrelevant. As always with record-routing, there are multiple issues being mixed here. The issues are: 1. does the value of the userhost portion of the request URI in ACK matter to the proxy that receives it, given a Route header is present 2. how do we handle record-routing with local outbound proxies The original question raised by Sherman is (1). The 5300 seems to have correctly computed the Route set (flipped the order of RR, add Contact at the bottom). THen, it popped the top route set element, and placed that in the R-URI, but modified the host portion. Arunachalam has argued that it doesn't matter, since the request can be routed by the proxy without the correct userhost field, as a Route header is present. This is absolutely not correct. As others have pointed out, the Request URI is used for transaction identification. A UA MUST NOT modify the URI (stripping maddr/port is a separate issue that I don't want to intersperse here) when it places it into the R-URI. A separate issue (2) is whether the proxy will use the Route header or the R-URI to forward the request, when the domain (or maddr) in the request URI is not its own, as is the case for local outbound proxy. I think we are best off by starting a new thread on that topic, which I will do. -Jonathan R. > -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Friday, April 13, 2001 6:24 AM To: 'Arunachalam Venkatraman'; Sherman Gong; sip@lists.bell-labs.com Cc: 'Jonathan Rosenberg' Subject: RE: [SIP] Request-uri does not match record-route header... Hi, I believe the Record-Route test has been completely rewritten (message attached). I personally believe however Arunachalam's response should be qualified by the saying that a proxy should only use the next Route header if a. the proxy knows that it record-routed this call leg b. or the Request-URI resolves to the local proxy's address. I don't believe this is reflected in the new Record-Route text. It touches on an unresolved (or at least that was my feeling) discussion a long time about whether a Record-Routing's interaction with "Outbound Proxies". For instance, when a UA or Proxy, puts the first Route header in the Request-URI but then sends the message to an outbound proxy because the UA lacks DNS capability. The outbound proxy may not have Record-Route'd but it must not remove/process the next Route header either. At risk of reopening this discussion, did we reach at conclusion on this point, that is, when a proxy should use the next Route header and when should it not (if the Request-URI is does not resolve to the proxy's address)? Robert. <<[SIP] new record-route text!>> -----Original Message---- From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com] Sent: Thursday, April 12, 2001 5:46 PM To: Sherman Gong; sip@lists.bell-labs.com Subject: RE: [SIP] Request-uri does not match record-route header... You are correct in that the REQ URI in ACK of your example should be 192.168.10.114. However, I don't know what is the value of copying the topmost route to the REQ URI . If the port of the UAS is different from that in the Route, it looks wrong! The fact is, the REQ URI is not used for routing when there is a ROUTE header in the message. I have found that the REQ URI in the ACK to a proxy I have been testing with, can be anything (so long as it parses ok) when there is a ROUTE header. The proxy uses the Route header for routing and not the REQ URI, when a ROUTE header is present. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com] On Behalf Of Sherman Gong Sent: Thursday, April 12, 2001 10:09 AM To: sip@lists.bell-labs.com Subject: [SIP] Request-uri does not match record-route header... Having a problem whereby the request-uri used in the ACK does not match that which was in the record-route header in the 200 OK. Per the SIP bis draft (section 6.39 in the 02 version), the first Route header (constructed from the record-route header) should be removed and used as the Request-URI. I included a couple of notes below asterisks (******). I have been getting conflicting arguments on which requirement this should follow. Need to determine which spec. is correct. 1) 6.29 Record-Route The Record-Route request and response header field is added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. It contains a globally reachable Request-URI that identifies the proxy server. Each proxy server adds its Request-URI to the beginning of the list. The server copies the Record-Route header field unchanged into the response. (Record-Route is only relevant for 2xx responses.) The calling user agent client copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order of requests, so that the first entry is closest to the user agent client. If the response contained a Contact header field, the calling user agent adds its content as the last Route header. Unless this would cause a loop, any client MUST send any subsequent requests for this call leg to the first Request-URI in the Route request header field and remove that entry. The above describes building Route headers from the Record-Route headers, and sending subsequent requests to the first Route, removing that entry. 6.33 Route The Route request-header field determines the route taken by a request. Each host removes the first entry and then proxies the request to the host listed in that entry, also using it as the Request-URI. The operation is further described in Section 6.29. The above notes that the Route header used to proxy a request should also be used as the Request-URI. This is the part that is not being done correctly by the 5300. The 5300 is building it's own request URI based on the destination of the request, rather than using the URI in the Route header as the Request-URI. Note that the 5300 is sending the request to the correct destination, which in our case does not match that in the Route header (but they don't have to match). Or 2) from page 20 of the draft The maddr parameter indicates the server address to be contacted for this user, overriding the address supplied in the host field. This address is typically, but not necessarily, a multicast address. The maddr field can be used to force requests from traveling users to visit a home proxy even if an outbound proxy is used. c5300-3# *Jan 22 08:34:05.632: ISDN Se0:23: RX <- SETUP pd = 8 callref = 0x0001 *Jan 22 08:34:05.632: Bearer Capability i = 0x8090A2 *Jan 22 08:34:05.636: Channel ID i = 0xA98381 *Jan 22 08:34:05.636: Calling Party Number i = 0x2180, '2062011001', Plan:ISDN, Type:National *Jan 22 08:34:05.636: Called Party Number i = 0xA1, '3032011001', Plan:ISDN, Type:National *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE) *Jan 22 08:34:05.652: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_call_setup *Jan 22 08:34:05.652: act_idle_call_setup:Not using Voice Class Codec *Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160 *Jan 22 08:34:05.652: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_CONNECTING) *Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_IDLE, SUBSTATE_CONNECT ING) *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_connection_created *Jan 22 08:34:05.652: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 192.168.10.114:5060, local_p ort 50727 *Jan 22 08:34:05.656: CCSIP-SPI-CONTROL: sipSPIOutgoingCallSDP *Jan 22 08:34:05.656: sipSPIAddLocalContact *Jan 22 08:34:05.656: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE *Jan 22 08:34:05.656: CCSIP-SPI-CONTROL: sip_stats_method *Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_SENT_INVITE, SUBSTATE_ NONE) *Jan 22 08:34:05.660: ISDN Se0:23: TX -> CALL_PROC pd = 8 callref = 0x8001 *Jan 22 08:34:05.660: Channel ID i = 0xA98381 *Jan 22 08:34:05.660: Sent: INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Date: Sat, 22 Jan 2000 01:34:05 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Cisco-Guid: 3954197371-3232041567-0-1845248076 User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x CSeq: 101 INVITE Max-Forwards: 6 Timestamp: 948530045 Contact: Expires: 180 Content-Type: application/sdp Content-Length: 138 v=0 o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184 s=SIP Call c=IN IP4 192.168.66.184 t=0 0 m=audio 20492 RTP/AVP 0 *Jan 22 08:34:05.672: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 CSeq: 101 INVITE Content-Length: 0 *Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: act_sentinvite_new_message *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:05.672: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:05.672: Roundtrip delay 16 milliseconds for method INVITE *Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING, SUBS TATE_PROCEEDING_PROCEEDING) *Jan 22 08:34:05.852: Received: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: Date:Sat, 22 Jan 2000 08:33:50 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Timestamp:948530045 Server:Cisco SIP Gateway (UAS)/IOS 12.x CSeq: 101 INVITE Content-Length: 0 *Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: act_recdproc_new_message *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:05.856: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:05.856: Roundtrip delay 200 milliseconds for method INVITE *Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would wait for 200OK to do negotiation. *Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200 OK *Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_ RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) *Jan 22 08:34:05.856: ISDN Se0:23: TX -> ALERTING pd = 8 callref = 0x8001 *Jan 22 08:34:06.356: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: ;tag=6DFC2C58-820 Date:Sat, 22 Jan 2000 08:33:50 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Timestamp:948530045 Server:Cisco SIP Gateway (UAS)/IOS 12.x Contact: Record-Route: Record-Route: CSeq: 101 INVITE Content-Type:application/sdp Content-Length: 126 Session-Expires:300 v=0 o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2 s=SIP Call t=0 0 m=audio 4036 RTP/AVP 0 c=IN IP4 209.6.0.2 ************************************* Note **************************************** Note that the record route header: Record-Route: is the one that should be used for the subsequent ACK. *Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.114:34050 *Jan 22 08:34:06.356: CCSIP-SPI-CONTROL: act_recdproc_new_message *Jan 22 08:34:06.356: CCSIP-SPI-CONTROL: sipSPICheckResponse *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sip_stats_status_code *Jan 22 08:34:06.360: Roundtrip delay 704 milliseconds for method INVITE *Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description *Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x messages did not have SDP *Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful *Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information: Negotiated Codec : g711ulaw , bytes :160 Early Media : 0 Delayed Media : 0 Bridge Done : 0 New Media : 0 DSP DNLD Reqd : 0 Media Dest addr/Port : 209.6.0.2:4036 *Jan 22 08:34:06.360: sipSPIProcessMediaChanges *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIReconnectConnection *Jan 22 08:34:06.360: Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIProcess200OKforinvite *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sipSPIAddRouteHeaders status = TRUE Route , *Jan 22 08:34:06.360: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE *Jan 22 08:34:06.360: CCSIP-SPI-CONTROL: sip_stats_method *Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) to (STATE_AC TIVE, SUBSTATE_NONE) *Jan 22 08:34:06.360: The Call Setup Information is : Call Control Block (CCB) : 0x6221E11C State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 2062011001 Called Number : 3032011001 Negotiated Codec : g711ulaw Negotiated Codec Bytes : 160 Negotiated Dtmf-relay : 0 Source IP Address (Media): 192.168.66.184 Source IP Port (Media): 20492 Destn IP Address (Media): 209.6.0.2 Destn IP Port (Media): 4036 Destn SIP Req Addr:Port : 192.168.10.141:5060 Destn SIP Resp Addr:Port : 0.0.0.0:0 Destination Name : 192.168.10.114 *Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1 with 192.168.10.141:5060 *Jan 22 08:34:06.364: Sent: ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.66.184:50727 From: "2062011001" To: ;tag=6DFC2C58-820 Date: Sat, 22 Jan 2000 01:34:05 GMT Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 Route: , Max-Forwards: 6 Content-Length: 0 CSeq: 101 ACK ********************************* Note *********************************** Request-URI in above ACK has domain of 192.168.10.141, should have been 192.168.10.114 when the record-route was turned into a Route header, removed, and used as the Request-URI. *Jan 22 08:34:06.364: sipSPIRtcpUpdates No rtp session in bridge, create a new one *Jan 22 08:34:06.364: CCSIP-SPI-CONTROL: ccsip_caps_ind *Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES: ccCallID=1276, current_seq_num=0x217C *Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES: ccCallID=1276, current_seq_num=0x9EC *Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec : g711ulaw, Bytes=160 *Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE *Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw, Bytes=160 *Jan 22 08:34:06.368: CCSIP-SPI-CONTROL: ccsip_caps_ack *Jan 22 08:34:06.372: ISDN Se0:23: TX -> CONNECT pd = 8 callref = 0x8001 *Jan 22 08:34:06.372: Progress Ind i = 0x8182 - Destination address is non-ISDN *Jan 22 08:34:06.388: ISDN Se0:23: RX <- CONNECT_ACK pd = 8 callref = 0x0001 *Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id 0x227, bchan 0, dsl 0 3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001 c5300-3# Thanks SG _______________________________________________ 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. --- Jonathan D. Rosenberg 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 _______________________________________________ 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 Wed Apr 25 17:15:31 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01337 for ; Wed, 25 Apr 2001 17:15:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8633E4433A; Wed, 25 Apr 2001 17:13:03 -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 09B1A44344 for ; Wed, 25 Apr 2001 17:12:15 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24677; Wed, 25 Apr 2001 17:11:12 -0400 (EDT) Received: from bgracely-pc (bgracely-isdn1.cisco.com [10.83.118.50]) by dingdong.cisco.com (Mirapoint) with ESMTP id AEK24281; Wed, 25 Apr 2001 17:12:13 -0400 (EDT) Message-Id: <4.2.0.58.20010425171019.00a89560@dingdong.cisco.com> X-Sender: bgracely@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 To: kanumuri sreeram , Jonathan Rosenberg , "'Drage, Keith (Keith)'" , "'Mayank Sharma'" , "Chen, Xin (Xin)" , "'sip@lists.bell-labs.com'" From: Brian Gracely Subject: Re: [SIP] 3gpp--controoler????? In-Reply-To: <20010425191847.3188.qmail@web14206.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_376502972==_.ALT" 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: Wed, 25 Apr 2001 17:11:52 -0400 --=====================_376502972==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed the 3pcc controller can also be thought of as a back-to-back UA.....ie. 2 UAs in the same logical entity. It terminates the signaling, but the media goes between points A & B. it will need to be call-stateful, like a UA. BG At 12:18 PM 04/25/2001 -0700, kanumuri sreeram wrote: >hi all, > >i have a douth regarding the 3pcc in sip. > >i am clear that this is possible with the help of the controller. > >like it is what which will take care of the signalling and the medai will >be transfer will be taking place among them selves "true" i.e > >A-------------CONTROLLER---------------------------B > > direct media transfer > >=================================== > > > >ok but i am not claer about this entity controller can any one make me >clear likw what is ? > >if this is a different entity it should also be showm in the architecture >of sip > >like sipua,proxy,rediect,CONTROLLER.... > >so i am clear with me douth can anu one help me > >sreeram > > > > > > > > >Do You Yahoo!? >Yahoo! Auctions - buy the things you want at >great prices --=====================_376502972==_.ALT Content-Type: text/html; charset="us-ascii" the 3pcc controller can also be thought of as a back-to-back UA.....ie. 2 UAs in the same logical entity.  It terminates the signaling, but the media goes between points A & B.  it will need to be call-stateful, like a UA.

BG



At 12:18 PM 04/25/2001 -0700, kanumuri sreeram wrote:

hi all,

i have a douth regarding the 3pcc in sip.

i am clear that this is possible with the help of the controller.

like it is what which will take care of the signalling and the medai will be transfer will be taking place among them selves "true" i.e

A-------------CONTROLLER---------------------------B

  direct media transfer

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

 

ok but i am not claer about this entity controller can any one make me clear likw what is ?

if this is a different entity it should also be showm in the architecture of sip

like sipua,proxy,rediect,CONTROLLER....

so i am clear with me douth can anu one help me

sreeram


 

 



Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
--=====================_376502972==_.ALT-- _______________________________________________ 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 Wed Apr 25 17:36:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01911 for ; Wed, 25 Apr 2001 17:36:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93A254438F; Wed, 25 Apr 2001 17:36:03 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by lists.bell-labs.com (Postfix) with ESMTP id C5AA94438B for ; Wed, 25 Apr 2001 17:35:44 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by glatton.cnchost.com id RAA04160; Wed, 25 Apr 2001 17:35:43 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <3AE7438C.7030504@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] RE: [Sip-implementors] Clarification on sdp usage sought References: Content-Type: text/html; 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: Wed, 25 Apr 2001 17:37:16 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote:
Moving this to SIP, since its a bigger issue.	

 

-----Original Message-----
From: Shan Lu [mailto:slu@nextone.com]
Sent: Tuesday, April 24, 2001 2:30 PM
Cc: Sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Clarification on sdp usage sought


However, it is JUST ADVISORY. 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Receivers need to be prepared to receive any number of 
frames per packet.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is easier said than done. Take G.729 for example. If an 
implementation supports the base frame size (10ms), then I agree that 
any number of frames per packet can be supported because a 
multi-frame  
RTP packet can always be sliced up. However, the 10ms frame 
size may not 
be suitable for some implementations (due to, say, too many 
interrupts 
from the DSP. I assume DSPs here again.) So you may have an 
implementation that can only support nx20ms, or nx30ms G.729. 
 In other 
cases, you have implementations that can support nx10 ms 
G.729 but the 
size has to be preconfigured (because, say, trade-offs have 
to be made 
here and different DSP codes have to be loaded in the DSPs.) 
We've seen 
a lot of these cases in past SIP bake-offs and H323 events.

Right. And these are causing interoperability failures. Thats why you need
to deal with this properly, and be prepared to receive any number of frame
sizes. If you want to get larger packetizations in order to reduce DSP
interrupts, then send a ptime with some larger value in the SDP. But, its
only advisory. You must be prepared to receive any number. Its what rfc1889
says. Its what the update to rfc1889 says. Its there for a reason.


One may argue that the 20ms or 30ms G.729 is really not G.729 
compliant. 
But let's be practical here. The only thing you lose by 
doubling G.729 
frame size from 10ms to 20ms is additional 10ms one-way delay, which 
obviously is not a big deal for VoIP applications.

Apparently, the problem is that we are losing interoperability.

What about non-frame based codecs -- G.711 A/u-law? I believe 
the "frame 
size" is defined (in RFC???) to be 1 ms. But I have yet to see one 
DSP-based implementation that can operate G.711 on 1ms granularity.

Realistically, no one is ever going to send that fast, and you can send
ptime as an advisory to tell them not to send that fast. If they do anyway,
hang up. But, your code must support any number of samples per packet. Thats
not just a spec requirement, its good software design. 

All in all, let me repeat what I said above:We need something 
in SDP to 
support this application -- codec specific packetization size.

No, what we need is for people to actually implement the specifications
correctly. Supporting the various nuances of all the different constraints
an implementation might introduce is a road to interoperability nightmares
and complexity. What if some implementation can do 20ms G.729 when a video
codec is running, but 10ms otherwise? Shall we support that? What if another
implementation supports 30ms G.729 when H.263 with B frames is running, in
conjunction with silence suppression, but if there is no video, and only
silence suppression, it does 20ms, and if nothing else, 10ms. Shall we
support that too?

We have taken the approach with SIP to keep it simple, and keep it general.
I think we should stick with that approach.

-Jonathan R.

                

When you design a protocol, you make some assumptions. In this case, the
assumption is that once an implementation indicates G.729 capability, then
it must support any number of base G.729 frames in a packet.  As evidenced
by past SIP and H323 interoperability events, this assumption is not true.
And we can rest assured that if one can find  implementations at these testing
events that do not have the  "any frame size" capability, there will be many
more products out there with the same problem. Now you have two options:
1. Make necessary changes in the protocol to accommodate the reality.  2.
Make no changes and ignore the problem.

                

If we choose Option #2, one can be certain that the problem or the "faulty"
implementations will not go away.  What we will end up with is that either
the deployment is comprised of only one vendor or when multiple vendors are
involved, the configurations have to be "tweaked", which is exactly how we
got around the problem at Bake-offs.  Will it work? Maybe. But surely not
very desirable.

 

While we are at it, let's also discuss other SDP issues. The one proposal
on the table allows more than more codec in the responding SDP (200OK or
ACK). This could easily lead to different codecs being used for transmit
and receive. If you take the same approach as the frame size issue, you may
assume that if an implementation advertises 3 codecs, it must be able to
transmit and receive on any combination of the codecs, which is even more 
problematic in my view.     

                

I am not saying that we need to complicate the protocol so much to accommodate
every single implementation constraint. But for common, known implementation
limitations, such as frame size and symmetric operation, we must come up
with a way to cope with.

                

Regards,

                

Shan Lu 

                

NexTone Communications

                

                

                

                

                

                

                

                

                

                

                

                

                




_______________________________________________
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  Wed Apr 25 23:44:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09432
	for ; Wed, 25 Apr 2001 23:44: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 6D0C244338; Wed, 25 Apr 2001 23:44:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 88E6144336
	for ; Wed, 25 Apr 2001 23:43:15 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id WAA19128
	for ; Wed, 25 Apr 2001 22:43:40 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 25 Apr 2001 22:43:29 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 25 Apr 2001 22:43:14 -0500
Message-ID: 
From: "Mary Barnes" 
To: Steve Donovan ,
        Jonathan Rosenberg 
Cc: Rakesh Shah ,
        "'sip@lists.bell-labs.com'" ,
        "'bcampbell@dynamicsoft.com'" 
Subject: RE: [SIP] First cut review of Session Timer draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE03.0647DAD0"
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: Wed, 25 Apr 2001 22:43:15 -0500

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_01C0CE03.0647DAD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

I also have a few first cut comments on the draft for the last-call(for
which Rakesh has just made the WG announcement). I've followed Ben's
formatting convention and also use " " to indicate exact text
references/proposals:

3:4 - In the middle of the paragraph, there is a statement: 
" To make  sure the UAC is aware it must
actually do them, the UAS MUST add a Require header to the 200 class
response, with the tag "timer", when the request contains a Require
header with tag "timer". "
--> The last clause of the sentence should be...
" when the request contains a Supported header with tag "timer". "

9:1 (Section 5) Propose that the statement "In general, proxies which ask
for session timers will record-route, since they won't receive refresheds if
they don't." be changed to something a bit stronger (i.e. a bold
RECOMMENDATION) such as: 
"It is RECOMMENDED that the proxy include the record-route header if it
wants to receive the refreshes."

12:Table 3 - (minor formatting) Propose line spacing between table entries.
It can be a bit difficult to read since the Behavior spans multiple lines.
Another suggestion would be to have the entries in the same order in which
the scenarios were discussed in the preceeding paragraphs.  


In addition I have a couple more general recommendations on the Session
Timer one of which is in line with Ben's recommendation about a strong
statement on NOT to use Session Timer for billing. 

- Per the recent thread on the use of Session Timer for Pre-paid (you can
view this as a billing variant, but I see it more as a Service or
Application requiring a general purpose timing mechanism), I would suggest
adding a statement along the lines as follows just before the NAT/firewall
control paragraph on page 2:
"The Session Timer SHOULD NOT be used for service implementations (e.g.
Billing, Pre-paid, etc.).  Session Timer is not a general purpose network
timing mechanism, but is more specific to being able to free up resources
for some pathological scenarios.  Indeed, the Session Timer could be viewed
as much more of a network "maintenance" mechanism than a general purpose
network timer primitive mechanism." 

- 2:5 In addition, I would suggest at a minimum to "soften" the endorsement
of session timer for NAT/Firewall control.  One suggestion would be
rewording the paragraph to be:
"Another possible application of the session timer may be in NAT and
firewall control."  
In line with this suggestion, I would think since the referenced draft is
still an ongoing project of the WG that it may not be prudent to include
this reference in this document going forward.  
A more radical suggestion would be to remove the NAT and firewall paragraph
altogether.  The NAT/firewall draft references Session Timer and I think
that would be sufficient (i.e the circular references are unnecessary). In
additon, my view would be that if any potential application of the Session
Timer were discussed further in this draft, it would be the use for the
recovery mechanism to accomplish soft stated SIP sessions (referenced page
2, paragraph 3),  Particularly since this is the substantiation given for
using INVITES rather than a lighter weight mechansim such as the INFO ping
(which reduces end to end messaging and simplifies the processing for the
mechanism).   

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
IMS Solutions Standards Strategy
972-684-5432

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: Tuesday, April 24, 2001 11:57 AM
To: Steve Donovan; Jonathan Rosenberg
Cc: Rakesh Shah; 'sip@lists.bell-labs.com'
Subject: [SIP] First cut review of Session Timer draft.


Here are my first cut comments on session-timer for the upcoming last-call.
Most of these are minor comments. Please forgive me if I am re-opening old
discussions, as I did not follow the original session-timer work. 

Comments referring to specific parts of the document are prefixed with
(page:paragraph)

Global - We might need language (perhaps in security considerations) that
recommends against using session-timer for billing purposes with out
additional corroboration. I can imagine a theft-of-service attack where the
UAs collude in letting the session expire, but maintain the RTP session. Any
proxy in the middle would assume the call was over. This will not work if
the timer controls a firewall, but it could if the timer was only used to
establish end-of-call for billing purposes.

Global - (nit) there are several sections where the normative language is
not clear. For example, it often says "X does Y" instead of "X MUST|MAY|etc
do Y." Most of these are in the early descriptions, so perhaps the intent is
to reserve normative language for the specific behavior descriptions later
in the draft. If that is so, then it is not consistent.

3:2-A proxy can lower but not increase the expiration time. Jonathan brought
up the issue of a DoS attack using insanely small expirations. If a proxy
cannot increase the expiration, it at least needs the option of rejecting
requests with expiration values below a threshold.

3:4 - (Typo) Sentence "They UAS MAY..." should read "The UAS MAY..."

3:4 - (Minor) I am not sure I see the value in pushing responsibility back
to a supporting UAC, if the UAC did not request the timer in the first
place. Why not just let the UAS deal with it, if the UAS is the element that
wishes to use a timer? At least it might make sense to say that the UAS must
insert the Required header IF it wishes the UAC to handle the re-invites.

4:5  What happens if the UAC does _NOT_ include a Session-Expires header on
the re-invite? I assume everyone resets their timers with the original
values? Or does timer processing cease?

5:2 - Doesn't option of absolute time imply an assumption that all elements
have their clocks reasonably synchronized?

5:3 - Again, we need to allow elements to reject expirations below a
configured threshold.

10:2 - How can a proxy know that it is the closes proxy to the UAC that
cares about the timer? Except in the trivial case where the proxy is the
closest to the UAC period, this seems problematic.

_______________________________________________
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_01C0CE03.0647DAD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] First cut review of Session Timer draft




Hi all,




I also have a few first cut comments on the draft for =
the last-call(for which Rakesh has just made the WG announcement). I've =
followed Ben's formatting convention and also use " " to =
indicate exact text references/proposals:



3:4 - In the middle of the paragraph, there is a =
statement: 

" To make  sure the UAC is aware it =
must

actually do them, the UAS MUST add a Require header =
to the 200 class

response, with the tag "timer", when the =
request contains a Require

header with tag "timer". "

--> The last clause of the sentence should =
be...

" when the request contains a Supported header =
with tag "timer". "




9:1 (Section 5) Propose that the statement "In =
general, proxies which ask for session timers will record-route, since =
they won't receive refresheds if they don't." be changed to =
something a bit stronger (i.e. a bold RECOMMENDATION) such as: =




"It is RECOMMENDED that the proxy include the =
record-route header if it wants to receive the refreshes."




12:Table 3 - (minor formatting) Propose line spacing =
between table entries.  It can be a bit difficult to read since =
the Behavior spans multiple lines.  Another suggestion would be to =
have the entries in the same order in which the scenarios were =
discussed in the preceeding paragraphs.  





In addition I have a couple more general =
recommendations on the Session Timer one of which is in line with Ben's =
recommendation about a strong statement on NOT to use Session Timer for =
billing. 



- Per the recent thread on the use of Session Timer =
for Pre-paid (you can view this as a billing variant, but I see it more =
as a Service or Application requiring a general purpose timing =
mechanism), I would suggest adding a statement along the lines as =
follows just before the NAT/firewall control paragraph on page =
2:



"The Session Timer SHOULD NOT be used for =
service implementations (e.g. Billing, Pre-paid, etc.).  Session =
Timer is not a general purpose network timing mechanism, but is more =
specific to being able to free up resources for some pathological =
scenarios.  Indeed, the Session Timer could be viewed as much more =
of a network "maintenance" mechanism than a general purpose =
network timer primitive mechanism." 



- 2:5 In addition, I would suggest at a minimum to =
"soften" the endorsement of session timer for NAT/Firewall =
control.  One suggestion would be rewording the paragraph to =
be:



"Another possible application of the session =
timer may be in NAT and firewall control."  

In line with this suggestion, I would think since =
the referenced draft is still an ongoing project of the WG that it may =
not be prudent to include this reference in this document going =
forward.  



A more radical suggestion would be to remove the NAT =
and firewall paragraph altogether.  The NAT/firewall draft =
references Session Timer and I think that would be sufficient (i.e the =
circular references are unnecessary). In additon, my view would be that =
if any potential application of the Session Timer were discussed =
further in this draft, it would be the use for the recovery mechanism =
to accomplish soft stated SIP sessions (referenced page 2, paragraph =
3),  Particularly since this is the substantiation given for using =
INVITES rather than a lighter weight mechansim such as the INFO ping =
(which reduces end to end messaging and simplifies the processing for =
the mechanism).   



Regards,

Mary H. Barnes

mbarnes@nortelnetworks.com

IMS Solutions Standards Strategy

972-684-5432




-----Original Message-----

From: Ben Campbell [mailto:bcampbell@dynamicsoft.c=
om]

Sent: Tuesday, April 24, 2001 11:57 AM

To: Steve Donovan; Jonathan Rosenberg

Cc: Rakesh Shah; 'sip@lists.bell-labs.com'

Subject: [SIP] First cut review of Session Timer =
draft.






Here are my first cut comments on session-timer for =
the upcoming last-call.

Most of these are minor comments. Please forgive me =
if I am re-opening old

discussions, as I did not follow the original =
session-timer work. 




Comments referring to specific parts of the document =
are prefixed with

(page:paragraph)




Global - We might need language (perhaps in security =
considerations) that

recommends against using session-timer for billing =
purposes with out

additional corroboration. I can imagine a =
theft-of-service attack where the

UAs collude in letting the session expire, but =
maintain the RTP session. Any

proxy in the middle would assume the call was over. =
This will not work if

the timer controls a firewall, but it could if the =
timer was only used to

establish end-of-call for billing purposes.




Global - (nit) there are several sections where the =
normative language is

not clear. For example, it often says "X does =
Y" instead of "X MUST|MAY|etc

do Y." Most of these are in the early =
descriptions, so perhaps the intent is

to reserve normative language for the specific =
behavior descriptions later

in the draft. If that is so, then it is not =
consistent.




3:2-A proxy can lower but not increase the expiration =
time. Jonathan brought

up the issue of a DoS attack using insanely small =
expirations. If a proxy

cannot increase the expiration, it at least needs =
the option of rejecting

requests with expiration values below a =
threshold.




3:4 - (Typo) Sentence "They UAS MAY..." =
should read "The UAS MAY..."




3:4 - (Minor) I am not sure I see the value in =
pushing responsibility back

to a supporting UAC, if the UAC did not request the =
timer in the first

place. Why not just let the UAS deal with it, if the =
UAS is the element that

wishes to use a timer? At least it might make sense =
to say that the UAS must

insert the Required header IF it wishes the UAC to =
handle the re-invites.




4:5  What happens if the UAC does _NOT_ include =
a Session-Expires header on

the re-invite? I assume everyone resets their timers =
with the original

values? Or does timer processing cease?




5:2 - Doesn't option of absolute time imply an =
assumption that all elements

have their clocks reasonably synchronized?




5:3 - Again, we need to allow elements to reject =
expirations below a

configured threshold.




10:2 - How can a proxy know that it is the closes =
proxy to the UAC that

cares about the timer? Except in the trivial case =
where the proxy is the

closest to the UAC period, this seems =
problematic.




_______________________________________________

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_01C0CE03.0647DAD0--

_______________________________________________
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 Apr 26 02:56:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24906
	for ; Thu, 26 Apr 2001 02:56:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C951244338; Thu, 26 Apr 2001 02:56:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id B1F0444336
	for ; Thu, 26 Apr 2001 02:55:34 -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 f3Q6tXO09331;
	Thu, 26 Apr 2001 08:55:33 +0200 (MEST)
Received: from lmf.ericsson.se (lmf21339pc.lmf.ericsson.se [131.160.30.161])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3Q6tWJ24623;
	Thu, 26 Apr 2001 09:55:32 +0300 (EET DST)
Message-ID: <3AE7C65F.E2142663@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "'Sean Olson (EUS)'" ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References: 
Content-Type: multipart/mixed;
 boundary="------------B67DAC0FF76997EF404C87CF"
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, 26 Apr 2001 09:55:27 +0300

This is a multi-part message in MIME format.
--------------B67DAC0FF76997EF404C87CF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>>Actually, I would rather remove the reference to cancelling a
>>>request with
>>>BYE. Thats legacy from the old days when, in fact, sending a
>>>BYE meant you
>>>didn't need to respond to the original INVITE.
>>>
>>Do you mean to remove the option of sending a BYE prior
>>to the conclusion of the INVITE transaction signalling that
>>the INVITE transaction should be "cancelled"? Or do you mean
>>simply the idea that a BYE sent in this case means that the
>>INVITE does not need to be responded to (with a 487)?
> 
>The idea that BYE in this case means that the INVITE doesn't need
>to be responded to.

I don't know if this is related to the issue, but just to clarify:

What if we get a Contact/Record-Route in a provisional response to the
INVITE, which means the BYE could be sent another route (using other
proxies) than the INVITE. If there is no response to the INVITE, how
will be intermediate proxies handling the INVITE know that there will be
no response?

Regards,

Christer Holmberg
Ericsson Finland




> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       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
> 
> _______________________________________________
> 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.
--------------B67DAC0FF76997EF404C87CF
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

--------------B67DAC0FF76997EF404C87CF--


_______________________________________________
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 Apr 26 03:44:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25601
	for ; Thu, 26 Apr 2001 03:44:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4892D44349; Thu, 26 Apr 2001 03:44:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from rwcxch02.clarent.com (unknown [208.205.112.130])
	by lists.bell-labs.com (Postfix) with ESMTP id 9D26844336
	for ; Thu, 26 Apr 2001 03:43:55 -0400 (EDT)
Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21)
	id <2HCDYPGH>; Thu, 26 Apr 2001 00:40:40 -0700
Received: from rwcjfmule01 (adsl-64-169-17-212.dsl.snfc21.pacbell.net [64.169.17.212]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 2HCDYPGG; Thu, 26 Apr 2001 00:40:36 -0700
From: Jean-Francois Mule 
Reply-To: Jean-Francois Mule 
To: "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
Subject: [SIP] draft-mahy-sip-message-waiting-01.txt
Message-ID: <018c01c0ce24$5b4cd3c0$e54b010a@rwcjfmule01>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <4.2.0.58.20010322102030.01b03820@lint.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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, 26 Apr 2001 00:41:49 -0700
Content-Transfer-Encoding: 7bit

Hi,
The I-D mentions audible/visual message waiting indications in the
introduction but then remains silent on this.
Has there been any considerations to include the type of mwi
(audible/visual) as optional in application/simple-message-summary?
Jean-Francois Mule.
Clarent

_______________________________________________
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 Apr 26 07:07:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27581
	for ; Thu, 26 Apr 2001 07:07:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B760944363; Thu, 26 Apr 2001 07:07:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by lists.bell-labs.com (Postfix) with ESMTP id DA8B644362
	for ; Thu, 26 Apr 2001 07:06:35 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Thu, 26 Apr 2001 12:03:15 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-31) id MAA09795; Thu, 26 Apr 2001 12:06:33 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A3A.003CEB90 ; Thu, 26 Apr 2001 12:05:24 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" 
To: alan.johnston@wcom.cpm
Cc: sip@lists.bell-labs.com
Message-ID: <80256A3A.003CDA69.00@marconicomms.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Cseq with call stateful proxies
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, 26 Apr 2001 12:04:27 +0100



In section 3.1.2 of the SIP Call Flows document, the BYE that is originated by
the
called party has a CSEQ of 1; the note states that this is not 2 because each UA
maintains its own CSEQ count. However, if the intermediate proxy is call
stateful, then
it is going to receive a subsequent message (BYE in this case) with an old CSEQ
number on this
call leg, albeit in the opposite direction to the previous CSEQ with value 1.
The RFC states
that CSEQ must increment monotonically within a call leg, it does not state
anything about
the direction of the message within that call leg. I think there is some
conflict here that requires
clarification.

Regards,

K. Robinson



_______________________________________________
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 Apr 26 07:29:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28598
	for ; Thu, 26 Apr 2001 07:29:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 06D7E44373; Thu, 26 Apr 2001 07:29:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 724D64436E
	for ; Thu, 26 Apr 2001 07:28:16 -0400 (EDT)
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 f3QBTXa26388;
	Thu, 26 Apr 2001 16:59:33 +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 f3QBbVB29422;
	Thu, 26 Apr 2001 17:07:36 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256A3A.003EE4D5 ; Thu, 26 Apr 2001 16:56:58 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Keith Robinson" 
Cc: sip@lists.bell-labs.com
Message-ID: <65256A3A.003EE353.00@sampark.hss.hns.com>
Subject: Re: [SIP] Cseq with call stateful proxies
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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, 26 Apr 2001 16:56:54 +0530




CSeq spacing is independant in the two directions of the call leg. Not sure
if this is explicity written in the draft,
but its there in the SIP FAQ.

http://www.cs.columbia.edu/~hgs/sip/faq/cache/23.html (last para)

regds
arjun
--
Arjun Roychowdhury @ Hughes Software Systems





"Keith Robinson"  on 04/26/2001 04:34:27 PM

To:   alan.johnston@wcom.cpm
cc:   sip@lists.bell-labs.com

Subject:  [SIP] Cseq with call stateful proxies






In section 3.1.2 of the SIP Call Flows document, the BYE that is originated
by
the
called party has a CSEQ of 1; the note states that this is not 2 because
each UA
maintains its own CSEQ count. However, if the intermediate proxy is call
stateful, then
it is going to receive a subsequent message (BYE in this case) with an old
CSEQ
number on this
call leg, albeit in the opposite direction to the previous CSEQ with value
1.
The RFC states
that CSEQ must increment monotonically within a call leg, it does not state
anything about
the direction of the message within that call leg. I think there is some
conflict here that requires
clarification.

Regards,

K. Robinson



_______________________________________________
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 Apr 26 08:05:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29739
	for ; Thu, 26 Apr 2001 08:05:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E9384436D; Thu, 26 Apr 2001 08:05:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from commserver.iperia.com (unknown [63.84.167.3])
	by lists.bell-labs.com (Postfix) with ESMTP id D2E8144362
	for ; Thu, 26 Apr 2001 08:04:35 -0400 (EDT)
Received: by commserver.iperia.com with Internet Mail Service (5.5.2650.21)
	id <26LB1XPV>; Thu, 26 Apr 2001 08:05:26 -0400
Message-ID: <5143F854B82ED211B05E00104B235F649E22F6@commserver.iperia.com>
From: Steve Gardell 
To: "'Fairlie-Cuninghame, Robert'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CE49.2D8AA770"
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, 26 Apr 2001 08:05:25 -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_01C0CE49.2D8AA770
Content-Type: text/plain;
	charset="iso-8859-1"

The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!
 
At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF
recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of
these
3 variants is most cost effective might well be service-provider dependent.
 
I agree that control over "full or local" mixing is important to support a 
calling card service.

 
 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Wednesday, April 25, 2001 9:18 AM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] Join as replacement for DTMF/voice-forking.




If at first you don't succeed ..... 

Hi, 

I still didn't receive any comment back on using Join as a replacement to
beleaguered SDP based DTMF-forking. I am not sure if this is because 

a.	people don't see the problems with the existing DTMF forking scheme
(that has not been standardized anywhere), or 

b.	people see problems with using join to provide this service in a
highly flexible and generic manner that is easy to implement, extend and
handles cases where there are multiple media streams , or 

c.	people don't understand what I am proposing. 


What is the status of the Join: header work ? Who is handling it? 

This approach in my mind seems so much cleaner (and in the spirit of SIP)
than the current SDP based-approach. 

The concept is simple. A second is INVITE is sent from the joiner to the
joinee (where the joinee already has an established SIP session). Rather
than a Replaces header, the INVITE has a Join header. Other than that it is
almost identical to the current Replaces process. The only addition required
is perhaps a header parameter that specifies whether the Join is for full or
only local media mixing at the Joinee. In local mixing only the media from
the joinee is sent to the joiner and the joiner's media is only mixed with
the joinee rather than full conference-bridge style mixing. A possible
extension may also allow the joiner to be NOTIFIED when it is the last
INVITE present in the session.

This is of course compatible with the REFER draft which even further extends
what can be achieved with this simple addition. 

The SDP handling is easy as the Joiner can simply put no SDP in the INVITE,
the Joinee will then return the current session SDP in the 200OK. It is then
a simple matter for the joiner  to select what media streams are to be
"forked" in the ACK. No complicated "SDP" guessing games and SDP
manipulation by proxies (as for current forked-DTMF suggestions). It simply
supports multiple media streams and the addition or deletion of media
streams.

Additionally, it is easy to determine if a UA supports the Join header and
an application server can alternatively Require it in the initial INVITE.
Lastly, a join fails it does not jeopardize the existing sessions (as it
would in the existing forked DTMF proposal). This is especially important if
there are more than one application servers that are requesting to be
Join'ed.

I'd like to hear other peoples thoughts on this approach to problem that
really needs to be solve properly. At the last bakeoff there were many
companies wanting to use/deploy these important features. Where there is a
need without a specification then people often go off and implement their
own solutions (such as forking media streams through heuristical
interpretation of adding new SDP media streams).

Regards, 

Robert. 



------_=_NextPart_001_01C0CE49.2D8AA770
Content-Type: text/html;
	charset="iso-8859-1"




Join as replacement for DTMF/voice-forking.






The additional 
discussion really helps for those of us who don't


have 
the several hours a day it takes to really keep up on the SIP list!


 


At any rate, one concern - probably 
with both models - is that we can't


make the assumption that all gateways are willing to 
"invest" in the


additional DSP to support mixing or, 
for that matter, mid-call DTMF 
recognition.


In that case one could imagine 
implementing a B2BUA (with associated 


media processing) that can do this 
"in 
the network" with join as suggested 


or simply implementing the service in 
it's 
entirety at a B2BUA. Which of 
these


3 
variants is most cost effective might well be service-provider 
dependent.


 


I 
agree that control over "full or local" mixing is important to support a 



calling card 
service.


 


 -----Original Message-----
From: Fairlie-Cuninghame, Robert 
[mailto:rfairlie@nuera.com]
Sent: Wednesday, April 25, 2001 9:18 
AM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] Join as 
replacement for DTMF/voice-forking.





  
If at first you don't succeed ..... 

  
Hi, 

  
I still didn't receive any comment back on using 
  Join as a replacement to beleaguered SDP based DTMF-forking. I am not sure if 
  this is because 

  
    
    
  1. people don't see the problems with the existing 
    DTMF forking scheme (that has not been standardized anywhere), or 
    
  2. people see problems with using join to provide 
    this service in a highly flexible and generic manner that is easy to 
    implement, extend and handles cases where there are multiple media streams 
    <grin>, or 
    
  3. people don't understand what I am 
    proposing. 

  
What is the status of the Join: header work ? Who 
  is handling it? 

  
This approach in my mind seems so much cleaner (and 
  in the spirit of SIP) than the current SDP based-approach. 

  
The concept is simple. A second is INVITE is sent 
  from the joiner to the joinee (where the joinee already has an established SIP 
  session). Rather than a Replaces header, the INVITE has a Join header. Other 
  than that it is almost identical to the current Replaces process. The only 
  addition required is perhaps a header parameter that specifies whether the 
  Join is for full or only local media mixing at the Joinee. In local mixing 
  only the media from the joinee is sent to the joiner and the joiner's media is 
  only mixed with the joinee rather than full conference-bridge style mixing. A 
  possible extension may also allow the joiner to be NOTIFIED when it is the 
  last INVITE present in the session.

  
This is of course compatible with the REFER draft 
  which even further extends what can be achieved with this simple addition. 
  

  
The SDP handling is easy as the Joiner can simply 
  put no SDP in the INVITE, the Joinee will then return the current session SDP 
  in the 200OK. It is then a simple matter for the joiner  to select what 
  media streams are to be "forked" in the ACK. No complicated "SDP" guessing 
  games and SDP manipulation by proxies (as for current forked-DTMF 
  suggestions). It simply supports multiple media streams and the addition or 
  deletion of media streams.

  
Additionally, it is easy to determine if a UA 
  supports the Join header and an application server can alternatively Require 
  it in the initial INVITE. Lastly, a join fails it does not jeopardize the 
  existing sessions (as it would in the existing forked DTMF proposal). This is 
  especially important if there are more than one application servers that are 
  requesting to be Join'ed.

  
I'd like to hear other peoples thoughts on this 
  approach to problem that really needs to be solve properly. 
  At the last bakeoff there were many companies wanting to use/deploy these 
  important features. Where there is a need without a specification then people 
  often go off and implement their own solutions (such as forking media streams 
  through heuristical interpretation of adding new SDP media 
streams).

  
Regards, 

  
Robert. 



------_=_NextPart_001_01C0CE49.2D8AA770--

_______________________________________________
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 Apr 26 10:17:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04809
	for ; Thu, 26 Apr 2001 10:17: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 0B14C44362; Thu, 26 Apr 2001 10:17:04 -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 5BB5944346
	for ; Thu, 26 Apr 2001 10:16:22 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 26 10:12:58 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 956B444380; Thu, 26 Apr 2001 10:02:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id 47DB64437D
	for ; Thu, 26 Apr 2001 10:02:08 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA16917; Thu, 26 Apr 2001 09:02:04 -0500
Cc: "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA16866; Thu, 26 Apr 2001 09:02:00 -0500
Message-ID: <3AE82A55.35FB3E7A@lucent.com>
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 
Original-CC: "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
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: Thu, 26 Apr 2001 09:01:57 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> > Back to the subject of the associated text string value, I note the
> > following text in 6.21 would imply that "cancelled" and
> > "cancellation" can
> > be done by BYE, so we may want to change the words there as well.
> >
> >         Strictly speaking, CSeq header fields are needed for any
> >         SIP request that can be cancelled by a BYE or CANCEL
> >         request or where a client can issue several requests for
> >         the same Call-ID in close succession. Without a sequence
> >         number, the response to an INVITE could be mistaken for the
> >         response to the cancellation (BYE or CANCEL).
> 
> Actually, I would rather remove the reference to cancelling a request with
> BYE. Thats legacy from the old days when, in fact, sending a BYE meant you
> didn't need to respond to the original INVITE.

Please do.  This is a perennial source of confusion at the bakeoffs.  I have
observed implementations cancelling a request with BYE and while it is
clear that they should be using CANCEL instead, one cannot authoritatively
cite a section in the RFC for this behavior.  

As far as I can see, the only reason to send BYE in relation to a CANCEL is 
if the CANCEL from the UAC and a 200 OK (INVITE) from the UAS crossed each 
other on the wire. 

- 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

_______________________________________________
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 Apr 26 10:22:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04992
	for ; Thu, 26 Apr 2001 10:22:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6B8A444395; Thu, 26 Apr 2001 10:22:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17])
	by lists.bell-labs.com (Postfix) with ESMTP id B399F44394
	for ; Thu, 26 Apr 2001 10:21:35 -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 f3R0XoR18807;
	Thu, 26 Apr 2001 19:33:50 -0500 (GMT)
Received: from hrishikesh (unknown [10.10.10.96])
	by email.eximsoft.com (Postfix) with SMTP
	id 26B2E690EF; Thu, 26 Apr 2001 19:51:45 +0530 (IST)
Message-ID: <014901c0ce5b$b8967db0$600a0a0a@exim.com>
Reply-To: "Hrishikesh Saria" 
From: "Hrishikesh Saria" 
To: 
Cc: 
Subject: Fw: [Sip] Register
Organization: Eximsoft
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0146_01C0CE89.D23AE390"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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, 26 Apr 2001 19:48:09 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0146_01C0CE89.D23AE390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



How do you stop the retransmission of the 200OK response for the =
register message.

Also what needs to be done if you get a response out of sequence or an =
ACK when you have'nt got an invite

Reagrds
Hrishikesh Saria

------=_NextPart_000_0146_01C0CE89.D23AE390
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









 


 


How do you stop the retransmission of =
the 200OK=20
response for the register message.


 


Also what needs to be done if you get a =
response=20
out of sequence or an ACK when you have'nt got an invite


 


Reagrds


Hrishikesh =
Saria


------=_NextPart_000_0146_01C0CE89.D23AE390--


_______________________________________________
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 Apr 26 10:30:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05402
	for ; Thu, 26 Apr 2001 10:30:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 460D8443A0; Thu, 26 Apr 2001 10:30:04 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id B281244394
	for ; Thu, 26 Apr 2001 10:29:57 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Apr 26 10:28:46 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id CFB1844380; Thu, 26 Apr 2001 10:15:30 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id 881434437D
	for ; Thu, 26 Apr 2001 10:15:30 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA22144; Thu, 26 Apr 2001 09:15:26 -0500
Cc: "'Drage, Keith (Keith)'" ,
        "'Mayank Sharma'" ,
        "Chen, Xin (Xin)" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA22088; Thu, 26 Apr 2001 09:15:16 -0500
Message-ID: <3AE82D71.734B1B5@lucent.com>
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 
Original-CC: "'Drage, Keith (Keith)'" ,
        "'Mayank Sharma'" ,
        "Chen, Xin (Xin)" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] A question about Cancel request
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: Thu, 26 Apr 2001 09:15:13 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> I agree that it is worthwhile discussing the usage of CANCEL in a proxy in
> more detail. Unless anyone objects, I will add some text (for -04) that 
> says that a proxy SHOULD NOT send a CANCEL for a timed-out request for 
> which it has not received any provisional response. The proxy is supposed 
> to have gotten a 100 if the final response can't be answered within 500ms. 
> So, the absence of a provisional response after 32s implies that there is 
> either a malfunctioning, or non-existent server at the receiving end of 
> the request. In either case, sending CANCEL is useless.

Sounds good to me.  I always thought it was pointless sending a CANCEL to
the same destination that has not responded to re-transmitted INVITEs.

BTW, you mention -04 bis, what happened to -03?  As far as I know, -02 is
the latest on the SIP web site at Columbia...

Thanks,

- 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

_______________________________________________
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 Apr 26 10:40:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05843
	for ; Thu, 26 Apr 2001 10:40: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 78402443AB; Thu, 26 Apr 2001 10:40:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (unknown [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id AE6FF44394
	for ; Thu, 26 Apr 2001 10:39:36 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBC5L2>; Thu, 26 Apr 2001 07:38:10 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Steve Gardell'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CE5E.83E2F230"
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, 26 Apr 2001 07:38:10 -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_01C0CE5E.83E2F230
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Steve,
 
Thanks for your comment.
 
Pretty much everything can be done as a B2BUA and I agree with you: until
UA's with REFER &  Replaces capability are widely deployed, then B2BUA is
pretty much the only way to accomplish many of the "advanced call control"
features in an hetrogenous/non-controlled SIP network (IMO). However,
unfortuately a B2BUA does not help in the scenario described in this thread.

 
A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The
Application (or some related RTP processing/splitting/forwarding entity)
could process the media for every call for the entire duration of the call
[for common usage scenario]. However, I don't beleive this is generally a
scalable solution. I don't think you are denying that the features being
discussed are not very important to people wishing to provide calling-card
style services (non-disruptive in-call warnigns and announcements, media
triggered events such as triple # for call follow-on/return, etc).
 
For "Join" to work, one of the endpoints must support the Join header - just
like REFER you cannot guarantee every UA will implement this. This is the
same for the existing SDP-based stream forking behavior. I don't see that
this is a problem specific to this suggestion but rather a general problem
for adding extensions - not everyone is going to implement every extension.
This is not a reason to stop publishing extensions (which I'm sure you are
not debating). 
 
However, that does bring up a good advantage to this Join approach. IMO, it
is seems much easier for many PSTN-gateway based calling card services to
control the features supported by just _one_ of the UA's involved in a call
(usually the gateway). However, it may not always be the caller, for
instance, in a "PC to Phone" application where the client is located on a
"plain-vanilla" SIP client on the internet. In this case it might be usefull
to allow the Join header to be sent to the callee (the gateway) and specify
that the Join is only towards the remote party. (So the Join header options
become "local", "remote", or "full" mixing). This facility is not possible
with the current SDP-based stream forking approach.
 
To me this seems such a flexible, easy and clean way of achieving this
functionality.
 
Robert.

-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!
 
At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF
recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of
these
3 variants is most cost effective might well be service-provider dependent.
 
I agree that control over "full or local" mixing is important to support a 
calling card service.

 



------_=_NextPart_001_01C0CE5E.83E2F230
Content-Type: text/html;
	charset="iso-8859-1"







Join as replacement for DTMF/voice-forking.




Hi 
Steve,


 


Thanks 
for your comment.


 


Pretty 
much everything can be done as a B2BUA and I agree with you: until UA's with 
REFER &  Replaces capability are widely deployed, then B2BUA is pretty 
much the only way to accomplish many of the "advanced call control" 
features in an hetrogenous/non-controlled SIP network (IMO). However, 
unfortuately a B2BUA does not help in the scenario described in this thread. 



 


A 
B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The 
Application (or some related RTP processing/splitting/forwarding entity) could 
process the media for every call for the entire duration of 
the call [for common usage scenario]. However, I don't beleive this is generally 
a scalable solution. I don't think you are denying that the 
features being discussed are not very important to people wishing to provide 
calling-card style services (non-disruptive in-call warnigns and announcements, 
media triggered events such as triple # for call follow-on/return, 
etc).


 


For 
"Join" to work, one of the endpoints must support the Join header - 
just like REFER you cannot guarantee every UA will implement this. This is the 
same for the existing SDP-based stream forking behavior. I don't see that this 
is a problem specific to this suggestion but rather a general problem for adding 
extensions - not everyone is going to implement every extension. This is not a 
reason to stop publishing extensions (which I'm sure you are not debating). 



 


However, that does bring up a good advantage to this Join approach. IMO, 
it is seems much easier for many PSTN-gateway based calling card services to 
control the features supported by just _one_ of the UA's involved in a call 
(usually the gateway). However, it may not always be the caller, for instance, 
in a "PC to Phone" application where the client is located on a 
"plain-vanilla" SIP client on the internet. In this case it might be 
usefull to allow the Join header to be sent to the callee (the gateway) and 
specify that the Join is only towards the remote party. (So the Join header 
options become "local", "remote", or "full" 
mixing). This facility is not possible with the current SDP-based stream forking 
approach.


 


To me 
this seems such a flexible, easy and clean way of achieving this 
functionality.


 


Robert.



    
-----Original Message-----
From: Steve Gardell 
    [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 
    PM
To: 'Fairlie-Cuninghame, Robert'; 
    'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement 
    for DTMF/voice-forking.


    

    
The additional 
    discussion really helps for those of us who 
    don't

    
have the several hours a 
    day it takes to really keep up on the SIP list!

    
 

    
At any rate, one concern - 
    probably with both models - is that we 
    can't

    
make the assumption that all 
    gateways are willing to "invest" in 
    the

    
additional DSP to support mixing 
    or, for that matter, mid-call DTMF 
    recognition.

    
In that case one could imagine 
    implementing a B2BUA (with associated 
    

    
media processing) that can do this 
    "in the network" with join as 
    suggested 

    
or simply implementing the service 
    in it's entirety at 
    a B2BUA. Which of 
    these

    
3 
    variants is most cost effective might well be service-provider 
    dependent.

    
 

    
I agree that control over 
    "full or local" mixing is important to support a 
    

    
calling card 
    service.

    

    
 

    



------_=_NextPart_001_01C0CE5E.83E2F230--

_______________________________________________
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 Apr 26 10:43:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06043
	for ; Thu, 26 Apr 2001 10:43:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 40E56443B5; Thu, 26 Apr 2001 10:43:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157])
	by lists.bell-labs.com (Postfix) with ESMTP id 690BC44344
	for ; Wed, 25 Apr 2001 16:33:47 -0400 (EDT)
Received: from SGONG-W2K1.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA27529; Wed, 25 Apr 2001 13:33:40 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010425143242.016478d0@localhost>
X-Sender: sgong@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jonathan Rosenberg 
From: Sherman Gong 
Subject: RE: [SIP] Request-uri does not match record-route header...
Cc: "'Arunachalam Venkatraman'" ,
        "Fairlie-Cuninghame, Robert" ,
        sip@lists.bell-labs.com, Jonathan Rosenberg 
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: Wed, 25 Apr 2001 14:33:24 -0600

We have made a correction in our IOS code and calls are now 
processing.  Thanks for all of your advices.


At 03:20 PM 4/25/2001 -0400, Jonathan Rosenberg wrote:


>
>-----Original Message-----
> >From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
> >Sent: Tuesday, April 17, 2001 11:14 AM
> >To: Fairlie-Cuninghame, Robert; Sherman Gong; sip@lists.bell-labs.com
> >Cc: 'Jonathan Rosenberg'
> >Subject: RE: [SIP] Request-uri does not match record-route header...
> >
> >
> >How does the proxy know if the client is DNS capable? If the proxy know it
>is the default
> >proxy and should not Record Route, it can then simply route the call based
>on the maddr in
> >the Route. Again, the name-addr in the Req-URI is irrelevant.
>
>As always with record-routing, there are multiple issues being mixed here.
>
>The issues are:
>
>1. does the value of the userhost portion of the request URI in ACK matter
>to the proxy that receives it, given a Route header is present
>2. how do we handle record-routing with local outbound proxies
>
>The original question raised by Sherman is (1). The 5300 seems to have
>correctly computed the Route set (flipped the order of RR, add Contact at
>the bottom). THen, it popped the top route set element, and placed that in
>the R-URI, but modified the host portion. Arunachalam has argued that it
>doesn't matter, since the request can be routed by the proxy without the
>correct userhost field, as a Route header is present.
>
>This is absolutely not correct.
>
>As others have pointed out, the Request URI is used for transaction
>identification. A UA MUST NOT modify the URI (stripping maddr/port is a
>separate issue that I don't want to intersperse here) when it places it into
>the R-URI.
>
>A separate issue (2) is whether the proxy will use the Route header or the
>R-URI to forward the request, when the domain (or maddr) in the request URI
>is not its own, as is the case for local outbound proxy. I think we are best
>off by starting a new thread on that topic, which I will do.
>
>-Jonathan R.
>
> >
>-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
>Sent: Friday, April 13, 2001 6:24 AM
>To: 'Arunachalam Venkatraman'; Sherman Gong; sip@lists.bell-labs.com
>Cc: 'Jonathan Rosenberg'
>Subject: RE: [SIP] Request-uri does not match record-route header...
>
>Hi,
>I believe the Record-Route test has been completely rewritten (message
>attached). I personally believe however Arunachalam's response should be
>qualified by the saying that a proxy should only use the next Route header
>if
>a.       the proxy knows that it record-routed this call leg
>b.      or the Request-URI resolves to the local proxy's address.
>
>I don't believe this is reflected in the new Record-Route text. It touches
>on an unresolved (or at least that was my feeling) discussion a long time
>about whether a Record-Routing's interaction with "Outbound Proxies".
>For instance, when a UA or Proxy, puts the first Route header in the
>Request-URI but then sends the message to an outbound proxy because the UA
>lacks DNS capability. The outbound proxy may not have Record-Route'd but it
>must not remove/process the next Route header either.
>At risk of reopening this discussion, did we reach at conclusion on this
>point, that is, when a proxy should use the next Route header and when
>should it not (if the Request-URI is does not resolve to the proxy's
>address)?
>Robert.
><<[SIP] new record-route text!>>
>-----Original Message----
>From:   Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
>Sent:   Thursday, April 12, 2001 5:46 PM
>To:     Sherman Gong; sip@lists.bell-labs.com
>Subject:        RE: [SIP] Request-uri does not match record-route header...
>You are correct in that  the REQ URI in ACK of your example should be
>192.168.10.114.
>However, I don't know what is the value of copying the topmost route to the
>REQ URI .
>If the port of the UAS is different from that in the Route, it looks wrong!
>The fact is, the REQ URI is not used for routing when there is a ROUTE
>header in the message.
>I have found that the REQ URI in the ACK to a proxy I have been testing
>with, can be anything (so long as it parses ok) when there is a ROUTE
>header. The proxy uses the Route header for routing and not the REQ URI,
>when a ROUTE header is present.
>
>  -----Original Message-----
>From:   sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]
>
>On Behalf Of Sherman Gong
>Sent:   Thursday, April 12, 2001 10:09 AM
>To:     sip@lists.bell-labs.com
>Subject:        [SIP] Request-uri does not match record-route header...
>Having a problem whereby the request-uri used in the ACK does not match
>that which was in the record-route header in the 200 OK.  Per the SIP bis
>draft (section 6.39 in the 02 version), the first Route header (constructed
>from the record-route header) should be removed and used as the
>Request-URI.  I included a couple of notes below asterisks (******).
>I have been getting conflicting arguments on which requirement this should
>follow.  Need to determine which spec. is correct.
>1)  6.29 Record-Route
>      The Record-Route request and response header field is added to a
>      request by any proxy that insists on being in the path of subsequent
>      requests for the same call leg. It contains a globally reachable
>      Request-URI that identifies the proxy server. Each proxy server adds
>      its Request-URI to the beginning of the list.
>       The server copies the Record-Route header field unchanged into the
>       response. (Record-Route is only relevant for 2xx responses.)
>       The calling user agent client copies the Record-Route header into a
>       Route header field of subsequent requests within the same call leg,
>       reversing the order of requests, so that the first entry is closest
>       to the user agent client. If the response contained a Contact header
>       field, the calling user agent adds its content as the last Route
>       header. Unless this would cause a loop, any client MUST send any
>       subsequent requests for this call leg to the first Request-URI in the
>       Route request header field and remove that entry.
>
>     The above describes building Route headers from the Record-Route
>headers,
>     and sending subsequent requests to the first Route, removing that entry.
>
>
>   6.33 Route
>       The Route request-header field determines the route taken by a
>       request. Each host removes the first entry and then proxies the
>       request to the host listed in that entry, also using it as the
>       Request-URI. The operation is further described in Section 6.29.
>     The above notes that the Route header used to proxy a request should
>also
>      be used as the Request-URI.  This is the part that is not being done
>      correctly by the 5300.  The 5300 is building it's own request URI based
>
>on
>      the destination of the request, rather than using the URI in the Route
>     header as the Request-URI.  Note that the 5300 is sending the request
>to the
>     correct destination, which in our case does not match that in the Route
>     header (but they don't have to match).
>
>Or
>
>2)  from page 20 of the draft
>      The maddr parameter indicates the server address to be contacted for
>this user, overriding the address supplied in the host field. This
>      address is typically, but not necessarily, a multicast address. The
>maddr field can be used to force requests from traveling users to visit
>      a home proxy even if an outbound proxy is used.
>
>
>
>c5300-3#
>*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
>*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
>*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
>*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
>
>Plan:ISDN, Type:National
>*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
>Plan:ISDN, Type:National
>*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
>SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
>*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
>*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
>*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec
>*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
>:g711ulaw bytes: 160
>*Jan 22 08:34:05.652:  Queued event from SIP SPI :
>SIPSPI_EV_CREATE_CONNECTION
>*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
>SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
>*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
>SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
>ING)
>*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
>*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
>Connid(1) created to 192.168.10.114:5060, local_p
>ort 50727
>*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
>*Jan 22 08:34:05.656: sipSPIAddLocalContact
>*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
>*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
>*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
>SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
>NONE)
>*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
>
>*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
>*Jan 22 08:34:05.660: Sent:
>INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
>Via: SIP/2.0/UDP  192.168.66.184:50727
>From: "2062011001" 
>To: 
>Date: Sat, 22 Jan 2000 01:34:05 GMT
>Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
>Cisco-Guid: 3954197371-3232041567-0-1845248076
>User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
>CSeq: 101 INVITE
>Max-Forwards: 6
>Timestamp: 948530045
>Contact: 
>Expires: 180
>Content-Type: application/sdp
>Content-Length: 138
>v=0
>o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
>s=SIP Call
>c=IN IP4 192.168.66.184
>t=0 0
>m=audio 20492 RTP/AVP 0
>*Jan 22 08:34:05.672: Received:
>SIP/2.0 100 Trying
>Via: SIP/2.0/UDP  192.168.66.184:50727
>From: "2062011001" 
>To: 
>Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
>CSeq: 101 INVITE
>Content-Length: 0
>
>*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
>IPaddr: 192.168.1.114:34050
>*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
>*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
>*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
>*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE
>*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
>SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
>TATE_PROCEEDING_PROCEEDING)
>*Jan 22 08:34:05.852: Received:
>SIP/2.0 180 Ringing
>Via: SIP/2.0/UDP 192.168.66.184:50727
>From: "2062011001" 
>To: 
>Date:Sat, 22 Jan 2000 08:33:50 GMT
>Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
>Timestamp:948530045
>Server:Cisco SIP Gateway (UAS)/IOS 12.x
>CSeq: 101 INVITE
>Content-Length: 0
>
>*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
>IPaddr: 192.168.1.114:34050
>*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
>*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
>*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
>*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE
>*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
>
>wait for 200OK to do negotiation.
>*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
>OK
>*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
>
>SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
>RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
>*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
>*Jan 22 08:34:06.356: Received:
>SIP/2.0 200 OK
>Via: SIP/2.0/UDP 192.168.66.184:50727
>From: "2062011001" 
>To: ;tag=6DFC2C58-820
>Date:Sat, 22 Jan 2000 08:33:50 GMT
>Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
>Timestamp:948530045
>Server:Cisco SIP Gateway (UAS)/IOS 12.x
>Contact:
>Record-Route:
>port=udp>
>Record-Route:
>.141;transport=udp>
>CSeq: 101 INVITE
>Content-Type:application/sdp
>Content-Length: 126
>Session-Expires:300
>v=0
>o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
>s=SIP Call
>t=0 0
>m=audio 4036 RTP/AVP 0
>c=IN IP4 209.6.0.2
>
>************************************* Note
>****************************************
>Note that the record route header:
>Record-Route:
>.141;transport=udp>
>   is the one that should be used for the subsequent ACK.
>
>
>
>*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
>IPaddr: 192.168.1.114:34050
>*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
>*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
>*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
>*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE
>*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
>*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
>
>messages did not have SDP
>*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful
>
>*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
>Negotiated Codec      : g711ulaw , bytes :160
>Early Media           : 0
>Delayed Media         : 0
>Bridge Done           : 0
>New Media             : 0
>DSP DNLD Reqd         : 0
>Media Dest addr/Port  : 209.6.0.2:4036
>*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
>*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
>*Jan 22 08:34:06.360:  Queued event from SIP SPI :
>SIPSPI_EV_RECONNECT_CONNECTION
>*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
>*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
>TRUE Route ;maddr=192.168.10.141>, 
>*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
>*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
>*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
>
>SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
>TIVE, SUBSTATE_NONE)
>*Jan 22 08:34:06.360: The Call Setup Information is :
>   Call Control Block (CCB) : 0x6221E11C
>   State of The Call        : STATE_ACTIVE
>   TCP Sockets Used         : NO
>   Calling Number           : 2062011001
>   Called Number            : 3032011001
>   Negotiated Codec         : g711ulaw
>   Negotiated Codec Bytes   : 160
>   Negotiated Dtmf-relay    : 0
>   Source IP Address (Media): 192.168.66.184
>   Source IP Port    (Media): 20492
>   Destn  IP Address (Media): 209.6.0.2
>   Destn  IP Port    (Media): 4036
>   Destn SIP Req Addr:Port  : 192.168.10.141:5060
>   Destn SIP Resp Addr:Port : 0.0.0.0:0
>   Destination Name         : 192.168.10.114
>*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
>with 192.168.10.141:5060
>*Jan 22 08:34:06.364: Sent:
>ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
>Via: SIP/2.0/UDP  192.168.66.184:50727
>From: "2062011001" 
>To: ;tag=6DFC2C58-820
>Date: Sat, 22 Jan 2000 01:34:05 GMT
>Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
>Route: ,
>
>Max-Forwards: 6
>Content-Length: 0
>CSeq: 101 ACK
>
>********************************* Note ***********************************
>Request-URI in above ACK has domain of 192.168.10.141, should have been
>192.168.10.114 when the record-route was turned into a Route header,
>removed, and used as the Request-URI.
>
>
>
>*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
>new one
>*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
>*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
>ccCallID=1276, current_seq_num=0x217C
>*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
>ccCallID=1276, current_seq_num=0x9EC
>*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
>g711ulaw, Bytes=160
>*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
>CC_CAP_DTMF_RELAY_INBAND_VOICE
>*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
>Bytes=160
>*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
>*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
>*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
>is non-ISDN
>*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
>0x0001
>*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
>0x227, bchan 0, dsl 0
>3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
>c5300-3#
>
>Thanks
>SG
>
>_______________________________________________
>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.
>
>---
>Jonathan D. Rosenberg                       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

Thanks,

Sherman Gong  (SE)
720-875-1307  (Office)
303-886-8328  (Cell)





_______________________________________________
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 Apr 26 10:46:15 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06204
	for ; Thu, 26 Apr 2001 10:46:15 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7A0F7443BB; Thu, 26 Apr 2001 10:43:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb2.rediffmail.com (unknown [202.54.124.147])
	by lists.bell-labs.com (Postfix) with SMTP id B7EFE44353
	for ; Thu, 26 Apr 2001 03:14:20 -0400 (EDT)
Received: (qmail 8313 invoked by uid 510); 26 Apr 2001 07:18:30 -0000
Message-ID: <20010426071830.8311.qmail@mailweb2.rediffmail.com>
Received: from unknown (203.197.74.150) by rediffmail.com via HTTP; 26 Apr 2001 07:18:30 -0000
MIME-Version: 1.0
To: "sip@vovida.org" ,
        "sip@lists.bell-labs.com" ,
        "Sip-implementors@cs.columbia.edu" 
From: "Manish S. Jalan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] ERROR in OpInviteUrl.cxx
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: 26 Apr 2001 07:18:30 -0000
Content-Transfer-Encoding: 7bit

The following two lines are a cause for error when we run the ua in debug mode.
You have marked them for deletion, but not removed them.


    //TODO delete this debugging line
    cpLog( LOG_DEBUG, "Request url %s", digitCollector->getUrl().c_str() );


This line, while the ua runs in debug mode causes problems as it drops one digit of the destination's ip's last three digits.


Regards,
-Manish S. Jalan

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.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@lists.bell-labs.com  Thu Apr 26 10:49:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06312
	for ; Thu, 26 Apr 2001 10:49:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7FD9E443C3; Thu, 26 Apr 2001 10:43:17 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb26.rediffmail.com (unknown [203.199.83.30])
	by lists.bell-labs.com (Postfix) with SMTP id 0A5D444353
	for ; Thu, 26 Apr 2001 03:16:31 -0400 (EDT)
Received: (qmail 10636 invoked by uid 510); 26 Apr 2001 07:20:51 -0000
Message-ID: <20010426072051.10635.qmail@mailweb26.rediffmail.com>
Received: from unknown (203.197.74.150) by rediffmail.com via HTTP; 26 Apr 2001 07:20:51 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" ,
        "Sip-implementors@cs.columbia.edu" 
Subject:  Re: [Sip] ERROR in OpInviteUrl.cxx
From: "Manish S. Jalan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
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: 26 Apr 2001 07:20:51 -0000
Content-Transfer-Encoding: 7bit

Please ignore my earlier mail!
Sorry for the cross posting.
-Manish

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.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@lists.bell-labs.com  Thu Apr 26 10:55:21 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06593
	for ; Thu, 26 Apr 2001 10:55: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 108E2443D8; Thu, 26 Apr 2001 10:47:05 -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 E0326443BA
	for ; Thu, 26 Apr 2001 10:46:21 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 26 10:43:09 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id CC43044380; Thu, 26 Apr 2001 10:32:19 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id DB33D4437D
	for ; Thu, 26 Apr 2001 10:32:02 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA25143; Thu, 26 Apr 2001 09:31:55 -0500
Cc: Jonathan Rosenberg ,
        "'Sean Olson (EUS)'" ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA25038; Thu, 26 Apr 2001 09:31:20 -0500
Message-ID: <3AE83135.A268BCE6@lucent.com>
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: Christer Holmberg 
Original-CC: Jonathan Rosenberg ,
        "'Sean Olson (EUS)'" ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se>
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: Thu, 26 Apr 2001 09:31:17 -0500
Content-Transfer-Encoding: 7bit

Christer Holmberg wrote:
> 
> Hi,
> 
> >>>Actually, I would rather remove the reference to cancelling a
> >>>request with
> >>>BYE. Thats legacy from the old days when, in fact, sending a
> >>>BYE meant you
> >>>didn't need to respond to the original INVITE.
> >>>
> >>Do you mean to remove the option of sending a BYE prior
> >>to the conclusion of the INVITE transaction signalling that
> >>the INVITE transaction should be "cancelled"? Or do you mean
> >>simply the idea that a BYE sent in this case means that the
> >>INVITE does not need to be responded to (with a 487)?
> >
> >The idea that BYE in this case means that the INVITE doesn't need
> >to be responded to.
> 
> I don't know if this is related to the issue, but just to clarify:
> 
> What if we get a Contact/Record-Route in a provisional response to the
> INVITE, which means the BYE could be sent another route (using other
> proxies) than the INVITE. If there is no response to the INVITE, how
> will be intermediate proxies handling the INVITE know that there will be
> no response?

A Route list is only created from Contact/R-R headers at the UAC end when
it gets a final response (2xx, some 4xx ones).  It is not created on a
provisional response.

As far as intermediate proxies are concerned, the UAC will presumably send
a CANCEL when it hangs up (before receiving a final response); the CANCEL
should get propagated and acted upon by intermediate stateful proxies.

Oh, that brings up an interesting point:   If a stateful proxy
forked and one of the branches reached a stateless downstream server, when
the statful proxy gets a CANCEL, it will propogate the CANCEL to the state-
less downstream proxy.  What do statless proxies do on getting a CANCEL?  
Since they do not have state associated with the INVITE they received 
earlier, how do they handle the CANCEL?  Am I missing something obvious?

- 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

_______________________________________________
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 Apr 26 11:00:01 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06808
	for ; Thu, 26 Apr 2001 11:00:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81948443E3; Thu, 26 Apr 2001 10:52:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 9E210443E9
	for ; Thu, 26 Apr 2001 10:48:33 -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 f3QEmWN25194;
	Thu, 26 Apr 2001 16:48:32 +0200 (MEST)
Received: from lmf.ericsson.se (lmf21339pc.lmf.ericsson.se [131.160.30.161])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3QEmVJ22676;
	Thu, 26 Apr 2001 17:48:32 +0300 (EET DST)
Message-ID: <3AE83539.A90C9EC1@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vijay Gurbani 
Cc: Jonathan Rosenberg ,
        "'Sean Olson (EUS)'" ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se> <3AE83135.A268BCE6@lucent.com>
Content-Type: multipart/mixed;
 boundary="------------0241DE8F3F6BEB65D4C5A239"
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, 26 Apr 2001 17:48:25 +0300

This is a multi-part message in MIME format.
--------------0241DE8F3F6BEB65D4C5A239
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Hi,
>>
>>>>>Actually, I would rather remove the reference to cancelling a
>>>>>request with
>>>>>BYE. Thats legacy from the old days when, in fact, sending a
>>>>>BYE meant you
>>>>>didn't need to respond to the original INVITE.
>>>>>
>>>>Do you mean to remove the option of sending a BYE prior
>>>>to the conclusion of the INVITE transaction signalling that
>>>>the INVITE transaction should be "cancelled"? Or do you mean
>>>>simply the idea that a BYE sent in this case means that the
>>>>INVITE does not need to be responded to (with a 487)?
>>>
>>>The idea that BYE in this case means that the INVITE doesn't need
>>>to be responded to.
>>
>>I don't know if this is related to the issue, but just to clarify:
>>
>>What if we get a Contact/Record-Route in a provisional response to the
>>INVITE, which means the BYE could be sent another route (using other
>>proxies) than the INVITE. If there is no response to the INVITE, how
>>will be intermediate proxies handling the INVITE know that there will be
>>no response?
> 
>A Route list is only created from Contact/R-R headers at the UAC end when
>it gets a final response (2xx, some 4xx ones).  It is not created on a
>provisional response.

I hate to bring it up again, but this is something we discussed in the
overlap dialing and send-INFO-before-the-final-response-has arrived
threads. Especially for PSTN GWs, I think we agreed that the UAS GW can
send a provisional response, WITH a Contact/R-R, when the initial INVITE
is received, if the UAC needs to send INFO (or another INVITE with
additional digits, if overlap dialing is used) BEFORE it has received
the final response.
 
>As far as intermediate proxies are concerned, the UAC will presumably send
>a CANCEL when it hangs up (before receiving a final response); the CANCEL
>should get propagated and acted upon by intermediate stateful proxies.

Yes, but we are (at least at the moment) also allowed to send BYE
instead of CANCEL.

I don't see any reason why we can't use BYE instead of CANCEL, if we
want to terminate the call setup before the final response is received.
If people then use BYE to cancel other transactions, eg a re-INVITE
during a call (but they don't want to terminate the call) I think it's a
bug in their implementation. 

My personal view is that if I try to call someone, and put on the hook,
I should be able to send BYE no matter if I have received a 200 (or
another final response) or not.

Regards,

Christer Holmberg
Ericsson Finland


 
> Oh, that brings up an interesting point:   If a stateful proxy
> forked and one of the branches reached a stateless downstream server, when
> the statful proxy gets a CANCEL, it will propogate the CANCEL to the state-
> less downstream proxy.  What do statless proxies do on getting a CANCEL?
> Since they do not have state associated with the INVITE they received
> earlier, how do they handle the CANCEL?  Am I missing something obvious?
> 
> - 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
--------------0241DE8F3F6BEB65D4C5A239
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

--------------0241DE8F3F6BEB65D4C5A239--


_______________________________________________
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 Apr 26 11:45:58 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08991
	for ; Thu, 26 Apr 2001 11:45:57 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D2800443DF; Thu, 26 Apr 2001 11:45:04 -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 88F06443DF
	for ; Thu, 26 Apr 2001 11:44:23 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 26 11:40:45 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id EA07C44380; Thu, 26 Apr 2001 11:29:55 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id A4E0C4437D
	for ; Thu, 26 Apr 2001 11:29:55 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA09740; Thu, 26 Apr 2001 10:29:50 -0500
Cc: "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA09730; Thu, 26 Apr 2001 10:29:49 -0500
Message-ID: <3AE83EEA.A3A39CBB@lucent.com>
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: Christer Holmberg 
Original-CC: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se> <3AE83135.A268BCE6@lucent.com> <3AE83539.A90C9EC1@lmf.ericsson.se>
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: Thu, 26 Apr 2001 10:29:46 -0500
Content-Transfer-Encoding: 7bit

[Trimmed the CC list]

Christer Holmberg wrote:
[...]
> >A Route list is only created from Contact/R-R headers at the UAC end when
> >it gets a final response (2xx, some 4xx ones).  It is not created on a
> >provisional response.
> 
> I hate to bring it up again, but this is something we discussed in the
> overlap dialing and send-INFO-before-the-final-response-has arrived
> threads. 

OK; my apologies.  I did not keep up with that thread.  But regardless,
the core RFC's behavior is to create a Route list on a 2xx response.

> >As far as intermediate proxies are concerned, the UAC will presumably 
> >send a CANCEL when it hangs up (before receiving a final response); the 
> >CANCEL should get propagated and acted upon by intermediate stateful 
> >proxies.
> 
> Yes, but we are (at least at the moment) also allowed to send BYE
> instead of CANCEL.

And Jonathan's proposal was to do away with this behavior.  To the extent
that it makes the protocol simpler and less ambiguous, I think it is worth
working through this scenario only.

> I don't see any reason why we can't use BYE instead of CANCEL, if we
> want to terminate the call setup before the final response is received.
> If people then use BYE to cancel other transactions, eg a re-INVITE
> during a call (but they don't want to terminate the call) I think it's a
> bug in their implementation.

Incidentally, the fact that you would use a CANCEL to cancel a re-INVITE
(and not a BYE since it will tear the session down) begs for the same 
behavior for cancelling a pending (first) INVITE.  We should try to keep
the behavior as orthogonal as possible for first INVITEs and re-INVITEs.
 
> My personal view is that if I try to call someone, and put on the hook,
> I should be able to send BYE no matter if I have received a 200 (or
> another final response) or not.

I don't see why you as a user cares if a BYE or a CANCEL is sent when you
hang up.  You as an implementor of the stack *know* that a final response 
has not yet arrived to the INVITE, so why can't you just send a CANCEL and 
not a BYE?

- 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

_______________________________________________
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 Apr 26 12:08:59 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10089
	for ; Thu, 26 Apr 2001 12:08:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AA257443A7; Thu, 26 Apr 2001 12:03:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 9FF3844380
	for ; Thu, 26 Apr 2001 12:02:28 -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 f3QG2SO14764;
	Thu, 26 Apr 2001 18:02:28 +0200 (MEST)
Received: from lmf.ericsson.se (lmf21339pc.lmf.ericsson.se [131.160.30.161])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3QG2RJ25727;
	Thu, 26 Apr 2001 19:02:27 +0300 (EET DST)
Message-ID: <3AE8468C.D92D8B78@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vijay Gurbani 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se> <3AE83135.A268BCE6@lucent.com> <3AE83539.A90C9EC1@lmf.ericsson.se> <3AE83EEA.A3A39CBB@lucent.com>
Content-Type: multipart/mixed;
 boundary="------------934B5E8F86ABAD1F1C4EE19E"
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, 26 Apr 2001 19:02:20 +0300

This is a multi-part message in MIME format.
--------------934B5E8F86ABAD1F1C4EE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

> [Trimmed the CC list]
> 
> Christer Holmberg wrote:
> [...]
>>>A Route list is only created from Contact/R-R headers at the UAC end when
>>>it gets a final response (2xx, some 4xx ones).  It is not created on a
>>>provisional response.
>>
>>I hate to bring it up again, but this is something we discussed in the
>>overlap dialing and send-INFO-before-the-final-response-has arrived
>>threads.
> 
>OK; my apologies.  I did not keep up with that thread.  But regardless,
>the core RFC's behavior is to create a Route list on a 2xx response.

I know, and I think that that should be changed. I think it should be a
MUST to include it in a 2xx response, but that you MAY include it also
in the 18x provisonal responses (if one wants to support the features
related to overlap dialing, "early" INFOs, etc).
 
>>>As far as intermediate proxies are concerned, the UAC will presumably
>>>send a CANCEL when it hangs up (before receiving a final response); the
>>>CANCEL should get propagated and acted upon by intermediate stateful
>>>proxies.
>>
>>Yes, but we are (at least at the moment) also allowed to send BYE
>>instead of CANCEL.
>
>And Jonathan's proposal was to do away with this behavior.  To the extent
>that it makes the protocol simpler and less ambiguous, I think it is worth
>working through this scenario only. 
>>I don't see any reason why we can't use BYE instead of CANCEL, if we
>>want to terminate the call setup before the final response is received.
>>If people then use BYE to cancel other transactions, eg a re-INVITE
>>during a call (but they don't want to terminate the call) I think it's a
>>bug in their implementation.
> 
>Incidentally, the fact that you would use a CANCEL to cancel a re-INVITE
>(and not a BYE since it will tear the session down) begs for the same
>behavior for cancelling a pending (first) INVITE.  We should try to keep
>the behavior as orthogonal as possible for first INVITEs and re-INVITEs.

Well, that depends on from what point of view you look at it. Yes, if we
are talking about cancelling INVITEs and re-INVITEs, which both happen
to be the same SIP method, why not use the same method (CANCEL) to
cancel them? However, if we are talking about terminating a call, why
not use the same method (BYE) regarless of if we have received a final
response or not?

>>My personal view is that if I try to call someone, and put on the hook,
>>I should be able to send BYE no matter if I have received a 200 (or
>>another final response) or not.
> 
>I don't see why you as a user cares if a BYE or a CANCEL is sent when you
>hang up.  You as an implementor of the stack *know* that a final response
>has not yet arrived to the INVITE, so why can't you just send a CANCEL and
>not a BYE?

Of course I can, but I don't see why you as a user cares if a BYE or a
CANCEL is received when I want to hang up :)

Also, from a standardization point of view: first BYE was not allowed,
then it was allowed, and now we want to make it not allowed again... How
long is it then going to take before we want to allow it again? If there
are no really standard related problems by using BYE instead of CANCEL,
I think people using BYEs in a wrong way (ie by trying to cancel a
re-INVITE) should fix their implementations instead...

Regards,

Christer Holmberg
Ericsson Finland

> 
> - 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
--------------934B5E8F86ABAD1F1C4EE19E
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

--------------934B5E8F86ABAD1F1C4EE19E--


_______________________________________________
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 Apr 26 12:30:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11127
	for ; Thu, 26 Apr 2001 12:30:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 65F0C44363; Thu, 26 Apr 2001 12:30:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id A015C44344
	for ; Thu, 26 Apr 2001 12:29:01 -0400 (EDT)
Received: from gecko by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Apr 2001 16:29:01 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA02122; Thu, 26 Apr 2001 17:28:58 +0100 (BST)
Message-ID: <3AE84CD4.2A58E6A1@ubiquity.net>
From: James Undery 
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP List 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Registration Authentication
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, 26 Apr 2001 17:29:08 +0100
Content-Transfer-Encoding: 7bit

Hi,

Now the second version of the sip-register draft is out, it may be a
good time to bring up an issue I don't think was resolved last time. In

 http://lists.bell-labs.com/pipermail/sip/2000q4/003116.html

it was mentioned REGISTER is totally unprotected from by digest
authentication, i.e. auth-int does nothing to prevent someone from
replaying a successful registration with a different Contact header(s).
As PGP has been depreciated (and justifiably so) we are left without any
method, however weak, of authenticating REGISTER requests.

I am inclined to suggest deprecating REGISTER, however, I won't and
suggest instead we allow (or recommend) the contact headers are repeated
in the REGISTER message body.

James Undery


_______________________________________________
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 Apr 26 12:37:11 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11415
	for ; Thu, 26 Apr 2001 12:37:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CC1D2443BB; Thu, 26 Apr 2001 12:32:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id DC5FE443A8
	for ; Thu, 26 Apr 2001 12:31:28 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 26 Apr 2001 09:29:54 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id ; Thu, 26 Apr 2001 09:29:54 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD1160C0@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" 
To: "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 16F6928897400-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
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: Thu, 26 Apr 2001 09:29:53 -0700
Content-Transfer-Encoding: 7bit

I would think that the functionality of SIP ends when it delivers the
requested Notification. What the phone/the entity does with it(light a lamp,
render the same on a display, provide stutter dial tone or audible
notification et al) is more a matter of the local policy (depending upon the
capabilities of the end point).

Venkatesh

-----Original Message-----
From: Jean-Francois Mule [mailto:jfmule@clarent.com]
Sent: Thursday, April 26, 2001 12:42 AM
To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: [SIP] draft-mahy-sip-message-waiting-01.txt


Hi,
The I-D mentions audible/visual message waiting indications in the
introduction but then remains silent on this.
Has there been any considerations to include the type of mwi
(audible/visual) as optional in application/simple-message-summary?
Jean-Francois Mule.
Clarent

_______________________________________________
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 Apr 26 12:51:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12048
	for ; Thu, 26 Apr 2001 12:51:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E69CF44349; Thu, 26 Apr 2001 12:51: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 8588F44344
	for ; Thu, 26 Apr 2001 12:50:22 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Apr 26 12:47:24 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 2F26E44380; Thu, 26 Apr 2001 12:36:35 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id DFA684437D
	for ; Thu, 26 Apr 2001 12:36:34 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id LAA24749; Thu, 26 Apr 2001 11:36:29 -0500
Cc: "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id LAA24742; Thu, 26 Apr 2001 11:36:28 -0500
Message-ID: <3AE84E8A.B7802F61@lucent.com>
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: Christer Holmberg 
Original-CC: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se> <3AE83135.A268BCE6@lucent.com> <3AE83539.A90C9EC1@lmf.ericsson.se> <3AE83EEA.A3A39CBB@lucent.com> <3AE8468C.D92D8B78@lmf.ericsson.se>
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: Thu, 26 Apr 2001 11:36:26 -0500
Content-Transfer-Encoding: 7bit

Christer Holmberg wrote:
[...]
> Of course I can, but I don't see why you as a user cares if a BYE or a
> CANCEL is received when I want to hang up :)

I as a user (callee) don't, but I as a UAS stack implementor do.

To me, BYE has the semantics of "tear this session down"; sending a BYE to
a pending INVITE (in which case no session has been established yet*), does 
not make too much sense within the context of the sematics I outlined above.

* you may argue that early media, overlap signaling, etc. implies some sort 
  of a session, but a final 2xx response is what actually signifies the 
  acceptance of a session.  A compromise could be that if you support 
  100rel, then you can send a BYE to terminate early media streams, 
  otherwise use CANCEL (ugh! ugly)

> Also, from a standardization point of view: first BYE was not allowed,
> then it was allowed, and now we want to make it not allowed again... How
> long is it then going to take before we want to allow it again? 

I thought the genealogy was that "BYE was allowed in RFC 2543 to
terminate a pending INVITE, but current thinking is that it should not be".
I do not remember it being "not allowed, then it was allowed, and now we 
want to make it not allowed again."

> If there are no really standard related problems by using BYE instead of 
> CANCEL, I think people using BYEs in a wrong way (ie by trying to cancel a
> re-INVITE) should fix their implementations instead...

This is an issue that the SIP WG must come to a consensus on and reflect the
final behavior (as non-ambiguously as possible) in the bis (and ensuing
RFC).  

Best 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

_______________________________________________
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 Apr 26 13:04:37 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12590
	for ; Thu, 26 Apr 2001 13:04:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE404443AB; Thu, 26 Apr 2001 13:01:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 15F3C44394
	for ; Thu, 26 Apr 2001 13:00:51 -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 f3QH0oO02458;
	Thu, 26 Apr 2001 19:00:50 +0200 (MEST)
Received: from lmf.ericsson.se (lmf21339pc.lmf.ericsson.se [131.160.30.161])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3QH0oJ27751;
	Thu, 26 Apr 2001 20:00:50 +0300 (EET DST)
Message-ID: <3AE8543B.94947412@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vijay Gurbani 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References:  <3AE7C65F.E2142663@lmf.ericsson.se> <3AE83135.A268BCE6@lucent.com> <3AE83539.A90C9EC1@lmf.ericsson.se> <3AE83EEA.A3A39CBB@lucent.com> <3AE8468C.D92D8B78@lmf.ericsson.se> <3AE84E8A.B7802F61@lucent.com>
Content-Type: multipart/mixed;
 boundary="------------71CF7046BD88BA0C1CAADBF8"
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, 26 Apr 2001 20:00:43 +0300

This is a multi-part message in MIME format.
--------------71CF7046BD88BA0C1CAADBF8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Of course I can, but I don't see why you as a user cares if a BYE or a
>>CANCEL is received when I want to hang up :)
> 
>I as a user (callee) don't, but I as a UAS stack implementor do.
> 
>To me, BYE has the semantics of "tear this session down"; sending a BYE to
>a pending INVITE (in which case no session has been established yet*), does
>not make too much sense within the context of the sematics I outlined above.

I guess this is a matter on how we define a session, if "tear this
session down" is also 
valid for a session still not completely setup. For example, one could
argue that it is
partly setup from the UAC point of view, if he is ready to receive media
once he has
sent the INVITE... Anyway, I don't want to go in to those kind of
discussions - let's try
to solve this from a technical point of view instead :)
 
>* you may argue that early media, overlap signaling, etc. implies some sort
>  of a session, but a final 2xx response is what actually signifies the
>  acceptance of a session.  A compromise could be that if you support
>  100rel, then you can send a BYE to terminate early media streams,
>  otherwise use CANCEL (ugh! ugly)

Maybe not... :)

BTW, 100rel is also another example why one could want to insert
Contact/R-R in the provisional 
response, for the PRACKs.
 
>>Also, from a standardization point of view: first BYE was not allowed,
>>then it was allowed, and now we want to make it not allowed again... How
>>long is it then going to take before we want to allow it again?
> 
>I thought the genealogy was that "BYE was allowed in RFC 2543 to
>terminate a pending INVITE, but current thinking is that it should not be".
>I do not remember it being "not allowed, then it was allowed, and now we
>want to make it not allowed again."

I guess I put my words wrong. I meant the way we want to handle the BYE,
ie if a
final response should be sent for the INVITE if a BYE is received, etc.
First that
was the case, then it was decided to handle it like a BYE, and now we
want to forbid it.
 
>>If there are no really standard related problems by using BYE instead of
>>CANCEL, I think people using BYEs in a wrong way (ie by trying to cancel a
>>re-INVITE) should fix their implementations instead...
> 
>This is an issue that the SIP WG must come to a consensus on and reflect the
>final behavior (as non-ambiguously as possible) in the bis (and ensuing
>RFC).

I agree. Also, I think this is a relatively small issue, so we should
not spend that much time (why is everybody thinking of the overlap
dialing discussion?) on it.


Regards,

Christer Holmberg
Ericsson Finland


> 
> Best 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
--------------71CF7046BD88BA0C1CAADBF8
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

--------------71CF7046BD88BA0C1CAADBF8--


_______________________________________________
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 Apr 26 13:10:37 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12744
	for ; Thu, 26 Apr 2001 13:10:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 459D1443E5; Thu, 26 Apr 2001 13:07:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 56CF0443A7
	for ; Thu, 26 Apr 2001 13:06:42 -0400 (EDT)
Received: from mr6.exu.ericsson.se. (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3QH6i813016
	for ; Thu, 26 Apr 2001 12:06:44 -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 f3QH6fw22135
	for ; Thu, 26 Apr 2001 12:06:41 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Apr 26 12:06:40 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Thu, 26 Apr 2001 12:06:40 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Vijay Gurbani'" ,
        "Christer Holmberg (LMF)" 
Cc: Jonathan Rosenberg ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CE73.41C5D920"
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, 26 Apr 2001 12:06:38 -0500

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_01C0CE73.41C5D920
Content-Type: text/plain;
	charset="iso-8859-1"


>Oh, that brings up an interesting point:   If a stateful proxy
>forked and one of the branches reached a stateless downstream 
>server, when
>the statful proxy gets a CANCEL, it will propogate the CANCEL 
>to the state-
>less downstream proxy.  What do statless proxies do on getting 
>a CANCEL?  
>Since they do not have state associated with the INVITE they received 
>earlier, how do they handle the CANCEL?  Am I missing 
>something obvious?

Is there any reason why the stateless proxy would do something
other than forward the CANCEL request? I don't understand
what the alternative might be.

>
>- 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

/sean
--
Sean Olson 
Ericsson Inc.

------_=_NextPart_001_01C0CE73.41C5D920
Content-Type: text/html;
	charset="iso-8859-1"






RE: [SIP] Further editorial nit in the bis draft






>Oh, that brings up an interesting point:   If a stateful proxy

>forked and one of the branches reached a stateless downstream 

>server, when

>the statful proxy gets a CANCEL, it will propogate the CANCEL 

>to the state-

>less downstream proxy.  What do statless proxies do on getting 

>a CANCEL?  

>Since they do not have state associated with the INVITE they received 

>earlier, how do they handle the CANCEL?  Am I missing 

>something obvious?




Is there any reason why the stateless proxy would do something

other than forward the CANCEL request? I don't understand

what the alternative might be.




>

>- 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




/sean

--

Sean Olson <sean.olson@ericsson.com>

Ericsson Inc.





------_=_NextPart_001_01C0CE73.41C5D920--

_______________________________________________
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 Apr 26 14:22:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15147
	for ; Thu, 26 Apr 2001 14:22:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6F8874433D; Thu, 26 Apr 2001 14:22:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C10544339
	for ; Thu, 26 Apr 2001 14:21:54 -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 f3R4XhR28207;
	Thu, 26 Apr 2001 23:33:47 -0500 (GMT)
Received: from hrishikesh (unknown [10.10.10.96])
	by email.eximsoft.com (Postfix) with SMTP
	id 89343690ED; Thu, 26 Apr 2001 23:51:03 +0530 (IST)
Message-ID: <004b01c0ce7d$272a6ea0$600a0a0a@exim.com>
Reply-To: "Hrishikesh Saria" 
From: "Hrishikesh Saria" 
To: 
Organization: Eximsoft
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0048_01C0CEAB.40AA0E70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] Problem with ACK through proxy
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, 26 Apr 2001 23:47:28 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0048_01C0CEAB.40AA0E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi,
    i am receiving a Record-Route header in the 200 OK response. The =
Route header in the ACK  is being constructed using this. But the ACK is =
not reaching the callee , though it is reaching the proxy. But if the =
other person sends a Contact header in the 200 OK and that is added at =
the end of the Route header in ACK  , the ACK  is reaching the callee. =
If the Contact header is not present, what is being done ... this is =
wrong, i agree... (but it works) ... is that i am extracting the IP =
address of the callee's system from the 'c=3D...' of the SDP.=20
    So , i have 2 questions:
    is the contact header mandatory in 200 OK for invite?
    if not , what is the proper solution to the above problem? i,e,. =
without having to look at SDP header...

thanks in advance.

regards
hrishikesh

------=_NextPart_000_0048_01C0CEAB.40AA0E70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









hi,


    i am receiving a =
Record-Route=20
header in the 200 OK response. The Route header in the ACK  is being =
constructed=20
using this. But the ACK is not reaching the callee , though it is =
reaching the=20
proxy. But if the other person sends a Contact header in the 200 OK and =
that is=20
added at the end of the Route header in ACK  , the ACK  is =
reaching=20
the callee. If the Contact header is not present, what is being =
done ...=20
this is wrong, i agree... (but it works) ... is that i am extracting the =
IP=20
address of the callee's system from the 'c=3D...' of the SDP. =



    So , i have 2=20
questions:


    is the contact =
header mandatory=20
in 200 OK for invite?


    if not , what is the =
proper=20
solution to the above problem? i,e,. without having to look at SDP=20
header...


 


thanks in advance.


 


regards


hrishikesh


------=_NextPart_000_0048_01C0CEAB.40AA0E70--


_______________________________________________
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 Apr 26 16:46:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20679
	for ; Thu, 26 Apr 2001 16:46: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 B23954433D; Thu, 26 Apr 2001 16:46:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb6.rediffmail.com (unknown [202.54.124.151])
	by lists.bell-labs.com (Postfix) with SMTP id B555A443F6
	for ; Thu, 26 Apr 2001 10:56:17 -0400 (EDT)
Received: (qmail 5422 invoked by uid 510); 26 Apr 2001 15:01:51 -0000
Message-ID: <20010426150151.5421.qmail@mailweb6.rediffmail.com>
Received: from unknown (210.18.14.93) by rediffmail.com via HTTP; 26 Apr 2001 15:01:51 -0000
MIME-Version: 1.0
To: "hrishikesh.saria@eximsoft.com" ,
        "sip@lists.bell-labs.com" 
Subject:  Re: Fw: [Sip] Register
Cc: "sip@vovida.org" 
From: "Manish S. Jalan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
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: 26 Apr 2001 15:01:51 -0000
Content-Transfer-Encoding: 7bit

Well, I am not sure about the Registration scenario.
People on the SIP lists can well answer your your query on handling  out of sequence responses.

But, you can never receive an ACK without the INVITE.

ACK is sent only after the callee sends in a final response(>=200)

And callee can send a response only on receiving INVITE. Right?

So about receving ACK you can be assured that it will never come without a preceeding INVITE.

What most implementations do, is record the greatest response received as yet in a session and hence when a lower response is received, it is ignored.
The reason being, the caller can never receive multiple final responses.
It will receive a single final response.
As far as out out of sync responses goes, it will hence least affect the sip ua.

Why the caller receives only single final response?
Ans.
Because, the destination will send a single final response.

Haa, in case of a proxy acting in between if its a forking one, then the proxy server can receive multiple responses, which it will sort out and send a single final response to the caller.
So, the caller has to be least worried.

Hope it helps.

Bye,
-Manish S. Jalan


------------- Original Message --------------
"Hrishikesh Saria"  wrote:
To:
From:"Hrishikesh Saria" 
Date:Thu, 26 Apr 2001 19:48:09 +0530
CC:
Subject:Fw: [Sip] Register



How do you stop the retransmission of the 200OK response for the =
register message.

Also what needs to be done if you get a response out of sequence or an =
ACK when you have'nt got an invite

Reagrds
Hrishikesh Saria


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.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@lists.bell-labs.com  Thu Apr 26 17:02:52 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21554
	for ; Thu, 26 Apr 2001 17:02:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2E44844385; Thu, 26 Apr 2001 16:54:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 4BF1F4433D
	for ; Thu, 26 Apr 2001 16:53:28 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id QAA62191; Thu, 26 Apr 2001 16:53:27 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: 
Subject: RE: [SIP] Problem with ACK through proxy
Message-ID: <009201c0ce93$39fed410$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <004b01c0ce7d$272a6ea0$600a0a0a@exim.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: Thu, 26 Apr 2001 16:55:28 -0400
Content-Transfer-Encoding: 7bit

> is the contact header mandatory in 200 OK for invite?

Yes. The Contact header is mandatory in 2xx for 
INVITE as mentioned in section 6.15 and shown 
in table 4 rfc2543bis-02.

Note: older UAs might not add a Contact.  
In this case, it is up to the supporting 
record-routing Proxy to remember how to route to 
the final location.  (I assume that some proxies 
might attach Contact for the old UA to keep from 
having to store it.)  If there is no record-route,
the originating UA would send subsequent requests 
where it sent the previous on the call-leg.


_______________________________________________
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 Apr 26 20:05:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24980
	for ; Thu, 26 Apr 2001 20:05:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 060E94435D; Thu, 26 Apr 2001 20:05:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id E6D0C44339
	for ; Thu, 26 Apr 2001 20:04:24 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id UAA90886; Thu, 26 Apr 2001 20:04:24 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: 
Subject: RE: [SIP] First cut review of Session Timer draft.
Message-ID: <009401c0cead$e6d310b0$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F30B21@DYN-TX-EXCH-001.dynamicsoft.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: Thu, 26 Apr 2001 20:06:25 -0400
Content-Transfer-Encoding: 7bit

> Comments referring to specific parts of the document are prefixed with
> (page:paragraph)
> 



> 3:4 - (Minor) I am not sure I see the value in pushing 
> responsibility back
> to a supporting UAC, if the UAC did not request the timer in the first
> place. Why not just let the UAS deal with it, if the UAS is 
> the element that
> wishes to use a timer? 

I agree.  However the text is mainly to deal 
with proxies adding the "Session-Expires and 
Require timer" for functionality that it 
knows is supported by the UAC.  Hopefully 
a UAS isn't requiring it of the UAC when UAS 
is the one that wants it and could have done 
it.

> At least it might make sense to say 
> that the UAS must
> insert the Required header IF it wishes the UAC to handle the 
> re-invites.

It does elsewhere in the document: 
section 5.2 Case 1 and section 6 paragraph 2.

> 
> 4:5  What happens if the UAC does _NOT_ include a 
> Session-Expires header on
> the re-invite? I assume everyone resets their timers with the original
> values? Or does timer processing cease?

Timer processing ceases unless re-added 
by proxy or UAS.

> 
> 5:2 - Doesn't option of absolute time imply an assumption 
> that all elements
> have their clocks reasonably synchronized?

The Date header should be included to avoid 
the date/time synchronization problem.

> 
> 5:3 - Again, we need to allow elements to reject expirations below a
> configured threshold.

I agree.  And if possible, lets allow the minimum 
value to be returned with a standard format so that 
the request could be sent again hopefully without 
having to get the users and proxy admins involved 
for success.

> 10:2 - How can a proxy know that it is the closes proxy to 
> the UAC that
> cares about the timer? Except in the trivial case where the 
> proxy is the
> closest to the UAC period, this seems problematic.

I agree.  The text should reflect that the first 
proxy that receives the final response and wants 
the Session-Expires to be honored should add 
(if not present) the remembered Session-Expires 
and Require header containing "timer".


_______________________________________________
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 Apr 26 20:27:09 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25361
	for ; Thu, 26 Apr 2001 20:27:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9194C4437E; Thu, 26 Apr 2001 20:27:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange.NeTrue.com (unknown [207.104.210.242])
	by lists.bell-labs.com (Postfix) with ESMTP id 9E89A44339
	for ; Thu, 26 Apr 2001 20:26:42 -0400 (EDT)
Received: from roland (207.104.210.147 [207.104.210.147]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JV80G81V; Thu, 26 Apr 2001 17:30:22 -0700
Message-ID: <03fd01c0ceb0$f902cc50$93d268cf@netrue.com>
From: "Roland" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03EF_01C0CE76.47C094C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [SIP] any document about transfer or call-wait?
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, 26 Apr 2001 17:28:17 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_03EF_01C0CE76.47C094C0
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

Does anybody know where any papers is about transfer or call-wait =
functions?
specially call flow for these functions.

Thanks a lot!!!!

roland


------=_NextPart_000_03EF_01C0CE76.47C094C0
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable









Does anybody know where any papers is =
about=20
transfer or call-wait functions?


specially call flow for these=20
functions.


 


Thanks a lot!!!!


 


roland


 


------=_NextPart_000_03EF_01C0CE76.47C094C0--


_______________________________________________
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 Apr 26 22:29:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28219
	for ; Thu, 26 Apr 2001 22:29:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E390A44339; Thu, 26 Apr 2001 22:29:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id A91D544338
	for ; Thu, 26 Apr 2001 22:28:06 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id WAA08009; Thu, 26 Apr 2001 22:28:06 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: 
Subject: RE: [SIP] precedence rules for Route, maddr, and R-URI hostname
Message-ID: <009901c0cec1$f9db9060$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: 
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, 26 Apr 2001 22:30:07 -0400
Content-Transfer-Encoding: 7bit

Jonathan,

I have not noticed any flaws with the strawman. 

However I assume that only the SIP-URL 
of the Route instead of the whole Route 
contents are copied into the Request-URI.

Route = "Route" ":" 1# (name-addr *(";" rr-param))
 and
Request-URI = SIP-URL | absoluteURI

I mention this for clarity purposes and 
because it was discussed in your earlier 
"new record-route text" proposal.  That
proposal's example also only showed the SIP-URL
getting copied into the Route instead of the 
whole name-addr and the rr-param.  Is this
still the recommendation?


> Strawman
> --------
> 
> when a proxy receives a request, it checks for the existence 
> of a Route
> header. If one exists, that Route header is popped, and 
> placed into the
> request URI.



_______________________________________________
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 Apr 27 03:12:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17651
	for ; Fri, 27 Apr 2001 03:12: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 EDB2C44339; Fri, 27 Apr 2001 03:12: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 CA8ED44338
	for ; Fri, 27 Apr 2001 03:11:58 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA29176;
	Fri, 27 Apr 2001 03:15:35 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 03:11:57 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" , sip@lists.bell-labs.com
Subject: RE: [SIP] precedence rules for Route, maddr, and R-URI hostname
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, 27 Apr 2001 03:11:48 -0400



 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, April 26, 2001 10:30 PM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] precedence rules for Route, maddr, and 
> R-URI hostname
> 
> 
> Jonathan,
> 
> I have not noticed any flaws with the strawman. 
> 
> However I assume that only the SIP-URL 
> of the Route instead of the whole Route 
> contents are copied into the Request-URI.
> 
> Route = "Route" ":" 1# (name-addr *(";" rr-param))
>  and
> Request-URI = SIP-URL | absoluteURI
> 
> I mention this for clarity purposes and 
> because it was discussed in your earlier 
> "new record-route text" proposal.  That
> proposal's example also only showed the SIP-URL
> getting copied into the Route instead of the 
> whole name-addr and the rr-param.  Is this
> still the recommendation?

The request URI can only hold a URI, so yes, only the URI
part of Route (which does include URI parameters),
is copied into the request URI.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 03:34:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18071
	for ; Fri, 27 Apr 2001 03:34:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F88D44339; Fri, 27 Apr 2001 03:34: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 7314544338
	for ; Fri, 27 Apr 2001 03:33:42 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA29289;
	Fri, 27 Apr 2001 03:37:16 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 03:33:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christer Holmberg'" ,
        Vijay Gurbani 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
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, 27 Apr 2001 03:33:35 -0400



 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, April 26, 2001 1:01 PM
> To: Vijay Gurbani
> Cc: 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] Further editorial nit in the bis draft
> 
> 
> >>Also, from a standardization point of view: first BYE was 
> not allowed,
> >>then it was allowed, and now we want to make it not allowed 
> again... How
> >>long is it then going to take before we want to allow it again?
> > 
> >I thought the genealogy was that "BYE was allowed in RFC 2543 to
> >terminate a pending INVITE, but current thinking is that it 
> should not be".
> >I do not remember it being "not allowed, then it was 
> allowed, and now we
> >want to make it not allowed again."
> 
> I guess I put my words wrong. I meant the way we want to 
> handle the BYE,
> ie if a
> final response should be sent for the INVITE if a BYE is 
> received, etc.
> First that
> was the case, then it was decided to handle it like a BYE, and now we
> want to forbid it.

There has been a lot of misunderstanding about what I was saying.

No matter what, the original INVITE request is responded to. Period.
Christer somehow misunderstood my post to imply that the INVITE need not be
responded to if a BYE is used to "cancel" the call. This was my
interpretation of his post, at least, when he wrote:

> What if we get a Contact/Record-Route in a provisional response to the
> INVITE, which means the BYE could be sent another route (using other
> proxies) than the INVITE. If there is no response to the INVITE, how
> will be intermediate proxies handling the INVITE know that 
> there will be
> no response?

To be clear, the INVITE is ALWAYS responded to, so there is no issue above.

Vijay also misinterpreted my post to mean that we were getting rid of the
ability to terminate a call before 200 OK, using BYE. I was not proposing
that either. Before a final response is received (or a provisional response
with RR), the best way to hang up the call is to send CANCEL, and then if
you get any 200 OK, send BYE. Sending BYE first can cause unusual failure
conditions when the routing logic at intervening proxies is not
deterministic, or is deterministic, but based on variables outside of the
SIP request (like time of day). However, lots of people preferred this
approach since its easiest to implement. These issues have been discussed
and pointed out many times over a long period. THe current bis draft does
instruct a UA to send CANCEL and BYE at the same time. I actually don't like
this, since you can still get into conditions where you don't know whether
the call is hung up. 

It would be my proposal to have the spec say that the right behavior is
CANCEL, followed by BYE for any 200 OK that happen to pass the BYE on the
wire. If you get a non-200 response to INVITE after the CANCEL, you're done,
and the hangup was successful. However, the spec would also say that a basic
implementation MAY just send BYE right away, and point out the potential
issues.

Now, back to my original post on this, where I said:

>>>Actually, I would rather remove the reference to cancelling a
>>>request with
>>>BYE. Thats legacy from the old days when, in fact, sending a
>>>BYE meant you
>>>didn't need to respond to the original INVITE.

All I meant was that the following text from bis:

>Strictly speaking, CSeq header fields are needed
>for any SIP request that can be cancelled by a BYE
>or CAN-CEL request or where a client can issue several
>requests for the same Call-ID in close succession.
>Without a sequence number, the response to an INVITE
>could be mistaken for the response to the cancellation
>(BYE or CAN-CEL). Also, if the network duplicates packets
>or if an ACK is delayed until the server has sent an additional response,

this text seems to imply that BYE cancels a sip request, which is not really
true. BYE will trigger a final response to INVITE if none has been sent yet,
but thats not a general CANCEL operation. Nor is this text even correct,
that the response to BYE could be confused with the CANCEL response. All I
was saying, therefore, was to remove the reference to BYE in this paragraph.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 03:39:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18136
	for ; Fri, 27 Apr 2001 03:39:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E7EF2443BA; Fri, 27 Apr 2001 03:39: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 D5E0344338
	for ; Fri, 27 Apr 2001 03:38:18 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA29309;
	Fri, 27 Apr 2001 03:41:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 03:38:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Sean Olson (EUS)'" ,
        "'Vijay Gurbani'" ,
        "Christer Holmberg (LMF)" 
Cc: Jonathan Rosenberg ,
        "'Drage, Keith (Keith)'" ,
        "'Henning G. Schulzrinne'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
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, 27 Apr 2001 03:38:03 -0400



  
-----Original Message-----
>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
>Sent: Thursday, April 26, 2001 1:07 PM
>To: 'Vijay Gurbani'; Christer Holmberg (LMF)
>Cc: Jonathan Rosenberg; 'Drage, Keith (Keith)'; 'Henning G. Schulzrinne';
'sip@lists.bell-
>labs.com'
>Subject: RE: [SIP] Further editorial nit in the bis draft
>
>
>
>
>>Oh, that brings up an interesting point:   If a stateful proxy 
>>forked and one of the branches reached a stateless downstream 
>>server, when 
>>the statful proxy gets a CANCEL, it will propogate the CANCEL 
>>to the state- 
>>less downstream proxy.  What do statless proxies do on getting 
>>a CANCEL?  
>>Since they do not have state associated with the INVITE they received 
>>earlier, how do they handle the CANCEL?  Am I missing 
>>something obvious? 
>
>Is there any reason why the stateless proxy would do something 
>other than forward the CANCEL request? I don't understand 
>what the alternative might be. 

I agree. The stateless proxy will re-apply its routing logic and forward the
request downstream. You might run into problems if the stateless proxy is
trying to do some statistical load balancing, and sends the CANCEL a
different place than INVITE. For this reason, stateless proxies, in general,
should really only apply routing which is deterministic, that is, for which
the routing decision is dependent only on a static function where the only
input is the SIP reuqest, and possibly some static configuration data. If
you don't do this, you will also have troubles with retransmissions going
different places.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 03:59:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18513
	for ; Fri, 27 Apr 2001 03:59:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B2AF8443B5; Fri, 27 Apr 2001 03:59: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 3711544339
	for ; Fri, 27 Apr 2001 03:58:30 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA29360;
	Fri, 27 Apr 2001 04:02:06 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 03:58:28 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'James Undery'" ,
        SIP List 
Subject: RE: [SIP] Registration Authentication
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
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, 27 Apr 2001 03:58:24 -0400



 

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Thursday, April 26, 2001 12:29 PM
> To: SIP List
> Subject: [SIP] Registration Authentication
> 
> 
> Hi,
> 
> Now the second version of the sip-register draft is out, it may be a
> good time to bring up an issue I don't think was resolved 
> last time. In
> 
>  http://lists.bell-labs.com/pipermail/sip/2000q4/003116.html
> 
> it was mentioned REGISTER is totally unprotected from by digest
> authentication, i.e. auth-int does nothing to prevent someone from
> replaying a successful registration with a different Contact 
> header(s).

Thats not entirely true. A replay will succeed only until the nonce expires.
Assuming fairly short nonce lifetimes (a good idea, in general), that means
you need to replay within a few seconds. That is possible, of course.

> As PGP has been depreciated (and justifiably so) we are left 
> without any
> method, however weak, of authenticating REGISTER requests.
> 
> I am inclined to suggest deprecating REGISTER, however, I won't and
> suggest instead we allow (or recommend) the contact headers 
> are repeated
> in the REGISTER message body.

Err, deprecating register seems a bit extreme to deal with this problem.
Also a bit too late.

Anyway, I see a few solutions:

1. we define a real security framework that supports true integrity, both
using public key and shared secret. No doubt this will require copying the
signed thing into the bodies. I know work is underway on this, but it will
be a while.

2. as a shorter term solution, we define a variant on digest which includes
select header fields in the siganture, i.e., qop=auth-sip. We could specify
this faster, but its still gonna require a complete extension.

3. There might be another way..... no extensions needed. Complete integrity
protection. More to come.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 05:18:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19749
	for ; Fri, 27 Apr 2001 05:18:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A286344339; Fri, 27 Apr 2001 05:18: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 2E91844338
	for ; Fri, 27 Apr 2001 05:17:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA29722;
	Fri, 27 Apr 2001 05:21:20 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 05:17:43 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Vijay Gurbani'" ,
        Jonathan Rosenberg 
Cc: "'Drage, Keith (Keith)'" ,
        "'Mayank Sharma'" ,
        "Chen, Xin (Xin)" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] A question about Cancel request
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
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, 27 Apr 2001 05:17:41 -0400



 

> -----Original Message-----
> From: Vijay Gurbani [mailto:vkg@lucent.com]
> Sent: Thursday, April 26, 2001 10:15 AM
> To: Jonathan Rosenberg
> Cc: 'Drage, Keith (Keith)'; 'Mayank Sharma'; Chen, Xin (Xin);
> 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] A question about Cancel request
> 
> 
> Jonathan Rosenberg wrote:
> [...]
> > I agree that it is worthwhile discussing the usage of 
> CANCEL in a proxy in
> > more detail. Unless anyone objects, I will add some text 
> (for -04) that 
> > says that a proxy SHOULD NOT send a CANCEL for a timed-out 
> request for 
> > which it has not received any provisional response. The 
> proxy is supposed 
> > to have gotten a 100 if the final response can't be 
> answered within 500ms. 
> > So, the absence of a provisional response after 32s implies 
> that there is 
> > either a malfunctioning, or non-existent server at the 
> receiving end of 
> > the request. In either case, sending CANCEL is useless.
> 
> Sounds good to me.  I always thought it was pointless sending 
> a CANCEL to
> the same destination that has not responded to re-transmitted INVITEs.
> 
> BTW, you mention -04 bis, what happened to -03?  As far as I 
> know, -02 is
> the latest on the SIP web site at Columbia...

What I meant is that I won't include this in -03, since I want to get that
submitted shortly. -04 will end up being a more extensive update.

-Jonathan R.

---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 06:07:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20452
	for ; Fri, 27 Apr 2001 06:07:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 938B144339; Fri, 27 Apr 2001 06:07:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id C81A244338
	for ; Fri, 27 Apr 2001 06:06:02 -0400 (EDT)
Received: from gecko by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 27 Apr 2001 10:06:02 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA22227; Fri, 27 Apr 2001 11:05:53 +0100 (BST)
Message-ID: <3AE9447F.67D87498@ubiquity.net>
From: James Undery 
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: SIP List 
Subject: Re: [SIP] Registration Authentication
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: Fri, 27 Apr 2001 11:05:51 +0100
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: James Undery [mailto:jundery@ubiquity.net]
> > Sent: Thursday, April 26, 2001 12:29 PM
> > To: SIP List
> > Subject: [SIP] Registration Authentication
> >
> >
> > Hi,
> >
> > Now the second version of the sip-register draft is out, it may be a
> > good time to bring up an issue I don't think was resolved
> > last time. In
> >
> >  http://lists.bell-labs.com/pipermail/sip/2000q4/003116.html
> >
> > it was mentioned REGISTER is totally unprotected from by digest
> > authentication, i.e. auth-int does nothing to prevent someone from
> > replaying a successful registration with a different Contact
> > header(s).
>
> Thats not entirely true. A replay will succeed only until the nonce expires.
> Assuming fairly short nonce lifetimes (a good idea, in general), that means
> you need to replay within a few seconds. That is possible, of course.

One phrase "Man in the Middle", whatever your nonce lifetime is, even if it's
based on the transaction, you are really vunerable.

>
>
> Anyway, I see a few solutions:
>
> 1. we define a real security framework that supports true integrity, both
> using public key and shared secret. No doubt this will require copying the
> signed thing into the bodies. I know work is underway on this, but it will
> be a while.

That's definately the best idea as this example shows where the differences
between SIP and HTTP break the usefulness of HTTP Authentication to SIP.

>
>
> 2. as a shorter term solution, we define a variant on digest which includes
> select header fields in the siganture, i.e., qop=auth-sip. We could specify
> this faster, but its still gonna require a complete extension.
>
> 3. There might be another way..... no extensions needed. Complete integrity
> protection. More to come.
>

James Undery


_______________________________________________
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 Apr 27 10:40:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02324
	for ; Fri, 27 Apr 2001 10:40: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 92F4644339; Fri, 27 Apr 2001 10:40:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 6F83A44338
	for ; Fri, 27 Apr 2001 06:45:50 -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 GAA21287;
	Fri, 27 Apr 2001 06:45:49 -0400 (EDT)
Message-Id: <200104271045.GAA21287@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-10.txt
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, 27 Apr 2001 06:45:49 -0400

--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		: MIME media types for ISUP and QSIG Objects
	Author(s)	: E. Zimmerer, J. Peterson, A. Vemuri, L. Ong,
                          F. Audet, M. Watson
	Filename	: draft-ietf-sip-isup-mime-10.txt
	Pages		: 9
	Date		: 26-Apr-01
	
This document describes MIME types for application/ISUP and
application/QSIG objects for use in SIP [2] applications, according
to the rules defined in RFC 2048 [1].  These types can be used to
identify ISUP and QSIG objects within a SIP message such as INVITE or
INFO, as might be implemented when using SIP in an environment where
part of the call involves interworking to the PSTN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-10.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-mime-10.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-mime-10.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:	<20010426132702.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-isup-mime-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-isup-mime-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010426132702.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
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 Apr 27 10:44:31 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02618
	for ; Fri, 27 Apr 2001 10:44:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 31511443D7; Fri, 27 Apr 2001 10:43:05 -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 4DF2B443A5
	for ; Fri, 27 Apr 2001 10:42:25 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr 27 10:38:13 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 0C4B544380; Fri, 27 Apr 2001 10:27:27 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id BBC204437D
	for ; Fri, 27 Apr 2001 10:27:26 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA23090; Fri, 27 Apr 2001 09:27:24 -0500
Cc: "'Christer Holmberg'" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA23072; Fri, 27 Apr 2001 09:27:21 -0500
Message-ID: <3AE981C4.6A0D3E5@lucent.com>
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 
Original-CC: "'Christer Holmberg'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
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: Fri, 27 Apr 2001 09:27:16 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> To be clear, the INVITE is ALWAYS responded to, so there is no issue 
> above.
> 
> Vijay also misinterpreted my post to mean that we were getting rid of the
> ability to terminate a call before 200 OK, using BYE. I was not proposing
> that either. Before a final response is received (or a provisional 
> response with RR), the best way to hang up the call is to send CANCEL, and 
> then if you get any 200 OK, send BYE. 

Jonathan:

I misinterpret many thing, but definitely not this one :-)  In some earlier
posting, I made the same point: a BYE should be sent after a CANCEL iff 
the 200 OK (INVITE) from the UAS and the CANCEL pass each other on the wire.

> It would be my proposal to have the spec say that the right behavior is
> CANCEL, followed by BYE for any 200 OK that happen to pass the BYE on the
> wire. If you get a non-200 response to INVITE after the CANCEL, you're 
> done, and the hangup was successful. 

Fine; just a small nit: if you get a non-200 response to the INVITE after 
sending the CANCEL, there is no hangup -- no session was established.  The 
UAC ACKs the non-200 response for the INVITE and waits for the 200 OK 
(CANCEL).  That's it.

> However, the spec would also say that a basic implementation MAY just send 
> BYE right away, and point out the potential issues.

Ummm, if you do this, chances are that many UA implementations will trade
off complexity for time and implement sending BYE only.  Pretty soon we will 
be back to debating the same issue a few months from now.  My input (for 
what its worth) would be not to even mention that a basic implementation MAY 
just send BYE right away.

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

_______________________________________________
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 Apr 27 10:48:14 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02772
	for ; Fri, 27 Apr 2001 10:48:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6871A443E8; Fri, 27 Apr 2001 10:43:12 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 111B8443A6
	for ; Fri, 27 Apr 2001 10:42:43 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A50C8E01B0; Fri, 27 Apr 2001 10:41:16 -0400
Message-ID: <00de01c0cf28$7bb561e0$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Jonathan Rosenberg" ,
        "'Christer Holmberg'" ,
        "Vijay Gurbani" 
Cc: 
References: 
Subject: Re: [SIP] Further editorial nit in the bis draft
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
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, 27 Apr 2001 10:43:54 -0400
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:

> It would be my proposal to have the spec say that the right behavior is
> CANCEL, followed by BYE for any 200 OK that happen to pass the BYE on the
> wire. If you get a non-200 response to INVITE after the CANCEL, you're
done,
> and the hangup was successful. However, the spec would also say that a
basic
> implementation MAY just send BYE right away, and point out the potential
> issues.

I believe you meant "followed by BYE for any 200 OK that happened to pass
the CANCEL on the wire" in the first sentence.

I agree. You should not send two messages (CANCEL and BYE) when one will
suffice.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Jonathan Rosenberg" 
To: "'Christer Holmberg'" ; "Vijay
Gurbani" 
Cc: 
Sent: Friday, April 27, 2001 3:33 AM
Subject: RE: [SIP] Further editorial nit in the bis draft


>
>
>
>
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Thursday, April 26, 2001 1:01 PM
> > To: Vijay Gurbani
> > Cc: 'sip@lists.bell-labs.com'
> > Subject: Re: [SIP] Further editorial nit in the bis draft
> >
> >
> > >>Also, from a standardization point of view: first BYE was
> > not allowed,
> > >>then it was allowed, and now we want to make it not allowed
> > again... How
> > >>long is it then going to take before we want to allow it again?
> > >
> > >I thought the genealogy was that "BYE was allowed in RFC 2543 to
> > >terminate a pending INVITE, but current thinking is that it
> > should not be".
> > >I do not remember it being "not allowed, then it was
> > allowed, and now we
> > >want to make it not allowed again."
> >
> > I guess I put my words wrong. I meant the way we want to
> > handle the BYE,
> > ie if a
> > final response should be sent for the INVITE if a BYE is
> > received, etc.
> > First that
> > was the case, then it was decided to handle it like a BYE, and now we
> > want to forbid it.
>
> There has been a lot of misunderstanding about what I was saying.
>
> No matter what, the original INVITE request is responded to. Period.
> Christer somehow misunderstood my post to imply that the INVITE need not
be
> responded to if a BYE is used to "cancel" the call. This was my
> interpretation of his post, at least, when he wrote:
>
> > What if we get a Contact/Record-Route in a provisional response to the
> > INVITE, which means the BYE could be sent another route (using other
> > proxies) than the INVITE. If there is no response to the INVITE, how
> > will be intermediate proxies handling the INVITE know that
> > there will be
> > no response?
>
> To be clear, the INVITE is ALWAYS responded to, so there is no issue
above.
>
> Vijay also misinterpreted my post to mean that we were getting rid of the
> ability to terminate a call before 200 OK, using BYE. I was not proposing
> that either. Before a final response is received (or a provisional
response
> with RR), the best way to hang up the call is to send CANCEL, and then if
> you get any 200 OK, send BYE. Sending BYE first can cause unusual failure
> conditions when the routing logic at intervening proxies is not
> deterministic, or is deterministic, but based on variables outside of the
> SIP request (like time of day). However, lots of people preferred this
> approach since its easiest to implement. These issues have been discussed
> and pointed out many times over a long period. THe current bis draft does
> instruct a UA to send CANCEL and BYE at the same time. I actually don't
like
> this, since you can still get into conditions where you don't know whether
> the call is hung up.
>
> It would be my proposal to have the spec say that the right behavior is
> CANCEL, followed by BYE for any 200 OK that happen to pass the BYE on the
> wire. If you get a non-200 response to INVITE after the CANCEL, you're
done,
> and the hangup was successful. However, the spec would also say that a
basic
> implementation MAY just send BYE right away, and point out the potential
> issues.
>
> Now, back to my original post on this, where I said:
>
> >>>Actually, I would rather remove the reference to cancelling a
> >>>request with
> >>>BYE. Thats legacy from the old days when, in fact, sending a
> >>>BYE meant you
> >>>didn't need to respond to the original INVITE.
>
> All I meant was that the following text from bis:
>
> >Strictly speaking, CSeq header fields are needed
> >for any SIP request that can be cancelled by a BYE
> >or CAN-CEL request or where a client can issue several
> >requests for the same Call-ID in close succession.
> >Without a sequence number, the response to an INVITE
> >could be mistaken for the response to the cancellation
> >(BYE or CAN-CEL). Also, if the network duplicates packets
> >or if an ACK is delayed until the server has sent an additional response,
>
> this text seems to imply that BYE cancels a sip request, which is not
really
> true. BYE will trigger a final response to INVITE if none has been sent
yet,
> but thats not a general CANCEL operation. Nor is this text even correct,
> that the response to BYE could be confused with the CANCEL response. All I
> was saying, therefore, was to remove the reference to BYE in this
paragraph.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       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
>
> _______________________________________________
> 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  Fri Apr 27 10:51:41 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03004
	for ; Fri, 27 Apr 2001 10:51:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B33A1443F0; Fri, 27 Apr 2001 10:47:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 66F89443EF
	for ; Fri, 27 Apr 2001 10:46:32 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBC8V8>; Fri, 27 Apr 2001 07:46:54 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Steve Gardell'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF28.E6110350"
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, 27 Apr 2001 07:46:53 -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_01C0CF28.E6110350
Content-Type: text/plain;
	charset="iso-8859-1"

Hi again,
 
The Join approach could provide a good reason to stick with the SDP vocoder
set behaviour decided at the last IETF meeting rather than what was being
bandied about on the list.
 
If you want to do DTMF monitoring and non-disruptive voice announcements
from an AS to a SIP session (eg calling card service as previously
discussed), then you will want to receive only the DTMF stream and send
voice. [An AS will not usually want to receive the voice traffic all the
time due to loading issues - I know people are talking about voice
recognition but this is normally when the caller is connected to AS not all
the time, right?] 
 
Now the voice and DTMF are normally syncronized in the same SDP m= line -
possibly causing problems. This is not a problem if each side only saying
what it is willing to recieve - NOT send and receive. That is, the UA would
put that it can recieve both voice and DTMF (as normal) and the AS would
indicate that it can only receive DTMF. 
 
However, thanks to the flexibility of the Join header  it will work
even if we go with the send-and-receive SDP vocoder defintion. Instead you
would just send two INVITE's with Join headers: one specifying "a=recvonly"
listing the DTMF vocoder and the other specifying "a=sendonly" with the
voice coder.
 
Regards,
 
Robert.
 

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi Steve,
 
Thanks for your comment.
 
Pretty much everything can be done as a B2BUA and I agree with you: until
UA's with REFER &  Replaces capability are widely deployed, then B2BUA is
pretty much the only way to accomplish many of the "advanced call control"
features in an hetrogenous/non-controlled SIP network (IMO). However,
unfortuately a B2BUA does not help in the scenario described in this thread.

 
A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The
Application (or some related RTP processing/splitting/forwarding entity)
could process the media for every call for the entire duration of the call
[for common usage scenario]. However, I don't beleive this is generally a
scalable solution. I don't think you are denying that the features being
discussed are not very important to people wishing to provide calling-card
style services (non-disruptive in-call warnigns and announcements, media
triggered events such as triple # for call follow-on/return, etc).
 
For "Join" to work, one of the endpoints must support the Join header - just
like REFER you cannot guarantee every UA will implement this. This is the
same for the existing SDP-based stream forking behavior. I don't see that
this is a problem specific to this suggestion but rather a general problem
for adding extensions - not everyone is going to implement every extension.
This is not a reason to stop publishing extensions (which I'm sure you are
not debating). 
 
However, that does bring up a good advantage to this Join approach. IMO, it
is seems much easier for many PSTN-gateway based calling card services to
control the features supported by just _one_ of the UA's involved in a call
(usually the gateway). However, it may not always be the caller, for
instance, in a "PC to Phone" application where the client is located on a
"plain-vanilla" SIP client on the internet. In this case it might be usefull
to allow the Join header to be sent to the callee (the gateway) and specify
that the Join is only towards the remote party. (So the Join header options
become "local", "remote", or "full" mixing). This facility is not possible
with the current SDP-based stream forking approach.
 
To me this seems such a flexible, easy and clean way of achieving this
functionality.
 
Robert.

-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!
 
At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF
recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of
these
3 variants is most cost effective might well be service-provider dependent.
 
I agree that control over "full or local" mixing is important to support a 
calling card service.

 



------_=_NextPart_001_01C0CF28.E6110350
Content-Type: text/html;
	charset="iso-8859-1"







Join as replacement for DTMF/voice-forking.




Hi 
again,


 


The 
Join approach could provide a good reason to stick with the SDP vocoder set 
behaviour decided at the last IETF meeting rather than what was being bandied 
about on the list.


 


If you 
want to do DTMF monitoring and non-disruptive voice announcements from an AS to 
a SIP session (eg calling card service as previously discussed), then you will 
want to receive only the DTMF stream and send voice. [An AS will not usually 
want to receive the voice traffic all the time due to loading issues - I know 
people are talking about voice recognition but this is normally when the caller 
is connected to AS not all the time, right?] 


 


Now 
the voice and DTMF are normally syncronized in the same SDP m= line - possibly 
causing problems. This is not a problem if each side only saying what it is 
willing to recieve - NOT send and receive. That is, the UA would put that it can 
recieve both voice and DTMF (as normal) and the AS would indicate that it can 
only receive DTMF. 


 


However, thanks to the flexibility of the Join header <grin> it 
will work even if we go with the send-and-receive SDP vocoder defintion. Instead 
you would just send two INVITE's with Join headers: one specifying 
"a=recvonly" listing the DTMF vocoder and the other specifying 
"a=sendonly" with the voice coder.


 


Regards,


 


Robert.


 



    
-----Original Message-----
From: Fairlie-Cuninghame, Robert 
    [mailto:rfairlie@nuera.com]
Sent: Thursday, April 26, 2001 3:38 
    PM
To: 'Steve Gardell'; 
    'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement 
    for DTMF/voice-forking.


    
Hi 
    Steve,

    
 

    
Thanks for your comment.

    
 

    
Pretty much everything can be done as a B2BUA and I agree with you: 
    until UA's with REFER &  Replaces capability are widely deployed, 
    then B2BUA is pretty much the only way to accomplish many of the 
    "advanced call control" features in an hetrogenous/non-controlled 
    SIP network (IMO). However, unfortuately a B2BUA does not help in the 
    scenario described in this thread. 

    
 

    
A 
    B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The 
    Application (or some related RTP processing/splitting/forwarding entity) 
    could process the media for every call for the entire 
    duration of the call [for common usage scenario]. However, I don't beleive 
    this is generally a scalable solution. I don't think you 
    are denying that the features being discussed are not very important to 
    people wishing to provide calling-card style services (non-disruptive 
    in-call warnigns and announcements, media triggered events such as triple # 
    for call follow-on/return, etc).

    
 

    
For "Join" to work, one of the endpoints must support the 
    Join header - just like REFER you cannot guarantee every UA will implement 
    this. This is the same for the existing SDP-based stream forking behavior. I 
    don't see that this is a problem specific to this suggestion but rather a 
    general problem for adding extensions - not everyone is going to implement 
    every extension. This is not a reason to stop publishing extensions (which 
    I'm sure you are not debating). 

    
 

    
However, that does bring up a good advantage to this Join approach. 
    IMO, it is seems much easier for many PSTN-gateway based calling card 
    services to control the features supported by just _one_ of the UA's 
    involved in a call (usually the gateway). However, it may not always be the 
    caller, for instance, in a "PC to Phone" application where the 
    client is located on a "plain-vanilla" SIP client on the internet. 
    In this case it might be usefull to allow the Join header to be sent to the 
    callee (the gateway) and specify that the Join is only towards the remote 
    party. (So the Join header options become "local", 
    "remote", or "full" mixing). This facility is not 
    possible with the current SDP-based stream forking 
    approach.

    
 

    
To 
    me this seems such a flexible, easy and clean way of achieving this 
    functionality.

    
 

    
Robert.

    

        
-----Original Message-----
From: Steve Gardell 
        [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 
        1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 
        'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as 
        replacement for DTMF/voice-forking.


        

        
The additional 
        discussion really helps for those of us who 
        don't

        
have the several hours 
        a day it takes to really keep up on the SIP list!

        
 

        
At any 
        rate, one concern - probably with both models - is that we 
        can't

        
make the assumption that all 
        gateways are willing to "invest" in 
        the

        
additional 
        DSP to support mixing or, for that matter, mid-call DTMF 
        recognition.

        
In that 
        case one could imagine implementing a B2BUA (with associated 
        

        
media 
        processing) that can do this 
        "in the network" with join 
        as suggested 

        
or simply 
        implementing the service in it's entirety at 
        a B2BUA. Which of 
        these

        
3 variants is most cost effective might well be 
        service-provider dependent.

        
 

        
I agree that control over 
        "full or local" mixing is important to support a 
        

        
calling card 
        service.

        

        
 

        



------_=_NextPart_001_01C0CF28.E6110350--

_______________________________________________
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 Apr 27 10:55:47 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03221
	for ; Fri, 27 Apr 2001 10:55:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A95B7443F8; Fri, 27 Apr 2001 10:50:05 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 0246E443F7
	for ; Fri, 27 Apr 2001 10:49:55 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Apr 27 10:49:41 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 0787844384; Fri, 27 Apr 2001 10:36:26 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id B18134437D
	for ; Fri, 27 Apr 2001 10:36:25 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA25007; Fri, 27 Apr 2001 09:36:22 -0500
Cc: "'Sean Olson (EUS)'" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id JAA24995; Fri, 27 Apr 2001 09:36:21 -0500
Message-ID: <3AE983DF.7DAD9F2A@lucent.com>
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 
Original-CC: "'Sean Olson (EUS)'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
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: Fri, 27 Apr 2001 09:36:15 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> vkg>> Oh, that brings up an interesting point:   If a stateful proxy
> vkg>> forked and one of the branches reached a stateless downstream
> vkg>> server, when the statful proxy gets a CANCEL, it will propogate the 
> vkg>> CANCEL to the state-=less downstream proxy.  What do statless 
> vkg>> proxies do on getting a CANCEL?
> vkg>> Since they do not have state associated with the INVITE they 
> vkg>> received earlier, how do they handle the CANCEL?  Am I missing
> vkg>> something obvious?
> >
> sean>Is there any reason why the stateless proxy would do something
> sean>other than forward the CANCEL request? I don't understand
> sean>what the alternative might be.
> 
jdr> I agree. The stateless proxy will re-apply its routing logic and 
jdr> forward the request downstream. 

Yes, that's probably the case.  It is just that CANCEL is usually associated
with hop-by-hop behavior, not end-to-end.  So it seemed somehow funky that a 
stateless proxy will forward the CANCEL to the next downstream server. But 
of course, it cannot do anything else; it is stateless.

Thanks,

- 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

_______________________________________________
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 Apr 27 11:04:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03625
	for ; Fri, 27 Apr 2001 11:04:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 44DD3443A4; Fri, 27 Apr 2001 11:04:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id B888C44362
	for ; Fri, 27 Apr 2001 11:03:34 -0400 (EDT)
Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3RF3b810119
	for ; Fri, 27 Apr 2001 10:03:37 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr7.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3RF3W815914
	for ; Fri, 27 Apr 2001 10:03:33 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Apr 27 10:02:03 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Apr 2001 10:02:03 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Vijay Gurbani'" ,
        Jonathan Rosenberg 
Cc: "Christer Holmberg (LMF)" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF2B.03D15E10"
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, 27 Apr 2001 10:02:02 -0500

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_01C0CF2B.03D15E10
Content-Type: text/plain;
	charset="iso-8859-1"


>Jonathan:
>
>I misinterpret many thing, but definitely not this one :-)  In 
>some earlier
>posting, I made the same point: a BYE should be sent after a 
>CANCEL iff 
>the 200 OK (INVITE) from the UAS and the CANCEL pass each 
>other on the wire.

This is not what Jonathan is saying. He is referring to the
possibility of sending a BYE *instead* of a CANCEL, not sending
a BYE in the event a CANCEL crosses on the wire.

/sean

------_=_NextPart_001_01C0CF2B.03D15E10
Content-Type: text/html;
	charset="iso-8859-1"






RE: [SIP] Further editorial nit in the bis draft






>Jonathan:

>

>I misinterpret many thing, but definitely not this one :-)  In 

>some earlier

>posting, I made the same point: a BYE should be sent after a 

>CANCEL iff 

>the 200 OK (INVITE) from the UAS and the CANCEL pass each 

>other on the wire.




This is not what Jonathan is saying. He is referring to the

possibility of sending a BYE *instead* of a CANCEL, not sending

a BYE in the event a CANCEL crosses on the wire.




/sean





------_=_NextPart_001_01C0CF2B.03D15E10--

_______________________________________________
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 Apr 27 11:22:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04521
	for ; Fri, 27 Apr 2001 11:22: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 338A144362; Fri, 27 Apr 2001 11:22:04 -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 7C77344362
	for ; Fri, 27 Apr 2001 11:21:07 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03253;
	Fri, 27 Apr 2001 11:24:32 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 11:20:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Sean Olson (EUS)'" ,
        "'Vijay Gurbani'" ,
        Jonathan Rosenberg 
Cc: "Christer Holmberg (LMF)" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
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, 27 Apr 2001 11:20:54 -0400



  
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, April 27, 2001 11:02 AM
To: 'Vijay Gurbani'; Jonathan Rosenberg
Cc: Christer Holmberg (LMF); 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Further editorial nit in the bis draft

>>Jonathan: 
>> 
>>I misinterpret many thing, but definitely not this one :-)  In 
>>some earlier 
>>posting, I made the same point: a BYE should be sent after a 
>>CANCEL iff 
>>the 200 OK (INVITE) from the UAS and the CANCEL pass each 
>>other on the wire. 
>
>This is not what Jonathan is saying. He is referring to the 
>possibility of sending a BYE *instead* of a CANCEL, not sending 
>a BYE in the event a CANCEL crosses on the wire. 

Everyone loves to put words into my mouth...

I was saying that the preferred approach is to send CANCEL first, and then
iff you get a 200 OK anyway (which happens if the CANCEL and 200 OK pass on
the wire) then send BYE. I was also saying we should keep "just send BYE" as
a MAY. Vijay seems to be saying we should not even mention that possibility.

-Jonathan R.
---
Jonathan D. Rosenberg                       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

_______________________________________________
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 Apr 27 11:47:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06064
	for ; Fri, 27 Apr 2001 11:47: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 2D2B244362; Fri, 27 Apr 2001 11:47:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dryline-fw.wireless-sys.com (dryline-fw.yyz.somanetworks.com [216.126.67.45])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C40C44338
	for ; Fri, 27 Apr 2001 11:46:25 -0400 (EDT)
Received: from crusher.yyz.somanetworks.com.wireless-sys.com (osas@crusher.yyz.somanetworks.com [10.11.10.191])
	by dryline-fw.wireless-sys.com (8.8.7/8.8.7) with SMTP id LAA01082;
	Fri, 27 Apr 2001 11:46:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15081.37951.866666.95941@crusher.yyz.somanetworks.com>
From: Ovidiu Sas 
To: Manoj Bhatia 
Cc: "Manish S. Jalan" ,
        "sip@vovida.org" ,
        "sip@lists.bell-labs.com" ,
        "Sip-implementors@cs.columbia.edu" 
Subject: Re: [SIP] Clarification on sdp usage sought
In-Reply-To: <3AE729AA.458BCCC1@cisco.com>
References: <20010423120841.18191.qmail@mailweb1.rediffmail.com>
	<3AE729AA.458BCCC1@cisco.com>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
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, 27 Apr 2001 11:46:07 -0400 (EDT)
Content-Transfer-Encoding: 7bit


 Hello,

 I have a question related to SDP. See comments inline.

____________________
Manoj Bhatia writes:
 > 
 > Manish
 > 
 > See comments inline.
 > 
 > thanks
 > -manoj
 > 
 > "Manish S. Jalan" wrote:
 > 
 > > Hello,
 > >
 > > I am back to seek some more clarifications.
 > >
 > > Is the following sdp description ok:  (the order of attribute definitions especially)
 > >
 > > m=audio 1234 RTP/AVP 4 0
 > > a=rtpmap:4 G723/8000
 > > a=rtpmap:0 PCMU/8000
 > > a=ptime:20
 > > a=fmtp:4 bitrate=6300
 > >
 > 
 > This may not be illegal (given how loose the RFC is )
 > but I would think that it is  not the preferred way.
 > 
 > >
 > > or it should be,
 > >
 > > m=audio 1234 RTP/AVP 4 0
 > > a=rtpmap:4 G723/8000
 > > a=fmtp:4 bitrate=6300
 > > a=rtpmap:0 PCMU/8000
 > > a=ptime:20
 > >
 > 
 > This is the right definition.
 > The ptime parameter would correspond to G.711ulaw (payload 0) .

 I could't find any statement about the order of the media attributes
inside a media announcement in the RFC. In this context, how about
this definition:

  m=audio 1234 RTP/AVP 4
  a=rtpmap:4 G723/8000
  a=fmtp:4 bitrate=6300
  m=audio 1234 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=ptime:20

     => no information about the G723's packetization and 20ms
        packetization for PCMU.

 > 
 > >
 > > Is the ptime definition ok?
 > > the ptime is media specific or format specific?
 > >
 > > Please help me in clarifying the concepts.
 > > Any help is highly appreciated.
 > >
 > > Regards,
 > > -Manish S. Jalan
 > >

  Regards,
    Ovidiu Sas


_______________________________________________
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 Apr 27 12:03:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06818
	for ; Fri, 27 Apr 2001 12:03:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4CFB644395; Fri, 27 Apr 2001 12:03:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 560DD44372
	for ; Fri, 27 Apr 2001 12:02:24 -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 f3RG2N811937
	for ; Fri, 27 Apr 2001 11:02:23 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr7.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3RG2N817735
	for ; Fri, 27 Apr 2001 11:02:23 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Apr 27 11:02:22 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 27 Apr 2001 11:02:22 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Vijay Gurbani'" ,
        Jonathan Rosenberg 
Cc: "Sean Olson (EUS)" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF33.71A7ADB0"
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, 27 Apr 2001 11:02:22 -0500

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_01C0CF33.71A7ADB0
Content-Type: text/plain;
	charset="iso-8859-1"

Not mentioning it is not sufficient. 
If you don't want to allow this, then
add a "MUST NOT" regarding sending a BYE
before the INVITE transaction has completed.

/sean

>-----Original Message-----
>From: Vijay Gurbani [mailto:vkg@lucent.com]
>Sent: Friday, April 27, 2001 10:48 AM
>To: Jonathan Rosenberg
>Cc: 'Sean Olson (EUS)'; 'sip@lists.bell-labs.com'
>Subject: Re: [SIP] Further editorial nit in the bis draft
>
>
>Jonathan Rosenberg wrote:
>[...]
>> sean>This is not what Jonathan is saying. He is referring to the
>> sean>possibility of sending a BYE *instead* of a CANCEL, not sending
>> sean>a BYE in the event a CANCEL crosses on the wire.
>> 
>> Everyone loves to put words into my mouth...
>> 
>> I was saying that the preferred approach is to send CANCEL 
>first, and then
>> iff you get a 200 OK anyway (which happens if the CANCEL and 
>200 OK pass 
>> on the wire) then send BYE. 
>
>Right on!
>
>I could spend some time and come up with time-line diagrams if 
>anyone is
>interested (or if you want them to go in the -04 bis).  But it 
>is simple 
>really: If after sending CANCEL, a UAC gets a 200 OK (INVITE), 
>ACK it and 
>send a BYE (remember: CANCEL has no effect on a UAS state 
>machine if it has 
>already sent a final response).
>
>If after sending a CANCEL, a UAC gets a non-2xx response to the INVITE,
>just ACK it; no need to send the BYE -- session was never established.
>
>> I was also saying we should keep "just send BYE" as a MAY. 
>Vijay seems to 
>> be saying we should not even mention that possibility.
>
>Right.  We should not even mention it; a MAY will lead to the 
>same ambiguity 
>we are facing now.
>
>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
>

------_=_NextPart_001_01C0CF33.71A7ADB0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [SIP] Further editorial nit in the bis draft




Not mentioning it is not sufficient. 

If you don't want to allow this, then

add a "MUST NOT" regarding sending a BYE

before the INVITE transaction has completed.




/sean




>-----Original Message-----

>From: Vijay Gurbani [mailto:vkg@lucent.com]

>Sent: Friday, April 27, 2001 10:48 AM

>To: Jonathan Rosenberg

>Cc: 'Sean Olson (EUS)'; 'sip@lists.bell-labs.com'

>Subject: Re: [SIP] Further editorial nit in the bis draft

>

>

>Jonathan Rosenberg wrote:

>[...]

>> sean>This is not what Jonathan is saying. He is referring to the

>> sean>possibility of sending a BYE *instead* of a CANCEL, not sending

>> sean>a BYE in the event a CANCEL crosses on the wire.

>> 

>> Everyone loves to put words into my mouth...

>> 

>> I was saying that the preferred approach is to send CANCEL 

>first, and then

>> iff you get a 200 OK anyway (which happens if the CANCEL and 

>200 OK pass 

>> on the wire) then send BYE. 

>

>Right on!

>

>I could spend some time and come up with time-line diagrams if 

>anyone is

>interested (or if you want them to go in the -04 bis).  But it 

>is simple 

>really: If after sending CANCEL, a UAC gets a 200 OK (INVITE), 

>ACK it and 

>send a BYE (remember: CANCEL has no effect on a UAS state 

>machine if it has 

>already sent a final response).

>

>If after sending a CANCEL, a UAC gets a non-2xx response to the INVITE,

>just ACK it; no need to send the BYE -- session was never established.

>

>> I was also saying we should keep "just send BYE" as a MAY. 

>Vijay seems to 

>> be saying we should not even mention that possibility.

>

>Right.  We should not even mention it; a MAY will lead to the 

>same ambiguity 

>we are facing now.

>

>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

>





------_=_NextPart_001_01C0CF33.71A7ADB0--

_______________________________________________
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 Apr 27 12:07:44 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07002
	for ; Fri, 27 Apr 2001 12:07:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 02DE8443D8; Fri, 27 Apr 2001 12:03:11 -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 CFD9444395
	for ; Fri, 27 Apr 2001 12:02:24 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Apr 27 11:59:02 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 0882244380; Fri, 27 Apr 2001 11:48:15 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id BA2A74437D
	for ; Fri, 27 Apr 2001 11:48:14 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA10310; Fri, 27 Apr 2001 10:48:11 -0500
Cc: "'Sean Olson (EUS)'" ,
        "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA10292; Fri, 27 Apr 2001 10:48:10 -0500
Message-ID: <3AE994B4.B02F8479@lucent.com>
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 
Original-CC: "'Sean Olson (EUS)'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
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: Fri, 27 Apr 2001 10:48:04 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> sean>This is not what Jonathan is saying. He is referring to the
> sean>possibility of sending a BYE *instead* of a CANCEL, not sending
> sean>a BYE in the event a CANCEL crosses on the wire.
> 
> Everyone loves to put words into my mouth...
> 
> I was saying that the preferred approach is to send CANCEL first, and then
> iff you get a 200 OK anyway (which happens if the CANCEL and 200 OK pass 
> on the wire) then send BYE. 

Right on!

I could spend some time and come up with time-line diagrams if anyone is
interested (or if you want them to go in the -04 bis).  But it is simple 
really: If after sending CANCEL, a UAC gets a 200 OK (INVITE), ACK it and 
send a BYE (remember: CANCEL has no effect on a UAS state machine if it has 
already sent a final response).

If after sending a CANCEL, a UAC gets a non-2xx response to the INVITE,
just ACK it; no need to send the BYE -- session was never established.

> I was also saying we should keep "just send BYE" as a MAY. Vijay seems to 
> be saying we should not even mention that possibility.

Right.  We should not even mention it; a MAY will lead to the same ambiguity 
we are facing now.

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

_______________________________________________
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 Apr 27 12:24:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07601
	for ; Fri, 27 Apr 2001 12:24:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2CC144380; Fri, 27 Apr 2001 12:24:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 7720C44372
	for ; Fri, 27 Apr 2001 12:23:29 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBC91V>; Fri, 27 Apr 2001 09:23:51 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Vijay Gurbani'" ,
        Jonathan Rosenberg 
Cc: "'Sean Olson (EUS)'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF36.714736D0"
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, 27 Apr 2001 09:23:50 -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_01C0CF36.714736D0
Content-Type: text/plain;
	charset="iso-8859-1"

Just thought I'd butt in. 

While we are at it: we should put into the bis that a UA or proxy MAY
receive multiple 200 OK's and really MUST be able to handle them. 

Consider a forking proxy where two or more branches pickup at the same time
(eg both connected to automated answering services). Both branches will send
200 OK's and neither can be CANCELLED by the forking proxy. So the bis text
should describe the situation and the fact that the proxy MUST pass both 200
OK's back to the UA (violating the rule that the proxy can only return a
single final response). The UA should send an ACK & BYE to the 200 OK callee
it does not want. This should also be described in the bis. 

[In my mind it would make things cleaner if the proxy just BYE'd the
subsequent 200 OK's but I'm sure that won't be a popular suggestion given
that proxies aren't supposed to send BYE's. On the other hand, they're not
supposed to send multiple final responses either and I think that is a
greater evil.]

Regards,

Robert.

-----Original Message-----
From:	Vijay Gurbani [mailto:vkg@lucent.com]
Sent:	Friday, April 27, 2001 4:48 PM
To:	Jonathan Rosenberg
Cc:	'Sean Olson (EUS)'; 'sip@lists.bell-labs.com'
Subject:	Re: [SIP] Further editorial nit in the bis draft

Jonathan Rosenberg wrote:
[...]
> sean>This is not what Jonathan is saying. He is referring to the
> sean>possibility of sending a BYE *instead* of a CANCEL, not sending
> sean>a BYE in the event a CANCEL crosses on the wire.
> 
> Everyone loves to put words into my mouth...
> 
> I was saying that the preferred approach is to send CANCEL first, and then
> iff you get a 200 OK anyway (which happens if the CANCEL and 200 OK pass 
> on the wire) then send BYE. 

Right on!

I could spend some time and come up with time-line diagrams if anyone is
interested (or if you want them to go in the -04 bis).  But it is simple 
really: If after sending CANCEL, a UAC gets a 200 OK (INVITE), ACK it and 
send a BYE (remember: CANCEL has no effect on a UAS state machine if it has 
already sent a final response).

If after sending a CANCEL, a UAC gets a non-2xx response to the INVITE,
just ACK it; no need to send the BYE -- session was never established.

> I was also saying we should keep "just send BYE" as a MAY. Vijay seems to 
> be saying we should not even mention that possibility.

Right.  We should not even mention it; a MAY will lead to the same ambiguity

we are facing now.

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

_______________________________________________
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_01C0CF36.714736D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Further editorial nit in the bis draft




Just thought I'd butt in. 




While we are at it: we should put into =
the bis that a UA or proxy MAY receive multiple 200 OK's and really =
MUST be able to handle them. 



Consider a forking proxy where two or =
more branches pickup at the same time (eg both connected to automated =
answering services). Both branches will send 200 OK's and neither can =
be CANCELLED by the forking proxy. So the bis text should describe the =
situation and the fact that the proxy MUST pass both 200 OK's back to =
the UA (violating the rule that the proxy can only return a single =
final response). The UA should send an ACK & BYE to the 200 OK =
callee it does not want. This should also be described in the bis. =




[In my mind it would make things =
cleaner if the proxy just BYE'd the subsequent 200 OK's but I'm sure =
that won't be a popular suggestion given that proxies aren't supposed =
to send BYE's. On the other hand, they're not supposed to send multiple =
final responses either and I think that is a greater evil.]



Regards,




Robert.




-----Original =
Message-----

From:   Vijay Gurbani =
[mailto:vkg@lucent.com]

Sent:   Friday, April 27, 2001 4:48 PM

To:     Jonathan Rosenberg

Cc:     'Sean Olson (EUS)'; 'sip@lists.bell-labs.com'

Subject:       =
 Re: [SIP] Further editorial nit in =
the bis draft




Jonathan Rosenberg wrote:

[...]

> sean>This is not what =
Jonathan is saying. He is referring to the

> sean>possibility of sending a =
BYE *instead* of a CANCEL, not sending

> sean>a BYE in the event a =
CANCEL crosses on the wire.

> 

> Everyone loves to put words into =
my mouth...

> 

> I was saying that the preferred =
approach is to send CANCEL first, and then

> iff you get a 200 OK anyway =
(which happens if the CANCEL and 200 OK pass 

> on the wire) then send BYE. =





Right on!




I could spend some time and come up =
with time-line diagrams if anyone is

interested (or if you want them to go =
in the -04 bis).  But it is simple 

really: If after sending CANCEL, a =
UAC gets a 200 OK (INVITE), ACK it and 

send a BYE (remember: CANCEL has no =
effect on a UAS state machine if it has 

already sent a final response).=





If after sending a CANCEL, a UAC gets =
a non-2xx response to the INVITE,

just ACK it; no need to send the BYE =
-- session was never established.




> I was also saying we should keep =
"just send BYE" as a MAY. Vijay seems to 

> be saying we should not even =
mention that possibility.




Right.  We should not even =
mention it; a MAY will lead to the same ambiguity 

we are facing now.




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




_______________________________________________

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_01C0CF36.714736D0--

_______________________________________________
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 Apr 27 12:47:19 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08167
	for ; Fri, 27 Apr 2001 12:47: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 353B244361; Fri, 27 Apr 2001 12:47:04 -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 4B58744339
	for ; Fri, 27 Apr 2001 12:46:01 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA05039;
	Fri, 27 Apr 2001 12:49:30 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 12:45:53 -0400
Message-ID: 
From: Igor Slepchin 
To: Jonathan Rosenberg ,
        "'Sean Olson (EUS)'" ,
        "'Vijay Gurbani'" 
Cc: "Christer Holmberg (LMF)" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Further editorial nit in the bis draft
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, 27 Apr 2001 12:45:52 -0400

Well, the original motivation for sending a BYE instead of a CANCEL to
terminate call setup was PSTN connectivity, since PSTN gateways may
apparently want to send ISUP in SIP call termination messaging. 

With CANCELs being hop by hop and the note in 8.1 specifically prohibiting
sending payloads in CANCELs, it was somehow assumed that they are not suited
for conveying that ISUP payload. I never really bought into that argument so
I am fine with the proposed wording. However, at this point it may become a
compatibility issue if lots of folks have already implemented sending the
BYE. I'd recommend saying that UASs should be prepared to receive either a
BYE or a CANCEL but UACs SHOULD send a CANCEL and only BYE the 200 responses
if any.

---
Igor Slepchin


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, April 27, 2001 11:21 AM
> To: 'Sean Olson (EUS)'; 'Vijay Gurbani'; Jonathan Rosenberg
> Cc: Christer Holmberg (LMF); 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Further editorial nit in the bis draft
> 
> 
> 
> 
>   
> -----Original Message-----
> From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
> Sent: Friday, April 27, 2001 11:02 AM
> To: 'Vijay Gurbani'; Jonathan Rosenberg
> Cc: Christer Holmberg (LMF); 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Further editorial nit in the bis draft
> 
> >>Jonathan: 
> >> 
> >>I misinterpret many thing, but definitely not this one :-)  In 
> >>some earlier 
> >>posting, I made the same point: a BYE should be sent after a 
> >>CANCEL iff 
> >>the 200 OK (INVITE) from the UAS and the CANCEL pass each 
> >>other on the wire. 
> >
> >This is not what Jonathan is saying. He is referring to the 
> >possibility of sending a BYE *instead* of a CANCEL, not sending 
> >a BYE in the event a CANCEL crosses on the wire. 
> 
> Everyone loves to put words into my mouth...
> 
> I was saying that the preferred approach is to send CANCEL 
> first, and then
> iff you get a 200 OK anyway (which happens if the CANCEL and 
> 200 OK pass on
> the wire) then send BYE. I was also saying we should keep 
> "just send BYE" as
> a MAY. Vijay seems to be saying we should not even mention 
> that possibility.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       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
> 
> _______________________________________________
> 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  Fri Apr 27 13:13:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08877
	for ; Fri, 27 Apr 2001 13:13:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D7D7144380; Fri, 27 Apr 2001 13:13:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by lists.bell-labs.com (Postfix) with ESMTP id 96FAC44361
	for ; Fri, 27 Apr 2001 13:12:25 -0400 (EDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f3RHCRb04014
	for ; Fri, 27 Apr 2001 13:12:27 -0400 (EDT)
Message-Id: <200104271712.f3RHCRb04014@flyingfox.snowshore.com>
From: Eric Burger 
To: sip@lists.bell-labs.com
Subject: RE:  [SIP] Join as replacement for DTMF/voice-forking.
X-Mailer: CorporateTime Outlook Connector 3.0
MIME-Version: 1.0
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, 27 Apr 2001 17:12:00 GMT
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA08877

Note that the media does not necessarily have to go to the AS.  In fact, it's probably a bad idea for the reasons you list below.

A more scalable approach is to use a media server, and have the media server report the DTMF events to the AS, either through http (as in draft-rosenberg-sip-app-components), SIP INFO [no flames, please], or RFC 2833.

 +--------+   SIP   +------+
 |Caller/ |-------->|  AS  |
 |  GW    |         +------+
 +--------+          ^
         \          /
          \RTP     / SIP | SIP+http | SIP+RFC 2833
           \      /
            V    V
           +------+
           |  MS  |
           +------+

The media server does the media lifting for the application server, such as playing prompts and collecting digits, while the application server does the application heavy lifting, such as data base lookup, verification, etc.

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Fairlie-Cuninghame, Robert
Sent: Friday, April 27, 2001 10:46 AM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi again,

The Join approach could provide a good reason to stick with the SDP vocoder set behaviour decided at the last IETF meeting rather than what was being bandied about on the list.

If you want to do DTMF monitoring and non-disruptive voice announcements from an AS to a SIP session (eg calling card service as previously discussed), then you will want to receive only the DTMF stream and send voice. [An AS will not usually want to receive the voice traffic all the time due to loading issues - I know people are talking about voice recognition but this is normally when the caller is connected to AS not all the time, right?] 

Now the voice and DTMF are normally syncronized in the same SDP m= line - possibly causing problems. This is not a problem if each side only saying what it is willing to recieve - NOT send and receive. That is, the UA would put that it can recieve both voice and DTMF (as normal) and the AS would indicate that it can only receive DTMF. 

However, thanks to the flexibility of the Join header  it will work even if we go with the send-and-receive SDP vocoder defintion. Instead you would just send two INVITE's with Join headers: one specifying "a=recvonly" listing the DTMF vocoder and the other specifying "a=sendonly" with the voice coder.

Regards,

Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi Steve,

Thanks for your comment.

Pretty much everything can be done as a B2BUA and I agree with you: until UA's with REFER &  Replaces capability are widely deployed, then B2BUA is pretty much the only way to accomplish many of the "advanced call control" features in an hetrogenous/non-controlled SIP network (IMO). However, unfortuately a B2BUA does not help in the scenario described in this thread. 

A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The Application (or some related RTP processing/splitting/forwarding entity) could process the media for every call for the entire duration of the call [for common usage scenario]. However, I don't beleive this is generally a scalable solution. I don't think you are denying that the features being discussed are not very important to people wishing to provide calling-card style services (non-disruptive in-call warnigns and announcements, media triggered events such as triple # for call follow-on/return, etc).

For "Join" to work, one of the endpoints must support the Join header - just like REFER you cannot guarantee every UA will implement this. This is the same for the existing SDP-based stream forking behavior. I don't see that this is a problem specific to this suggestion but rather a general problem for adding extensions - not everyone is going to implement every extension. This is not a reason to stop publishing extensions (which I'm sure you are not debating). 

However, that does bring up a good advantage to this Join approach. IMO, it is seems much easier for many PSTN-gateway based calling card services to control the features supported by just _one_ of the UA's involved in a call (usually the gateway). However, it may not always be the caller, for instance, in a "PC to Phone" application where the client is located on a "plain-vanilla" SIP client on the internet. In this case it might be usefull to allow the Join header to be sent to the callee (the gateway) and specify that the Join is only towards the remote party. (So the Join header options become "local", "remote", or "full" mixing). This facility is not possible with the current SDP-based stream forking approach.

To me this seems such a flexible, easy and clean way of achieving this functionality.

Robert.
-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!

At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of these
3 variants is most cost effective might well be service-provider dependent.

I agree that control over "full or local" mixing is important to support a 
calling card service.


_______________________________________________
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 Apr 27 13:26:16 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09217
	for ; Fri, 27 Apr 2001 13:26: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 69C6244390; Fri, 27 Apr 2001 13:26:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 74AF844361
	for ; Fri, 27 Apr 2001 13:25:31 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBC9NF>; Fri, 27 Apr 2001 10:25:53 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Eric Burger'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CF3F.1B36A830"
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, 27 Apr 2001 10:25:51 -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_01C0CF3F.1B36A830
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Eric,

The problem is not when the caller (which may or may not be coming in
through a local gateway) is "talking" to the AS (through the media server).
The problems occur when the caller is talking to a third party. So voice +
DTMF RTP needs to go between the caller and third-party but the AS (through
media server or whatever) still needs to be able to a react to some
"triggers" (in my example, DTMF events) or play prompts to the Caller while
they are having a converstation with the third-party (eg, "You have one
minute remaining"). This is what I consider a "typical" pre-paid calling
card scenario. 

Robert.

-----Original Message-----
From:	Eric Burger [mailto:eburger@snowshore.com]
Sent:	Friday, April 27, 2001 6:12 PM
To:	sip@lists.bell-labs.com
Subject:	RE:  [SIP] Join as replacement for DTMF/voice-forking.

Note that the media does not necessarily have to go to the AS.  In fact,
it's probably a bad idea for the reasons you list below.

A more scalable approach is to use a media server, and have the media server
report the DTMF events to the AS, either through http (as in
draft-rosenberg-sip-app-components), SIP INFO [no flames, please], or RFC
2833.

 +--------+   SIP   +------+
 |Caller/ |-------->|  AS  |
 |  GW    |         +------+
 +--------+          ^
         \          /
          \RTP     / SIP | SIP+http | SIP+RFC 2833
           \      /
            V    V
           +------+
           |  MS  |
           +------+

The media server does the media lifting for the application server, such as
playing prompts and collecting digits, while the application server does the
application heavy lifting, such as data base lookup, verification, etc.

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On
Behalf Of Fairlie-Cuninghame, Robert
Sent: Friday, April 27, 2001 10:46 AM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi again,

The Join approach could provide a good reason to stick with the SDP vocoder
set behaviour decided at the last IETF meeting rather than what was being
bandied about on the list.

If you want to do DTMF monitoring and non-disruptive voice announcements
from an AS to a SIP session (eg calling card service as previously
discussed), then you will want to receive only the DTMF stream and send
voice. [An AS will not usually want to receive the voice traffic all the
time due to loading issues - I know people are talking about voice
recognition but this is normally when the caller is connected to AS not all
the time, right?] 

Now the voice and DTMF are normally syncronized in the same SDP m= line -
possibly causing problems. This is not a problem if each side only saying
what it is willing to recieve - NOT send and receive. That is, the UA would
put that it can recieve both voice and DTMF (as normal) and the AS would
indicate that it can only receive DTMF. 

However, thanks to the flexibility of the Join header  it will work
even if we go with the send-and-receive SDP vocoder defintion. Instead you
would just send two INVITE's with Join headers: one specifying "a=recvonly"
listing the DTMF vocoder and the other specifying "a=sendonly" with the
voice coder.

Regards,

Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi Steve,

Thanks for your comment.

Pretty much everything can be done as a B2BUA and I agree with you: until
UA's with REFER &  Replaces capability are widely deployed, then B2BUA is
pretty much the only way to accomplish many of the "advanced call control"
features in an hetrogenous/non-controlled SIP network (IMO). However,
unfortuately a B2BUA does not help in the scenario described in this thread.


A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The
Application (or some related RTP processing/splitting/forwarding entity)
could process the media for every call for the entire duration of the call
[for common usage scenario]. However, I don't beleive this is generally a
scalable solution. I don't think you are denying that the features being
discussed are not very important to people wishing to provide calling-card
style services (non-disruptive in-call warnigns and announcements, media
triggered events such as triple # for call follow-on/return, etc).

For "Join" to work, one of the endpoints must support the Join header - just
like REFER you cannot guarantee every UA will implement this. This is the
same for the existing SDP-based stream forking behavior. I don't see that
this is a problem specific to this suggestion but rather a general problem
for adding extensions - not everyone is going to implement every extension.
This is not a reason to stop publishing extensions (which I'm sure you are
not debating). 

However, that does bring up a good advantage to this Join approach. IMO, it
is seems much easier for many PSTN-gateway based calling card services to
control the features supported by just _one_ of the UA's involved in a call
(usually the gateway). However, it may not always be the caller, for
instance, in a "PC to Phone" application where the client is located on a
"plain-vanilla" SIP client on the internet. In this case it might be usefull
to allow the Join header to be sent to the callee (the gateway) and specify
that the Join is only towards the remote party. (So the Join header options
become "local", "remote", or "full" mixing). This facility is not possible
with the current SDP-based stream forking approach.

To me this seems such a flexible, easy and clean way of achieving this
functionality.

Robert.
-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!

At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF
recognition.
In that case one could imagine implementing a B2BUA (with associated 
media processing) that can do this "in the network" with join as suggested 
or simply implementing the service in it's entirety at a B2BUA. Which of
these
3 variants is most cost effective might well be service-provider dependent.

I agree that control over "full or local" mixing is important to support a 
calling card service.


_______________________________________________
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_01C0CF3F.1B36A830
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Join as replacement for DTMF/voice-forking.




Hi Eric,




The problem is not when the caller =
(which may or may not be coming in through a local gateway) is =
"talking" to the AS (through the media server). The problems occur when =
the caller is talking to a third party. So voice + DTMF RTP needs to go =
between the caller and third-party but the AS (through media server or =
whatever) still needs to be able to a react to some "triggers" (in my =
example, DTMF events) or play prompts to the Caller while they are =
having a converstation with the third-party (eg, "You have one minute =
remaining"). This is what I consider a "typical" pre-paid calling card =
scenario. 



Robert.




-----Original =
Message-----

From:   Eric Burger [mailto:eburger@snowshore.com]<=
/FONT>

Sent:   Friday, April 27, 2001 6:12 PM

To:     sip@lists.bell-labs.com

Subject:       =
 RE:  [SIP] Join as replacement =
for DTMF/voice-forking.




Note that the media does not =
necessarily have to go to the AS.  In fact, it's probably a bad =
idea for the reasons you list below.



A more scalable approach is to use a =
media server, and have the media server report the DTMF events to the =
AS, either through http (as in draft-rosenberg-sip-app-components), SIP =
INFO [no flames, please], or RFC 2833.



 +--------+   =
SIP   +------+

 |Caller/ |-------->|  =
AS  |

 |  GW    =
|         +------+

 +--------+       =
;   ^

         =
\          /

          =
\RTP     / SIP | SIP+http | SIP+RFC 2833

         &nb=
sp; \      /

         &nb=
sp;  V    V

         &nb=
sp; +------+

         &nb=
sp; |  MS  |

         &nb=
sp; +------+




The media server does the media =
lifting for the application server, such as playing prompts and =
collecting digits, while the application server does the application =
heavy lifting, such as data base lookup, verification, etc.



-----Original Message-----

From: sip-admin@lists.bell-labs.com =
[mailto:sip-admin@lists.bel=
l-labs.com]On Behalf Of Fairlie-Cuninghame, Robert

Sent: Friday, April 27, 2001 10:46 =
AM

To: 'Steve Gardell'; =
'sip@lists.bell-labs.com'

Subject: RE: [SIP] Join as =
replacement for DTMF/voice-forking.






Hi again,




The Join approach could provide a good =
reason to stick with the SDP vocoder set behaviour decided at the last =
IETF meeting rather than what was being bandied about on the =
list.



If you want to do DTMF monitoring and =
non-disruptive voice announcements from an AS to a SIP session (eg =
calling card service as previously discussed), then you will want to =
receive only the DTMF stream and send voice. [An AS will not usually =
want to receive the voice traffic all the time due to loading issues - =
I know people are talking about voice recognition but this is normally =
when the caller is connected to AS not all the time, right?] =




Now the voice and DTMF are normally =
syncronized in the same SDP m=3D line - possibly causing problems. This =
is not a problem if each side only saying what it is willing to recieve =
- NOT send and receive. That is, the UA would put that it can recieve =
both voice and DTMF (as normal) and the AS would indicate that it can =
only receive DTMF. 



However, thanks to the flexibility of =
the Join header <grin> it will work even if we go with the =
send-and-receive SDP vocoder defintion. Instead you would just send two =
INVITE's with Join headers: one specifying "a=3Drecvonly" =
listing the DTMF vocoder and the other specifying =
"a=3Dsendonly" with the voice coder.



Regards,




Robert.




-----Original Message-----

From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]=


Sent: Thursday, April 26, 2001 3:38 =
PM

To: 'Steve Gardell'; =
'sip@lists.bell-labs.com'

Subject: RE: [SIP] Join as =
replacement for DTMF/voice-forking.






Hi Steve,




Thanks for your comment.




Pretty much everything can be done as =
a B2BUA and I agree with you: until UA's with REFER &  =
Replaces capability are widely deployed, then B2BUA is pretty much the =
only way to accomplish many of the "advanced call control" =
features in an hetrogenous/non-controlled SIP network (IMO). However, =
unfortuately a B2BUA does not help in the scenario described in this =
thread. 



A B2BUA cannot inherently cause a =
_normal_ UA to fork or mix the media. The Application (or some related =
RTP processing/splitting/forwarding entity) could process the media for =
every call for the entire duration of the call [for common usage =
scenario]. However, I don't beleive this is generally a scalable =
solution. I don't think you are denying that the features being =
discussed are not very important to people wishing to provide =
calling-card style services (non-disruptive in-call warnigns and =
announcements, media triggered events such as triple # for call =
follow-on/return, etc).



For "Join" to work, one of =
the endpoints must support the Join header - just like REFER you cannot =
guarantee every UA will implement this. This is the same for the =
existing SDP-based stream forking behavior. I don't see that this is a =
problem specific to this suggestion but rather a general problem for =
adding extensions - not everyone is going to implement every extension. =
This is not a reason to stop publishing extensions (which I'm sure you =
are not debating). 



However, that does bring up a good =
advantage to this Join approach. IMO, it is seems much easier for many =
PSTN-gateway based calling card services to control the features =
supported by just _one_ of the UA's involved in a call (usually the =
gateway). However, it may not always be the caller, for instance, in a =
"PC to Phone" application where the client is located on a =
"plain-vanilla" SIP client on the internet. In this case it =
might be usefull to allow the Join header to be sent to the callee (the =
gateway) and specify that the Join is only towards the remote party. =
(So the Join header options become "local", =
"remote", or "full" mixing). This facility is not =
possible with the current SDP-based stream forking approach.



To me this seems such a flexible, easy =
and clean way of achieving this functionality.




Robert.

-----Original Message-----

From: Steve Gardell [mailto:sgardell@iperia.com]

Sent: Thursday, April 26, 2001 1:05 =
PM

To: 'Fairlie-Cuninghame, Robert'; =
'sip@lists.bell-labs.com'

Subject: RE: [SIP] Join as =
replacement for DTMF/voice-forking.






The additional discussion really helps =
for those of us who don't

have the several hours a day it takes =
to really keep up on the SIP list!




At any rate, one concern - probably =
with both models - is that we can't

make the assumption that all gateways =
are willing to "invest" in the

additional DSP to support mixing or, =
for that matter, mid-call DTMF recognition.

In that case one could imagine =
implementing a B2BUA (with associated 

media processing) that can do this =
"in the network" with join as suggested 

or simply implementing the service in =
it's entirety at a B2BUA. Which of these

3 variants is most cost effective =
might well be service-provider dependent.




I agree that control over "full =
or local" mixing is important to support a 

calling card service.






_______________________________________________

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_01C0CF3F.1B36A830--

_______________________________________________
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 Apr 27 13:36:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09406
	for ; Fri, 27 Apr 2001 13:36: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 E0AE2443E7; Fri, 27 Apr 2001 13:36:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by lists.bell-labs.com (Postfix) with ESMTP id 8DF85443E5
	for ; Fri, 27 Apr 2001 13:35:26 -0400 (EDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f3RHZSb04354
	for ; Fri, 27 Apr 2001 13:35:28 -0400 (EDT)
Message-Id: <200104271735.f3RHZSb04354@flyingfox.snowshore.com>
From: Eric Burger 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.
X-Mailer: CorporateTime Outlook Connector 3.0
MIME-Version: 1.0
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, 27 Apr 2001 17:35:00 GMT
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09406

If the calling user agent supports forking, then JOIN might work, but why not just have the application server INVITE into the call as a conference with an m= line for RFC 2833?  That doesn't require any changes to SIP.  It does require the UA/GW to support RFC 2833 "media", as well as supporting a micro conference consisting of the two voice parties and the RFC 2833, sendonly, application server party.  If the calling user agent supports forking, it may as well support it in the straight-forward way.

Likewise, the existing 3pcc proposals describe how to break-in and play prompts.  Looking at real implementations, you can put the called party on hold while you prompt the caller.  If you want "whisper-in-your-ear" to the caller, you'll probably either want to run the whole call through a media server or re-invite the entire call to the media server for the prompting sequence.


-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 27, 2001 1:25 PM
To: 'Eric Burger'; sip@lists.bell-labs.com
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi Eric, 
The problem is not when the caller (which may or may not be coming in through a local gateway) is "talking" to the AS (through the media server). The problems occur when the caller is talking to a third party. So voice + DTMF RTP needs to go between the caller and third-party but the AS (through media server or whatever) still needs to be able to a react to some "triggers" (in my example, DTMF events) or play prompts to the Caller while they are having a converstation with the third-party (eg, "You have one minute remaining"). This is what I consider a "typical" pre-paid calling card scenario. 
Robert. 


_______________________________________________
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 Apr 27 13:40:14 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09500
	for ; Fri, 27 Apr 2001 13:40:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 388F0443F5; Fri, 27 Apr 2001 13:36:12 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 913C0443E5
	for ; Fri, 27 Apr 2001 13:35:55 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Apr 27 13:35:17 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id DBDD544380; Fri, 27 Apr 2001 13:22:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.1.218.156])
	by lists.bell-labs.com (Postfix) with SMTP id 97CB54437D
	for ; Fri, 27 Apr 2001 13:22:01 -0400 (EDT)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA28356; Fri, 27 Apr 2001 12:21:58 -0500
Cc: "'sip@lists.bell-labs.com'" 
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA28336; Fri, 27 Apr 2001 12:21:55 -0500
Message-ID: <3AE9AAAE.9DA990D2@lucent.com>
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: "Fairlie-Cuninghame, Robert" 
Original-CC: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
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: Fri, 27 Apr 2001 12:21:50 -0500
Content-Transfer-Encoding: 7bit

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Just thought I'd butt in.

Welcome to the party :-)

> While we are at it: we should put into the bis that a UA or proxy MAY 
> receive multiple 200 OK's and really MUST be able to handle them.
> 
> Consider a forking proxy where two or more branches pickup at the same 
> time (eg both connected to automated answering services). Both branches 
> will send 200 OK's and neither can be CANCELLED by the forking proxy. 

Actually, they can be CANCELled by the proxy, except the CANCEL has no
effect on the UAS since it has already generated a final response.

> So the bis text should describe the situation and the fact that the proxy 
> MUST pass both 200 OK's back to the UA (violating the rule that the proxy 
> can only return a single final response). 

The bis does attempt to describe this (in a somewhat obfuscated manner -- 
you have to read between the lines).  It makes a distinction between 2xx 
responses to INVITE and non-2xx responses (see Section 12.4, -02 bis).  2xx 
responses (as many as the proxy sees) to INVITEs MUST be forwarded upstream 
immideately.  On the other hand, a proxy returns a single (best) final 
response IFF ALL the branches have reported a final response AND none of 
these responses was a 2xx response.

> The UA should send an ACK & BYE to the 200 OK callee it does not want. 
> This should also be described in the bis.

The -02 bis has text to this effect in Section 16.5 (not where you would
normally look for it).  For the PDF version, see page 106 - towards the
bottom. 

> [In my mind it would make things cleaner if the proxy just BYE'd the
> subsequent 200 OK's but I'm sure that won't be a popular suggestion given 
> that proxies aren't supposed to send BYE's. 

I won't even touch this :-)

- 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

_______________________________________________
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 Apr 27 16:47:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15467
	for ; Fri, 27 Apr 2001 16:47: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 0138C44339; Fri, 27 Apr 2001 16:47: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 CEC2C44338
	for ; Fri, 27 Apr 2001 16:46:04 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08826
	for ; Fri, 27 Apr 2001 16:49:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 27 Apr 2001 16:46:04 -0400
Message-ID: 
From: Jonathan Rosenberg 
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] meaning of IP address in SDP
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, 27 Apr 2001 16:46:04 -0400

Folks,

There appears to be some continuing confusion about the interpretation of
the IP address in the SDP of an INVITE or 200 OK.

When user A sends an INVITE with SDP, and the stream is sendrecv (which is
the default), the IP address in the c line for that stream is the address
where A expects to receive media for that stream. It DOES NOT imply that the
source address of media that A sends will be equal to that IP address. The
source IP address is chosen by the underlying OS based on its routing
tables. As such, a multihomed host has no way to know what the source
address of its RTP packets will be, until it actually tries to send them.
So, clearly, the IP address in the c line in the INVITE cannot possibly be
the source address, since A doesn't even know yet where it will send
packets.

Unfortunately, since rfc2543 does not explicitly say that the source address
won't be the address in the c line, several implementations appear to have
assumed that it will be. I want to make sure we are clear that this
assumption is false.

Please, in your implementations, do not make any assumptions about the
source address of media.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       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
 

_______________________________________________
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 Apr 27 17:36:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16794
	for ; Fri, 27 Apr 2001 17:36:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B2D7244339; Fri, 27 Apr 2001 17:36:03 -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 6D33944338
	for ; Fri, 27 Apr 2001 17:35:23 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA28445;
	Fri, 27 Apr 2001 17:34:19 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AEO16992 (AUTH shbhatna);
	Fri, 27 Apr 2001 17:35:21 -0400 (EDT)
Message-ID: <3AE9E61A.843B6E10@cisco.com>
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] precedence rules for Route, maddr, and R-URI hostname
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: Fri, 27 Apr 2001 17:35:22 -0400
Content-Transfer-Encoding: 7bit

Jonathan,  One question related to
this description. If a user agent
is configured to use its local outbound
proxy, does it send entire Route list
(formed from Record-Route and Contact
in 200) to its proxy in the ACK ?
Or is the user agent supposed to use
the Route list (and pop topmost entry), 
once the signaling path is established ?

Also, I am trying to think when
would a proxy receive a request
without Route header, maddr of
req-uri is proxy but host portion of
req-uri is not proxy.


Thanks,
Shail


Jonathan Rosenberg wrote:
> 
> Folks,
> 
> We need to finally come to conclusion on this nagging problem of the
> precedence rules for the Route header, R-URI maddr, and R-URI hostname.
> Specifically, when a proxy receives a request, what is the processing it
> uses to determine how to route it? The issue is linked with a bunch of very
> related ones, such as how we handle local-outbound proxies for hosts that
> have no DNS.
> 
> Like any problem, we need some requirements for this solution:
> 
> 1. a proxy should not need to know that it is a local-outbound proxy for the
> upstream element (which can be a UA or proxy), for this to work
> 2. Ideally, a subsequent request in a call should follow the path of proxies
> which record routed.
> 3. the solution should work correctly in the face of spirals
> 
> To proceed, I am going to make a strawman. Lets work from this, and proceed
> by having people point out issues or problems with this solution, rather
> than proposing completely new ones.
> 
> Strawman
> --------
> 
> when a proxy receives a request, it checks for the existence of a Route
> header. If one exists, that Route header is popped, and placed into the
> request URI. It is then sent using the procedures of draft-ietf-sip-srv. If
> no route header is present, the proxy examines the request URI. If it
> contains an maddr, and this maddr is not an interface that the proxy is
> listening on, the proxy forwards the request using the procedures of
> draft-ietf-sip-srv on the request URI (this will cause it to be forwarded to
> the address in the maddr). If the maddr is present, but is an interface the
> proxy is listening on, the maddr is stripped, and processing proceeds as if
> it were never there. If there was no maddr, and the domain of the request
> URI is not a domain the proxy is managing, the procedures of
> draft-ietf-sip-srv are used to forward the request to that URI. If the
> domain is one the proxy is managing, the request is processed.
> 
> Consider a UA which uses a pre-configured local outbound proxy. It sends an
> INVITE, and then wishes to send a request for the same call leg. If it has
> obtained a route set for this call leg, it SHOULD pop the top route entry,
> place it into the request URI, and use that to forward the request. If the
> proxy is not DNS capable, it MAY alternatively place the entire route set
> into Route headers (not popping the top URI). It sets the request URI to the
> same value it used for the initial INVITE, and sends it to its local
> outbound proxy.
> 
> One more thing we would need for this to work. The URI placed into the RR
> header MUST be unique for each unique request URI in the incoming request,
> but must not equal the URI of the incoming request (adding an maddr is fine,
> for example. So, the current normal behavior of copying the R-URI userhost
> into RR, and adding your own port and maddr, meets the requirement). The
> important implication of this is that when a proxy record-routes through a
> spiral, the URI in the RR needs to be different each time through the
> spiral.
> 
> This approach solves all of the problems that have been pointed out, I
> think:
> 
> 1. Lets say proxy X is a local outbound proxy for some UA Y, and Y doesn't
> do DNS. So, when X sends a re-INVITE, it doesn't pop the top route header.
> This request shows up at X. Since there is a Route header, X pops it, and
> forwards it there. Of course, thats back to itself. However, this is a
> SPIRAL, since the incoming request URI is guaranteed not to be the same as
> the URI in the top Route. So, it looks at the request again, and if there is
> a Route, sends it on its way. Of course, a smart proxy could simply notice
> this condition and not actually send it to itself.
> 
> 2. When using Route headers through a spiral, the request URI at each point
> in the spiral is guaranteed to be just as unique as the original request was
> through the set of proxies. This means that if the origina R-URI was
> different when received twice at the same proxy, the R-URI from Route will
> be different two. So, the case that Robert raised, where the requests will
> appear as loops, won't happen.
> 
> Comments?
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       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
> 
> 
> _______________________________________________
> 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  Fri Apr 27 17:48:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17254
	for ; Fri, 27 Apr 2001 17:48:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2903F443D2; Fri, 27 Apr 2001 17:48:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33])
	by lists.bell-labs.com (Postfix) with ESMTP id 469AD44339
	for ; Fri, 27 Apr 2001 17:47:40 -0400 (EDT)
Received: from email.masconit.com ([12.41.17.214])
          by mail.inetmail.att.net (mtiagic01) with ESMTP
          id <20010427214738gi128291pqe>; Fri, 27 Apr 2001 21:47:39 +0000
Received: from ashok (RANJIT [12.41.17.196]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id JB7P3TK3; Fri, 27 Apr 2001 16:54:43 -0500
Message-ID: <009a01c0cf64$55db79a0$c411290c@masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Shail Bhatnagar" ,
        "Jonathan Rosenberg" 
Cc: 
References:  <3AE9E61A.843B6E10@cisco.com>
Subject: Re: [SIP] precedence rules for Route, maddr, and R-URI hostname
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.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
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, 27 Apr 2001 16:52:20 -0500
Content-Transfer-Encoding: 7bit

Hi
     I think if a user agent is configured to its local proxy then need not
send the entire route list to proxy in ACK,, be'se the proxy would
know the route....thru Record-Route header.

Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com






----- Original Message -----
From: Shail Bhatnagar 
To: Jonathan Rosenberg 
Cc: 
Sent: Friday, April 27, 2001 4:35 PM
Subject: Re: [SIP] precedence rules for Route, maddr, and R-URI hostname


Jonathan,  One question related to
this description. If a user agent
is configured to use its local outbound
proxy, does it send entire Route list
(formed from Record-Route and Contact
in 200) to its proxy in the ACK ?
Or is the user agent supposed to use
the Route list (and pop topmost entry),
once the signaling path is established ?

Also, I am trying to think when
would a proxy receive a request
without Route header, maddr of
req-uri is proxy but host portion of
req-uri is not proxy.


Thanks,
Shail


Jonathan Rosenberg wrote:
>
> Folks,
>
> We need to finally come to conclusion on this nagging problem of the
> precedence rules for the Route header, R-URI maddr, and R-URI hostname.
> Specifically, when a proxy receives a request, what is the processing it
> uses to determine how to route it? The issue is linked with a bunch of
very
> related ones, such as how we handle local-outbound proxies for hosts that
> have no DNS.
>
> Like any problem, we need some requirements for this solution:
>
> 1. a proxy should not need to know that it is a local-outbound proxy for
the
> upstream element (which can be a UA or proxy), for this to work
> 2. Ideally, a subsequent request in a call should follow the path of
proxies
> which record routed.
> 3. the solution should work correctly in the face of spirals
>
> To proceed, I am going to make a strawman. Lets work from this, and
proceed
> by having people point out issues or problems with this solution, rather
> than proposing completely new ones.
>
> Strawman
> --------
>
> when a proxy receives a request, it checks for the existence of a Route
> header. If one exists, that Route header is popped, and placed into the
> request URI. It is then sent using the procedures of draft-ietf-sip-srv.
If
> no route header is present, the proxy examines the request URI. If it
> contains an maddr, and this maddr is not an interface that the proxy is
> listening on, the proxy forwards the request using the procedures of
> draft-ietf-sip-srv on the request URI (this will cause it to be forwarded
to
> the address in the maddr). If the maddr is present, but is an interface
the
> proxy is listening on, the maddr is stripped, and processing proceeds as
if
> it were never there. If there was no maddr, and the domain of the request
> URI is not a domain the proxy is managing, the procedures of
> draft-ietf-sip-srv are used to forward the request to that URI. If the
> domain is one the proxy is managing, the request is processed.
>
> Consider a UA which uses a pre-configured local outbound proxy. It sends
an
> INVITE, and then wishes to send a request for the same call leg. If it has
> obtained a route set for this call leg, it SHOULD pop the top route entry,
> place it into the request URI, and use that to forward the request. If the
> proxy is not DNS capable, it MAY alternatively place the entire route set
> into Route headers (not popping the top URI). It sets the request URI to
the
> same value it used for the initial INVITE, and sends it to its local
> outbound proxy.
>
> One more thing we would need for this to work. The URI placed into the RR
> header MUST be unique for each unique request URI in the incoming request,
> but must not equal the URI of the incoming request (adding an maddr is
fine,
> for example. So, the current normal behavior of copying the R-URI userhost
> into RR, and adding your own port and maddr, meets the requirement). The
> important implication of this is that when a proxy record-routes through a
> spiral, the URI in the RR needs to be different each time through the
> spiral.
>
> This approach solves all of the problems that have been pointed out, I
> think:
>
> 1. Lets say proxy X is a local outbound proxy for some UA Y, and Y doesn't
> do DNS. So, when X sends a re-INVITE, it doesn't pop the top route header.
> This request shows up at X. Since there is a Route header, X pops it, and
> forwards it there. Of course, thats back to itself. However, this is a
> SPIRAL, since the incoming request URI is guaranteed not to be the same as
> the URI in the top Route. So, it looks at the request again, and if there
is
> a Route, sends it on its way. Of course, a smart proxy could simply notice
> this condition and not actually send it to itself.
>
> 2. When using Route headers through a spiral, the request URI at each
point
> in the spiral is guaranteed to be just as unique as the original request
was
> through the set of proxies. This means that if the origina R-URI was
> different when received twice at the same proxy, the R-URI from Route will
> be different two. So, the case that Robert raised, where the requests will
> appear as loops, won't happen.
>
> Comments?
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg                       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
>
>
> _______________________________________________
> 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@lists.bell-labs.com  Fri Apr 27 18:43:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18388
	for ; Fri, 27 Apr 2001 18:43:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3464C443B2; Fri, 27 Apr 2001 18:43:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 7B7B544339
	for ; Fri, 27 Apr 2001 18:42:05 -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 SAA25762;
	Fri, 27 Apr 2001 18:42:05 -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 SAA07740;
	Fri, 27 Apr 2001 18:42:02 -0400 (EDT)
Message-ID: <3AE97C1F.E93AB95E@cs.columbia.edu>
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Undery 
Cc: Jonathan Rosenberg ,
        SIP List 
Subject: Re: [SIP] Registration Authentication
References:  <3AE9447F.67D87498@ubiquity.net>
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: Fri, 27 Apr 2001 07:03:11 -0700
Content-Transfer-Encoding: 7bit

One solution is to simply register via SSL. Avoids these issues and
requires no SIP changes.

> One phrase "Man in the Middle", whatever your nonce lifetime is, even if it's
> based on the transaction, you are really vunerable.

As long as the server keeps a log of recent registrations (pretty
trivial, if it remembers the nonce for the last update), it can detect
replay attempts. Doesn't address modifications of the request by The
Man, but it's the only way to prevent short-period replay. (IPsec does
something that's very roughly similar.)



_______________________________________________
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 Apr 27 21:02:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21105
	for ; Fri, 27 Apr 2001 21:02:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 536FC44339; Fri, 27 Apr 2001 21:02:05 -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 D38F944338
	for ; Fri, 27 Apr 2001 21:01:46 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA02425;
	Fri, 27 Apr 2001 21:00:43 -0400 (EDT)
Received: from cisco.com ([161.44.109.7])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AES01666 (AUTH shbhatna);
	Fri, 27 Apr 2001 21:01:45 -0400 (EDT)
Message-ID: <3AEA08BA.6919476F@cisco.com>
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ranjit Avasarala 
Cc: Jonathan Rosenberg , sip@lists.bell-labs.com
Subject: Re: [SIP] precedence rules for Route, maddr, and R-URI hostname
References:  <3AE9E61A.843B6E10@cisco.com> <009a01c0cf64$55db79a0$c411290c@masconit.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: Fri, 27 Apr 2001 20:03:06 -0400
Content-Transfer-Encoding: 7bit

Are you saying that ACK will
identify the INVITE transaction and
proxy will route the ACK based on
transaction state/next hop ?
That would require the Request-uri
if ACK to be same as INVITE.

Ranjit Avasarala wrote:
> 
> Hi
>      I think if a user agent is configured to its local proxy then need not
> send the entire route list to proxy in ACK,, be'se the proxy would
> know the route....thru Record-Route header.
> 
> Regards
> Ranjit
> Mascon Communication Technologies
> http://www.masconit.com
> 
> ----- Original Message -----
> From: Shail Bhatnagar 
> To: Jonathan Rosenberg 
> Cc: 
> Sent: Friday, April 27, 2001 4:35 PM
> Subject: Re: [SIP] precedence rules for Route, maddr, and R-URI hostname
> 
> Jonathan,  One question related to
> this description. If a user agent
> is configured to use its local outbound
> proxy, does it send entire Route list
> (formed from Record-Route and Contact
> in 200) to its proxy in the ACK ?
> Or is the user agent supposed to use
> the Route list (and pop topmost entry),
> once the signaling path is established ?
> 
> Also, I am trying to think when
> would a proxy receive a request
> without Route header, maddr of
> req-uri is proxy but host portion of
> req-uri is not proxy.
> 
> Thanks,
> Shail
> 
> Jonathan Rosenberg wrote:
> >
> > Folks,
> >
> > We need to finally come to conclusion on this nagging problem of the
> > precedence rules for the Route header, R-URI maddr, and R-URI hostname.
> > Specifically, when a proxy receives a request, what is the processing it
> > uses to determine how to route it? The issue is linked with a bunch of
> very
> > related ones, such as how we handle local-outbound proxies for hosts that
> > have no DNS.
> >
> > Like any problem, we need some requirements for this solution:
> >
> > 1. a proxy should not need to know that it is a local-outbound proxy for
> the
> > upstream element (which can be a UA or proxy), for this to work
> > 2. Ideally, a subsequent request in a call should follow the path of
> proxies
> > which record routed.
> > 3. the solution should work correctly in the face of spirals
> >
> > To proceed, I am going to make a strawman. Lets work from this, and
> proceed
> > by having people point out issues or problems with this solution, rather
> > than proposing completely new ones.
> >
> > Strawman
> > --------
> >
> > when a proxy receives a request, it checks for the existence of a Route
> > header. If one exists, that Route header is popped, and placed into the
> > request URI. It is then sent using the procedures of draft-ietf-sip-srv.
> If
> > no route header is present, the proxy examines the request URI. If it
> > contains an maddr, and this maddr is not an interface that the proxy is
> > listening on, the proxy forwards the request using the procedures of
> > draft-ietf-sip-srv on the request URI (this will cause it to be forwarded
> to
> > the address in the maddr). If the maddr is present, but is an interface
> the
> > proxy is listening on, the maddr is stripped, and processing proceeds as
> if
> > it were never there. If there was no maddr, and the domain of the request
> > URI is not a domain the proxy is managing, the procedures of
> > draft-ietf-sip-srv are used to forward the request to that URI. If the
> > domain is one the proxy is managing, the request is processed.
> >
> > Consider a UA which uses a pre-configured local outbound proxy. It sends
> an
> > INVITE, and then wishes to send a request for the same call leg. If it has
> > obtained a route set for this call leg, it SHOULD pop the top route entry,
> > place it into the request URI, and use that to forward the request. If the
> > proxy is not DNS capable, it MAY alternatively place the entire route set
> > into Route headers (not popping the top URI). It sets the request URI to
> the
> > same value it used for the initial INVITE, and sends it to its local
> > outbound proxy.
> >
> > One more thing we would need for this to work. The URI placed into the RR
> > header MUST be unique for each unique request URI in the incoming request,
> > but must not equal the URI of the incoming request (adding an maddr is
> fine,
> > for example. So, the current normal behavior of copying the R-URI userhost
> > into RR, and adding your own port and maddr, meets the requirement). The
> > important implication of this is that when a proxy record-routes through a
> > spiral, the URI in the RR needs to be different each time through the
> > spiral.
> >
> > This approach solves all of the problems that have been pointed out, I
> > think:
> >
> > 1. Lets say proxy X is a local outbound proxy for some UA Y, and Y doesn't
> > do DNS. So, when X sends a re-INVITE, it doesn't pop the top route header.
> > This request shows up at X. Since there is a Route header, X pops it, and
> > forwards it there. Of course, thats back to itself. However, this is a
> > SPIRAL, since the incoming request URI is guaranteed not to be the same as
> > the URI in the top Route. So, it looks at the request again, and if there
> is
> > a Route, sends it on its way. Of course, a smart proxy could simply notice
> > this condition and not actually send it to itself.
> >
> > 2. When using Route headers through a spiral, the request URI at each
> point
> > in the spiral is guaranteed to be just as unique as the original request
> was
> > through the set of proxies. This means that if the origina R-URI was
> > different when received twice at the same proxy, the R-URI from Route will
> > be different two. So, the case that Robert raised, where the requests will
> > appear as loops, won't happen.
> >
> > Comments?
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg                       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
> >
> >
> > _______________________________________________
> > 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@lists.bell-labs.com  Sat Apr 28 09:18:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13516
	for ; Sat, 28 Apr 2001 09:18: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 B368544339; Sat, 28 Apr 2001 09:18:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156])
	by lists.bell-labs.com (Postfix) with ESMTP id 485A344338
	for ; Sat, 28 Apr 2001 09:17:06 -0400 (EDT)
Received: from gardell2 (gardell.ne.mediaone.net [24.218.23.31])
	by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f3SDGb620602;
	Sat, 28 Apr 2001 09:16:37 -0400 (EDT)
Message-ID: <03dd01c0cfe5$d930ac40$6401a8c0@gardell2>
Reply-To: "Steven Gardell" 
From: "Steven Gardell" 
To: "Eric Burger" , 
References: <200104271712.f3RHCRb04014@flyingfox.snowshore.com>
Subject: Re: [SIP] Join as replacement for DTMF/voice-forking.
Organization: Iperia
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.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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, 28 Apr 2001 09:19:17 -0400
Content-Transfer-Encoding: 7bit

It is certainly a good idea to have a flexible architecture that
enables us to build "service deployment vehicles" in a
variety of different ways as described in
draft-rosenberg-sip-app-components, but I would
point out that there are many different possibilities for the
communication mechanisms between the logical "AS" and "MS"
components. As the aforementioned draft discussed, in some
cases such as a dedicated messaging platform, these
components might be merged (Scaling might be
accomplished by alternative mechanisms such as a call
distributing proxy server.) It really depends on the service.
What is optimal for voice mail may be sub-optimal for a much
less media-intensive service such as a calling card platform.

----- Original Message -----
From: Eric Burger 
To: 
Sent: Friday, April 27, 2001 1:12 PM
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Note that the media does not necessarily have to go to the AS.  In fact, it's probably a
bad idea for the reasons you list below.

A more scalable approach is to use a media server, and have the media server report the
DTMF events to the AS, either through http (as in draft-rosenberg-sip-app-components), SIP
INFO [no flames, please], or RFC 2833.

 +--------+   SIP   +------+
 |Caller/ |-------->|  AS  |
 |  GW    |         +------+
 +--------+          ^
         \          /
          \RTP     / SIP | SIP+http | SIP+RFC 2833
           \      /
            V    V
           +------+
           |  MS  |
           +------+

The media server does the media lifting for the application server, such as playing
prompts and collecting digits, while the application server does the application heavy
lifting, such as data base lookup, verification, etc.

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
Fairlie-Cuninghame, Robert
Sent: Friday, April 27, 2001 10:46 AM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi again,

The Join approach could provide a good reason to stick with the SDP vocoder set behaviour
decided at the last IETF meeting rather than what was being bandied about on the list.

If you want to do DTMF monitoring and non-disruptive voice announcements from an AS to a
SIP session (eg calling card service as previously discussed), then you will want to
receive only the DTMF stream and send voice. [An AS will not usually want to receive the
voice traffic all the time due to loading issues - I know people are talking about voice
recognition but this is normally when the caller is connected to AS not all the time,
right?]

Now the voice and DTMF are normally syncronized in the same SDP m= line - possibly causing
problems. This is not a problem if each side only saying what it is willing to recieve -
NOT send and receive. That is, the UA would put that it can recieve both voice and DTMF
(as normal) and the AS would indicate that it can only receive DTMF.

However, thanks to the flexibility of the Join header  it will work even if we go
with the send-and-receive SDP vocoder defintion. Instead you would just send two INVITE's
with Join headers: one specifying "a=recvonly" listing the DTMF vocoder and the other
specifying "a=sendonly" with the voice coder.

Regards,

Robert.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Thursday, April 26, 2001 3:38 PM
To: 'Steve Gardell'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


Hi Steve,

Thanks for your comment.

Pretty much everything can be done as a B2BUA and I agree with you: until UA's with REFER
&  Replaces capability are widely deployed, then B2BUA is pretty much the only way to
accomplish many of the "advanced call control" features in an hetrogenous/non-controlled
SIP network (IMO). However, unfortuately a B2BUA does not help in the scenario described
in this thread.

A B2BUA cannot inherently cause a _normal_ UA to fork or mix the media. The Application
(or some related RTP processing/splitting/forwarding entity) could process the media for
every call for the entire duration of the call [for common usage scenario]. However, I
don't beleive this is generally a scalable solution. I don't think you are denying that
the features being discussed are not very important to people wishing to provide
calling-card style services (non-disruptive in-call warnigns and announcements, media
triggered events such as triple # for call follow-on/return, etc).

For "Join" to work, one of the endpoints must support the Join header - just like REFER
you cannot guarantee every UA will implement this. This is the same for the existing
SDP-based stream forking behavior. I don't see that this is a problem specific to this
suggestion but rather a general problem for adding extensions - not everyone is going to
implement every extension. This is not a reason to stop publishing extensions (which I'm
sure you are not debating).

However, that does bring up a good advantage to this Join approach. IMO, it is seems much
easier for many PSTN-gateway based calling card services to control the features supported
by just _one_ of the UA's involved in a call (usually the gateway). However, it may not
always be the caller, for instance, in a "PC to Phone" application where the client is
located on a "plain-vanilla" SIP client on the internet. In this case it might be usefull
to allow the Join header to be sent to the callee (the gateway) and specify that the Join
is only towards the remote party. (So the Join header options become "local", "remote", or
"full" mixing). This facility is not possible with the current SDP-based stream forking
approach.

To me this seems such a flexible, easy and clean way of achieving this functionality.

Robert.
-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Thursday, April 26, 2001 1:05 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Join as replacement for DTMF/voice-forking.


The additional discussion really helps for those of us who don't
have the several hours a day it takes to really keep up on the SIP list!

At any rate, one concern - probably with both models - is that we can't
make the assumption that all gateways are willing to "invest" in the
additional DSP to support mixing or, for that matter, mid-call DTMF recognition.
In that case one could imagine implementing a B2BUA (with associated
media processing) that can do this "in the network" with join as suggested
or simply implementing the service in it's entirety at a B2BUA. Which of these
3 variants is most cost effective might well be service-provider dependent.

I agree that control over "full or local" mixing is important to support a
calling card service.


_______________________________________________
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 Apr 30 01:47:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22760
	for ; Mon, 30 Apr 2001 01:47:07 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1A06144338; Mon, 30 Apr 2001 01:47:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 01F7F44337
	for ; Mon, 30 Apr 2001 01:46:17 -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 f3U5kCO09391;
	Mon, 30 Apr 2001 07:46:17 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.161])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3U5kCJ28700;
	Mon, 30 Apr 2001 08:46:12 +0300 (EET DST)
Message-ID: <3AECFC22.C871EC1E@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin 
Cc: Jonathan Rosenberg ,
        "'Sean Olson (EUS)'" ,
        "'Vijay Gurbani'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Further editorial nit in the bis draft
References: 
Content-Type: multipart/mixed;
 boundary="------------3C24DB1E9F64B2E1FAA9A1AF"
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, 30 Apr 2001 08:46:10 +0300

This is a multi-part message in MIME format.
--------------3C24DB1E9F64B2E1FAA9A1AF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi all,

>Well, the original motivation for sending a BYE instead of a CANCEL to
>terminate call setup was PSTN connectivity, since PSTN gateways may
>apparently want to send ISUP in SIP call termination messaging.
> 
>With CANCELs being hop by hop and the note in 8.1 specifically prohibiting
>sending payloads in CANCELs, it was somehow assumed that they are not suited
>for conveying that ISUP payload. I never really bought into that argument so
>I am fine with the proposed wording. However, at this point it may become a
>compatibility issue if lots of folks have already implemented sending the
>BYE. I'd recommend saying that UASs should be prepared to receive either a
>BYE or a CANCEL but UACs SHOULD send a CANCEL and only BYE the 200 responses
>if any.

By saying that "UASs should be prepared to receive either a BYE or a
CANCEL" would not solve anything, and soon we would have this discussion
again, since many implementations would probably not implement support
to receive BYE. My suggestion would be to say that "A UAS MUST be
prepared to receive either a BYE or a CANCEL". A UAC can then send
either BYE or CANCEL (no SHOULDs needed), depending on the functionality
(Igor gave an example why a PSTN GW may want to use BYE instead of
CANCEL).

However, it should be clearly written that BYEs are used to terminate
whole calls/call setups, so that people don't start using them to
"cancel" transactions, ie re-INVITEs.

I know that my MUST-proposal may have some backward compability issues,
but solving those issues (not only in this case) by adding a lots of
SHOULDs will in many cases only move the problems to a later stage...

Regards,

Christer Holmberg
Ericsson Finland






> 
> ---
> Igor Slepchin
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Friday, April 27, 2001 11:21 AM
> > To: 'Sean Olson (EUS)'; 'Vijay Gurbani'; Jonathan Rosenberg
> > Cc: Christer Holmberg (LMF); 'sip@lists.bell-labs.com'
> > Subject: RE: [SIP] Further editorial nit in the bis draft
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
> > Sent: Friday, April 27, 2001 11:02 AM
> > To: 'Vijay Gurbani'; Jonathan Rosenberg
> > Cc: Christer Holmberg (LMF); 'sip@lists.bell-labs.com'
> > Subject: RE: [SIP] Further editorial nit in the bis draft
> >
> > >>Jonathan:
> > >>
> > >>I misinterpret many thing, but definitely not this one :-)  In
> > >>some earlier
> > >>posting, I made the same point: a BYE should be sent after a
> > >>CANCEL iff
> > >>the 200 OK (INVITE) from the UAS and the CANCEL pass each
> > >>other on the wire.
> > >
> > >This is not what Jonathan is saying. He is referring to the
> > >possibility of sending a BYE *instead* of a CANCEL, not sending
> > >a BYE in the event a CANCEL crosses on the wire.
> >
> > Everyone loves to put words into my mouth...
> >
> > I was saying that the preferred approach is to send CANCEL
> > first, and then
> > iff you get a 200 OK anyway (which happens if the CANCEL and
> > 200 OK pass on
> > the wire) then send BYE. I was also saying we should keep
> > "just send BYE" as
> > a MAY. Vijay seems to be saying we should not even mention
> > that possibility.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg                       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
> >
> > _______________________________________________
> > 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.
> >
--------------3C24DB1E9F64B2E1FAA9A1AF
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

--------------3C24DB1E9F64B2E1FAA9A1AF--


_______________________________________________
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 Apr 30 13:19:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19613
	for ; Mon, 30 Apr 2001 13:19:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1BC7344342; Mon, 30 Apr 2001 13:19:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange.NeTrue.com (unknown [207.104.210.242])
	by lists.bell-labs.com (Postfix) with ESMTP id 5D23744337
	for ; Mon, 30 Apr 2001 13:18:53 -0400 (EDT)
Received: from roland (207.104.210.147 [207.104.210.147]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id J5BZ5WAZ; Mon, 30 Apr 2001 10:21:50 -0700
Message-ID: <005001c0d199$c64fe4a0$93d268cf@netrue.com>
From: "Roland" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004D_01C0D15F.146D0040"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [SIP] where can find document for sip conference or multicast
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, 30 Apr 2001 10:19:46 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_004D_01C0D15F.146D0040
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

Hello everyone,
=20
 Can anybody tell me where I can get some specifications for sip =
conference or multicast?
the 2543 never mentions the detail for this function.

Thanks a lot

ROland=20

------=_NextPart_000_004D_01C0D15F.146D0040
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable









Hello everyone,


 


 Can anybody tell me where I can =
get some=20
specifications for sip conference or multicast?


the 2543 never mentions the detail for =
this=20
function.


 


Thanks a lot


 


ROland 


------=_NextPart_000_004D_01C0D15F.146D0040--


_______________________________________________
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 Apr 30 13:52:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20557
	for ; Mon, 30 Apr 2001 13:52:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 222A144349; Mon, 30 Apr 2001 13:52:04 -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 BB61B44342
	for ; Mon, 30 Apr 2001 13:51:06 -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 f3UHo1s16859
	for ; Mon, 30 Apr 2001 13:50:01 -0400 (EDT)
Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AEU01869 (AUTH shbhatna);
	Mon, 30 Apr 2001 13:51:04 -0400 (EDT)
Message-ID: <3AEDA609.626D336A@cisco.com>
From: Shail Bhatnagar 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 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] Should proxy forward non-200 final response after CANCEL
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, 30 Apr 2001 13:51:05 -0400
Content-Transfer-Encoding: 7bit

A transaction stateful proxy receives a 
non-200 final response to the original
request after tha request has been 
CANCEL(led). (for example 487) Should it
forward this non-200 final response upstream ??

Thanks,
Shail

_______________________________________________
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 Apr 30 14:47:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22177
	for ; Mon, 30 Apr 2001 14:47:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1528344338; Mon, 30 Apr 2001 14:47:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E20E44337
	for ; Mon, 30 Apr 2001 14:46:11 -0400 (EDT)
Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3UIkE801928;
	Mon, 30 Apr 2001 13:46:14 -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 f3UIkAu13983;
	Mon, 30 Apr 2001 13:46:10 -0500 (CDT)
Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA03997; Mon, 30 Apr 2001 13:46:09 -0500 (CDT)
From: adam.roach@ericsson.com
Reply-To: 
To: , 
Subject: RE: [SIP] Problem with ACK through proxy
Message-ID: <61D824C63B99D311975E00508B0CC98502251710@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: <009201c0ce93$39fed410$2b01a8c0@broadsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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, 30 Apr 2001 13:46:08 -0500
Content-Transfer-Encoding: 7bit

> From: Brett Tate [mailto:brett@broadsoft.com]
>
> Note: older UAs might not add a Contact.  
> In this case, it is up to the supporting 
> record-routing Proxy to remember how to route to 
> the final location.  (I assume that some proxies 
> might attach Contact for the old UA to keep from 
> having to store it.)  If there is no record-route,
> the originating UA would send subsequent requests 
> where it sent the previous on the call-leg.

Ummm... I thought that 2543 made the assumption that,
if no "Contact" header is present, the "From" field
is to be used for future contacts. If you're trying
to interop with older clients, I'd say that this is
still the most appropriate behavior.

/a


_______________________________________________
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 Apr 30 16:12:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24681
	for ; Mon, 30 Apr 2001 16:12: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 0820044338; Mon, 30 Apr 2001 16:12:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id F271544337
	for ; Mon, 30 Apr 2001 16:11:43 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id QAA90350; Mon, 30 Apr 2001 16:11:42 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: , 
Subject: RE: [SIP] Problem with ACK through proxy
Message-ID: <002501c0d1b2$10ae0dc0$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <61D824C63B99D311975E00508B0CC98502251710@eamrcnt717.exu.ericsson.se>
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, 30 Apr 2001 16:13:46 -0400
Content-Transfer-Encoding: 7bit

> > > is the contact header mandatory in 200 OK for invite?
> >
> > Yes. The Contact header is mandatory in 2xx for 
> > INVITE as mentioned in section 6.15 and shown 
> > in table 4 rfc2543bis-02.
> >
> > Note: older UAs might not add a Contact.  
> > In this case, it is up to the supporting 
> > record-routing Proxy to remember how to route to 
> > the final location.  (I assume that some proxies 
> > might attach Contact for the old UA to keep from 
> > having to store it.)  If there is no record-route,
> > the originating UA would send subsequent requests 
> > where it sent the previous on the call-leg.
> 
> Ummm... I thought that 2543 made the assumption that,
> if no "Contact" header is present, the "From" field
> is to be used for future contacts. If you're trying
> to interop with older clients, I'd say that this is
> still the most appropriate behavior.
> 

Yes, the From is used to help build the Route from 
called to caller if there was no Contact in original 
INVITE.  The From is not used in build route from 
caller to called.

The question and answer dealt with building Route
for ACK/etc from INVITE's 200 that contained 
Record-Route and no Contact, and what the proxy 
needs to do when receiving ACK without Route that 
needs to be delivered to the same called UA 
(that didn't add its Contact in 200).


_______________________________________________
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 Apr 30 20:29:13 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29075
	for ; Mon, 30 Apr 2001 20:29: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 0D91644338; Mon, 30 Apr 2001 20:29:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 63FA544337
	for ; Mon, 30 Apr 2001 20:28:47 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id UAA26892; Mon, 30 Apr 2001 20:28:46 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'SIPWG Mailing List (E-mail)'" 
Subject: RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call
Message-ID: <002901c0d1d5$f9e88ba0$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: 
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, 30 Apr 2001 20:30:50 -0400
Content-Transfer-Encoding: 7bit

General comment/question: 

Why can Session-Expires and Require "timer" 
be in negative re-INVITE responses since it 
is not guaranteed that re-INVITE has gotten 
to the far end?  Let me know if I missed the 
sentence that would ensure that a proxy won't
generate such a response as means to extend
the session timer.  Was it added as a means 
for a proxy to help produce a BYE quicker?

Section 4 last paragraph:
The Session-Expires immediate and Require 
"timer" looks like a kludge for UA's 
that don't add/use tags.  It seems strange 
that they are current enough to implement
timer draft but not current enough to add 
tags to the To and From.  Note: the proxy 
should not add the Session-Expires immediate
and Require "timer" for the UA since the 
proxy doesn't know the destination UA's 
reason for the reject.  Please make being 
able to distinguish a re-INVITE from INVITE 
a requirement for implementing the draft.



General comment/question:

Please mention in the draft that 
the UAS receiving a re-INVITE SHOULD NOT 
revive a dead call-leg unless it knows that 
the associated media session is still 
active/allocated for that call-leg.

Reasons:
1) Helps ensure that the reviver is one 
   that pays for call if the revived party
   actually hung up previously.

2) Helps ensure that the reviver only pays
   for call if reviver knows it will be
   paying for call.

3) Only re-alerts the receiver when sender
   really desires such a thing.


_______________________________________________
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.





        

Making DTMF, CN etc. as separate streams will
create
more issues with many existing systems. 

Aravindan
--- Shan Lu <slu@nextone.com> wrote:

Hi,

Before we come up with any solution, let's first
understand what the 
problems are and what we want out of SDP.

Problems:

When more than more audio codecs are listed in
"m="
line, SDP lacks 
mechanism to indicate:
1. sendrecv, sendonly, or recvonly for each
codec;
2. packetization size supported for each codec ;
3. simultaneous capabilities. (e.g., a UA can
support audio codecs A, B, 
and C, but when video codec X is used, can only
support audio codec A.)

Desirable functions of SDP:

1. To indicate to the other side the full
capabilities of a UA
2. To indicate to the other side the media types
(codec, pack. size, 
uni. or bi-directional) that will be used for a
particular session in an 
unequivocal way.

As an implementor, I can testify firsthand that I
can not appreciate the 
last point enough. Here is why: In the real
world,
most DSP based codec 
implementations can ONLY support symmetric
operation. If tx uses codec 
A, rx must also use codec A. So if the first SDP
(INVITE or 200 OK)  
lists codecs A, B and C, and second SDP (200 OK
or
ACK) responds with 
codecs A and B, one UA may start use codec A and
the
other may pick 
codec B, which results in either dead silence or
garbled speech. We have 
seen this happen at the bake-offs.

And packetization size is another issue. Take
G.729
for example. The 
base frame size is 10ms. But due to resource
restrictions, many 
implementations can only support a fixed, integer
multiple of the base 
frame, say 20ms or 30 ms. On some
implementations,
packetization size is 
either a runtime or configuration parameter. In
any
case, a 20 ms won't 
talk to 30 ms G.729. We heard quite a few
distorted
conversations 
because of codec size mismatch at SIP bake-offs
and
at H323 
Interoperability Events.

Hence, I'd like to propose the following:

1. Assume all audio codecs (not including DTMF)
are
send and recv, and 
require symmetric operation;
2. Originating SDP lists packetization size for
each
codec unless 
default value is used;
3. If supported, origination SDP lists explicitly
whether DTMF is send 
o
r recv, with sendrecv being default;
4. Responding SDP lists one and ONLY one codec
for
each media (if, of 
course, there exists overlap) and, when
applicable,
includes 
packetization size and send/recv attribute;
5. The side that originates SDP uses OPTIONS to
query the other side's 
capability after call setup, if necessary.

Example: UA1 supports codecs A (20ms), B (30ms),
and
C (20ms), and can 
transmit and recv DTMF; UA2 supports codecs A(10
ms), B (30ms), and D( 
20ms) and can transmit DTMF (but not recv).
Here's
the SDP exchange:

UA1->UA2 (INVITE)

m=audio 40000 RTP/AVP 100 101 102
a=rtpmap: 100 A/8000
a=ptime: 20
a=rtpmap:101 B/8000
a=ptime: 30
a=rtpmap:102 C/8000
a=ptime: 20
m=audio 40000 RTP/AVP 103
a=fmtp:103 0-15
a=sendrecv

UA2->UA1 (200 OK)
m=audio 30000 RTP/AVP 101
a=rtpmap:101 B/8000
a=ptime: 30
m=audio 30000 RTP/AVP 103
a=fmtp:103 0-15
a=sendonly

Note that there are two "m=" lines in each SDP
because the DTMF and 
codec are really simultaneous capabilities. The
usage of "a=ptime" is a 
little bit stretch here at codec level and may
cause
problem for 
existing implementations. But I haven't seen it
used
very much.

Regards,

Shan Lu

NexTone Communications
Gonzalo Camarillo wrote:

Hello,

There have been already several mails showing
certain confusion about

SDP usage in SIP.
In the last IETF the conclusion was:
For sendrecv flows (uni-directional flows are
easy), the caller puts in

the INVITe the codecs that he can both send AND
receive.

The open issue is what the callee returns:
1) a sub-set of the codecs listed in the INVITE
that he can send AND

receive.
2) all the codecs that he can send AND receive.

Note that caller and callee have reversed roles
if
the SDP from the

client to the server is sent in the ACK instead
of
in the INVITE.

I would like to ask folks not to mix this open
issue with another

similar issue: I have a DSP that cannot change
codecs on-the-fly, and I

want to pick up just one codec. Let us discuss
this issue at other time.

My proposal is to go for solution number 2. This
gives a symmetrical

negotiation. Besides, it covers more cases than
<
/blockquote>
solution number 1). It

can happen that for a particular codec, the
callee
can send AND receive

it but the caller can just send it. Therefore,
the
caller does not

include it in the INVITE. However, if the callee
lists it in the 200 OK,

the caller will be able to send it.

Opinions?

Gonzalo


_______________________________________________
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.


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/




                                                                                                                                                  


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.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.




                                                                                                                                                  

                                                                                                                                                  


--------------060106000309030501060700--


_______________________________________________
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  Wed Apr  4 14:12:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27863
	for ; Wed, 4 Apr 2001 14:12:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E5B4D44346; Wed,  4 Apr 2001 14:12:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 24BD544337
	for ; Wed,  4 Apr 2001 14:11:02 -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.9.3/8.9.1) with ESMTP id LAA02989;
	Wed, 4 Apr 2001 11:10:52 -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 ADP08613;
	Wed, 4 Apr 2001 11:10:47 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA05235; Wed, 4 Apr 2001 11:10:47 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15051.25511.669347.632339@thomasm-u1.cisco.com>
To: Juha Heinanen 
Cc: "Sean Olson (EUS)" ,
        "'brett@broadsoft.com'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Response if user not registered?
In-Reply-To: <15051.17608.217056.987028@lohi.eng.telia.fi>
References: 
	<15051.17608.217056.987028@lohi.eng.telia.fi>
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!
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: Wed, 4 Apr 2001 11:10:47 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Juha Heinanen writes:
 > Sean Olson (EUS) writes:
 > 
 >  > Barring
 >  > an outbound request because a terminal is not registered
 >  > at the local outbound proxy is a reasonable thing to do.
 > 
 > no it isn't.  as has been mentioned many times, sip registration is not
 > for that kind of purpose.  it must be enough that the outboud proxy is
 > (a) able to authenticate the calling sip ua and that (b) the
 > authenticated (and thus known) user has via subscription or otherwise
 > the right to make outboud calls via this outbound proxy.

  That's not what Sean actually wrote though,
  or at least that's not the way I interpreted
  what he wrote. I interpreted him to mean that
  it needs to authenticate (register) with the
  outbound proxy first, then do a SIP REGISTER.
  If that's what he meant, I think we're all in
  violent agreement.

		Mike
  

_______________________________________________
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  Wed Apr  4 14:49:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28810
	for ; Wed, 4 Apr 2001 14:49: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 22B8A44339; Wed,  4 Apr 2001 14:49:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27])
	by lists.bell-labs.com (Postfix) with SMTP id 5D4BC44337
	for ; Wed,  4 Apr 2001 14:48:56 -0400 (EDT)
Message-ID: <20010404184855.2281.qmail@web13901.mail.yahoo.com>
Received: from [149.112.117.3] by web13901.mail.yahoo.com; Wed, 04 Apr 2001 11:48:55 PDT
From: aravindan shanmugam 
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal
To: Shan Lu 
Cc: sip 
In-Reply-To: <3ACB606F.7090905@nextone.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Wed, 4 Apr 2001 11:48:55 -0700 (PDT)

No one said that the packet size has to be same in
both direction. I can send 20ms packet and receive
30ms packet, it is simple. Why would anyone want to
configure it?. If you still feel it is essential to
have packet size I leave it to you and others.

Aravindan
--- Shan Lu  wrote:
> 
> aravindan shanmugam wrote:
> 
> > --- Shan Lu  wrote:
> > 
> >> 
> >> aravindan shanmugam wrote:
> >> 
> >>> Hi,
> >>> 
> >>> Handling different packet size is not a
> difficult
> >>> problem as long as the packet size is an integer
> >>> multiple of codec frame size. Let us not add
> more
> >>> variables to the problem.
> >> 
> >> Can you tell me how if neither side indicates the
> >> packet size ?
> >> 
> >> Shan Lu
> >> 
> > 
> > You know the payload size of RTP packet when you
> > receive a packet after protocol processing and you
> > know the codec frame size from the codec type.
> Thus,
> > you can estimate the number of codec frames in the
> > packet. For more details refer to
> > draft-ietf-avt-profile document.
> > 
> > Aravindan
> 
> I see. You want to leave the burden to RTP PT. Let's
> consider the 
> following two scenarios:
> 
> 1. UA1 and UA2 both can support 20 ms and 30 ms of
> Codec A and both can 
> switch packetization size "on-the-fly". But the
> default configuration is 
> 20 ms for UA1 and 30 ms for UA2. Now are you saying
> that UA1 should 
> refrain from transmitting RTP packets till packets
> arrive from UA2 at 
> which time UA1 can figure out the packet size the
> other side wants to 
> use and switch to that size? Of course, both UAs may
> start transmit at 
> the same time. But for sure the first moments of
> speech won't be as 
> clear as a user would like to hear due to
> packetization size mismatch. 
> And how do you make sure that the two UAs do not
> switch simultaneously 
> which will again lead to packet size mismatch? Let's
>  not forget that 
> even "on-the-fly" switch takes time and a user can
> definitely tell it.
> 
> 2. UA1 can ONLY support 20ms codec A and UA2 can
> ONLY support 30ms codec 
> A. UA1 calls UA2. UA2 rings and user picks up the
> phone. Then what? Dead 
> silence, garbled speech, or busy/reorder tone, or
> LED display "packet 
> size mismatch"?  What you want in this case is for
> UA2 to send 415 
> "unsupported media type" response because the two
> UAs can never have a 
> media connection. This of course assumes UAs have a
> way to list 
> packetization size.
> 
> Hope this is enough to convince you. A protocol has
> to be designed based 
> on reality. And the reality is many codec
> implementations use DSPs and 
> DSPs have limitations. If we have super-fast DSPs
> with super-large 
> on-chip RAM, packetization size is not a problem 
> Nor is codec type.
> 
> Regards,
> 
> Shan Lu
> 
> > 
> >>> 
> >>> Making DTMF, CN etc. as separate streams will
> >> 
> >> create
> >> 
> >>> more issues with many existing systems. 
> >>> 
> >>> Aravindan
> >>> --- Shan Lu  wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> Before we come up with any solution, let's
> first
> >>>> understand what the 
> >>>> problems are and what we want out of SDP.
> >>>> 
> >>>> Problems:
> >>>> 
> >>>> When more than more audio codecs are listed in
> >>> 
> >> "m="
> >> 
> >>>> line, SDP lacks 
> >>>> mechanism to indicate:
> >>>> 1. sendrecv, sendonly, or recvonly for each
> >>> 
> >> codec;
> >> 
> >>>> 2. packetization size supported for each codec
> ;
> >>>> 3. simultaneous capabilities. (e.g., a UA can
> >>>> support audio codecs A, B, 
> >>>> and C, but when video codec X is used, can only
> >>>> support audio codec A.)
> >>>> 
> >>>> Desirable functions of SDP:
> >>>> 
> >>>> 1. To indicate to the other side the full
> >>>> capabilities of a UA
> >>>> 2. To indicate to the other side the media
> types
> >>>> (codec, pack. size, 
> >>>> uni. or bi-directional) that will be used for a
> >>>> particular session in an 
> >>>> unequivocal way.
> >>>> 
> >>>> As an implementor, I can testify firsthand that
> I
> >>>> can not appreciate the 
> >>>> last point enough. Here is why: In the real
> >>> 
> >> world,
> >> 
> >>>> most DSP based codec 
> >>>> implementations can ONLY support symmetric
> >>>> operation. If tx uses codec 
> >>>> A, rx must also use codec A. So if the first
> SDP
> >>>> (INVITE or 200 OK)  
> >>>> lists codecs A, B and C, and second SDP (200 OK
> >>> 
> >> or
> >> 
> >>>> ACK) responds with 
> >>>> codecs A and B, one UA may start use codec A
> and
> >>> 
> >> the
> >> 
> >>>> other may pick 
> >>>> codec B, which results in either dead silence
> or
> >>>> garbled speech. We have 
> >>>> seen this happen at the bake-offs.
> >>>> 
> >>>> And packetization size is another issue. Take
> >>> 
> >> G.729
> >> 
> >>>> for example. The 
> >>>> base frame size is 10ms. But due to resource
> >>>> restrictions, many 
> >>>> implementations can only support a fixed,
> integer
> >>>> multiple of the base 
> >>>> frame, say 20ms or 30 ms. On some
> >>> 
> >> implementations,
> >> 
> >>>> packetization size is 
> >>>> either a runtime or configuration parameter. In
> >>> 
> >> any
> >> 
> >>>> case, a 20 ms won't 
> >>>> talk to 30 ms G.729. We heard quite a few
> >>> 
> >> distorted
> >> 
> >>>> conversations 
> >>>> because of codec size mismatch at SIP bake-offs
> >>> 
> >> and
> >> 
> >>>> at H323 
> >>>> Interoperability Events.
> >>>> 
> >>>> Hence, I'd like to propose the following:
> >>>> 
> >>>> 1. Assume all audio codecs (not including DTMF)
> >>> 
> >> are
> >> 
> >>>> send and recv, and 
> >>>> require symmetric operation;
> >>>> 2. Originating SDP lists packetization size for
> >>> 
> >> each
> >> 
> >>>> codec unless 
> >>>> default value is used;
> >>>> 3. If supported, origination SDP lists
> explicitly
> >>>> whether DTMF is send 
> >>>> or recv, with sendrecv being default;
> >>>> 4. Responding SDP lists one and ONLY one codec
> >>> 
> >> for
> >> 
> >>>> each media (if, of 
> >>>> course, there exists overlap) and, when
> >>> 
> >> applicable,
> >> 
> >>>> includes 
> >>>> packetization size and send/recv attribute;
> >>>> 5. The side that originates SDP uses OPTIONS to
> >>>> query the other side's 
> >>>> capability after call setup, if necessary.
> >>>> 
> >>>> Example: UA1 supports codecs A (20ms), B
> (30ms),
> >>> 
> >> and
> >> 
> >>>> C (20ms), and can 
> >>>> transmit and recv DTMF; UA2 supports codecs
> A(10
> >>>> ms), B (30ms), and D( 
> >>>> 20ms) and can transmit DTMF (but not recv).
> >>> 
> >> Here's
> >> 
> >>>> the SDP exchange:
> >>>> 
> >>>> UA1->UA2 (INVITE)
> >>>> 
> >>>> m=audio 40000 RTP/AVP 100 101 102
> >>>> a=rtpmap: 100 A/8000
> >>>> a=ptime: 20
> >>>> a=rtpmap:101 B/8000
> >>>> a=ptime: 30
> >>>> a=rtpmap:102 C/8000
> >>>> a=ptime: 20
> >>>> m=audio 40000 RTP/AVP 103
> >>>> a=fmtp:103 0-15
> >>>> a=sendrecv
> >>>> 
> >>>> UA2->UA1 (200 OK)
> >>>> m=audio 30000 RTP/AVP 101
> >>>> a=rtpmap:101 B/8000
> >>>> a=ptime: 30
> >>>> m=audio 30000 RTP/AVP 103
> >>>> a=fmtp:103 0-15
> >>>> a=sendonly
> >>>> 
> >>>> Note that there are two "m=" lines in each SDP
> >>>> because the DTMF and 
> >>>> codec are really simultaneous capabilities. The
> >>>> usage of "a=ptime" is a 
> >>>> little bit stretch here at codec level and may
> >>> 
> >> cause
> >> 
> >>>> problem for 
> >>>> existing implementations. But I haven't seen it
> >>> 
> >> used
> >> 
> >>>> very much.
> >>>> 
> >>>> Regards,
> >>>> 
> >>>> Shan Lu
> >>>> 
> >>>> NexTone Communications
> >>>> 
> >>>> Gonzalo Camarillo wrote:
> >>>> 
> >>>>> Hello,
> >>>>> 
> >>>>> There have been already several mails showing
> >>>> 
> >>>> certain confusion about
> >>>> 
> >>>>> SDP usage in SIP.
> >>>>> In the last IETF the conclusion was:
> >>>>> For sendrecv flows (uni-directional flows are
> >>>> 
> >>>> easy), the caller puts in
> >>>> 
> >>>>> the INVITe the codecs that he can both send
> AND
> >>>> 
> >>>> receive.
> >>>> 
> >>>>> The open issue is what the callee returns:
> >>>>> 1) a sub-set of the codecs listed in the
> INVITE
> >>>> 
> >>>> that he can send AND
> >>>> 
> >>>>> receive.
> >>>>> 2) all the codecs that he can send AND
> receive.
> >>>>> 
> >>>>> Note that caller and callee have reversed
> roles
> >>>> 
> >> if
> >> 
> >>>> the SDP from the
> >>>> 
> >>>>> client to the server is sent in the ACK
> instead
> >>>> 
> >> of
> >> 
> >>>> in the INVITE.
> >>>> 
> >>>>> I would like to ask folks not to mix this open
> >>>> 
> >>>> issue with another
> >>>> 
> >>>>> similar issue: I have a DSP that cannot change
> >>>> 
> >>>> codecs on-the-fly, and I
> >>>> 
> >>>>> want to pick up just one codec. Let us discuss
> >>>> 
> >>>> this issue at other time.
> >>>> 
> >>>>> My proposal is to go for solution number 2.
> This
> >>>> 
> >>>> gives a symmetrical
> >>>> 
> >>>>> negotiation. Besides, it covers more cases
> than
> >>>> 
> >>>> solution number 1). It
> >>>> 
> >>>>> can happen that for a particular codec, the
> >>>> 
> >> callee
> >> 
> >>>> can send AND receive
> >>>> 
> >>>>> it but the caller can just send it. Therefore,
> >>>> 
> >> the
> >> 
> >>>> caller does not
> >>>> 
> >>>>> include it in the INVITE. However, if the
> callee
> >>>> 
> >>>> lists it in the 200 OK,
> >>>> 
> >>>>> the caller will be able to send it.
> >>>>> 
> >>>>> Opinions?
> >>>>> 
> >>>>> Gonzalo
> >>>> 
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> 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.
> >>> 
> >>> 
> >>> 
> >>>
> __________________________________________________
> >>> Do You Yahoo!?
> >>> Get email at your own domain with Yahoo! Mail. 
> >>> http://personal.mail.yahoo.com/
> >>> 
> >>> 
> >>> 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail. 
> > http://personal.mail.yahoo.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.
> > 
> > 
> > 
> 
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.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@lists.bell-labs.com  Wed Apr  4 14:55:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28949
	for ; Wed, 4 Apr 2001 14:55: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 3374244364; Wed,  4 Apr 2001 14:55:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by lists.bell-labs.com (Postfix) with ESMTP id B212544337
	for ; Wed,  4 Apr 2001 14:36:49 -0400 (EDT)
Received: from chiron.east.isi.edu (chiron.east.isi.edu [38.218.19.204])
	by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA07882;
	Wed, 4 Apr 2001 14:36:40 -0400 (EDT)
Received: from chiron (csp@localhost)
	by chiron.east.isi.edu (8.11.0/8.11.0) with ESMTP id f34Iamt29553;
	Wed, 4 Apr 2001 14:36:48 -0400
Message-Id: <200104041836.f34Iamt29553@chiron.east.isi.edu>
To: Shan Lu 
Cc: aravindan shanmugam , sip 
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal 
In-Reply-To: Your message of "Wed, 04 Apr 2001 13:57:03 EDT."
             <3ACB606F.7090905@nextone.com> 
From: Colin Perkins 
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: Wed, 04 Apr 2001 14:36:47 -0400

--> Shan Lu writes:
>aravindan shanmugam wrote:
>> --- Shan Lu  wrote:
>>> aravindan shanmugam wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Handling different packet size is not a difficult
>>>> problem as long as the packet size is an integer
>>>> multiple of codec frame size. Let us not add more
>>>> variables to the problem.
>>> 
>>> Can you tell me how if neither side indicates the
>>> packet size ?
>>> 
>>> Shan Lu
>>> 
>> 
>> You know the payload size of RTP packet when you
>> receive a packet after protocol processing and you
>> know the codec frame size from the codec type. Thus,
>> you can estimate the number of codec frames in the
>> packet. For more details refer to
>> draft-ietf-avt-profile document.
>> 
>> Aravindan
>
>I see. You want to leave the burden to RTP PT. Let's consider the 
>following two scenarios:
>
>1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can 
>switch packetization size "on-the-fly". But the default configuration is 
>20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should 
>refrain from transmitting RTP packets till packets arrive from UA2 at 
>which time UA1 can figure out the packet size the other side wants to 
>use and switch to that size? Of course, both UAs may start transmit at 
>the same time. But for sure the first moments of speech won't be as 
>clear as a user would like to hear due to packetization size mismatch. 
>And how do you make sure that the two UAs do not switch simultaneously 
>which will again lead to packet size mismatch? Let's  not forget that 
>even "on-the-fly" switch takes time and a user can definitely tell it.
>
>2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec 
>A. UA1 calls UA2. UA2 rings and user picks up the phone. Then what? Dead 
>silence, garbled speech, or busy/reorder tone, or LED display "packet 
>size mismatch"?  What you want in this case is for UA2 to send 415 
>"unsupported media type" response because the two UAs can never have a 
>media connection. This of course assumes UAs have a way to list 
>packetization size.
>
>Hope this is enough to convince you. A protocol has to be designed based 
>on reality. And the reality is many codec implementations use DSPs and 
>DSPs have limitations. If we have super-fast DSPs with super-large 
>on-chip RAM, packetization size is not a problem  Nor is codec type.

SDP has an a=ptime attribute, if you really need to signal this. Although,
as both SDP and the RTP A/V profile note, "it should not be necessary to
know ptime to decode RTP audio, and it is intended as a recommendation for
the encoding/packetisation of audio."

Colin

_______________________________________________
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  Wed Apr  4 15:13:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29213
	for ; Wed, 4 Apr 2001 15:13: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 587184433B; Wed,  4 Apr 2001 15:13:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from rodney.cnchost.com (rodney.concentric.net [207.155.252.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 821E944336
	for ; Wed,  4 Apr 2001 15:12:56 -0400 (EDT)
Received: from nextone.com ([207.113.13.1])
	by rodney.cnchost.com
	id PAA07159; Wed, 4 Apr 2001 15:12:55 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.10]
Message-ID: <3ACB7373.6000909@nextone.com>
From: Shan Lu 
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal
References: <200104041836.f34Iamt29553@chiron.east.isi.edu>
Content-Type: multipart/alternative;
 boundary="------------010601090700060001050708"
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: Wed, 04 Apr 2001 15:18:11 -0400


--------------010601090700060001050708
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Colin Perkins wrote:

> --> Shan Lu writes:
> 
>> aravindan shanmugam wrote:
>> 
>>> --- Shan Lu  wrote:
>>> 
>>>> aravindan shanmugam wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Handling different packet size is not a difficult
>>>>> problem as long as the packet size is an integer
>>>>> multiple of codec frame size. Let us not add more
>>>>> variables to the problem.
>>>> 
>>>> Can you tell me how if neither side indicates the
>>>> packet size ?
>>>> 
>>>> Shan Lu
>>>> 
>>> You know the payload size of RTP packet when you
>>> receive a packet after protocol processing and you
>>> know the codec frame size from the codec type. Thus,
>>> you can estimate the number of codec frames in the
>>> packet. For more details refer to
>>> draft-ietf-avt-profile document.
>>> 
>>> Aravindan
>> 
>> I see. You want to leave the burden to RTP PT. Let's consider the 
>> following two scenarios:
>> 
>> 1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can 
>> switch packetization size "on-the-fly". But the default configuration is 
>> 20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should 
>> refrain from transmitting RTP packets till packets arrive from UA2 at 
>> which time UA1 can figure out the packet size the other side wants to 
>> use and switch to that size? Of course, both UAs may start transmit at 
>> the same time. But for sure the first moments of speech won't be as 
>> clear as a user would like to hear due to packetization size mismatch. 
>> And how do you make sure that the two UAs do not switch simultaneously 
>> which will again lead to packet size mismatch? Let's  not forget that 
>> even "on-the-fly" switch takes time and a user can definitely tell it.
>> 
>> 2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec 
>> A. UA1 calls UA2. UA2 rings and user picks up the phone. Then what? Dead 
>> silence, garbled speech, or busy/reorder tone, or LED display "packet 
>> size mismatch"?  What you want in this case is for UA2 to send 415 
>> "unsupported media type" response because the two UAs can never have a 
>> media connection. This of course assumes UAs have a way to list 
>> packetization size.
>> 
>> Hope this is enough to convince you. A protocol has to be designed based 
>> on reality. And the reality is many codec implementations use DSPs and 
>> DSPs have limitations. If we have super-fast DSPs with super-large 
>> on-chip RAM, packetization size is not a problem  Nor is codec type.
> 
> 
> SDP has an a=ptime attribute, if you really need to signal this. Although,
> as both SDP and the RTP A/V profile note, "it should not be necessary to
> know ptime to decode RTP audio, and it is intended as a recommendation for
> the encoding/packetisation of audio."
> 
> Colin

a=ptime is exactly what I proposed to use. See my early posting:

http://lists.bell-labs.com/pipermail/sip/2001q2/006521.html
I agree with you that it is not necessary to know ptime to decode RTP 
stream. The problem is not decdoing. Rather it is how to make sure the 
two sides use the same size.


Regards,

Shan Lu

> 
> 
> 


--------------010601090700060001050708
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Colin Perkins wrote:


--> Shan Lu writes:

  
aravindan shanmugam wrote:
--- Shan Lu <slu@nextone.com> wrote:
aravindan shanmugam wrote:

Hi,

Handling different packet size is not a difficult
problem as long as the packet size is an integer
multiple of codec frame size. Let us not add more
variables to the problem.
Can you tell me how if neither side indicates the
packet size ?

Shan Lu

You know the payload size of RTP packet when you
receive a packet after protocol processing and you
know the codec frame size from the codec type. Thus,
you can estimate the number of codec frames in the
packet. For more details refer to
draft-ietf-avt-profile document.

Aravindan
I see. You want to leave the burden to RTP PT. Let's consider the 
following two scenarios:

1. UA1 and UA2 both can support 20 ms and 30 ms of Codec A and both can 
switch packetization size "on-the-fly". But the default configuration is 
20 ms for UA1 and 30 ms for UA2. Now are you saying that UA1 should 
refrain from transmitting RTP packets till packets arrive from UA2 at 
which time UA1 can figure out the packet size the other side wants to 
use and switch to that size? Of course, both UAs may start transmit at 
the same time. But for sure the first moments of speech won't be as 
clear as a user would like to hear due to packetization size mismatch. 
And how do you make sure that the two UAs do not switch simultaneously 
which will again lead to packet size mismatch? Let's  not forget that 
even "on-the-fly" switch takes time and a user can definitely tell it.

2. UA1 can ONLY support 20ms codec A and UA2 can ONLY support 30ms codec 
A. UA1 calls
 UA2. UA2 rings and user picks up the phone. Then what? Dead 
silence, garbled speech, or busy/reorder tone, or LED display "packet 
size mismatch"?  What you want in this case is for UA2 to send 415 
"unsupported media type" response because the two UAs can never have a 
media connection. This of course assumes UAs have a way to list 
packetization size.

Hope this is enough to convince you. A protocol has to be designed based 
on reality. And the reality is many codec implementations use DSPs and 
DSPs have limitations. If we have super-fast DSPs with super-large 
on-chip RAM, packetization size is not a problem  Nor is codec type.

          

SDP has an a=ptime attribute, if you really need to signal this. Although,
as both SDP and the RTP A/V profile note, "it should not be necessary to
know ptime to decode RTP audio, and it is intended as a recommendation for
the encoding/packetisation of audio."

Colin

          

a=ptime is exactly what I proposed to use. See my early posting: 
http://lists.bell-labs.com/pipermail/sip/2001q2/006521.html

I agree with you that it is not necessary to know ptime to decode RTP stream.
The problem is not decdoing. Rather it is how to make sure the two sides
use the same size. 

          

          

Regards,

          

Shan Lu

          




            

            


--------------010601090700060001050708--


_______________________________________________
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  Wed Apr  4 15:28:14 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29539
	for ; Wed, 4 Apr 2001 15:28:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A34EB44365; Wed,  4 Apr 2001 15:26:04 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from thunderer.cnchost.com (thunderer.concentric.net [207.155.252.72])
	by lists.bell-labs.com (Postfix) with ESMTP id D68E54435C
	for ; Wed,  4 Apr 2001 15:25:20 -0400 (EDT)
Received: from nextone.com ([207.113.13.1])
	by thunderer.cnchost.com
	id PAA04832; Wed, 4 Apr 2001 15:25:20 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.10]
Message-ID: <3ACB766F.50904@nextone.com>
From: Shan Lu 
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK? -- A proposal
References: <20010404184855.2281.qmail@web13901.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
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: Wed, 04 Apr 2001 15:30:55 -0400
Content-Transfer-Encoding: 7bit



aravindan shanmugam wrote:

> No one said that the packet size has to be same in
> both direction. I can send 20ms packet and receive
> 30ms packet, it is simple. Why would anyone want to
> configure it?. If you still feel it is essential to
> have packet size I leave it to you and others.
> 
> Aravindan

It is possible to have different sizes for enc and dec. But as a 
practical matter, it is a lot harder for systems to do it that way, 
especially for those based on DSPs. If you want to assume that UAs 
support different sizes for encoding and decoding, one can certainly 
assume that UAs support asymmetric codecs for encoding and decoding. 
Then this entire discussion on SDP becomes unnecessary. But does it 
solve our problem? Also, what about my case #2?

Regards,

Shan Lu

> 
> --- Shan Lu  wrote:
> 
>> aravindan shanmugam wrote:
>> 
>>> --- Shan Lu  wrote:
>>> 
>>>> aravindan shanmugam wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Handling different packet size is not a
>>>> 
>> difficult
>> 
>>>>> problem as long as the packet size is an integer
>>>>> multiple of codec frame size. Let us not add
>>>> 
>> more
>> 
>>>>> variables to the problem.
>>>> 
>>>> Can you tell me how if neither side indicates the
>>>> packet size ?
>>>> 
>>>> Shan Lu
>>>> 
>>> You know the payload size of RTP packet when you
>>> receive a packet after protocol processing and you
>>> know the codec frame size from the codec type.
>> 
>> Thus,
>> 
>>> you can estimate the number of codec frames in the
>>> packet. For more details refer to
>>> draft-ietf-avt-profile document.
>>> 
>>> Aravindan
>> 
>> I see. You want to leave the burden to RTP PT. Let's
>> consider the 
>> following two scenarios:
>> 
>> 1. UA1 and UA2 both can support 20 ms and 30 ms of
>> Codec A and both can 
>> switch packetization size "on-the-fly". But the
>> default configuration is 
>> 20 ms for UA1 and 30 ms for UA2. Now are you saying
>> that UA1 should 
>> refrain from transmitting RTP packets till packets
>> arrive from UA2 at 
>> which time UA1 can figure out the packet size the
>> other side wants to 
>> use and switch to that size? Of course, both UAs may
>> start transmit at 
>> the same time. But for sure the first moments of
>> speech won't be as 
>> clear as a user would like to hear due to
>> packetization size mismatch. 
>> And how do you make sure that the two UAs do not
>> switch simultaneously 
>> which will again lead to packet size mismatch? Let's
>>  not forget that 
>> even "on-the-fly" switch takes time and a user can
>> definitely tell it.
>> 
>> 2. UA1 can ONLY support 20ms codec A and UA2 can
>> ONLY support 30ms codec 
>> A. UA1 calls UA2. UA2 rings and user picks up the
>> phone. Then what? Dead 
>> silence, garbled speech, or busy/reorder tone, or
>> LED display "packet 
>> size mismatch"?  What you want in this case is for
>> UA2 to send 415 
>> "unsupported media type" response because the two
>> UAs can never have a 
>> media connection. This of course assumes UAs have a
>> way to list 
>> packetization size.
>> 
>> Hope this is enough to convince you. A protocol has
>> to be designed based 
>> on reality. And the reality is many codec
>> implementations use DSPs and 
>> DSPs have limitations. If we have super-fast DSPs
>> with super-large 
>> on-chip RAM, packetization size is not a problem 
>> Nor is codec type.
>> 
>> Regards,
>> 
>> Shan Lu
> 
> 
> 
> 


_______________________________________________
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  Wed Apr  4 18:11:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02923
	for ; Wed, 4 Apr 2001 18:11:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E59E44337; Wed,  4 Apr 2001 18:11:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 7DC2044336
	for ; Wed,  4 Apr 2001 18:10:11 -0400 (EDT)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Wed, 4 Apr 2001 15:10:57 -0700
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Apr 2001 14:11:15 -0700 (Pacific Daylight Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905);
	 Wed, 4 Apr 2001 15:11:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: 
Thread-Topic: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)
Thread-Index: AcC9EZsnqTvewEpXSsypJT/ebDqdOAAQFOsw
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ,
        "Dean Willis" , ,
        
X-OriginalArrivalTime: 04 Apr 2001 22:11:15.0187 (UTC) FILETIME=[2A5ACC30:01C0BD54]
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: Wed, 4 Apr 2001 15:11:14 -0700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA02923

The session timer belongs to the category of "safety belts" tools. It
should be though as a last resort tool, to wipe up sessions that are
left open after both clients die, or one single client dies and the
other is too dumb to notice. (If any of the client is up and notices,
e.g. through absence of RTP and RTCP traffic, that client sends a BYE,
and the problem is solved; same is true if there is a human listening to
a phone through a gateway.)

Let's first consider the standard RTCP interval of 5 seconds. I would
not want to drop a session just because I lost one RTCP packet, so I
would wait for at least 10 seconds, or more likely 30 seconds, before
raising an alarm. Setting a session timer to less than 30 seconds should
be a protocol violation, causing some 4xx error. 

Let's then consider the average duration of a business call, typically
between one or a few minutes. Enforcing a heartbeat creates an extra
load on the proxies. If the timer is of the same duration as the average
call, the extra load is about 33% -- add a heart beat + response to a
typical exchange of INVITE/180/200/ACK/BYE/200. I personally find 33% a
bit large for the added value; I would rather aim for a few percents,
i.e. a session timer of at least 10 minutes.

-- Christian Huitema 

> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> >
> > Yes, but if each of the proxies along the path knows what its
> > safe "lower
> > bound" on retransmits is and refuses to pass a session timer
> > with a value
> > lower than the safety threshold, the attack can be avoided.
> > This isn't a
> > protocol change.
> 
> No, thats not true. Consider the case of:
> 
> UA1 -> P1 -> P2 -> P3 -> UA2
> 
> UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it
too
> low. P2 increases it. Now the request goes to P3, which reduces it to
an
> even lower value. This is forwarded to UA2, which reflects it in the
> response, and its forwarded upstream towards UA1. I guess P2 could
discard
> the response, but thats not really a good thing, since the transaction
> will
> end up timing out. Even then, rogue P1 could reduce the timer value in
the
> response once its passed P2.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.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.

_______________________________________________
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  Wed Apr  4 18:44:02 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03721
	for ; Wed, 4 Apr 2001 18:44:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D700D44337; Wed,  4 Apr 2001 18:44:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DD9D44336
	for ; Wed,  4 Apr 2001 18:40:12 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4att.ericy.com [138.85.92.12])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f34MeB819021;
	Wed, 4 Apr 2001 17:40:11 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f34MeB929181;
	Wed, 4 Apr 2001 17:40:11 -0500 (CDT)
Received: from xserv3.exu.ericsson.se (xserv3 [138.85.75.182]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA19573; Wed, 4 Apr 2001 17:40:10 -0500 (CDT)
Received: (from eussean@localhost)
	by xserv3.exu.ericsson.se (8.8.8+Sun/8.8.8) id RAA10075;
	Wed, 4 Apr 2001 17:40:08 -0500 (CDT)
From: Sean Olson 
Message-Id: <200104042240.RAA10075@xserv3.exu.ericsson.se>
Subject: Re: [SIP] Response if user not registered?
To: jh@lohi.eng.telia.fi (Juha Heinanen)
Cc: sean.olson@ericsson.com ("Sean Olson (EUS)"),
        brett@broadsoft.com ('brett@broadsoft.com'),
        sip@lists.bell-labs.com ('sip@lists.bell-labs.com')
In-Reply-To: <15051.17608.217056.987028@lohi.eng.telia.fi> from "Juha Heinanen" at Apr 04, 2001 06:59:04 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
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: Wed, 4 Apr 2001 17:40:08 -0500 (CDT)
Content-Transfer-Encoding: 7bit

> 
> Sean Olson (EUS) writes:
> 
>  > Barring
>  > an outbound request because a terminal is not registered
>  > at the local outbound proxy is a reasonable thing to do.
> 
> no it isn't.  as has been mentioned many times, sip registration is not
> for that kind of purpose.  it must be enough that the outboud proxy is
> (a) able to authenticate the calling sip ua and that (b) the
> authenticated (and thus known) user has via subscription or otherwise
> the right to make outboud calls via this outbound proxy.
> 
> -- juha
> 

This is 100% an application policy decision. It is not
an issue with the SIP protocol. You might as well tell
me that it is illegal for a SIP proxy to use time of day
to route a SIP request. We are not using the SIP REGISTER
for this purpose. We are using registration state. This is
a big difference. Part of this registration state has to
do with whether or not the user is authenticated to make
outbound calls. 

-- 
-----------------------------------------------------------------
Sean Olson            mailto:sean.olson@ericsson.com
Ericsson Inc.         

_______________________________________________
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 Apr  5 01:53:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16237
	for ; Thu, 5 Apr 2001 01:53: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 3149044337; Thu,  5 Apr 2001 01:53:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id A46B044336
	for ; Thu,  5 Apr 2001 01:52:32 -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 f355qTs20889;
	Thu, 5 Apr 2001 07:52:29 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.86])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f355qQK17490;
	Thu, 5 Apr 2001 08:52:26 +0300 (EET DST)
Message-ID: <3ACC0818.D523D451@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "'Dean Willis'" , brett@broadsoft.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Session timer considered harmful (was RE: 
 draft-ietf-sip-session- timer: refresh rate)
References: 
Content-Type: multipart/mixed;
 boundary="------------A19514DBDBB58BB48E867327"
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 Apr 2001 08:52:24 +0300

This is a multi-part message in MIME format.
--------------A19514DBDBB58BB48E867327
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Yes, but if each of the proxies along the path knows what its
>>safe "lower bound" on retransmits is and refuses to pass a session timer
>>with a value lower than the safety threshold, the attack can be avoided.
>>This isn't a protocol change.
> 
>No, thats not true. Consider the case of:
> 
>UA1 -> P1 -> P2 -> P3 -> UA2
> 
>UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it too
>low. P2 increases it. Now the request goes to P3, which reduces it to an
>even lower value. This is forwarded to UA2, which reflects it in the
>response, and its forwarded upstream towards UA1. I guess P2 could discard
>the response, but thats not really a good thing, since the transaction will
>end up timing out. Even then, rogue P1 could reduce the timer value in the
>response once its passed P2.

Even if P1, P2 and P3 acceptes the session timer value, the re-INVITEs
between UA1 and UA2 may
then go via another proxy (unless P1, P2 and P3 inserted themselves in
the route), P4, which then can not handle the value chosen.

However, I still don't think that setting a minimum value is the right
thing to do, because the correct value depends on so many things,
including the size and architecture of the network, the reliability of
the network and the proxies, call priorities etc etc etc. Instead I
think that it should be more clear pointed out what the purpose of the
session timer really is, why a low timer value is bad and a high timer
value is good enough for the purpose.

Also, sending session-timer re-INVITEs every second is not the only way
to overload a SIP network. I can even happen in a "normal" situation,
when a big-capacity-GHz-multiprocessor proxy forwards huge amounts of
initial INVITEs (or any other kind of requests) to a
I-did-it-during-the-coffe-break Commodore64 proxy...  So, I still think
it's up to the network operator to build his network, and route his
traffic, so that this doesn't happen. And, in the case of inter-operator
traffic there probably will be all kind of agreements between the two
operators (charging, routing, whatever...), so a minimum session-timer
value could just be one of those agreements.

And, if a proxy still receives re-INVITEs more often that it wants/can
handle, we could define a "session-timer value too low" error response,
or something...

Regards,

Christer Holmberg
Ericsson Finland
--------------A19514DBDBB58BB48E867327
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

--------------A19514DBDBB58BB48E867327--


_______________________________________________
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 Apr  5 09:55:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02352
	for ; Thu, 5 Apr 2001 09:55: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 7CC2C44350; Thu,  5 Apr 2001 09:55:03 -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.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id E1E5844336
	for ; Wed,  4 Apr 2001 19:33:49 -0400 (EDT)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA04943
	for ; Wed, 4 Apr 2001 16:34:12 -0700 (PDT)
Received: from CISCOXGJYYQQOY (dhcp-128-107-141-189.cisco.com [128.107.141.189])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with SMTP id ABA00432;
	Wed, 4 Apr 2001 16:33:41 -0700 (PDT)
Message-ID: <013e01c0bd60$5fdb46d0$bd8d6b80@CISCOXGJYYQQOY>
From: "Amit Choksi" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_013B_01C0BD25.B343D2A0"
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
Subject: [SIP] DNS SRV lookup
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: Wed, 4 Apr 2001 16:38:38 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_013B_01C0BD25.B343D2A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
This is a question in reference to the draft-ietf-sip-srv-01.txt =
(SIP:--Locating Sip Servers),=20
page 2 says
" The client tries to find one or more addresses for the SIP server by =
querying the DNS. If step elicits no addresses , the client continues to =
the next step. However if a step elicits one or more addresses, but no =
SIP server at any of those addresses responds, then the client concludes =
the server is down and dies not continue on to the next step"

If the retransmission is turned off and the dns lookup gives more than =
one address. The client continues with the next step by sending the =
request to the destination of the address with highest weight and =
priority. If this is unsuccessful then does the client need to send the =
request to another address obtained in priority or conclude the server =
is down ?
Hope I was clear. Please let me know if this does not make sense.=20

Thanks
Amit Choksi

------=_NextPart_000_013B_01C0BD25.B343D2A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi,


This is a question in reference to =
the=20
draft-ietf-sip-srv-01.txt (SIP:--Locating Sip Servers), 


page 2 says


" The client tries to find one or more =
addresses=20
for the SIP server by querying the DNS. If step elicits no addresses , =
the=20
client continues to the next step. However if a step elicits one or more =

addresses, but no SIP server at any of those addresses responds, then =
the client=20
concludes the server is down and dies not continue on to the next=20
step"


 


If the retransmission is turned off and =
the dns=20
lookup gives more than one address. The client continues with the next =
step by=20
sending the request to the destination of the address with highest =
weight and=20
priority. If this is unsuccessful then does the client =
need to=20
send the request to another address obtained in priority or conclude the =
server=20
is down ?


Hope I was clear. Please let me know if =
this does=20
not make sense. 


 


Thanks


Amit Choksi


------=_NextPart_000_013B_01C0BD25.B343D2A0--


_______________________________________________
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 Apr  5 09:56:50 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02435
	for ; Thu, 5 Apr 2001 09:56:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 401DC4435E; Thu,  5 Apr 2001 09:55:10 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by lists.bell-labs.com (Postfix) with ESMTP id 6F81144336
	for ; Thu,  5 Apr 2001 00:41:17 -0400 (EDT)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f354fEG25486;
	Thu, 5 Apr 2001 07:41:14 +0300
From: Juha Heinanen 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15051.63338.536754.601675@lohi.eng.telia.fi>
To: Sean Olson 
Cc: sean.olson@ericsson.com ("Sean Olson (EUS)"),
        brett@broadsoft.com ('brett@broadsoft.com'),
        sip@lists.bell-labs.com ('sip@lists.bell-labs.com')
Subject: Re: [SIP] Response if user not registered?
In-Reply-To: <200104042240.RAA10075@xserv3.exu.ericsson.se>
References: <15051.17608.217056.987028@lohi.eng.telia.fi>
	<200104042240.RAA10075@xserv3.exu.ericsson.se>
X-Mailer: VM 6.75 under Emacs 19.34.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: Thu, 5 Apr 2001 07:41:14 +0300 (EEST)
Content-Transfer-Encoding: 7bit

Sean Olson writes:

 > This is 100% an application policy decision. It is not
 > an issue with the SIP protocol. You might as well tell
 > me that it is illegal for a SIP proxy to use time of day
 > to route a SIP request. We are not using the SIP REGISTER
 > for this purpose. We are using registration state. This is
 > a big difference. Part of this registration state has to
 > do with whether or not the user is authenticated to make
 > outbound calls. 

fine, but then there is no need to a new error code (registration
required) for this (we don't have an error code for wrong time of the
day either).

-- juha

_______________________________________________
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 Apr  5 10:32:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03249
	for ; Thu, 5 Apr 2001 10:32:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D75544359; Thu,  5 Apr 2001 10:32:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by lists.bell-labs.com (Postfix) with ESMTP id 0A41244350
	for ; Thu,  5 Apr 2001 10:31:53 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA17244
	for ; Thu, 5 Apr 2001 16:31:49 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA20953
	for ; Thu, 5 Apr 2001 16:31:51 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2653.19)
	id ; Thu, 5 Apr 2001 16:31:50 +0200
Message-ID: <2F55078199E8D411A9D50008C71E2F9D430541@MCHH232E>
From: Buettner Werner 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Redirect  - 305: Use Proxy
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 Apr 2001 16:31:36 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA03249

Hello All

Here is a question which I have about the redirection response 305 use proxy.

If I have a redirect server, and an INVITE is received by this server, then the routing table could tell the server which address to use for the next hop.  This info is then passed back in a 3xx response, so that the UA (or requesting server) can resend the INVITE to the next hop.  305 seems a good one to be used, since the contact info about the user has not changed, only the info I have on where to go next.  But the specification confuses me on this point.  In bis02 it is stated that the 305 message MUST ONLY be generated by UAS.  Does this now mean that I as redirect server cannot use this response?  Or should one read the description of UAS/UAC in such a manner that a redirect server also fits the description.  The same question is also applicable if I have a proxy server which occasionaly does a redirection.

Thank you for your time.

Kind Regards

Werner Büttner

_______________________________________________
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 Apr  5 16:03:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13169
	for ; Thu, 5 Apr 2001 16:03:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 39F3144346; Thu,  5 Apr 2001 16:03:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from uswgco34.uswest.com (uswgco34.uswest.com [199.168.32.123])
	by lists.bell-labs.com (Postfix) with ESMTP id AC82144336
	for ; Thu,  5 Apr 2001 15:55:23 -0400 (EDT)
Received: from egate-ut2.uswc.uswest.com (egate-ut2.uswc.uswest.com [148.157.122.199])
	by uswgco34.uswest.com (8.10.0/8.10.0) with ESMTP id f35JrNp15964
	for ; Thu, 5 Apr 2001 13:53:24 -0600 (MDT)
Received: from dubntex010.qwest.net (localhost [127.0.0.1])
	by egate-ut2.uswc.uswest.com (8.10.0/8.10.0) with ESMTP id f35JrNb03069
	for ; Thu, 5 Apr 2001 13:53:23 -0600 (MDT)
Received: by DUBNTEX010.qwest.net with Internet Mail Service (5.5.2653.19)
	id ; Thu, 5 Apr 2001 15:53:21 -0400
Message-ID: <0D399EF04D05D211880900104BC6BC080701F1A5@duntx001.qwest.net>
From: "Fiutem, Richard" 
To: "'Session Initiation Protocol'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] ITU-T Q.BICC Recommendation
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 Apr 2001 15:53:21 -0400

To my esteemed colleagues:

Is a draft copy of the ITU-T Q.BICC Recommendation available somewhere?

Please contact me with any questions or concerns, 


Sincerely 

Richard Fiutem 
ATM Interoperability Engineer 
4650 Lakehurst Court
Dublin, Ohio  43016
Richard.Fiutem@qwest.com 
(v) 614-215-5446 
(f)  614-215-5677 
(p) 800-906-9655
(c) 513-739-5398 
 

 





_______________________________________________
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 Apr  6 09:30:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08880
	for ; Fri, 6 Apr 2001 09:30:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BC90B4433A; Fri,  6 Apr 2001 09:30:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by lists.bell-labs.com (Postfix) with ESMTP id A06A044336
	for ; Fri,  6 Apr 2001 09:29:50 -0400 (EDT)
Received: from oleane (dyn-1-1-057.Vin.dialup.oleane.fr [195.25.4.57]) by smtp2.cluster.oleane.net with SMTP id f36DTnD81895 for ; Fri, 6 Apr 2001 15:29:49 +0200 (CEST)
Message-ID: <018b01c0be9d$d1932c00$8001a8c0@oleane.com>
From: "Peter Lewis" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0188_01C0BEAE.94BEE7E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] IP-based Cellular Networks 2001
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 Apr 2001 15:30:59 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0188_01C0BEAE.94BEE7E0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Building all-IP cellular networks is still a challenge and drain a lot =
of research and developpement activities by industry and academic =
research laboratories.  IPCN 2001 (IP-based Cellular Networks) will take =
place in Paris on May 15 to 18 and will provide a state of the art of =
the current research and developpement progress and present an overview =
of the current IETF and 3GPP activities in this area.=20
http://www.upperside.fr/ipcn01/ipcn01intro.htm


------=_NextPart_000_0188_01C0BEAE.94BEE7E0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









Building all-IP cellular networks is =
still a=20
challenge and drain a lot of research and developpement activities by =
industry=20
and academic research laboratories.  IPCN 2001 =
(IP-based=20
Cellular Networks) will take place in Paris on May 15 to 18 and will =
provide a=20
state of the art of the current research and developpement progress and =
present=20
an overview of the current IETF and 3GPP activities in this area.=20

http://www.uppers=
ide.fr/ipcn01/ipcn01intro.htm


 


------=_NextPart_000_0188_01C0BEAE.94BEE7E0--


_______________________________________________
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  Sun Apr  8 08:27:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08518
	for ; Sun, 8 Apr 2001 08:27:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4FFBD4433A; Sun,  8 Apr 2001 08:27:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 9A69844336
	for ; Sun,  8 Apr 2001 08:26:23 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA07627 for ; Sun, 8 Apr 2001 05:26:13 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA05627 for ; Sun, 8 Apr 2001 05:26:13 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <2JGDC358>; Sun, 8 Apr 2001 07:26:12 -0500
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B45225@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Call-ID and CSeq in Registration
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, 8 Apr 2001 07:26:11 -0500

What is the exact use a SIP server does with these two fields upon receiving a Registration request. What bad thing would have happened at the server side, if it had not received the Call-ID info? same for CSeq?
(I mean: If Call-ID serves as the key field to the client's record, we could use the  field?! 
As far as the CSeq goes, the spec says that the server shall not reject the reg. request even if the CSeq is out of order, so what is the use of it?)

I understand the CSeq helps the client to tell one response from the other. Same regarding Call-ID for distinguishing requests which have been sent to different servers? Is that true?

Thanks,

Uri

_______________________________________________
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  Sun Apr  8 08:32:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08544
	for ; Sun, 8 Apr 2001 08:32:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C57394434C; Sun,  8 Apr 2001 08:32:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 63D744433A
	for ; Sun,  8 Apr 2001 08:31:53 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA12721 for ; Sun, 8 Apr 2001 05:31:38 -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA14800 for ; Sun, 8 Apr 2001 05:31:38 -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <2PNQTRCG>; Sun, 8 Apr 2001 07:31:37 -0500
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B45226@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Call-ID and CSeq in Registration
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
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: Sun, 8 Apr 2001 07:31:33 -0500

Oh, perhaps the job of the CSeq field at the server, is simply as in the
INVITE case, to tell retransmissions from new requests? If so, would the
server use the increasing CSeq number when doing its updates? I guess not,
since it works in an "insert" mode anyway. Is that correct?

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com]
Sent: Sunday, April 08, 2001 7:26 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Call-ID and CSeq in Registration


What is the exact use a SIP server does with these two fields upon receiving
a Registration request. What bad thing would have happened at the server
side, if it had not received the Call-ID info? same for CSeq?
(I mean: If Call-ID serves as the key field to the client's record, we could
use the  field?! 
As far as the CSeq goes, the spec says that the server shall not reject the
reg. request even if the CSeq is out of order, so what is the use of it?)

I understand the CSeq helps the client to tell one response from the other.
Same regarding Call-ID for distinguishing requests which have been sent to
different servers? Is that true?

Thanks,

Uri

_______________________________________________
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  Sun Apr  8 08:38:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08582
	for ; Sun, 8 Apr 2001 08:38:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3DA7D4434C; Sun,  8 Apr 2001 08:38:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by lists.bell-labs.com (Postfix) with ESMTP id 0DA254433E
	for ; Sun,  8 Apr 2001 08:37:05 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id FAA10107 for ; Sun, 8 Apr 2001 05:31:33 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA29008 for ; Sun, 8 Apr 2001 05:37:04 -0700 (MST)]
Received: by IL35EXM01 with Internet Mail Service (5.5.2651.58)
	id ; Sun, 8 Apr 2001 07:37:03 -0500
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A06B45227@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 
To: sip@lists.bell-labs.com
Subject:  [SIP] Call-ID and CSeq in Registration Q#3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
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: Sun, 8 Apr 2001 07:36:12 -0500

And one more to complete this sequence of Reg. questions..
Bis  says:
"Clients may register from different locations, by necessity using different Call-ID values."
What odes that mean? Any example?

Thanks!

Uri

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com]
Sent: Sunday, April 08, 2001 7:32 AM
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Call-ID and CSeq in Registration


Oh, perhaps the job of the CSeq field at the server, is simply as in the
INVITE case, to tell retransmissions from new requests? If so, would the
server use the increasing CSeq number when doing its updates? I guess not,
since it works in an "insert" mode anyway. Is that correct?

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com]
Sent: Sunday, April 08, 2001 7:26 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Call-ID and CSeq in Registration


What is the exact use a SIP server does with these two fields upon receiving
a Registration request. What bad thing would have happened at the server
side, if it had not received the Call-ID info? same for CSeq?
(I mean: If Call-ID serves as the key field to the client's record, we could
use the  field?! 
As far as the CSeq goes, the spec says that the server shall not reject the
reg. request even if the CSeq is out of order, so what is the use of it?)

I understand the CSeq helps the client to tell one response from the other.
Same regarding Call-ID for distinguishing requests which have been sent to
different servers? Is that true?

Thanks,

Uri

_______________________________________________
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@lists.bell-labs.com  Mon Apr  9 05:54:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02213
	for ; Mon, 9 Apr 2001 05:54:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 098B94433A; Mon,  9 Apr 2001 05:54:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106])
	by lists.bell-labs.com (Postfix) with ESMTP id BC43244336
	for ; Mon,  9 Apr 2001 05:53:12 -0400 (EDT)
Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25])
	by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id CAA10293
	for ; Mon, 9 Apr 2001 02:53:40 -0700 (PDT)
Message-ID: <3AD18681.468E1292@indigosw.com>
From: Carmelo Zaccone 
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms69009887152BBB550A40FC5D"
Subject: [SIP] FW: [Sip-implementors] Message integrity with digest
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, 09 Apr 2001 11:53:05 +0200

This is a cryptographically signed message in MIME format.

--------------ms69009887152BBB550A40FC5D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


	

>                Hi all,

>        As you know, the 'qop=auth-int' alternative that the 
>        digest scheme defines, offers a mechanism to have
>        the message integrity security feature in our 
>        transactions. 
>
>        As it is currently defined, the spec just takes 
>        the message body into consideration for the digest 
>        scheme.
>
>        This provides us with a certain level of protection,
>        but we may easily extend it to a higher level of 
>        protection. That, more or less, can be compared 
>        to the one provided by the PGP security scheme.
>
>        As defined in the spec, the PGP scheme does not only
>        take the body for its response calculation but also
>        everything that follows the Authorization/ 
>        ProxyAuthorization headers.
>
>        This level of protection is obviously better as we 
>        may also protect headers.
>
>        e.g. think of an unprotected subject header combined with the 
>        currently defined digest message integrity mechanisms ...
>        Messages may be valid from an authentication point of view but
>        a third party between the SIP peers may have changed the
>        subject, maybe leading the communication to a completely 
>        different meaning.
>
>        So, in SIP I would propose extending the way we use the digest 
>        integrity mechanims to map the PGP message integrity coverage.
>       i.e. extending the entity body signification by defining it as
>        everything that follows the Authorization/ProxyAuthorization
>        headers as defined in chapt. 14.1.2 for the pgp-signature.
>        
>        NB1: As the digest already covers the realm and SIP request METHOD, 
>        we could avoid taking them into consideration
>
>        NB2: Obviously, in scenarios where multiples Authorization/
>        ProxyAuthorization headers have to be present, the order in which 
>        an entity inserts its credentials into the message becomes important.    
>                Carmelo 

-- 
...........................................................
  Indigo                         Carmelo Zaccone             
    Software                       Head Software Engineer  
                                                           
  Indigo Software Group, Inc.                              
        505 Montgomery Street               50 rue Wiertz         
      San Francisco, CA 94111              Brussels, 1050        
                          USA                     Belgium               
                                                            
      Phone: 1 (415) 887-3511      Phone : +32 2 230 3594  
      Fax  : 1 (415) 887-3001      Direct: +32 2 235 0955  
                                   Fax   : +32 2 280 2676  
...........................................................
--------------ms69009887152BBB550A40FC5D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcEwggKlMIICDqADAgECAgMC/TowDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyOTA4NDA0MFoXDTAxMDcyOTA4NDA0
MFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYU
Y2FybWVsb0BpbmRpZ29zdy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMscjUn0
bWLZVJy6I5bTZnLKm7KzvuQfWngwyWymRpz0dL8MOZILegqPuleEQBAjdkYkkIry836xdt6C
6BI96vzdhYHxkMrs/C6vjOxMS540pewaSe92Qd7iZMxqI0xiCgAdRyvbqe6WzvQq7McKvW+V
JjyAyWC9shLIdk3DwbChAgMBAAGjUjBQMB8GA1UdEQQYMBaBFGNhcm1lbG9AaW5kaWdvc3cu
Y29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJ
KoZIhvcNAQEEBQADgYEASJe+fm1ekU/kOo7wJlkh6YMZsd15ejoVA5aVVpyuR7u0mcsn0OR5
pEICbdJrnjFwN7FkEAhJ6vl2sv77BmhWJlSKT0lqempDWKCFG+7w8VqaomqFB1oQhVQo5TBG
Grh9m9ztHDMIVf8bJh6ED/lPrKJUsVM0kReDLCvtnq1mpygwggMUMIICfaADAgECAgELMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw
EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL
Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMC
WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNV
BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl
cnNvbmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrt
ZaeSBl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaF
PmzzlZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAw
HwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ
6TH66bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQ
fGuRb4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31
AG70HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy
ZWVtYWlsIFJTQSAxOTk5LjkuMTYCAwL9OjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQwOTA5NTMwN1owIwYJKoZIhvcNAQkE
MRYEFJ5f9IWhVL1w0ZDLEg9YFpR213OXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MA0GCSqGSIb3DQEBAQUABIGAQ+1hbnkvFrff5NkmwwGG0tKwHv+DfU0Oah0bPi294VJuh9lR
GhpOIQwMG68EoBVm3AlPP5+d0v8Lm2fWdZtspattMi64WY1uSaF+hSavh/eaEibXSkIPa29J
bRdOje0g+FB+bJoPFkCxhLzuH+F30paQ8m9E8sJEIAIZB6hBc0U=
--------------ms69009887152BBB550A40FC5D--


_______________________________________________
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 Apr  9 05:56:34 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02236
	for ; Mon, 9 Apr 2001 05:56:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4433244354; Mon,  9 Apr 2001 05:55:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106])
	by lists.bell-labs.com (Postfix) with ESMTP id 0CDE844336
	for ; Mon,  9 Apr 2001 05:54:01 -0400 (EDT)
Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25])
	by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id CAA10443
	for ; Mon, 9 Apr 2001 02:54:28 -0700 (PDT)
Message-ID: <3AD186B4.25393E64@indigosw.com>
From: Carmelo Zaccone 
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" 
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms82E20A2B6BA3B9FA951C95E9"
Subject: [SIP] [Fwd: [Sip-implementors] Message integrity with digest]
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, 09 Apr 2001 11:53:56 +0200

This is a cryptographically signed message in MIME format.

--------------ms82E20A2B6BA3B9FA951C95E9
Content-Type: multipart/mixed;
 boundary="------------C817F17BC41A21B82A15B584"

This is a multi-part message in MIME format.
--------------C817F17BC41A21B82A15B584
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


-- 
...........................................................
  Indigo                         Carmelo Zaccone             
    Software                       Head Software Engineer  
                                                           
  Indigo Software Group, Inc.                              
        505 Montgomery Street               50 rue Wiertz         
      San Francisco, CA 94111              Brussels, 1050        
                          USA                     Belgium               
                                                            
      Phone: 1 (415) 887-3511      Phone : +32 2 230 3594  
      Fax  : 1 (415) 887-3001      Direct: +32 2 235 0955  
                                   Fax   : +32 2 280 2676  
...........................................................
--------------C817F17BC41A21B82A15B584
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: 
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id KAA28832
	for ; Thu, 5 Apr 2001 10:07:43 -0700 (PDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA21778;
	Thu, 5 Apr 2001 13:07:12 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA03176;
	Thu, 5 Apr 2001 13:07:12 -0400 (EDT)
	(envelope-from lennox)
From: Jonathan Lennox 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <15052.42559.552988.636121@conrail.cs.columbia.edu>
Date: Thu, 5 Apr 2001 13:07:11 -0400 (EDT)
To: Carmelo Zaccone 
Cc: "sip-implementors@cs.columbia.edu" 
Subject: Re: [Sip-implementors] Message integrity with digest
In-Reply-To: <3ACCA3AD.984B8365@indigosw.com>
References: <3ACCA3AD.984B8365@indigosw.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7bit

On Thursday, April 5 2001, "Carmelo Zaccone" wrote to "sip-implementors@cs.columbia.edu" saying:

> 	As you know, the 'qop=auth-int' alternative that the 
> 	digest scheme defines, offers a mechanism to have
> 	the message integrity security feature in our 
> 	transactions. 

[...]

> 	So, in SIP I would propose extending the way we use the digest 
> 	integrity mechanims to map the PGP message integrity coverage.
> 	i.e. extending the entity body signification by defining it as
> 	everything that follows the Authorization/ProxyAuthorization
> 	headers as defined in chapt. 14.1.2 for the pgp-signature.

A much cleaner (though more bandwidth-intensive) way of solving this
problem would be to define a 'message/sip' MIME type, which duplicates all
the end-to-end headers and includes the body, and then run auth-int
integrity checking over *that*.  Headers inside the message/sip body 'win'
over the headers in the authenticated body.  This is much more robust in the
presence of intermediate proxies which might mangle or re-order headers.

A 'message/sip' MIME type would also lets us use S/MIME and PGP/MIME
authentication and encryption on message headers.

This discussion should maybe move to the main sip list?

-- 
Jonathan Lennox
lennox@cs.columbia.edu


--------------C817F17BC41A21B82A15B584--

--------------ms82E20A2B6BA3B9FA951C95E9
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcEwggKlMIICDqADAgECAgMC/TowDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyOTA4NDA0MFoXDTAxMDcyOTA4NDA0
MFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYU
Y2FybWVsb0BpbmRpZ29zdy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMscjUn0
bWLZVJy6I5bTZnLKm7KzvuQfWngwyWymRpz0dL8MOZILegqPuleEQBAjdkYkkIry836xdt6C
6BI96vzdhYHxkMrs/C6vjOxMS540pewaSe92Qd7iZMxqI0xiCgAdRyvbqe6WzvQq7McKvW+V
JjyAyWC9shLIdk3DwbChAgMBAAGjUjBQMB8GA1UdEQQYMBaBFGNhcm1lbG9AaW5kaWdvc3cu
Y29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJ
KoZIhvcNAQEEBQADgYEASJe+fm1ekU/kOo7wJlkh6YMZsd15ejoVA5aVVpyuR7u0mcsn0OR5
pEICbdJrnjFwN7FkEAhJ6vl2sv77BmhWJlSKT0lqempDWKCFG+7w8VqaomqFB1oQhVQo5TBG
Grh9m9ztHDMIVf8bJh6ED/lPrKJUsVM0kReDLCvtnq1mpygwggMUMIICfaADAgECAgELMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw
EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL
Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMC
WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNV
BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl
cnNvbmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrt
ZaeSBl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaF
PmzzlZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAw
HwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ
6TH66bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQ
fGuRb4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31
AG70HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy
ZWVtYWlsIFJTQSAxOTk5LjkuMTYCAwL9OjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQwOTA5NTM1N1owIwYJKoZIhvcNAQkE
MRYEFLo8XZhd9ukyA8NoV7ZIMnDe6kNNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MA0GCSqGSIb3DQEBAQUABIGAVWjLvKnDW1qRIv7ypLP6KS6CnL1bOFX5DliUoYNtXb36HdGe
xrM0Ssm2MSc+nX5/1FyH2TkyDvmZJ+4kQRcfawaLokyqxpsC7o/fA4XjjuPVlDjvbvu8okbd
fjYDnk4O/OwDsyp0x45Ftw1UC3A28wIzeSEkD/AsCtK+3IfrX48=
--------------ms82E20A2B6BA3B9FA951C95E9--


_______________________________________________
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 Apr  9 06:53:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02644
	for ; Mon, 9 Apr 2001 06:53:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4141D4433A; Mon,  9 Apr 2001 06:53:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106])
	by lists.bell-labs.com (Postfix) with ESMTP id 16C8244336
	for ; Mon,  9 Apr 2001 06:52:35 -0400 (EDT)
Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25])
	by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id DAA19350;
	Mon, 9 Apr 2001 03:52:26 -0700 (PDT)
Message-ID: <3AD1944A.EBF9B425@indigosw.com>
From: Carmelo Zaccone 
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox 
Cc: "sip-implementors@cs.columbia.edu" ,
        "sip@lists.bell-labs.com" 
References: <3ACCA3AD.984B8365@indigosw.com> <15052.42559.552988.636121@conrail.cs.columbia.edu>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7E3E8D2B1AB21A54258EEAFF"
Subject: [SIP] Re: [Sip-implementors] Message integrity with digest
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, 09 Apr 2001 12:51:54 +0200

This is a cryptographically signed message in MIME format.

--------------ms7E3E8D2B1AB21A54258EEAFF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



	Hi Jonathan,

> [...]
> A much cleaner (though more bandwidth-intensive) way of solving this
> problem would be to define a 'message/sip' MIME type, which duplicates all
> the end-to-end headers and includes the body, and then run auth-int
> integrity checking over *that*.  Headers inside the message/sip body 'win'
> over the headers in the authenticated body.  This is much more robust in the
> presence of intermediate proxies which might mangle or re-order headers.
> 
> A 'message/sip' MIME type would also lets us use S/MIME and PGP/MIME
> authentication and encryption on message headers.
> 
> This discussion should maybe move to the main sip list?

	This idea seems indeed cleaner but as you mention, it 
	suffers from the bandwith point of view.
	This is even more consuming if you take into consideration the
	scenario where multiple challenges are proposed and therefore 
	multiple credentials have to be provided.

	e.g. 
	UA1 calls UA2 via Proxy P1 and Proxy P2
	UA1 -> P1 -> P2 -> UA2

	Let's imagine that P1, P2 and UA2 are requesting authentication to UA1

	This will lead to a message with the possible following skeletton

	INVITE ... SIP/2.0
	h1
	h2
	h3
	Px-Auth (for P1)
	Px-Auth (for P2)........./\
	Auth    (for UA2)..../\   |
	h4.............../\   |   |
	h5                |   |   |
	h6                |   |   |
	CRLF              |   |   |
	BODY.............\/..\/..\/
                         Chk Chk Chk
			 at  at  at
			 UA2 P1  P2

	Using the idea to play with the message/sip MIME type, we will also
	need to play with multiparts MIME.
	Indeed, every entity realising a check on the credentials has
	a different 'body' to sign (cf picture). This will imply that we 
	need to set the content-type of the SIP message not to message/sip
	but to multipart-mime such as to place the different signated bodies
	in different multipart-body. (each multipart-body having the content-type 
	set to message/sip)
	This obviously will increase significantly the message size and also
	implies providing a mechanism (e.g. sections order) for the 
	determination of which multipart-body is for which checking entity.

	Anyway, as it is mentioned in the SIP spec. at section 6,
	'If authentication is used, the rules in Section 13.2 apply. Proxies
	SHOULD NOT re-order header fields'
	(maybe we need to change this to MUST NOT ?)  
	
	We have now two choices of doing the same thing. Either we select one,
	or we decide to enable both...

	Cheers,

		Carmelo


-- 
...........................................................
  Indigo                         Carmelo Zaccone             
    Software                       Head Software Engineer  
                                                           
  Indigo Software Group, Inc.                              
        505 Montgomery Street               50 rue Wiertz         
      San Francisco, CA 94111              Brussels, 1050        
                          USA                     Belgium               
                                                            
      Phone: 1 (415) 887-3511      Phone : +32 2 230 3594  
      Fax  : 1 (415) 887-3001      Direct: +32 2 235 0955  
                                   Fax   : +32 2 280 2676  
...........................................................
--------------ms7E3E8D2B1AB21A54258EEAFF
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcEwggKlMIICDqADAgECAgMC/TowDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDcyOTA4NDA0MFoXDTAxMDcyOTA4NDA0
MFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYU
Y2FybWVsb0BpbmRpZ29zdy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMscjUn0
bWLZVJy6I5bTZnLKm7KzvuQfWngwyWymRpz0dL8MOZILegqPuleEQBAjdkYkkIry836xdt6C
6BI96vzdhYHxkMrs/C6vjOxMS540pewaSe92Qd7iZMxqI0xiCgAdRyvbqe6WzvQq7McKvW+V
JjyAyWC9shLIdk3DwbChAgMBAAGjUjBQMB8GA1UdEQQYMBaBFGNhcm1lbG9AaW5kaWdvc3cu
Y29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJ
KoZIhvcNAQEEBQADgYEASJe+fm1ekU/kOo7wJlkh6YMZsd15ejoVA5aVVpyuR7u0mcsn0OR5
pEICbdJrnjFwN7FkEAhJ6vl2sv77BmhWJlSKT0lqempDWKCFG+7w8VqaomqFB1oQhVQo5TBG
Grh9m9ztHDMIVf8bJh6ED/lPrKJUsVM0kReDLCvtnq1mpygwggMUMIICfaADAgECAgELMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw
EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL
Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMC
WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNV
BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl
cnNvbmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrt
ZaeSBl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaF
PmzzlZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAw
HwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ
6TH66bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQ
fGuRb4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31
AG70HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0
ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy
ZWVtYWlsIFJTQSAxOTk5LjkuMTYCAwL9OjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQwOTEwNTE1N1owIwYJKoZIhvcNAQkE
MRYEFKtVkxKF2jdJr8R/F2M4EBrQaHi3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MA0GCSqGSIb3DQEBAQUABIGALngtSsukqfqYuuqcubqtU6DKyo4K+CI+l7OyxP3jii50Wl1y
+MpOSRtEfIaZqwBJS9r/Q2AXJjT4V/7Bmi2NcirfuX9TFRZk0m+BKoXJCNfDm1iWeWcZnOUh
YT1wJcBI9hn/KhX8sF85JEPmEa9XNeWsxASlQGyosI5VbkKMmNA=
--------------ms7E3E8D2B1AB21A54258EEAFF--


_______________________________________________
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 Apr  9 10:03:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07144
	for ; Mon, 9 Apr 2001 10:03:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 654214433D; Mon,  9 Apr 2001 10:03: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 E26AA44336
	for ; Mon,  9 Apr 2001 10:02:13 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Apr  9 09:58:45 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id B66CB44380; Mon,  9 Apr 2001 09:47:47 -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 32B654437D
	for ; Mon,  9 Apr 2001 09:47:47 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 9 Apr 2001 14:47:46 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB001AC318B@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" 
To: "'Mayank Sharma'" ,
        "Chen, Xin (Xin)" ,
        "'sip@lists.bell-labs.com'" ,
        "'Jonathan Rosenberg'" 
Subject: RE: [SIP] A question about Cancel request
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
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, 9 Apr 2001 14:47:38 +0100

We have a clear incompatibility in the SIP drafts here.

While draft-ietf-sip-call-flows-03.txt section 3.2.3 implies that the
expected action is to send a CANCEL, we have been unable to find any text in
the bis-02 draft indicating any special use of CANCEL from a proxy in this
case. 

The only text we have found is text that says anybody can send a CANCEL at
any time.

Whether it is MUST, MAY or MUST NOT I believe we do need some text on this
subject.

My view is that it would say MAY, possibly followed by some guidance
comments on conditions when it might be more appropriate than others.

by the way, the signalling flows draft says the CANCEL is sent 7 times. I
thought 11 was the more appropriate number in this case, using both T1 and
T2.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
> Sent: 	04 April 2001 7:30
> To: 	'Mayank Sharma'; Chen, Xin (Xin); sip@lists.bell-labs.com
> Subject: 	RE: [SIP] A question about Cancel request
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Mayank Sharma [mailto:mayanks@mindtree.com]
> > Sent: Tuesday, April 03, 2001 1:46 AM
> > To: Chen, Xin (Xin); sip@lists.bell-labs.com
> > Subject: RE: [SIP] A question about Cancel request
> > 
> > 
> > > I have a basic question about sip.
> > > Cancel request is used to cancel a pending INVITE.
> > > In sip signalling establishment procedure, if the callee 
> > > agent for some
> > > reason fails, it can't receive anything from its proxy, after 
> > > the proxy
> > > server of the callee retransmittes 6 times INVITE messges, it 
> > > should give up
> > > sending INVITE. My quesiton is whether the Cancel request is 
> > > needed to send
> > > out by the proxy server to the callee, if so, it will cause 
> > > another 11 times
> > > cancle request beeing sent.
> > 
> > The Cancel is required to be sent to the callee. Simple 
> > reason being that the
> > 
> > proxy does not know weather the callee UA is down or is 
> > simply not responding
> > for the time being. Sending Cancel ensures that in case UA is 
> > not down this
> > Cancel
> > will cancel the previous Invite, and the UA is not supposed 
> > to respond to
> > that Invite
> > at a later stage.
> 
> Actually, I have debated whether or not CANCEL is useful in the case where
> you never received any provisional response at all, not even a 100. This
> is
> likely a sign that the device or the network has failed, in which case the
> CANCEL is not useful. 
> 
> I would tend to think that the best answer is to say that if you never
> receive a provisional response, you MAY send a CANCEL, but its not
> mandatory. If you do get a provisional response, you SHOULD CANCEL upon
> timeout.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.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.
> 

_______________________________________________
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 Apr  9 10:24:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07594
	for ; Mon, 9 Apr 2001 10:24:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2160744354; Mon,  9 Apr 2001 10:24:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from brahma01.netbrahma.com (unknown [164.164.70.67])
	by lists.bell-labs.com (Postfix) with ESMTP id F3AF94433D
	for ; Mon,  9 Apr 2001 10:23:53 -0400 (EDT)
Received: from netbrahma.com (SUNILK [172.16.72.151]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 23F753HH; Mon, 9 Apr 2001 19:54:35 +0530
Message-ID: <3AD1C62D.6128C55B@netbrahma.com>
From: "T.Sunil Kumar" 
Organization: Netbrahma Technologies Pvt. Ltd
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bell - SIP 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Few queries after reading 2543 rfc...
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, 09 Apr 2001 19:54:45 +0530
Content-Transfer-Encoding: 7bit

Hi guys,

We're seeking explanations for the following queries that raised after
going thru SIP rfc 2543. Can anyone of you please respond....

1) What is the importance of 'tag' parameter in 'To' header field in
response. RFC says that it is useful to differentiate responses when an
intermediate proxy forks the request. How does a proxy or User agent
client maps a response to its host using 'tag' parameter when that 'tag'
was not sent in the request.

2) What is the significance of 'Cseq' header field. RFC says that ACK
request should contain Cseq same as corresponding INVITE request but BYE
should increment the sequence number in Cseq - why?

3)  When the callee responds (in its 200 response) with a new URI in
Contact header field, the caller would send ACK request to the new URI
mentioned by the callee. How does the session description bargain happen
between caller and new callee  if there is no session information passed
in ACK request - pl. refer to example 16.2

4) When does the bearer path/voice path become through between callee
and caller - is it after caller receives 200 response OR after caller
send ACK request for 200 response.

Thank you so much for your time and help.

Best regards,
--Sunil

T.Sunil Kumar
Net Brahma Technologies
Internext Networking Software
A Microland Group Venture
sunilk@netbrahma.com
http://www.netbrahma.com
Tel : 91.80. 552 1451/5011/5012/5014 ext 269/270
Fax : 91.80. 553 7233



_______________________________________________
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 Apr  9 13:36:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12699
	for ; Mon, 9 Apr 2001 13:36:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 04A2D4433D; Mon,  9 Apr 2001 13:36:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lists.bell-labs.com (Postfix) with ESMTP id 256704433A
	for ; Mon,  9 Apr 2001 13:35:53 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA17956 for ; Mon, 9 Apr 2001 10:35:42 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA05307 for ; Mon, 9 Apr 2001 10:35:02 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 9 Apr 2001 12:34:32 -0500
Message-ID: <557F0D0BBE89D411A085009027B0F7412688CB@IL27EXM08.cig.mot.com>
From: Ziyad Nigel-NZIYAD1 
To: sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [SIP] Status of draft-agrawal-sip-h323-interworking-00.txt
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, 9 Apr 2001 12:34:31 -0500

Hi!
 What is the status of draft-agrawal-sip-h323-interworking-00.txt? I have in
my notes that it was decided at IETF 50 not to move forward on it. Is that
correct?

Thank you,

Dr. Nigel A. Ziyad
Senior Staff Engineer
Motorola GTSS--Network Standards & Advanced Technology
Phone: 847-632-2098    Fax: 847-632-7912
Pager (2-way): 888-478-0351 or 4780351@skytel.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@lists.bell-labs.com  Mon Apr  9 17:23:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17261
	for ; Mon, 9 Apr 2001 17:23:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9DB0544338; Mon,  9 Apr 2001 17:23:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by lists.bell-labs.com (Postfix) with ESMTP id B8F3244336
	for ; Mon,  9 Apr 2001 17:22:04 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f39LM3Z25016;
	Mon, 9 Apr 2001 17:22:03 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id RAA10273; Mon, 9 Apr 2001 17:20:53 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <2S9Y0XPN>; Mon, 9 Apr 2001 17:22:02 -0400
Message-ID: 
From: "Roy, Radhika R, ALCOO" 
To: Ziyad Nigel-NZIYAD1 ,
        sip-implementors@cs.columbia.edu, sip@lists.bell-labs.com
Subject: RE: [SIP] Status of draft-agrawal-sip-h323-interworking-00.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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: Mon, 9 Apr 2001 17:22:01 -0400

Hi, Nigel:

Your note is NOT correct. The draft has been put for the last call and is
moving through the IETF process as required.

Hope this will clarify the things to you. 

(Kindly see the latest draft in the following URL:
http://search.ietf.org/internet-drafts/
draft-agrawal-sip-h323-interworking-reqs-02.txt)

Best regards,
Radhika R. Roy

-----Original Message-----
From: Ziyad Nigel-NZIYAD1 [mailto:Nigel.A.Ziyad@motorola.com]
Sent: Monday, April 09, 2001 1:35 PM
To: sip-implementors@cs.columbia.edu; sip@lists.bell-labs.com
Subject: [SIP] Status of draft-agrawal-sip-h323-interworking-00.txt


Hi!
 What is the status of draft-agrawal-sip-h323-interworking-00.txt? I have in
my notes that it was decided at IETF 50 not to move forward on it. Is that
correct?

Thank you,

Dr. Nigel A. Ziyad
Senior Staff Engineer
Motorola GTSS--Network Standards & Advanced Technology
Phone: 847-632-2098    Fax: 847-632-7912
Pager (2-way): 888-478-0351 or 4780351@skytel.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.

_______________________________________________
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 Apr  9 18:25:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18159
	for ; Mon, 9 Apr 2001 18:25:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AB30344343; Mon,  9 Apr 2001 18:25:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 1719B4433C
	for ; Mon,  9 Apr 2001 18:24:01 -0400 (EDT)
Received: from zrchb213.us.nortel.com by smtprch1.nortel.com;
          Mon, 9 Apr 2001 16:00:07 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <2FFM7PKK>; Mon, 9 Apr 2001 15:59:57 -0500
Message-ID: <63E0DAD7784FD21188310000F80824B304B97DE3@zmpkdx02.us.nortel.com>
From: "Mo Zonoun" 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] transfer call flows
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C138.017C0C10"
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, 9 Apr 2001 15:59:45 -0500

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_01C0C138.017C0C10
Content-Type: text/plain;
	charset="iso-8859-1"

I posted the following question while back but I didn't get any response.
How do you make sure that a new INVITE in a Call Transfer gets to the
correct UA-C when there are multiple UA candidates, including the case where
the UA-C is a gateway to another network.

Mo Zonoun 


------_=_NextPart_001_01C0C138.017C0C10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] transfer call flows 




I posted the following question while back but I =
didn't get any response.

How do you make sure that a new INVITE in a Call =
Transfer gets to the correct UA-C when there are multiple UA =
candidates, including the case where the UA-C is a gateway to another =
network.



Mo Zonoun 





------_=_NextPart_001_01C0C138.017C0C10--

_______________________________________________
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 Apr  9 18:46:23 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18402
	for ; Mon, 9 Apr 2001 18:46: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 6E17144378; Mon,  9 Apr 2001 18:44:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id B706444373
	for ; Mon,  9 Apr 2001 18:43:47 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f39GgnP07473;
	Mon, 9 Apr 2001 11:42:50 -0500
Message-ID: <008201c0c146$7b3a8c80$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "Jonathan Rosenberg" , ,
        
References: 
Subject: Re: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)
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
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, 9 Apr 2001 17:43:21 -0500
Content-Transfer-Encoding: 7bit


Lower "sanity" bounds in UA1 or UA2 have the opportunity to correct the
situation.

An interesting point -- (in the absence of reply modification) the
session-timer approval process appears to give the proxy closest to the
terminating UA significantly more "say" about the session timer value. Of
course, a rogue proxy could just retransmit INVITES as often as it wants, no
need to have the UA do it on its behalf by munging session-timer  . . . so
perhaps we're barking a a tree with too many squirrels in it . . .

However, another edge condition may result -- perhaps one proxy tolerates a
session-timer value (T)  in the range A
To: "'Dean Willis'" ; "Jonathan Rosenberg"
; ; 
Sent: Wednesday, April 04, 2001 9:04 AM
Subject: RE: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)


>
>
>
>
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Wednesday, April 04, 2001 3:16 AM
> > To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com
> > Subject: Re: [SIP] Session timer considered harmful (was RE:
> > draft-ietf-sip-session- timer: refresh rate)
> >
> >
> >
> > Yes, but if each of the proxies along the path knows what its
> > safe "lower
> > bound" on retransmits is and refuses to pass a session timer
> > with a value
> > lower than the safety threshold, the attack can be avoided.
> > This isn't a
> > protocol change.
>
> No, thats not true. Consider the case of:
>
> UA1 -> P1 -> P2 -> P3 -> UA2
>
> UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it too
> low. P2 increases it. Now the request goes to P3, which reduces it to an
> even lower value. This is forwarded to UA2, which reflects it in the
> response, and its forwarded upstream towards UA1. I guess P2 could discard
> the response, but thats not really a good thing, since the transaction
will
> end up timing out. Even then, rogue P1 could reduce the timer value in the
> response once its passed P2.
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.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@lists.bell-labs.com  Mon Apr  9 18:55:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18445
	for ; Mon, 9 Apr 2001 18:55: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 9D66B44373; Mon,  9 Apr 2001 18:55:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id C66B644372
	for ; Mon,  9 Apr 2001 18:54:28 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f39GrqP07512;
	Mon, 9 Apr 2001 11:53:52 -0500
Message-ID: <009801c0c148$06268e10$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "Sean Olson (EUS)" , ,
        
References: 
Subject: Re: [SIP] Response if user not registered?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0095_01C0C11E.1CC86A50"
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@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, 9 Apr 2001 17:54:24 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0095_01C0C11E.1CC86A50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [SIP] Response if user not registered?I disagree that barring a =
terminal from sending an INVITE through a proxy because that terminal =
has not sent an INVITE through that proxy is a reasonable thing to do. =
That is -- I don't think its a good idea, and I don't think the 3GPP =
model technically requires it. Certainly you might wish to refuse to =
transit messages for a device that doesn't have a layer-2 registration, =
as such a message would rather obviously be a spoof of some kind. So, =
there's sort of a layer 2/3 confusion in the concept of registration in =
3GPP, which I believe can be traed back to the semantics of the GSM =
registration process.

But in any case, the main problem here is that the 3GPP visited proxy, =
or P-CSCF, is attempting to discover the home edge proxy (I-CSCF or =
S-CSCF) that will process future INVITEs from the mobile terminal by =
analyzing the target of the terminal's REGISTER message. Practically =
speaking, the P-CSCF is deducing an outbound proxy rule for the mobile =
terminal by observing the target of RESGISTERs from that terminal. In =
other words, this approach uses REGISTER to force source routing for =
INVITEs -- and it's all a means for forcing INVITES to be processed by =
both local and remote proxies BEFORE applying the usual INVITE =
destination resolution algorithm. It's a source-routing kludge, and =
there's GOT to be a better way. At least I hope there is.

--
Dean

  ----- Original Message -----=20
  From: Sean Olson (EUS)=20
  To: 'brett@broadsoft.com' ; 'sip@lists.bell-labs.com'=20
  Sent: Wednesday, April 04, 2001 9:20 AM
  Subject: RE: [SIP] Response if user not registered?


  >> I believe this issue in 3gpp arises because for them, they=20
  >> have "extended"=20
  >> register to do more than create bindings. They use it to=20
  >> assign the proxy=20
  >> which will handle both incoming and outgoing calls for the user, =
and=20
  >> basically do not allow outgoing calls until such a selection=20
  >> is made.=20

  This is incorrect. The REGISTER process in 3GPP is used=20
  for address bindings. The selection of a local outbound=20
  proxy is done BEFORE the registration occurs. Barring=20
  an outbound request because a terminal is not registered=20
  at the local outbound proxy is a reasonable thing to do.=20
  Letting the user know that this is the case is also=20
  a reasonable thing to do. 403 seems appropriate.=20

  /sean=20


------=_NextPart_000_0095_01C0C11E.1CC86A50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [SIP] Response if user not registered?






I disagree that barring a terminal from =
sending an=20
INVITE through a proxy because that terminal has not sent an INVITE =
through that=20
proxy is a reasonable thing to do. That is -- I don't think its a good =
idea, and=20
I don't think the 3GPP model technically requires it. Certainly you =
might wish=20
to refuse to transit messages for a device that doesn't have a layer-2=20
registration, as such a message would rather obviously be a spoof of =
some kind.=20
So, there's sort of a layer 2/3 confusion in the concept of registration =
in=20
3GPP, which I believe can be traed back to the semantics of the GSM =
registration=20
process.


 


But in any case, the main problem here =
is that the=20
3GPP visited proxy, or P-CSCF, is attempting to discover the home =
edge=20
proxy (I-CSCF or S-CSCF) that will process future INVITEs from the =
mobile=20
terminal by analyzing the target of the terminal's REGISTER message. =
Practically=20
speaking, the P-CSCF is deducing an outbound proxy rule for the mobile =
terminal=20
by observing the target of RESGISTERs from that terminal. In other =
words, this=20
approach uses REGISTER to force source routing for INVITEs -- and it's =
all a=20
means for forcing INVITES to be processed by both local and remote =
proxies=20
BEFORE applying the usual INVITE destination resolution algorithm. It's =
a=20
source-routing kludge, and there's GOT to be a better way. At least I =
hope there=20
is.


 


--
Dean


 



  
----- Original Message ----- 

  From:=20
  Sean=20
  Olson (EUS) 
  
To: 'brett@broadsoft.com' ; 'sip@lists.bell-labs.com' =


  
Sent: Wednesday, April 04, 2001 =
9:20=20
  AM

  
Subject: RE: [SIP] Response if =
user not=20
  registered?

  


  
>> I believe this issue in 3gpp arises because =
for them,=20
  they 
>> have "extended" =

>> register to do more than create bindings. They use =
it to=20
  
>> assign the proxy 
>> which will handle both incoming and outgoing calls =
for the=20
  user, and 
>> basically do not allow =
outgoing=20
  calls until such a selection 
>> is =
made.=20
  

  
This is incorrect. The REGISTER process in 3GPP is =
used=20
  
for address bindings. The selection of a local=20
  outbound 
proxy is done BEFORE the =
registration occurs.=20
  Barring 
an outbound request because a =
terminal is not=20
  registered 
at the local outbound proxy is a =
reasonable=20
  thing to do. 
Letting the user know that this =
is the=20
  case is also 
a reasonable thing to do. 403 =
seems=20
  appropriate. 

  
/sean 


------=_NextPart_000_0095_01C0C11E.1CC86A50--


_______________________________________________
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 Apr  9 19:19:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18945
	for ; Mon, 9 Apr 2001 19:19: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 C2D6244372; Mon,  9 Apr 2001 19:19: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 8723344368
	for ; Mon,  9 Apr 2001 19:18:18 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA13691;
	Mon, 9 Apr 2001 19:21:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 9 Apr 2001 19:18:16 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Dean Willis'" ,
        Jonathan Rosenberg , brett@broadsoft.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-si
	p-session- timer: refresh rate)
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: Mon, 9 Apr 2001 19:18:11 -0400



 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Monday, April 09, 2001 6:43 PM
> To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> 
> Lower "sanity" bounds in UA1 or UA2 have the opportunity to 
> correct the
> situation.
> 
> An interesting point -- (in the absence of reply modification) the
> session-timer approval process appears to give the proxy 
> closest to the
> terminating UA significantly more "say" about the session 
> timer value. 

Yes. That is the essense of the problem, for which this Min-Timer header (or
whatever I had called it) was meant to solve. 


> Of
> course, a rogue proxy could just retransmit INVITES as often 
> as it wants, no
> need to have the UA do it on its behalf by munging 
> session-timer  

Not true at all! Getting someone else to send lots of packets, without
having to do it yourself, is the essence of smurf attacks. I have described
in a previous note, a very nice attack which can bring down an origination
provider network:

http://lists.bell-labs.com/pipermail/sip/2001q2/006528.html

Also, there are really TWO separate problems here:

1. how to deal with the case, where all elements are cooperating, and we
want to make sure that the session timer is not lower than the minimum of
the smallest allowed timers across all proxies. For that, this Min-Timer
value has been proposed.

2. how to deal with the case where a rogue proxy or UA can use session timer
to launch attacks against network elements.

> However, another edge condition may result -- perhaps one 
> proxy tolerates a
> session-timer value (T)  in the range A tolerates C where A of session-timer
> is acceptable to all proxies. On the other hand, NO 
> negotation protocol can
> meet these requirements . . . . so I guess we need 
> bidirectional negotation
> to be able to detect it.

Ouch... I'd rather not go down that avenue.

In this case, I'd rather enforce the lower limit above the higher one. That
is, the proxy who wants A ----- Original Message -----
> From: "Jonathan Rosenberg" 
> To: "'Dean Willis'" ; "Jonathan Rosenberg"
> ; ; 
> 
> Sent: Wednesday, April 04, 2001 9:04 AM
> Subject: RE: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: Wednesday, April 04, 2001 3:16 AM
> > > To: Jonathan Rosenberg; brett@broadsoft.com; 
> sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Session timer considered harmful (was RE:
> > > draft-ietf-sip-session- timer: refresh rate)
> > >
> > >
> > >
> > > Yes, but if each of the proxies along the path knows what its
> > > safe "lower
> > > bound" on retransmits is and refuses to pass a session timer
> > > with a value
> > > lower than the safety threshold, the attack can be avoided.
> > > This isn't a
> > > protocol change.
> >
> > No, thats not true. Consider the case of:
> >
> > UA1 -> P1 -> P2 -> P3 -> UA2
> >
> > UA1 requests session timer. Its OK to P1. Goes to P2, which 
> thinks it too
> > low. P2 increases it. Now the request goes to P3, which 
> reduces it to an
> > even lower value. This is forwarded to UA2, which reflects it in the
> > response, and its forwarded upstream towards UA1. I guess 
> P2 could discard
> > the response, but thats not really a good thing, since the 
> transaction
> will
> > end up timing out. Even then, rogue P1 could reduce the 
> timer value in the
> > response once its passed P2.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.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.
> 

_______________________________________________
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 Apr  9 19:47:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19596
	for ; Mon, 9 Apr 2001 19:47:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2344E44338; Mon,  9 Apr 2001 19:47:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id B795444336
	for ; Mon,  9 Apr 2001 19:46:01 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f39HjQP07658;
	Mon, 9 Apr 2001 12:45:27 -0500
Message-ID: <00c901c0c14f$3a97fbf0$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "Christian Huitema" ,
        
References: 
Subject: Re: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)
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
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, 9 Apr 2001 18:45:57 -0500
Content-Transfer-Encoding: 7bit


Christian's analysis is excellent, where session-timer is used by devices
supporting telephony applications.

But that's not all SIP does -- and I suggest that the proxies in the middle
really shouldn't care about or be bounded by the limits of the telephony
application.

What are the implications if the negotiated session is a DOOM game? What if
it's a one-frame-per-hour security camera? What about ten-second
microvideos? What happends when we apply SIP to interplanetary traffic,
where Speed-of-Light assures some really long delays? (Yes, I know Vint is
working with JPL on Interplanetary Internet -- I hope to use SIP to call
somebody on Mars within my lifetime -- and I hope we have IPv6 by then . .
.).

The real questions are, what is the shortest reasonable period that one can
expect SIP signaling to complete within, and for how many of multiples of
this  time periods do we wish to hold state in stateful devices?

I argue that minimum session-timer timer values would be more appropriately
derived from the fundamental timers of SIP signaling, not from
application-specific timers.

One might envision a chain of 100 stateful proxies between two endpoints.
Assuming that the maximal response-reply cycle period of roughly 20 seconds
results at each hop, one might have to hold state for quite a long time
before one decided on giving up on the call . . .

However, I suspect any such estimation method would still end up with
minimal timers for ANY network topology in the roughly one-minute range . .
.

One could readily prevent Session-Timer from being used in a fashion
exceeding this value by using only realtive time descriptions and expressing
those times in mutiples of the "minimum" value. For example, assuming we use
minutes, the smallest expressible timer  is 1 minute, which fiys within the
bounds I assumed earlier in this message. Or we could use 100s of seconds .
. .

On the other hand, history shows that protocols that assume "slowness" in
the world often have to be "sped up" to deal with the
multiple-order-of-magnitude changes that occur in the environment every few
years. Perhaps in a few years we'll be dealing with proxies handling a
billion calls per second and only 10ms of  state capacity . . .

--
Dean


----- Original Message -----
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ; "Dean Willis"
; ;

Sent: Wednesday, April 04, 2001 5:11 PM
Subject: RE: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)


> The session timer belongs to the category of "safety belts" tools. It
> should be though as a last resort tool, to wipe up sessions that are
> left open after both clients die, or one single client dies and the
> other is too dumb to notice. (If any of the client is up and notices,
> e.g. through absence of RTP and RTCP traffic, that client sends a BYE,
> and the problem is solved; same is true if there is a human listening to
> a phone through a gateway.)
>
> Let's first consider the standard RTCP interval of 5 seconds. I would
> not want to drop a session just because I lost one RTCP packet, so I
> would wait for at least 10 seconds, or more likely 30 seconds, before
> raising an alarm. Setting a session timer to less than 30 seconds should
> be a protocol violation, causing some 4xx error.
>
> Let's then consider the average duration of a business call, typically
> between one or a few minutes. Enforcing a heartbeat creates an extra
> load on the proxies. If the timer is of the same duration as the average
> call, the extra load is about 33% -- add a heart beat + response to a
> typical exchange of INVITE/180/200/ACK/BYE/200. I personally find 33% a
> bit large for the added value; I would rather aim for a few percents,
> i.e. a session timer of at least 10 minutes.
>
> -- Christian Huitema
>
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> >
> > > -----Original Message-----
> > > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > >
> > > Yes, but if each of the proxies along the path knows what its
> > > safe "lower
> > > bound" on retransmits is and refuses to pass a session timer
> > > with a value
> > > lower than the safety threshold, the attack can be avoided.
> > > This isn't a
> > > protocol change.
> >
> > No, thats not true. Consider the case of:
> >
> > UA1 -> P1 -> P2 -> P3 -> UA2
> >
> > UA1 requests session timer. Its OK to P1. Goes to P2, which thinks it
> too
> > low. P2 increases it. Now the request goes to P3, which reduces it to
> an
> > even lower value. This is forwarded to UA2, which reflects it in the
> > response, and its forwarded upstream towards UA1. I guess P2 could
> discard
> > the response, but thats not really a good thing, since the transaction
> > will
> > end up timing out. Even then, rogue P1 could reduce the timer value in
> the
> > response once its passed P2.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.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.
>
> _______________________________________________
> 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 Apr  9 20:02:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19945
	for ; Mon, 9 Apr 2001 20:02:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5E8744358; Mon,  9 Apr 2001 20:02:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 1563C44343
	for ; Mon,  9 Apr 2001 20:01:37 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 09 Apr 2001 17:00:13 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <2RYQ4DFA>; Mon, 9 Apr 2001 17:00:12 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD5B886C@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" 
To: jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 16CC928717303-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Subject: [SIP] Question Regarding Processing of Via by UAC
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, 9 Apr 2001 17:00:06 -0700
Content-Transfer-Encoding: 7bit

Hi,

I had a quick question regarding the processing of Via field by an UAS as
described in section 6.47.5 of the bis02 titled "Forwarding Responses". The
last bullet item in this section states that,

"Otherwise, if it is not receiver-tagged, send the response to the address
indicated by the sent-by value in the SECOND Via header field".

Why "sent-by" value in the SECOND Via header field? Shouldn't it read the
"First" / Topmost?

Thanks,
Venkatesh 


_______________________________________________
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 Apr  9 20:12:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20142
	for ; Mon, 9 Apr 2001 20:12:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 18D5444385; Mon,  9 Apr 2001 20:12:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 60C2444358
	for ; Mon,  9 Apr 2001 20:11:42 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f39IB6P07734;
	Mon, 9 Apr 2001 13:11:06 -0500
Message-ID: <012701c0c152$d04cb160$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "Jonathan Rosenberg" , ,
        
References: 
Subject: Re: [SIP] Session timer considered harmful (was RE: draft-ietf-sip-session- timer: refresh rate)
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
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, 9 Apr 2001 19:11:37 -0500
Content-Transfer-Encoding: 7bit


Ok, if a proxy doesn't stay in the route, it has no need to set the
session-timer value, right?

If a proxy DOES stay in the route, there's no amplifier effect because the
proxy that set the low timer is still being forced to forward the results .
. .

What you really seem worried about is a proxy, in the path ONLY during the
first INVITE, using session-timer to gain amplification via each of the
terminal nodes for each call transiting that proxy.

So, could we tie the ability to set session-timer to record-route?

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" 
To: "'Dean Willis'" ; "Jonathan Rosenberg"
; ; 
Sent: Monday, April 09, 2001 6:18 PM
Subject: RE: [SIP] Session timer considered harmful (was RE:
draft-ietf-sip-session- timer: refresh rate)


>
>
>
>
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Monday, April 09, 2001 6:43 PM
> > To: Jonathan Rosenberg; brett@broadsoft.com; sip@lists.bell-labs.com
> > Subject: Re: [SIP] Session timer considered harmful (was RE:
> > draft-ietf-sip-session- timer: refresh rate)
> >
> >
> >
> > Lower "sanity" bounds in UA1 or UA2 have the opportunity to
> > correct the
> > situation.
> >
> > An interesting point -- (in the absence of reply modification) the
> > session-timer approval process appears to give the proxy
> > closest to the
> > terminating UA significantly more "say" about the session
> > timer value.
>
> Yes. That is the essense of the problem, for which this Min-Timer header
(or
> whatever I had called it) was meant to solve.
>
>
> > Of
> > course, a rogue proxy could just retransmit INVITES as often
> > as it wants, no
> > need to have the UA do it on its behalf by munging
> > session-timer
>
> Not true at all! Getting someone else to send lots of packets, without
> having to do it yourself, is the essence of smurf attacks. I have
described
> in a previous note, a very nice attack which can bring down an origination
> provider network:
>
> http://lists.bell-labs.com/pipermail/sip/2001q2/006528.html
>
> Also, there are really TWO separate problems here:
>
> 1. how to deal with the case, where all elements are cooperating, and we
> want to make sure that the session timer is not lower than the minimum of
> the smallest allowed timers across all proxies. For that, this Min-Timer
> value has been proposed.
>
> 2. how to deal with the case where a rogue proxy or UA can use session
timer
> to launch attacks against network elements.
>
> > However, another edge condition may result -- perhaps one
> > proxy tolerates a
> > session-timer value (T)  in the range A > tolerates C > where A > of session-timer
> > is acceptable to all proxies. On the other hand, NO
> > negotation protocol can
> > meet these requirements . . . . so I guess we need
> > bidirectional negotation
> > to be able to detect it.
>
> Ouch... I'd rather not go down that avenue.
>
> In this case, I'd rather enforce the lower limit above the higher one.
That
> is, the proxy who wants A
> -Jonathan R.
>
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> > ----- Original Message -----
> > From: "Jonathan Rosenberg" 
> > To: "'Dean Willis'" ; "Jonathan Rosenberg"
> > ; ;
> > 
> > Sent: Wednesday, April 04, 2001 9:04 AM
> > Subject: RE: [SIP] Session timer considered harmful (was RE:
> > draft-ietf-sip-session- timer: refresh rate)
> >
> >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > > > Sent: Wednesday, April 04, 2001 3:16 AM
> > > > To: Jonathan Rosenberg; brett@broadsoft.com;
> > sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] Session timer considered harmful (was RE:
> > > > draft-ietf-sip-session- timer: refresh rate)
> > > >
> > > >
> > > >
> > > > Yes, but if each of the proxies along the path knows what its
> > > > safe "lower
> > > > bound" on retransmits is and refuses to pass a session timer
> > > > with a value
> > > > lower than the safety threshold, the attack can be avoided.
> > > > This isn't a
> > > > protocol change.
> > >
> > > No, thats not true. Consider the case of:
> > >
> > > UA1 -> P1 -> P2 -> P3 -> UA2
> > >
> > > UA1 requests session timer. Its OK to P1. Goes to P2, which
> > thinks it too
> > > low. P2 increases it. Now the request goes to P3, which
> > reduces it to an
> > > even lower value. This is forwarded to UA2, which reflects it in the
> > > response, and its forwarded upstream towards UA1. I guess
> > P2 could discard
> > > the response, but thats not really a good thing, since the
> > transaction
> > will
> > > end up timing out. Even then, rogue P1 could reduce the
> > timer value in the
> > > response once its passed P2.
> > >
> > > -Jonathan R.
> > > ---
> > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > > http://www.dynamicsoft.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.
> >
>
> _______________________________________________
> 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 Apr  9 21:18:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20713
	for ; Mon, 9 Apr 2001 21:18:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5809A44379; Mon,  9 Apr 2001 21:18:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id BACA04435B
	for ; Mon,  9 Apr 2001 21:17:09 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 09 Apr 2001 18:15:46 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <2RYQ4DJX>; Mon, 9 Apr 2001 18:15:45 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD5B88D8@mailserver.sylantro.com>
From: "Sharath Rajasekar" 
To: "sip list" , jdrosen@dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 16CC814818446-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Subject: [SIP] Delivering Caller-ID through 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: Mon, 9 Apr 2001 18:15:42 -0700
Content-Transfer-Encoding: 7bit


Consider a SIP UA with a SIP URL userA@example.com which is associated 
with a SIP Phone. This SIP Phone has a public number (444-555-6666). 

When a call is initiated by the phone, to a PSTN number, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : UserA 
	To : Unknown 
      ...

How can one deliver the calling public number(444-555-6666 in this case) 
to the PSTN as caller-id through the gateway ?
  
Some generic tag may be used say..."pstn-number: 444-555-6666" in the 
From header, but this will mean that all gateways must support this tag.
Is there some other solution to this problem.


Regards
Sharath



_______________________________________________
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  Tue Apr 10 06:00:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10201
	for ; Tue, 10 Apr 2001 06:00:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C2B024433E; Tue, 10 Apr 2001 06:00:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gw.softfront.co.jp (gw.softfront.co.jp [202.232.222.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 900C744336
	for ; Tue, 10 Apr 2001 05:59:35 -0400 (EDT)
Received: from mail2.softfront.co.jp (mail2.softfront.co.jp [172.16.1.41])
	by gw.softfront.co.jp (8.9.3/3.7W) with SMTP id SAA43339
	for ; Tue, 10 Apr 2001 18:59:34 +0900 (JST)
Received: from shagotom by mail2.softfront.co.jp id AA00472 ; 10 Apr 2001 19:00:09 +0900
Message-ID: <004401c0c1a5$43cce540$c51010ac@softfront.co.jp>
From: "Rafiqul Islam Maruf" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0040_01C0C1F0.B3298B50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] Looking For A Quality Location Server
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 Apr 2001 19:01:50 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C0C1F0.B3298B50
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hi Everybody!

If this is not the right place to post this mail, I am extremely
sorry. Please ignore it. Otherwise:

We are looking for a quality 'Location Server' to communicate with 
SIP-Gateway. The server must be able to communicate with our LDAP 
server.

Any information (model specification and company) will be highly 
appreciated.

Maruf
---------------------------------------------
Division of R&D
Softfront, Inc., Sapporo, Japan
TEL: +81 (011) 623-1006
FAX: +81 (011) 623-1007 
WEB: www.softfront.co.jp OR www.softfront.com



------=_NextPart_000_0040_01C0C1F0.B3298B50
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable









Hi Everybody!


 




If this is not the right place to =
post this mail,=20
I am extremely


sorry. Please ignore it. =
Otherwise:


 


We are looking =
for a quality 'Location=20
Server' to communicate with 


SIP-Gateway. The=20
server must be able to communicate with our LDAP 


server.


 


Any information (model specification =
and company)=20
will be highly 


appreciated.


 


Maruf


---------------------------------------------
Division of=20
R&D


Softfront, Inc., Sapporo, =
Japan
TEL: +81 (011)=20
623-1006


FAX: +81 (011) 623-1007 


WEB: www.softfront.co.jp OR=20
www.softfront.com



 


------=_NextPart_000_0040_01C0C1F0.B3298B50--


_______________________________________________
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  Tue Apr 10 09:27:19 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14352
	for ; Tue, 10 Apr 2001 09:27: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 384844433A; Tue, 10 Apr 2001 09:27:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52])
	by lists.bell-labs.com (Postfix) with ESMTP id DC7A944336
	for ; Tue, 10 Apr 2001 09:26:28 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3ADP5J14536
	for ; Tue, 10 Apr 2001 09:25:05 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 10 Apr 2001 09:26:03 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 10 Apr 2001 09:26:04 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250C953@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Dean Willis'" ,
        "'brian.rosen@marconi.com'" ,
        "'jo@tzi.org'" 
Cc: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C1C1.2711C9E0"
X-Orig: 
Subject: [SIP] Draft SIP WG Minutes
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 Apr 2001 09:21:29 -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_01C0C1C1.2711C9E0
Content-Type: text/plain;
	charset="iso-8859-1"

Better late than never.

The SIP WG met for its first session on Monday afternoon, under the
chairmanship of Dean Willis , Brian Rosen
, and Joerg Ott .

1. Agenda Bashing
   ==============

Dean Willis introduced the meeting and session agendas.  In response to
strong representations from the Area Directors, the meeting will feature
larger segments in contrast to the brief discussions of earlier meetings.

2. Status (Dean Willis - charts)
   =============================

Currently tracking about 70 drafts.
Reached saturation point.

The Chairs are trying to get control of the workload.

2.1 Proposal For Reorganization
    ---------------------------

Proposal: split into SIP and SIPPING work groups.  Split in drafts would be
about 24:40.  Remaining drafts would be "out of scope".

Distinguish SIP from uses of SIP.

Actions: immediate split of mailing lists.
Separate WG meetings next time around.
Continue with same chairs until stable.

Discussion:
  Henning Schulzrinne  noted a potential problem with
messages posted to wrong list: it will mean extra traffic getting the
message redirected.
  Allison Mankin  observed that if the lists become
moderated to prevent message rerouting, they must have a published policy
which says all that messages will be posted (except possibly spam).  The
Chair could have a sorting policy which assigns messages to list.
  IETF mailing list interactions will create complications.
  Brian Rosen has enforced SIP/implementor's list separation through direct
notes to offenders.
  Jonathan Rosenberg  remarked that any sorting
policy won't reduce total volume, just ease processing.
  It was noted that some offenders of the current separation policy are
familiar names in SIP work.
  Last Call procedures will encourage division by referring draft to
appropriate list.

  Brian Rosen asked for comments on base idea of splitting groups.  None
were offered.

Dean explained the new web tracking of the workload.  It can be found on the
SIP WG supplemental home page.

Last Call: Chairs will push harder for comments to move drafts forward in
time to meet milestones.

2.2 Draft Charters For SIP and SIPPING
    ----------------------------------

The draft charters for SIP and SIPPING are shown on SIP WG supplemental home
page.

Key charter items for SIP:
 - 2543bis
 - call control
...
Flemming Andreassen  noted that there are open issues
regarding the privacy draft.

Key charter items for SIPPING
 - SIPT
 - hearing impaired
 - ...

SIPPING won't normally process a Standards Track change/extension to SIP.
The use of extensions etc. would be described in SIPPING.

Rohan Mahy  remarked that adding codepoints doesn't need to
go to SIP.

Area Director decree: all features which may be "required" MUST be
documented as standards-track items in SIP WG.  SIPPING would define
requirements.

Jonathan noted an open issue on ambiguity regarding Contact parameter
registration.  Allison agreed this could be a SIPPING work item.

2.3 Open Issues
    -----------
 
IN interworking.  Area Director agreement that a design team (SIN) review
related drafts and identify issues which would prevent IN from interworking
with the IN.  There was insufficient support to make this an IETF work item
(SIPPING charter item) at this point.

Firewall passage: MIDCOM owns control

Jonathan Rosenberg led a brief discussion on where call control fits.  The
basic principle is that "how to" is in SIPPING, extensions like REFER go
into SIP.

Dave Oran  suggested that in effect we would double number
of drafts we have now.  In response, H.323 interworking was cited as a
current counter-example -- no extensions are involved, so the drafts will
all be targetted to SIPPING.

Generally: there will be a number of corner cases.  Sorting them out will
require exercise of chair judgement, fed by arguments from authors.  We
could see a flow where the initial work is done in SIPPING, moves to SIP,
and finally back to SIPPING to define usage of the resulting protocol.

Security: generally a core SIP item to ensure that it is fully integrated
with the protocol.  Michael Thomas  suggested giving it to
SIPPING first because many of the issues are implementation-related.
Allison Mankin pointed out that every SIPPING draft should discuss security
issues.

A speaker referred to the work in 3GPP/3GPP2 on SIP usage to talk to
application servers: is this part of the IN mess?
Henning Schulzrinne responded that this work is not necessarily part of IN.
The speaker was concerned that the work as currently directed represented at
the least an issue of misunderstanding of Internet architecture.  The Chairs
noted that one shouldn't confuse IN with 3GPP.


3. Bis Issues (Jonathan Rosenberg) (charts)
   ========================================

Jonathan noted that the volume of mail on the list is now such that it is no
longer feasible for issues to be tracked by the leadership of the WG.  He
urged WG participants to take responsibility for tracking issues they raised
until final resolution.

3.1 Issue: SDP in response: subset of SDP in INVITE?
    ------------------------------------------------

RFC 2543 is inconsistent between the text and the examples.

Requiring that the responder send back a subset of the codecs indicated by
the initiator prevents the responder from indicating sendonly capabilities.
It is suggested as an alternative that the text indicate that each end
indicates what it can receive.

Michael Thomas noted that SDP is not adapted to negotiation.  UAs should use
re-INVITES as required for this purpose.

General agreement: the text should say that each end indicates its own
receive capabilities.

3.2 Issue: Cseq Incrementing
    ------------------------

The text says that sequence numbers should be "contiguous".  Incrementing by
1 is useful for ordering.
 
Robert Sparks  noted that the receiving end cannot
be guaranteed to see increment by 1 because of 407 sent back from an
intermediate node on a re-INVITE.

Rohan Mahy suggested that we try to capture the motivation for any agreed
solution in the meeting minutes, so we don't have to hold the discussion
again.

Resolution: the UAC should still increment by 1.
The receiver should do a sanity check on gaps and reset if it finds too
large a gap.

3.3 Issue: TCP Connection Handling
    ------------------------------

(1) Proposal: closing of TCP connections does not affect SIP state.
Assuming otherwise results in problems (per slide).
The proposal raises potential backward compatibility problems.  Jonathan
asked the implementors in the crowd whether tyhese were real.  There was
positive support for the proposal.  This will be confirmed on the list.

(2) Need text on using persistent connections with TCP.  The proposed text
was shown on a chart.

Matt Holdrege  asked if these proposals would be carried
over to SCTP.  Jonathan Rosenberg cited lack of SCTP expert involvement and
of understanding of how SCTP applies to SIP (why it would be needed).
Allison Mankin noted that SCTP application discussion has just started in
the Transport Area WG.

There was a general view that this isn't a core specification item as
phrased -- more of a BCP.  Jonathan will think of words capturing the intent
at the standards level.

3.4 Issue: Response Failover
    ------------------------

We would like calls to survive mid-transaction proxy failures.
Usage of the "received" parameter prevents SRV-based reroute.
Proposal: try the address given in the "received" parameter first.  Upon
indication of failure, use domain lookup on the Via header URI.
Problems: this only works on stateful proxies.  There are complications if
the crashed proxy forks.
Rohan Mahy suggested that the text prohibit ("SHOULD") a forking proxy from
inserting a URI in its Via header which points to proxies which cannot
handle forked requests.

3.5 Issue: Tags
    -----------

Agreed at last meeting: From tags should be mandatory.
The specification says a tag should be unique within a UA instance.  There
is value in making tags unique per call leg.  (Helpful with billing.)  On
this last point, Bill Marshall  noted that a rogue UA
could reuse tag values to confuse billing system.  Jonathan had a different
context in mind.

Jonathan's proposal: make tags unique per call.  A tag MAY contain a portion
to associate it with the creating UA instance.  
Billing or whatever would actually have to gather tags off 200 OK -- INVITE
only has the From tag.

Henning Schulzrinne suggested we not specify implementation too closely, so
that in particular, application to billing is a possibility rather than a
recommendation.  Rohan Mahy suggested that the proposal solves a non-problem
for well-behaved implementations, and by definition the others may not do
the right thing.  It was also noted that this use of tags needs at least one
trusted side.  

Jonathan(?) referred to the discussion of the use of tags to distinguish the
call-leg, as proposed in the Replaces draft.  These discussions support the
per-call uniqueness requirement.  Jonathan proposed that we add text to
indicate the implications of different implementations of tags.

4. SIP Events (Adam Roach ) (charts)
   ================================
   draft-roach-sip-subscribe-notify-03.txt

A new version of the draft is due.

Current issues:

(a) State agent -- generalization of presence agent.

(b) Subscriptions can be initiated by other than SUBSCRIBE -- 481 must
remove all subscriptions.

(c) PINT compatibility
Lawrence Conroy  noted the need for text to resolve the
inconsistency between the PINT work and the way SUBS/NOT has evolved.  Adam
assured him that the necessary text is present (assume lack of event header
implies PINT). 

(d) Throttling needs to be done.

(e) Instant notification should be sent upon subscription, even though state
is not actually resolved.  To do this, the suggestion is to send the
notification with neutral information. 
Jonathan Rosenberg and Henning Schulzrinne pointed out that the required
action may depend on the package -- a designer issue, not a blanket
requirement.  Package guidelines should require designers to talk about how
this situation is handled.  Jonathan has other guideline items which he will
provide to Adam.

(f) Authorization of subscriptions.  Jonathan Rosenberg suggested
authorization procedures also should be defined on a package by package
basis.  The question was raised, whether a QAUTH generalized mechanism is
required.  Rohan Mahy suggested that this is a special case of feature
authorization.  Ian Rytina  stated that QAUTH
has a place, but not in presence.  The issue will be further discussed in
SIMPLE/IMPP.  In general, this is an example of a SIPPING discussion item,
with outcome to be acted on by SIP.

(g) SUBSCRIBE response codes.
202 non-committal -- have to wait for Notify to give final result.
Are 403 or 603 allowable?
Does 200 mean subscription is definitively approved?
Jonathan suggests that this should be part of the package definition

(h) Denial of service concerns:
UASs should keep no state for unauthenticated SUBSCRIBE messages, to protect
themselves against denial of service attacks..
Is it reasonable to allow each userid/password combination have only one
pending SUBSCRIBE at each node?  Dean Willis pointed out that in the failure
recovery case, restart would be slow.
More discussion needed.

(i) Forking
Lots of discussion at interim meeting, no resolution.
The UAC gets multiple NOTIFYs back although only one 20x response was passed
by the forking proxy, with Record-Route ambiguity as a result.
It took some discussion for Adam to demonstrate the problem.
Proposed: two solutions, one of which SHOULD be used by any subscriber.
[Sorry I don't have them, hope they are shown on Adam's charts -- PTT] The
event package should specify the preferred response.
Rohan Mahy noted that there is a general issue with proxies forking methods
they don't understand.
Jonathan Rosenberg was concerned that this violates the basic SIP working
assumption: that the final result of INVITE is a relationship between two
parties at most.  As a result, may be more general problems buried here
which mean a lot of work.
The suggestion is that this is an instance of a general non-INVITE forking
problem.  The general fix is to strengthen proxy "SHOULD" record-route on
non-INVITE methods to "MUST".
   


====================================
Part I Tuesday am

The proposed agenda was accepted with insertion of a resumed exposition of
the revised Last Call process.  Dean Willis(?) explained the 1a, 2a etc
notations on the web display of WG work items by indicating how they
correspond to stages of processing defined elsewhere on the page.

1. REFER Issues and Call Control (Robert Sparks) (charts)
   draft-ietf-sip-cc-transfer-04.txt
   draft-biggs-sip-replaces-00.txt
   ======================================================

Robert began with a review of recent changes to the REFER method
(draft-ietf-sip-cc-transfer-04.txt).  The major one was that NOTIFYs
generated in response to REFER will use the Event: refer package.

Road map: 
Model document in progress (Rohan Mahy)
Splitting current draft -- extension vs. usage.
Need Join/Replace for Transfer.

Robert Sparks ran through motivation for Replaces: header
Issues brought up:

Existing call-leg identifier: the draft proposal to use tags only and not
the full From: and To: headers had led to a lot of private discussion.  No
new points were brought up at the meeting.

Tom Taylor  asked for opinions on Replaces
behaviour if the existing call-leg is not already fully set up.  A number of
people responded.
 - Jonathan Rosenberg was uncomfortable with the idea -- tags may be
lacking.
 - Dave Oran thought that unwinding the state machine might be tricky.
 - Rohan Mahy was of the view that processing would have to wait until
states of the new and old call synchronized.
 - Dave Oran questioned what would happen if original call forked and was
ringing simultaneously at two points.  Rohan Mahy argued that a referred
INVITE goes through same process as original and therefore could follow the
fork.  Henning Schulzrinne responded that two separate processes could see
separate call dispositions.
 - Christian Huitema  viewed the suggestion
as nonsensical.
Nevertheless, Tom Taylor pointed out, the Replaces draft would have to
define UA behaviour under such circumstances, even if this behaviour were to
ignore the header.             

Robert Sparks continued with a walk-through for attended call transfer.

Henning Schulzrinne noted that the repeated use of Replaces in a
conferencing situation could lead to untraceable results.

As a separate issue, he preferred Refer BYE rather than triggered BYE (as
the draft has it now) -- have to be very careful not to mess up operation of
other features.  Speaking to that issue, Jonathan Rosenberg suggested that
the entity that has resource constraints is the one which should manage the
resource constraints.  Robert Sparks had the view that the problem is user
experience more than management of the pipe into the phone.  Jonathan said
the protocol should make the semantics explicit: Join + BYE.  Rohan Mahy was
concerned that Join implies need for mixing.  He wanted to see clean
separation of semantics between mixing and replacement.

Robert(?) clarified the semantics of Replaces: resources from the old call
are reallocated to the new one and old call is terminated.  He will provide
call flows.

Rohan Mahy(?) made a final remark: Join without mixing makes no sense.  We
MUST resolve this stuff this week -- it is a major bottleneck on feature
development.

2. Overlap Signalling Handling (Gonzalo Camarillo
) (charts)
   ========================================================

The authors of the SIP-T draft are splitting drafts so overlap signalling
handling will be a separate topic.

Three approaches:
 - en bloc
 - multiple INVITEs
 - INFO.

Tom Taylor warned that which policy is used where is a matter of local
policy, not standardization -- real-life implementations will have to
support all three.

Gonzalo continued with an analysis of the pros and cons of the three
policies.  He judged that both forced en bloc conversion and INFO messages
(as the only means of carrying updated signalling) would be untenable.  This
leaves multiple INVITEs, where each INVITE carries complete state.

The presented chart showed overlapping calls, a potential problem.  An
earlier INVITE could succeed because the partial called number is valid.
Dave Oran suggested that the UAC should wait for a 484 before sending its
next INVITE.

Jonathan Rosenberg noted that the succession of INVITEs actually displayed
Replaces: semantics.  He would have to think through the consequences if
Replaces were used.

Christian Huitema noted that in legacy usage the PBX can hold on to a call
while information accumulates.

Tom Taylor pointed out that if the call terminates on an egress gateway, it
has moved beyond reach of any but mid-call services in the SIP network.  We
need contingency plan if more digits arrive.  Jonathan Rosenberg agreed that
there is a problem if the call goes to egress gateway with too few digits.

Gonzalo Camarillo noted a general problem: successive INVITEs may not follow
the same path.  The result of successive INVITEs could be extra IAMs rather
than SAMs propagated onwards into the PSTN.

Further discussion curtailed for lack of time.


3. SIP-H.323 Interworking Requirements  (Radhika Roy) (charts)
   ======================================================

Radhika Roy  presented status and recent changes for two
documents.  Review of the requirements document
draft-agrawal-sip-h323-interworking-reqs-02.txt leading to Informational RFC
status has been requested in various WGs in lieu of WG Last Call.  The
latest issue of the interworking specification is
draft-agrawal-sip-h323-interworking-00.txt.


4. Privacy (Flemming Andreasen)
   ============================ 
   draft-dcsgroup-sip-privacy-02.txt

Status: no real participation in the WG.
New call for comments on list.
Got comments from Mark Watson  -- generalize
components of the proposed Remote-Party-ID header.  The comments were
resolved after substantial discussion.  The discussants gave up on the
proposed inclusion of location information.

Flemming showed the proposed requirements and their proposed resolution

Dave Oran requested consensus that the different types within the updated
proposal be IANA registered.  Agreed.

Comments:
Jonathan Rosenberg noted that this is a Proxy-Requires extension and thus
breaks interoperability.  There may be ways to deal with it (e.g. sequential
forwarding of the message until a path is found which works).

Jon Peterson  asked if it were the general view
that this should be THE SIP privacy mechanism.

Henning Schulzrinne agreed with Jonathan that the feature can operate, but
forking gets messy.  The IESG will insist on a full description of how a
call will fall back to baseline operation if the extension fails.  Jonathan
confirmed that observation.

Allison Mankin noted that work in progress may provide a method to give
location information which is privacy oriented.

Dean Willis followed up on Jon Peterson's question, posing it again to the
meeting.  Jon amplified: do we want to rely on the presence of trusted
network intermediaries for SIP privacy?  Dean Willis suggested that we may
need more development of requirements before we can answer that question.
Jonathan Rosenberg noted the need for the network to pierce veils of
anonymity e.g. for malicious call trace.  However, this is much tougher for
SIP than for the PSTN.  Dave Oran stated that the question was too broad: we
can't commit to this for all SIP for all time, but real networks do have
call trace requirements.  Radhika Roy noted that the requirement to
interwork with the PSTN adds a dimension to the problem.

Addressing the content of the draft, Henning Schulzrinne observed that it is
very dangerous to rely on a network entity to clean up.  This issue has to
be fully addressed in the draft.  

Jonathan Rosenberg suggested that current work focus on the requirements of
malicious call trace -- e.g. when it has to be possible, in-call or later.
Dean Willis raised a process issue: can we consider regulatory requirements?
Allison Mankin responded that regulatory requirements are informational,
feeding into IETF requirements for privacy and security.  We would hope that
the latter are more stringent.  Note also RFC 2804.  (Comments from audience
to effect that the IETF shows more willingness to support malicious call
trace than wiretap.)  Allison suggested that the WG put together a privacy
requirements draft.  She observed that the current privacy draft looks very
good.

The suggestion was made that this document should retain its present scope,
while the requirements document could have expanded scope.  Michael Thomas
noted a potential need for media anonymization.  The question is whether
this is good enough for what it is trying to do.  Dave Oran responded that
anonymization is solved.  However, this work is driven by two requirements
-- the need for an identity besides that supplied by user for processing the
call, plus anonymity.

Brian Rosen asked what the next move should be.  He suggested the document
should be split into requirements and protocol parts, and asked if there
were any objection to this.  He called for a hum of opposition to
progressing this document to standards track.  A clarification: this would
be a mechanism, but there could be others.  Jonathan Rosenberg wondered if
Experimental be acceptable.  Allison Mankin replied that Experimental is
probably not appropriate.  The WG should take time to get it right if
necessary.

The question was put: is there opposition to moving forward according to
plan (July LC)?  No opposition was shown.


5. 3GPP Proposals (Keith Drage ) (charts)
   =====================================

Keith provided URLs pointing to current documents.  (These are already on
the supplementary WG web site.)

He walked through a signalling path chart showing how many operators could
potentially be involved in a call (A's visited network, A's home network,
B's home network, B's visited network).

Keith presented the 3GPP functional architecture.  Some questions were
raised about the BCGF.  It was explained as a routing function which knows
where gateways are.  Jonathan Rosenberg expressed satisfaction with the
match to the SIP architecture.

Keith provided the 3GPP approval schedule, noting its dependency on a series
of drafts: 2543bis, manyfolks resource, 100rel, privacy, call-auth,
subscribe-notify [and perhaps others].  Michael Thomas expressed concern
regarding the applicability of call-auth.

For path requirements, Keith suggested a need for a new header for
hop-by-hop registration (3 registrars).  Jonathan Rosenberg pointed out that
this can be done with the current protocol.  Jonathan Lennox
 asked a question to clarify the route manipulation
involved.

Several issues need settlement.  One is Via, Route, and Record-Route hiding
as in draft-byerly-sip-hide-route-00.txt.  Another is notification of the UA
in a proxy-initiated deregistration.  Jonathan Rosenberg suggested using the
SIP presence draft as a potential solution.  A member of the audience
indicated that this was how they were implementing the process.


6.  Further Discussion Of List Issues (Jonathan Rosenberg)
    ======================================================

(a) Network-initiated deregistration:
Solution: use presence -- is there a consensus?
Dave Oran observed that the dertegistration notice could trigger something
like notification of police (in the event of cell phone theft).  Henning
Schulzrinne asked if this is really a subject for standardization, and
expressed his opinion that it is not.

(b) 409 and Multiple Contacts:
Can the current prohibition on change of action values be removed?  Jonathan
was not sure that the resulting behaviour would be well defined.  Robert
Sparks suggested that the behaviour can be reasoned out.  Jonathan was not
convinced.  Robert provided an example of a potential application prevented
by the current text.

A lengthy discussion ensued.  There were various proposed interpretations,
but none was accepted as definitive.  There are possible ways to resolve the
issue, but it has to go to the list.

(c) Record Routing:
Need more comments on the new text.
Issue -- what about new methods?  Current text says they should not be RRed.
Nevertheless, Record-Route may be justified e.g. for firewall traversal.
Jonathan proposed to allow RR on any method.  The UA ignores RR if it
arrives on a method where it is inappropriate.  Adam Roach noted that the
2543bis draft says that proxies should put RR on all methods for robustness
(hence including BYE).  There is a bigger issue here: what does it mean to
refresh RR state?
Called on time.


Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
taylor@nortelnetworks.com 

------_=_NextPart_001_01C0C1C1.2711C9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Draft SIP WG Minutes




Better late than never.




The SIP WG met for its first session on Monday =
afternoon, under the chairmanship of Dean Willis =
<dwillis@dynamicsoft.com>, Brian Rosen =
<brian.rosen@marconi.com>, and Joerg Ott =
<jo@tzi.org>.



1. Agenda Bashing

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




Dean Willis introduced the meeting and session =
agendas.  In response to strong representations from the Area =
Directors, the meeting will feature larger segments in contrast to the =
brief discussions of earlier meetings.



2. Status (Dean Willis - charts)

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




Currently tracking about 70 drafts.

Reached saturation point.




The Chairs are trying to get control of the =
workload.




2.1 Proposal For Reorganization

    =
---------------------------




Proposal: split into SIP and SIPPING work =
groups.  Split in drafts would be about 24:40.  Remaining =
drafts would be "out of scope".



Distinguish SIP from uses of SIP.




Actions: immediate split of mailing lists.

Separate WG meetings next time around.

Continue with same chairs until stable.




Discussion:

  Henning Schulzrinne =
<hgs@cs.columbia.edu> noted a potential problem with messages =
posted to wrong list: it will mean extra traffic getting the message =
redirected.



  Allison Mankin <mankin@isi.edu> observed =
that if the lists become moderated to prevent message rerouting, they =
must have a published policy which says all that messages will be =
posted (except possibly spam).  The Chair could have a sorting =
policy which assigns messages to list.



  IETF mailing list interactions will create =
complications.

  Brian Rosen has enforced SIP/implementor's =
list separation through direct notes to offenders.

  Jonathan Rosenberg =
<jdrosen@dynamicsoft.com> remarked that any sorting policy won't =
reduce total volume, just ease processing.



  It was noted that some offenders of the =
current separation policy are familiar names in SIP work.

  Last Call procedures will encourage division =
by referring draft to appropriate list.




  Brian Rosen asked for comments on base idea of =
splitting groups.  None were offered.




Dean explained the new web tracking of the =
workload.  It can be found on the SIP WG supplemental home =
page.




Last Call: Chairs will push harder for comments to =
move drafts forward in time to meet milestones.




2.2 Draft Charters For SIP and SIPPING

    =
----------------------------------




The draft charters for SIP and SIPPING are shown on =
SIP WG supplemental home page.




Key charter items for SIP:

 - 2543bis

 - call control

...

Flemming Andreassen <fandreas@cisco.com> noted =
that there are open issues regarding the privacy draft.




Key charter items for SIPPING

 - SIPT

 - hearing impaired

 - ...




SIPPING won't normally process a Standards Track =
change/extension to SIP.  The use of extensions etc. would be =
described in SIPPING.



Rohan Mahy <rohan@cisco.com> remarked that =
adding codepoints doesn't need to go to SIP.




Area Director decree: all features which may be =
"required" MUST be documented as standards-track items in SIP =
WG.  SIPPING would define requirements.



Jonathan noted an open issue on ambiguity regarding =
Contact parameter registration.  Allison agreed this could be a =
SIPPING work item.



2.3 Open Issues

    -----------

 

IN interworking.  Area Director agreement that =
a design team (SIN) review related drafts and identify issues which =
would prevent IN from interworking with the IN.  There was =
insufficient support to make this an IETF work item (SIPPING charter =
item) at this point.



Firewall passage: MIDCOM owns control




Jonathan Rosenberg led a brief discussion on where =
call control fits.  The basic principle is that "how to" =
is in SIPPING, extensions like REFER go into SIP.



Dave Oran <oran@cisco.com> suggested that in =
effect we would double number of drafts we have now.  In response, =
H.323 interworking was cited as a current counter-example -- no =
extensions are involved, so the drafts will all be targetted to =
SIPPING.



Generally: there will be a number of corner =
cases.  Sorting them out will require exercise of chair judgement, =
fed by arguments from authors.  We could see a flow where the =
initial work is done in SIPPING, moves to SIP, and finally back to =
SIPPING to define usage of the resulting protocol.



Security: generally a core SIP item to ensure that it =
is fully integrated with the protocol.  Michael Thomas =
<mat@cisco.com> suggested giving it to SIPPING first because many =
of the issues are implementation-related.  Allison Mankin pointed =
out that every SIPPING draft should discuss security issues.



A speaker referred to the work in 3GPP/3GPP2 on SIP =
usage to talk to application servers: is this part of the IN =
mess?

Henning Schulzrinne responded that this work is not =
necessarily part of IN.  The speaker was concerned that the work =
as currently directed represented at the least an issue of =
misunderstanding of Internet architecture.  The Chairs noted that =
one shouldn't confuse IN with 3GPP.





3. Bis Issues (Jonathan Rosenberg) (charts)

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




Jonathan noted that the volume of mail on the list is =
now such that it is no longer feasible for issues to be tracked by the =
leadership of the WG.  He urged WG participants to take =
responsibility for tracking issues they raised until final =
resolution.



3.1 Issue: SDP in response: subset of SDP in =
INVITE?

    =
------------------------------------------------




RFC 2543 is inconsistent between the text and the =
examples.




Requiring that the responder send back a subset of =
the codecs indicated by the initiator prevents the responder from =
indicating sendonly capabilities.  It is suggested as an =
alternative that the text indicate that each end indicates what it can =
receive.



Michael Thomas noted that SDP is not adapted to =
negotiation.  UAs should use re-INVITES as required for this =
purpose.




General agreement: the text should say that each end =
indicates its own receive capabilities.




3.2 Issue: Cseq Incrementing

    ------------------------




The text says that sequence numbers should be =
"contiguous".  Incrementing by 1 is useful for =
ordering.

 

Robert Sparks <rsparks@dynamicsoft.com> noted =
that the receiving end cannot be guaranteed to see increment by 1 =
because of 407 sent back from an intermediate node on a =
re-INVITE.



Rohan Mahy suggested that we try to capture the =
motivation for any agreed solution in the meeting minutes, so we don't =
have to hold the discussion again.



Resolution: the UAC should still increment by =
1.

The receiver should do a sanity check on gaps and =
reset if it finds too large a gap.




3.3 Issue: TCP Connection Handling

    =
------------------------------




(1) Proposal: closing of TCP connections does not =
affect SIP state.  Assuming otherwise results in problems (per =
slide).



The proposal raises potential backward compatibility =
problems.  Jonathan asked the implementors in the crowd whether =
tyhese were real.  There was positive support for the =
proposal.  This will be confirmed on the list.



(2) Need text on using persistent connections with =
TCP.  The proposed text was shown on a chart.




Matt Holdrege <matt@ipverse.com> asked if these =
proposals would be carried over to SCTP.  Jonathan Rosenberg cited =
lack of SCTP expert involvement and of understanding of how SCTP =
applies to SIP (why it would be needed).  Allison Mankin noted =
that SCTP application discussion has just started in the Transport Area =
WG.



There was a general view that this isn't a core =
specification item as phrased -- more of a BCP.  Jonathan will =
think of words capturing the intent at the standards level.



3.4 Issue: Response Failover

    ------------------------




We would like calls to survive mid-transaction proxy =
failures.

Usage of the "received" parameter prevents =
SRV-based reroute.

Proposal: try the address given in the =
"received" parameter first.  Upon indication of failure, =
use domain lookup on the Via header URI.



Problems: this only works on stateful proxies.  =
There are complications if the crashed proxy forks.

Rohan Mahy suggested that the text prohibit =
("SHOULD") a forking proxy from inserting a URI in its Via =
header which points to proxies which cannot handle forked =
requests.



3.5 Issue: Tags

    -----------




Agreed at last meeting: From tags should be =
mandatory.

The specification says a tag should be unique within =
a UA instance.  There is value in making tags unique per call =
leg.  (Helpful with billing.)  On this last point, Bill =
Marshall <wtm@research.att.com> noted that a rogue UA could reuse =
tag values to confuse billing system.  Jonathan had a different =
context in mind.



Jonathan's proposal: make tags unique per call.  =
A tag MAY contain a portion to associate it with the creating UA =
instance.  



Billing or whatever would actually have to gather =
tags off 200 OK -- INVITE only has the From tag.




Henning Schulzrinne suggested we not specify =
implementation too closely, so that in particular, application to =
billing is a possibility rather than a recommendation.  Rohan Mahy =
suggested that the proposal solves a non-problem for well-behaved =
implementations, and by definition the others may not do the right =
thing.  It was also noted that this use of tags needs at least one =
trusted side.  



Jonathan(?) referred to the discussion of the use of =
tags to distinguish the call-leg, as proposed in the Replaces =
draft.  These discussions support the per-call uniqueness =
requirement.  Jonathan proposed that we add text to indicate the =
implications of different implementations of tags.



4. SIP Events (Adam Roach =
<adam.roach@ericsson.com>) (charts)

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

   =
draft-roach-sip-subscribe-notify-03.txt




A new version of the draft is due.




Current issues:




(a) State agent -- generalization of presence =
agent.




(b) Subscriptions can be initiated by other than =
SUBSCRIBE -- 481 must remove all subscriptions.




(c) PINT compatibility

Lawrence Conroy <lwc@roke.co.uk> noted the =
need for text to resolve the inconsistency between the PINT work and =
the way SUBS/NOT has evolved.  Adam assured him that the necessary =
text is present (assume lack of event header implies PINT). 



(d) Throttling needs to be done.




(e) Instant notification should be sent upon =
subscription, even though state is not actually resolved.  To do =
this, the suggestion is to send the notification with neutral =
information. 



Jonathan Rosenberg and Henning Schulzrinne pointed =
out that the required action may depend on the package -- a designer =
issue, not a blanket requirement.  Package guidelines should =
require designers to talk about how this situation is handled.  =
Jonathan has other guideline items which he will provide to =
Adam.



(f) Authorization of subscriptions.  Jonathan =
Rosenberg suggested authorization procedures also should be defined on =
a package by package basis.  The question was raised, whether a =
QAUTH generalized mechanism is required.  Rohan Mahy suggested =
that this is a special case of feature authorization.  Ian Rytina =
<ian.rytina@ERICSSON.COM.AU> stated that QAUTH has a place, but =
not in presence.  The issue will be further discussed in =
SIMPLE/IMPP.  In general, this is an example of a SIPPING =
discussion item, with outcome to be acted on by SIP.



(g) SUBSCRIBE response codes.

202 non-committal -- have to wait for Notify to give =
final result.

Are 403 or 603 allowable?

Does 200 mean subscription is definitively =
approved?

Jonathan suggests that this should be part of the =
package definition




(h) Denial of service concerns:

UASs should keep no state for unauthenticated =
SUBSCRIBE messages, to protect themselves against denial of service =
attacks..



Is it reasonable to allow each userid/password =
combination have only one pending SUBSCRIBE at each node?  Dean =
Willis pointed out that in the failure recovery case, restart would be =
slow.



More discussion needed.




(i) Forking

Lots of discussion at interim meeting, no =
resolution.

The UAC gets multiple NOTIFYs back although only one =
20x response was passed by the forking proxy, with Record-Route =
ambiguity as a result.



It took some discussion for Adam to demonstrate the =
problem.

Proposed: two solutions, one of which SHOULD be used =
by any subscriber.  [Sorry I don't have them, hope they are shown =
on Adam's charts -- PTT] The event package should specify the preferred =
response.



Rohan Mahy noted that there is a general issue with =
proxies forking methods they don't understand.

Jonathan Rosenberg was concerned that this violates =
the basic SIP working assumption: that the final result of INVITE is a =
relationship between two parties at most.  As a result, may be =
more general problems buried here which mean a lot of work.



The suggestion is that this is an instance of a =
general non-INVITE forking problem.  The general fix is to =
strengthen proxy "SHOULD" record-route on non-INVITE methods =
to "MUST".



   






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

Part I Tuesday am




The proposed agenda was accepted with insertion of a =
resumed exposition of the revised Last Call process.  Dean =
Willis(?) explained the 1a, 2a etc notations on the web display of WG =
work items by indicating how they correspond to stages of processing =
defined elsewhere on the page.



1. REFER Issues and Call Control (Robert Sparks) =
(charts)

   =
draft-ietf-sip-cc-transfer-04.txt

   draft-biggs-sip-replaces-00.txt

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




Robert began with a review of recent changes to the =
REFER method (draft-ietf-sip-cc-transfer-04.txt).  The major one =
was that NOTIFYs generated in response to REFER will use the Event: =
refer package.



Road map: 

Model document in progress (Rohan Mahy)

Splitting current draft -- extension vs. =
usage.

Need Join/Replace for Transfer.




Robert Sparks ran through motivation for Replaces: =
header

Issues brought up:




Existing call-leg identifier: the draft proposal to =
use tags only and not the full From: and To: headers had led to a lot =
of private discussion.  No new points were brought up at the =
meeting.



Tom Taylor <taylor@nortelnetworks.com> asked =
for opinions on Replaces behaviour if the existing call-leg is not =
already fully set up.  A number of people responded.



 - Jonathan Rosenberg was uncomfortable with the =
idea -- tags may be lacking.

 - Dave Oran thought that unwinding the state =
machine might be tricky.

 - Rohan Mahy was of the view that processing =
would have to wait until states of the new and old call =
synchronized.

 - Dave Oran questioned what would happen if =
original call forked and was ringing simultaneously at two =
points.  Rohan Mahy argued that a referred INVITE goes through =
same process as original and therefore could follow the fork.  =
Henning Schulzrinne responded that two separate processes could see =
separate call dispositions.



 - Christian Huitema =
<huitema@exchange.microsoft.com> viewed the suggestion as =
nonsensical.

Nevertheless, Tom Taylor pointed out, the Replaces =
draft would have to define UA behaviour under such circumstances, even =
if this behaviour were to ignore the =
header.           =
;  



Robert Sparks continued with a walk-through for =
attended call transfer.




Henning Schulzrinne noted that the repeated use of =
Replaces in a conferencing situation could lead to untraceable =
results.



As a separate issue, he preferred Refer BYE rather =
than triggered BYE (as the draft has it now) -- have to be very careful =
not to mess up operation of other features.  Speaking to that =
issue, Jonathan Rosenberg suggested that the entity that has resource =
constraints is the one which should manage the resource =
constraints.  Robert Sparks had the view that the problem is user =
experience more than management of the pipe into the phone.  =
Jonathan said the protocol should make the semantics explicit: Join + =
BYE.  Rohan Mahy was concerned that Join implies need for =
mixing.  He wanted to see clean separation of semantics between =
mixing and replacement.



Robert(?) clarified the semantics of Replaces: =
resources from the old call are reallocated to the new one and old call =
is terminated.  He will provide call flows.



Rohan Mahy(?) made a final remark: Join without =
mixing makes no sense.  We MUST resolve this stuff this week -- it =
is a major bottleneck on feature development.



2. Overlap Signalling Handling (Gonzalo Camarillo =
<gonzalo.camarillo@lmf.ericsson.se>) (charts)

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




The authors of the SIP-T draft are splitting drafts =
so overlap signalling handling will be a separate topic.




Three approaches:

 - en bloc

 - multiple INVITEs

 - INFO.




Tom Taylor warned that which policy is used where is =
a matter of local policy, not standardization -- real-life =
implementations will have to support all three.



Gonzalo continued with an analysis of the pros and =
cons of the three policies.  He judged that both forced en bloc =
conversion and INFO messages (as the only means of carrying updated =
signalling) would be untenable.  This leaves multiple INVITEs, =
where each INVITE carries complete state.



The presented chart showed overlapping calls, a =
potential problem.  An earlier INVITE could succeed because the =
partial called number is valid.  Dave Oran suggested that the UAC =
should wait for a 484 before sending its next INVITE.



Jonathan Rosenberg noted that the succession of =
INVITEs actually displayed Replaces: semantics.  He would have to =
think through the consequences if Replaces were used.



Christian Huitema noted that in legacy usage the PBX =
can hold on to a call while information accumulates.




Tom Taylor pointed out that if the call terminates on =
an egress gateway, it has moved beyond reach of any but mid-call =
services in the SIP network.  We need contingency plan if more =
digits arrive.  Jonathan Rosenberg agreed that there is a problem =
if the call goes to egress gateway with too few digits.



Gonzalo Camarillo noted a general problem: successive =
INVITEs may not follow the same path.  The result of successive =
INVITEs could be extra IAMs rather than SAMs propagated onwards into =
the PSTN.



Further discussion curtailed for lack of time.






3. SIP-H.323 Interworking Requirements  (Radhika =
Roy) (charts)

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




Radhika Roy <rrroy@att.com> presented status =
and recent changes for two documents.  Review of the requirements =
document draft-agrawal-sip-h323-interworking-reqs-02.txt leading to =
Informational RFC status has been requested in various WGs in lieu of =
WG Last Call.  The latest issue of the interworking specification =
is draft-agrawal-sip-h323-interworking-00.txt.





4. Privacy (Flemming Andreasen)

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

   =
draft-dcsgroup-sip-privacy-02.txt




Status: no real participation in the WG.

New call for comments on list.

Got comments from Mark Watson =
<mwatson@nortelnetworks.com> -- generalize components of the =
proposed Remote-Party-ID header.  The comments were resolved after =
substantial discussion.  The discussants gave up on the proposed =
inclusion of location information.



Flemming showed the proposed requirements and their =
proposed resolution




Dave Oran requested consensus that the different =
types within the updated proposal be IANA registered.  =
Agreed.




Comments:

Jonathan Rosenberg noted that this is a =
Proxy-Requires extension and thus breaks interoperability.  There =
may be ways to deal with it (e.g. sequential forwarding of the message =
until a path is found which works).



Jon Peterson <Jon.Peterson@level3.com> asked if =
it were the general view that this should be THE SIP privacy =
mechanism.




Henning Schulzrinne agreed with Jonathan that the =
feature can operate, but forking gets messy.  The IESG will insist =
on a full description of how a call will fall back to baseline =
operation if the extension fails.  Jonathan confirmed that =
observation.



Allison Mankin noted that work in progress may =
provide a method to give location information which is privacy =
oriented.




Dean Willis followed up on Jon Peterson's question, =
posing it again to the meeting.  Jon amplified: do we want to rely =
on the presence of trusted network intermediaries for SIP =
privacy?  Dean Willis suggested that we may need more development =
of requirements before we can answer that question.  Jonathan =
Rosenberg noted the need for the network to pierce veils of anonymity =
e.g. for malicious call trace.  However, this is much tougher for =
SIP than for the PSTN.  Dave Oran stated that the question was too =
broad: we can't commit to this for all SIP for all time, but real =
networks do have call trace requirements.  Radhika Roy noted that =
the requirement to interwork with the PSTN adds a dimension to the =
problem.



Addressing the content of the draft, Henning =
Schulzrinne observed that it is very dangerous to rely on a network =
entity to clean up.  This issue has to be fully addressed in the =
draft.  



Jonathan Rosenberg suggested that current work focus =
on the requirements of malicious call trace -- e.g. when it has to be =
possible, in-call or later.  Dean Willis raised a process issue: =
can we consider regulatory requirements?  Allison Mankin responded =
that regulatory requirements are informational, feeding into IETF =
requirements for privacy and security.  We would hope that the =
latter are more stringent.  Note also RFC 2804.  (Comments =
from audience to effect that the IETF shows more willingness to support =
malicious call trace than wiretap.)  Allison suggested that the WG =
put together a privacy requirements draft.  She observed that the =
current privacy draft looks very good.



The suggestion was made that this document should =
retain its present scope, while the requirements document could have =
expanded scope.  Michael Thomas noted a potential need for media =
anonymization.  The question is whether this is good enough for =
what it is trying to do.  Dave Oran responded that anonymization =
is solved.  However, this work is driven by two requirements -- =
the need for an identity besides that supplied by user for processing =
the call, plus anonymity.



Brian Rosen asked what the next move should be.  =
He suggested the document should be split into requirements and =
protocol parts, and asked if there were any objection to this.  He =
called for a hum of opposition to progressing this document to =
standards track.  A clarification: this would be a mechanism, but =
there could be others.  Jonathan Rosenberg wondered if =
Experimental be acceptable.  Allison Mankin replied that =
Experimental is probably not appropriate.  The WG should take time =
to get it right if necessary.



The question was put: is there opposition to moving =
forward according to plan (July LC)?  No opposition was =
shown.






5. 3GPP Proposals (Keith Drage =
<drage@lucent.com>) (charts)

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




Keith provided URLs pointing to current =
documents.  (These are already on the supplementary WG web =
site.)




He walked through a signalling path chart showing how =
many operators could potentially be involved in a call (A's visited =
network, A's home network, B's home network, B's visited =
network).



Keith presented the 3GPP functional =
architecture.  Some questions were raised about the BCGF.  It =
was explained as a routing function which knows where gateways =
are.  Jonathan Rosenberg expressed satisfaction with the match to =
the SIP architecture.



Keith provided the 3GPP approval schedule, noting its =
dependency on a series of drafts: 2543bis, manyfolks resource, 100rel, =
privacy, call-auth, subscribe-notify [and perhaps others].  =
Michael Thomas expressed concern regarding the applicability of =
call-auth.



For path requirements, Keith suggested a need for a =
new header for hop-by-hop registration (3 registrars).  Jonathan =
Rosenberg pointed out that this can be done with the current =
protocol.  Jonathan Lennox <lennox@cs.columbia.edu> asked a =
question to clarify the route manipulation involved.



Several issues need settlement.  One is Via, =
Route, and Record-Route hiding as in =
draft-byerly-sip-hide-route-00.txt.  Another is notification of =
the UA in a proxy-initiated deregistration.  Jonathan Rosenberg =
suggested using the SIP presence draft as a potential solution.  A =
member of the audience indicated that this was how they were =
implementing the process.





6.  Further Discussion Of List Issues (Jonathan =
Rosenberg)

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




(a) Network-initiated deregistration:

Solution: use presence -- is there a =
consensus?

Dave Oran observed that the dertegistration notice =
could trigger something like notification of police (in the event of =
cell phone theft).  Henning Schulzrinne asked if this is really a =
subject for standardization, and expressed his opinion that it is =
not.



(b) 409 and Multiple Contacts:

Can the current prohibition on change of action =
values be removed?  Jonathan was not sure that the resulting =
behaviour would be well defined.  Robert Sparks suggested that the =
behaviour can be reasoned out.  Jonathan was not convinced.  =
Robert provided an example of a potential application prevented by the =
current text.



A lengthy discussion ensued.  There were various =
proposed interpretations, but none was accepted as definitive.  =
There are possible ways to resolve the issue, but it has to go to the =
list.



(c) Record Routing:

Need more comments on the new text.

Issue -- what about new methods?  Current text =
says they should not be RRed.  Nevertheless, Record-Route may be =
justified e.g. for firewall traversal.  Jonathan proposed to allow =
RR on any method.  The UA ignores RR if it arrives on a method =
where it is inappropriate.  Adam Roach noted that the 2543bis =
draft says that proxies should put RR on all methods for robustness =
(hence including BYE).  There is a bigger issue here: what does it =
mean to refresh RR state?



Called on time.






Tom Taylor

Multimedia Control and Applications Standards

Ph.  +1 613 736 0961

taylor@nortelnetworks.com 





------_=_NextPart_001_01C0C1C1.2711C9E0--

_______________________________________________
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  Tue Apr 10 09:35:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14603
	for ; Tue, 10 Apr 2001 09:35:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2BCD4437A; Tue, 10 Apr 2001 09:35:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12])
	by lists.bell-labs.com (Postfix) with ESMTP id 846D44433A
	for ; Tue, 10 Apr 2001 09:34:20 -0400 (EDT)
Received: from WINNT ([207.113.13.1])
	by devonshire.cnchost.com
	id JAA07850; Tue, 10 Apr 2001 09:34:17 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.10]
From: "Medhavi" 
To: "Sharath Rajasekar" ,
        "sip list" , 
Subject: RE: [SIP] Delivering Caller-ID through SIP
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.50.4522.1200
Importance: Normal
In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD5B88D8@mailserver.sylantro.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, 9 Apr 2001 21:38:21 -0400
Content-Transfer-Encoding: 7bit

I think you can use the p= in SDP, as one option.

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar
Sent: Monday, April 09, 2001 9:16 PM
To: sip list; jdrosen@dynamicsoft.com
Subject: [SIP] Delivering Caller-ID through SIP



Consider a SIP UA with a SIP URL userA@example.com which is associated 
with a SIP Phone. This SIP Phone has a public number (444-555-6666). 

When a call is initiated by the phone, to a PSTN number, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : UserA 
	To : Unknown 
      ...

How can one deliver the calling public number(444-555-6666 in this case) 
to the PSTN as caller-id through the gateway ?
  
Some generic tag may be used say..."pstn-number: 444-555-6666" in the 
>From header, but this will mean that all gateways must support this tag.
Is there some other solution to this problem.


Regards
Sharath



_______________________________________________
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  Tue Apr 10 10:02:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15596
	for ; Tue, 10 Apr 2001 10:02:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6EC984434B; Tue, 10 Apr 2001 10:02:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange.satyam.net.in (unknown [202.144.12.32])
	by lists.bell-labs.com (Postfix) with ESMTP id E472C4433E
	for ; Tue, 10 Apr 2001 06:16:44 -0400 (EDT)
Received: from HQBNG01EXFE01.mindtree.com (lan-202-144-95-250.maa.sify.net [202.144.95.250] (may be forged))
	by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id PAA31647;
	Tue, 10 Apr 2001 15:47:16 +0530
Received: from hqbng01ex01.mindtree.com ([172.20.20.4]) by HQBNG01EXFE01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 10 Apr 2001 15:44:28 +0530
Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by hqbng01ex01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 10 Apr 2001 15:44:28 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [SIP] Few queries after reading 2543 rfc...
Message-ID: <2330401A6FE03445ADA682F5EBB7502D31C797@mtv01ex01.mindtree.com>
Thread-Topic: [SIP] Few queries after reading 2543 rfc...
Thread-Index: AcDBAKVflnisxsOMTbenSP0Rn8uC9QApQvmw
From: "Mayank Sharma" 
To: "T.Sunil Kumar" ,
        "Bell - SIP" 
X-OriginalArrivalTime: 10 Apr 2001 10:14:28.0135 (UTC) FILETIME=[06A1F370:01C0C1A7]
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 Apr 2001 15:44:27 +0530
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15596

> 1) What is the importance of 'tag' parameter in 'To' header field in
> response. RFC says that it is useful to differentiate 
> responses when an
> intermediate proxy forks the request. How does a proxy or User agent
> client maps a response to its host using 'tag' parameter when 
> that 'tag'
> was not sent in the request.

When the UAS responds to a request it puts a tag parameter in the To header 
of the response that it sends. In case the Request was forked by a proxy
server
The proxy server will receive two responses to its request with different Tag

parameter in it's To field. Hence the Proxy server will know that response
with
such an such tag came from such and such UAS.

> 
> 2) What is the significance of 'Cseq' header field. RFC says that ACK
> request should contain Cseq same as corresponding INVITE 
> request but BYE
> should increment the sequence number in Cseq - why?

In a particular sequence of transactions with same Call-ID, Cseq
differentiates
the transactions (read the rfc for the defination of transaction). ACK
contains the
CSeq of the response to which it is ACKing. in case of response to INVITE, it
will
have the same Cseq as that of INVITE.

> 
> 3)  When the callee responds (in its 200 response) with a new URI in
> Contact header field, the caller would send ACK request to the new URI
> mentioned by the callee. How does the session description 
> bargain happen
> between caller and new callee  if there is no session 
> information passed

the Contact that is send with a 200 OK response tells the caller the current
location
of the callee. so the ACK need not travel through all the proxies through
which INVITE and 200 OK passed. Thus the ACK is sent to the same person
bypassing the proxy. 

RFC is very clear regarding these doubts.

Regards,
Maynk Sharma
Mindtree Consultancy Pvt. Ltd.

_______________________________________________
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  Tue Apr 10 12:07:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19373
	for ; Tue, 10 Apr 2001 12:07:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 35E4D44353; Tue, 10 Apr 2001 12:07:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 451B24433A
	for ; Tue, 10 Apr 2001 12:06:18 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GBL00B5C3946M@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 10 Apr 2001 16:03:04 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GBL00J0138W3W@dgismtp01.wcomnet.com>;
 Tue, 10 Apr 2001 16:03:04 +0000 (GMT)
Received: from wcom.com ([166.44.56.217])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GBL00I3I38OSN@dgismtp01.wcomnet.com>; Tue,
 10 Apr 2001 16:02:54 +0000 (GMT)
From: Alan Johnston 
Subject: Re: [SIP] transfer call flows
To: Mo Zonoun 
Cc: sip@lists.bell-labs.com
Message-id: <3AD32EBC.5D178C3F@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_hsItS2w+V147L7nsAIxEWw)"
X-Accept-Language: en
References: <63E0DAD7784FD21188310000F80824B304B97DE3@zmpkdx02.us.nortel.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: Tue, 10 Apr 2001 11:03:09 -0500


--Boundary_(ID_hsItS2w+V147L7nsAIxEWw)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mo,

See http://lists.bell-labs.com/pipermail/sip/2001q1/006481.html

Thanks,
Alan Johnston
WorldCom
sip:alan@digitalari.com

Mo Zonoun wrote:

>
>
> I posted the following question while back but I didn't get any
> response.
> How do you make sure that a new INVITE in a Call Transfer gets to the
> correct UA-C when there are multiple UA candidates, including the case
> where the UA-C is a gateway to another network.
>
> Mo Zonoun

--Boundary_(ID_hsItS2w+V147L7nsAIxEWw)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Mo,

See http://lists.bell-labs.com/pipermail/sip/2001q1/006481.html

Thanks,

Alan Johnston

WorldCom

sip:alan@digitalari.com

Mo Zonoun wrote:

 

I posted the following question while back but I didn't
get any response.

How do you make sure that a new INVITE in a Call Transfer
gets to the correct UA-C when there are multiple UA candidates, including
the case where the UA-C is a gateway to another network.

Mo Zonoun



--Boundary_(ID_hsItS2w+V147L7nsAIxEWw)--

_______________________________________________
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  Tue Apr 10 13:07:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21213
	for ; Tue, 10 Apr 2001 13:07:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1694D44338; Tue, 10 Apr 2001 13:07:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hotmail.com (f259.law14.hotmail.com [64.4.20.134])
	by lists.bell-labs.com (Postfix) with ESMTP id 6E8BE44337
	for ; Tue, 10 Apr 2001 13:06:26 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 10 Apr 2001 10:06:19 -0700
Received: from 171.71.159.231 by lw14fd.law14.hotmail.msn.com with HTTP;	Tue, 10 Apr 2001 17:06:19 GMT
X-Originating-IP: [171.71.159.231]
From: "Charles Chen" 
To: taylor@nortelnetworks.com, dean.willis@softarmor.com,
        brian.rosen@marconi.com, jo@tzi.org
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Draft SIP WG Minutes
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 10 Apr 2001 17:06:19.0684 (UTC) FILETIME=[8FDD1640:01C0C1E0]
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 Apr 2001 17:06:19 -0000

>(i) Forking Lots of discussion at interim meeting, no resolution. The UAC 
>gets multiple NOTIFYs back although only one 20x response was >passed by 
>the forking proxy, with
>Record-Route ambiguity as a result.
>
>It took some discussion for Adam to demonstrate the problem. Proposed: two 
>solutions, one of which SHOULD be used by any > subscriber.  [Sorry I don't 
>have them, hope they
>are shown on Adam's charts -- PTT] The event package should specify > the 
>preferred response.
>
>Rohan Mahy noted that there is a general issue with proxies forking > 
>methods they don't understand. Jonathan Rosenberg was concerned that this 
>violates the basic SIP > working assumption: that the final result of
>INVITE is a relationship between two parties at most.  As a result, > may 
>be more general problems buried here which
>mean a lot of work.
>

Is the problem a general forking issue for SIP (including INVITE) or just 
non-INVITE forking problem?

Charles C.
>The suggestion is that this is an instance of a general non-INVITE > 
>forking problem.  The general fix is to strengthen
>proxy "SHOULD" record-route on non-INVITE methods to "MUST".
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.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@lists.bell-labs.com  Tue Apr 10 13:43:10 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21987
	for ; Tue, 10 Apr 2001 13:43: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 56D1F44338; Tue, 10 Apr 2001 13:43:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E11A44337
	for ; Tue, 10 Apr 2001 13:42:24 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id NAA66302; Tue, 10 Apr 2001 13:41:53 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'sip list'" 
Subject: RE: [SIP] Delivering Caller-ID through SIP
Message-ID: <001901c0c1e5$c33b7860$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: <79FEAA5FABA7D411BF580001023D1BBD5B88D8@mailserver.sylantro.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: Tue, 10 Apr 2001 13:43:32 -0400
Content-Transfer-Encoding: 7bit

> Consider a SIP UA with a SIP URL userA@example.com which is 
> associated 
> with a SIP Phone. This SIP Phone has a public number (444-555-6666). 
> 
> When a call is initiated by the phone, to a PSTN number, the following
> INVITE will be sent out...
> 
> 	INVITE sip:4085551111@gateway.company.com SIP/2.0
>       From : UserA 
> 	To : Unknown 
>       ...
> 
> How can one deliver the calling public number(444-555-6666 in 
> this case) 
> to the PSTN as caller-id through the gateway ?
>   
> Some generic tag may be used say..."pstn-number: 444-555-6666" in the 
> From header, but this will mean that all gateways must 
> support this tag.
> Is there some other solution to this problem.
> 

The following draft deals with Caller-ID 
and privacy:
http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-01.txt

The remote party ID would contain 
rpi-id-type="term" for the PSTN number 
associated with the terminal.  The remote 
party ID would contain rpi-id-type="user" 
when identifying the user making the call.


_______________________________________________
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  Tue Apr 10 18:15:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27206
	for ; Tue, 10 Apr 2001 18:15:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2A71744337; Tue, 10 Apr 2001 18:15:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 6F63444336
	for ; Tue, 10 Apr 2001 18:14:51 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3AGEJP10939
	for ; Tue, 10 Apr 2001 11:14:19 -0500
Message-ID: <009001c0c20b$a9785bc0$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "IETF SIP (E-mail)" 
Subject: Fw: [SIP] Delivering Caller-ID through SIP
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
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 Apr 2001 17:02:14 -0500
Content-Transfer-Encoding: 7bit

whoops, forgot to copy the list here . . .

Sorry!

--
Dean

----- Original Message -----
From: "Dean Willis" 
To: "Sharath Rajasekar" 
Sent: Tuesday, April 10, 2001 11:56 AM
Subject: Re: [SIP] Delivering Caller-ID through SIP


> Personally, I set my From: field to: sip:9724735455@dfw.dynamicsoft.com
when
> placing a call through a gateway. All the gateway's I've worked with
happily
> strip off the domain part and copy 9724735455 into the Calling Party ID.
>
> This is facilitated by the phone on my desk, which supports multiple user
> profiles (lines). I have the line1 button set up to use my phone number in
> the From:, and line 2 set to use my username in the From:. I pick the
> appropriate "line" for an outbound call manually. Works dandy with no new
> headers.
>
> One might also envision a user outbound proxy or application server (or a
> smart UA) performing this service automatically on behlaf of the user.
>
> --
> Dean
>
>
> ----- Original Message -----
> From: "Sharath Rajasekar" 
> To: "sip list" ; 
> Sent: Monday, April 09, 2001 8:15 PM
> Subject: [SIP] Delivering Caller-ID through SIP
>
>
> >
> > Consider a SIP UA with a SIP URL userA@example.com which is associated
> > with a SIP Phone. This SIP Phone has a public number (444-555-6666).
> >
> > When a call is initiated by the phone, to a PSTN number, the following
> > INVITE will be sent out...
> >
> > INVITE sip:4085551111@gateway.company.com SIP/2.0
> >       From : UserA 
> > To : Unknown 
> >       ...
> >
> > How can one deliver the calling public number(444-555-6666 in this case)
> > to the PSTN as caller-id through the gateway ?
> >
> > Some generic tag may be used say..."pstn-number: 444-555-6666" in the
> > >From header, but this will mean that all gateways must support this
tag.
> > Is there some other solution to this problem.
> >
> >
> > Regards
> > Sharath
> >
> >
> >
> > _______________________________________________
> > 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  Tue Apr 10 18:28:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27346
	for ; Tue, 10 Apr 2001 18:28:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 31CD04434B; Tue, 10 Apr 2001 18:28:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41])
	by lists.bell-labs.com (Postfix) with ESMTP id 303C544337
	for ; Tue, 10 Apr 2001 18:27:23 -0400 (EDT)
Received: from notes500.cc.telcordia.com (notes500a.cc.telcordia.com [128.96.150.9])
	by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA14391;
	Tue, 10 Apr 2001 18:22:31 -0400 (EDT)
From: sghosh1@telcordia.com
Subject: Re: Fw: [SIP] Delivering Caller-ID through SIP
To: "Dean Willis" 
Cc: "IETF SIP (E-mail)" 
Message-ID: 
X-MIMETrack: Serialize by Router on notes500/Telcordia(Release 5.0.6 |December 14, 2000) at
 04/10/2001 06:22:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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 Apr 2001 18:22:05 -0400



How does SIP convey the "privacy indicator" (presentation restriction
information) to the ISUP/ISDN implementation
on the gateway when the outgoing IAM/SETUP is built ?  What if I dial *67
and want to supress my Caller-ID ?

/somit





"Dean Willis"  on 04/10/2001 06:02:14 PM

To:   "IETF SIP (E-mail)" 
cc:    (bcc: Somit Ghosh/Telcordia)
Subject:  Fw: [SIP] Delivering Caller-ID through SIP



whoops, forgot to copy the list here . . .

Sorry!

--
Dean

----- Original Message -----
From: "Dean Willis" 
To: "Sharath Rajasekar" 
Sent: Tuesday, April 10, 2001 11:56 AM
Subject: Re: [SIP] Delivering Caller-ID through SIP


> Personally, I set my From: field to: sip:9724735455@dfw.dynamicsoft.com
when
> placing a call through a gateway. All the gateway's I've worked with
happily
> strip off the domain part and copy 9724735455 into the Calling Party ID.
>
> This is facilitated by the phone on my desk, which supports multiple user
> profiles (lines). I have the line1 button set up to use my phone number
in
> the From:, and line 2 set to use my username in the From:. I pick the
> appropriate "line" for an outbound call manually. Works dandy with no new
> headers.
>
> One might also envision a user outbound proxy or application server (or a
> smart UA) performing this service automatically on behlaf of the user.
>
> --
> Dean
>
>
> ----- Original Message -----
> From: "Sharath Rajasekar" 
> To: "sip list" ; 
> Sent: Monday, April 09, 2001 8:15 PM
> Subject: [SIP] Delivering Caller-ID through SIP
>
>
> >
> > Consider a SIP UA with a SIP URL userA@example.com which is associated
> > with a SIP Phone. This SIP Phone has a public number (444-555-6666).
> >
> > When a call is initiated by the phone, to a PSTN number, the following
> > INVITE will be sent out...
> >
> > INVITE sip:4085551111@gateway.company.com SIP/2.0
> >       From : UserA 
> > To : Unknown 
> >       ...
> >
> > How can one deliver the calling public number(444-555-6666 in this
case)
> > to the PSTN as caller-id through the gateway ?
> >
> > Some generic tag may be used say..."pstn-number: 444-555-6666" in the
> > >From header, but this will mean that all gateways must support this
tag.
> > Is there some other solution to this problem.
> >
> >
> > Regards
> > Sharath
> >
> >
> >
> > _______________________________________________
> > 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@lists.bell-labs.com  Tue Apr 10 19:36:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28019
	for ; Tue, 10 Apr 2001 19:36:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E0CA144337; Tue, 10 Apr 2001 19:36:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DCE044336
	for ; Tue, 10 Apr 2001 19:35:19 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3ANXuJ04665
	for ; Tue, 10 Apr 2001 19:33:56 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 10 Apr 2001 19:35:14 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 10 Apr 2001 19:35:16 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250C96A@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "Mo Zonoun" , sip@lists.bell-labs.com
Subject: RE: [SIP] transfer call flows
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0C216.E29E0610"
X-Orig: 
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 Apr 2001 19:35:11 -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_01C0C216.E29E0610
Content-Type: text/plain;
	charset="iso-8859-1"

The accepted solution is to include an Accept_Contact: header in the INVITE,
(i.e. as a parameter to the URI in the Refer-To:) indicating the detailed
contact address to reach.  For an invitation to another party to join a
conference call on a bridge server, for instance, the Accept-Contact would
identify not only the bridge server but also the specific bridge serving the
conference.

-----Original Message-----
From: Zonoun, Mo [SC2:4K02:EXCH] 
Sent: Monday, April 09, 2001 5:00 PM
To: sip@lists.bell-labs.com
Subject: RE: [SIP] transfer call flows



I posted the following question while back but I didn't get any response. 
How do you make sure that a new INVITE in a Call Transfer gets to the
correct UA-C when there are multiple UA candidates, including the case where
the UA-C is a gateway to another network.

Mo Zonoun 


------_=_NextPart_001_01C0C216.E29E0610
Content-Type: text/html;
	charset="iso-8859-1"




RE: [SIP] transfer call flows




The 
accepted solution is to include an Accept_Contact: header in the INVITE, (i.e. 
as a parameter to the URI in the Refer-To:) indicating the detailed contact 
address to reach.  For an invitation to another party to join a conference 
call on a bridge server, for instance, the Accept-Contact would identify not 
only the bridge server but also the specific bridge serving the 
conference.



  
-----Original Message-----
From: Zonoun, Mo [SC2:4K02:EXCH] 
  
Sent: Monday, April 09, 2001 5:00 PM
To: 
  sip@lists.bell-labs.com
Subject: RE: [SIP] transfer call 
  flows


  
I posted the following question while back but I didn't get 
  any response. 
How do you make sure that a new INVITE 
  in a Call Transfer gets to the correct UA-C when there are multiple UA 
  candidates, including the case where the UA-C is a gateway to another 
  network.

  
Mo Zonoun 


------_=_NextPart_001_01C0C216.E29E0610--

_______________________________________________
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  Wed Apr 11 09:31:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23798
	for ; Wed, 11 Apr 2001 09:31:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8724944337; Wed, 11 Apr 2001 09:31:02 -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 42A1344336
	for ; Wed, 11 Apr 2001 09:30:03 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18643;
	Wed, 11 Apr 2001 09:29:07 -0400 (EDT)
Received: from slevy-pc (dhcp-64-102-97-110.cisco.com [64.102.97.110])
	by dingdong.cisco.com (Mirapoint)
	with SMTP id ACX07570;
	Wed, 11 Apr 2001 09:30:00 -0400 (EDT)
Message-Id: <4.1.20010411093200.009ff100@dingdong.cisco.com>
X-Sender: stlevy@dingdong.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: sghosh1@telcordia.com, "Dean Willis" 
From: Steve Levy 
Subject: Re: Fw: [SIP] Delivering Caller-ID through SIP
Cc: "IETF SIP (E-mail)" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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: Wed, 11 Apr 2001 09:36:08 -0700


Check Section 6.26 (From Header) of 2543.bis-02. There it states:

A system SHOULD use the display name "Anonymous" if the
   identity of the client is to remain hidden.

The 'Anonymous' should be converted into presentation restricted for ISUP/ISDN

Steve

At 06:22 PM 4/10/01 -0400, sghosh1@telcordia.com wrote:
>
>
>How does SIP convey the "privacy indicator" (presentation restriction
>information) to the ISUP/ISDN implementation
>on the gateway when the outgoing IAM/SETUP is built ?  What if I dial *67
>and want to supress my Caller-ID ?
>
>/somit
>
>
>
>
>
>"Dean Willis"  on 04/10/2001 06:02:14 PM
>
>To:   "IETF SIP (E-mail)" 
>cc:    (bcc: Somit Ghosh/Telcordia)
>Subject:  Fw: [SIP] Delivering Caller-ID through SIP
>
>
>
>whoops, forgot to copy the list here . . .
>
>Sorry!
>
>--
>Dean
>
>----- Original Message -----
>From: "Dean Willis" 
>To: "Sharath Rajasekar" 
>Sent: Tuesday, April 10, 2001 11:56 AM
>Subject: Re: [SIP] Delivering Caller-ID through SIP
>
>
>> Personally, I set my From: field to: sip:9724735455@dfw.dynamicsoft.com
>when
>> placing a call through a gateway. All the gateway's I've worked with
>happily
>> strip off the domain part and copy 9724735455 into the Calling Party ID.
>>
>> This is facilitated by the phone on my desk, which supports multiple user
>> profiles (lines). I have the line1 button set up to use my phone number
>in
>> the From:, and line 2 set to use my username in the From:. I pick the
>> appropriate "line" for an outbound call manually. Works dandy with no new
>> headers.
>>
>> One might also envision a user outbound proxy or application server (or a
>> smart UA) performing this service automatically on behlaf of the user.
>>
>> --
>> Dean
>>
>>
>> ----- Original Message -----
>> From: "Sharath Rajasekar" 
>> To: "sip list" ; 
>> Sent: Monday, April 09, 2001 8:15 PM
>> Subject: [SIP] Delivering Caller-ID through SIP
>>
>>
>> >
>> > Consider a SIP UA with a SIP URL userA@example.com which is associated
>> > with a SIP Phone. This SIP Phone has a public number (444-555-6666).
>> >
>> > When a call is initiated by the phone, to a PSTN number, the following
>> > INVITE will be sent out...
>> >
>> > INVITE sip:4085551111@gateway.company.com SIP/2.0
>> >       From : UserA 
>> > To : Unknown 
>> >       ...
>> >
>> > How can one deliver the calling public number(444-555-6666 in this
>case)
>> > to the PSTN as caller-id through the gateway ?
>> >
>> > Some generic tag may be used say..."pstn-number: 444-555-6666" in the
>> > >From header, but this will mean that all gateways must support this
>tag.
>> > Is there some other solution to this problem.
>> >
>> >
>> > Regards
>> > Sharath
>> >
>> >
>> >
>> > _______________________________________________
>> > 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@lists.bell-labs.com  Wed Apr 11 10:23:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24704
	for ; Wed, 11 Apr 2001 10:23:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5C72944337; Wed, 11 Apr 2001 10:23: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 D654644336
	for ; Wed, 11 Apr 2001 10:22:38 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00956
	for ; Wed, 11 Apr 2001 10:26:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 11 Apr 2001 10:22:38 -0400
Message-ID: 
From: Rakesh Shah 
To: "SIPWG Mailing List (E-mail)" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C292.DBF53F58"
Subject: [SIP] Email Addresses Needed
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: Wed, 11 Apr 2001 10:22:37 -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_01C0C292.DBF53F58
Content-Type: text/plain;
	charset="iso-8859-1"

There are several people that have signed up to be NITS and draft reviewers
that I don't have email addresses for. I need email addresses for the
following:
 
Deason, Neil
Gilad, Itimar
Levin, Orit
Marples, Dave
Undery, James
Vahrahtree, Jayshree
Yu, James
 
Please forgive any misspellings (and please do correct me).

Regards,

Rakesh
_______________________________
Mr. Rakesh C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
1st Floor
East Hanover, N.J. 07936 
(973) 952-5066 direct 
(201) 214-6084 cell
(973) 952-5000 main
(973) 952-5050 fax
rshah@dynamicsoft.com 

 

------_=_NextPart_001_01C0C292.DBF53F58
Content-Type: text/html;
	charset="iso-8859-1"









There are several people that have signed up to be NITS 
and draft reviewers that I don't have email addresses for. I need email 
addresses for the following:


 


Deason, Neil


Gilad, Itimar


Levin, Orit


Marples, Dave


Undery, James


Vahrahtree, Jayshree


Yu, 
James


 


Please forgive any misspellings (and please do correct 
me).


Regards,

Rakesh
_______________________________
Mr. Rakesh 
C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock 
Avenue
1st Floor
East Hanover, N.J. 07936 
(973) 
952-5066 direct 
(201) 214-6084 cell
(973) 952-5000 main
(973) 952-5050 
fax
rshah@dynamicsoft.com 


 


------_=_NextPart_001_01C0C292.DBF53F58--

_______________________________________________
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  Wed Apr 11 10:51:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25276
	for ; Wed, 11 Apr 2001 10:51:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 968E244340; Wed, 11 Apr 2001 10:51:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by lists.bell-labs.com (Postfix) with ESMTP id A113A44337
	for ; Wed, 11 Apr 2001 10:50:54 -0400 (EDT)
Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10])
	by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id f3BEoJ923727;
	Wed, 11 Apr 2001 09:50:19 -0500 (CDT)
Received: from trimail2.tri.sbc.com (localhost [127.0.0.1])
	by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id f3BEoj716607;
	Wed, 11 Apr 2001 09:50:45 -0500 (CDT)
Received: by morprs04.sbc.com with Internet Mail Service (5.5.2448.0)
	id ; Wed, 11 Apr 2001 09:50:40 -0500
Message-ID: <4D45BA2A58A7D3119E050008C7E69E29B40DE9@morprs04.sbc.com>
From: "Parolkar, Satish" 
To: "'Medhavi'" ,
        Sharath Rajasekar ,
        sip list , jdrosen@dynamicsoft.com
Subject: RE: [SIP] Delivering Caller-ID through SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
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: Wed, 11 Apr 2001 09:50:37 -0500

I wonder if one could use the optional Display Name to deliver the public
number associated with the SIP phone.

When a call is initiated by the SIP phone with public number 444-555-6666,
to a PSTN number 4085551111, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : 4445556666 
	To : Unknown 
      ...

However, the issue remains 
Who is responsible to authenticate the number delivered to the PSTN?
A user can put any number desired. Is the IP/PSTN gateway responsible to
authenticate the Delivered Number?


Comments.

Satish

-----Original Message-----
From: Medhavi [mailto:mbhatia@nextone.com]
Sent: Monday, April 09, 2001 8:38 PM
To: Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com
Subject: RE: [SIP] Delivering Caller-ID through SIP


I think you can use the p= in SDP, as one option.

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar
Sent: Monday, April 09, 2001 9:16 PM
To: sip list; jdrosen@dynamicsoft.com
Subject: [SIP] Delivering Caller-ID through SIP



Consider a SIP UA with a SIP URL userA@example.com which is associated 
with a SIP Phone. This SIP Phone has a public number (444-555-6666). 

When a call is initiated by the phone, to a PSTN number, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : UserA 
	To : Unknown 
      ...

How can one deliver the calling public number(444-555-6666 in this case) 
to the PSTN as caller-id through the gateway ?
  
Some generic tag may be used say..."pstn-number: 444-555-6666" in the 
>From header, but this will mean that all gateways must support this tag.
Is there some other solution to this problem.


Regards
Sharath



_______________________________________________
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@lists.bell-labs.com  Wed Apr 11 11:09:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25663
	for ; Wed, 11 Apr 2001 11:09:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F38B9443A2; Wed, 11 Apr 2001 11:09:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ns-inetext.inet.com (ns-inetext.inet.com [199.171.211.140])
	by lists.bell-labs.com (Postfix) with ESMTP id C93644439F
	for ; Wed, 11 Apr 2001 11:08:12 -0400 (EDT)
Received: from harpo.inetint.com (harpo [172.16.99.60])
	by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id KAA06198
	for ; Wed, 11 Apr 2001 10:08:12 -0500 (CDT)
Received: from inet.com ([172.16.13.183]) by harpo.inetint.com
          (Netscape Messaging Server 4.15) with ESMTP id GBMVDM00.971;
          Wed, 11 Apr 2001 10:08:10 -0500 
Message-ID: <3AD47361.6E558670@inet.com>
From: "Mart Nurmet" 
Organization: NI Product Technology
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Parolkar Satish" 
Cc: "'Medhavi'" ,
        Sharath Rajasekar ,
        sip list , jdrosen@dynamicsoft.com
Subject: Re: [SIP] Delivering Caller-ID through SIP
References: <4D45BA2A58A7D3119E050008C7E69E29B40DE9@morprs04.sbc.com>
Content-Type: multipart/mixed;
 boundary="------------2158A0E5ACE9763B00AB6A3F"
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: Wed, 11 Apr 2001 10:08:18 -0500

This is a multi-part message in MIME format.
--------------2158A0E5ACE9763B00AB6A3F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Further, how will the PSTNs treat this if it was a possibly ported number when
presented to them?  And let's not forget, that Area 1, dialing plans don't
necessarily hold for the rest of the world.  Will 15 digit dialing be
standardized soon?  Or other plans.

"Parolkar, Satish" wrote:

> I wonder if one could use the optional Display Name to deliver the public
> number associated with the SIP phone.
>
> When a call is initiated by the SIP phone with public number 444-555-6666,
> to a PSTN number 4085551111, the following
> INVITE will be sent out...
>
>         INVITE sip:4085551111@gateway.company.com SIP/2.0
>       From : 4445556666 
>         To : Unknown 
>       ...
>
> However, the issue remains
> Who is responsible to authenticate the number delivered to the PSTN?
> A user can put any number desired. Is the IP/PSTN gateway responsible to
> authenticate the Delivered Number?
>
> Comments.
>
> Satish
>
> -----Original Message-----
> From: Medhavi [mailto:mbhatia@nextone.com]
> Sent: Monday, April 09, 2001 8:38 PM
> To: Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com
> Subject: RE: [SIP] Delivering Caller-ID through SIP
>
> I think you can use the p= in SDP, as one option.
>
> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar
> Sent: Monday, April 09, 2001 9:16 PM
> To: sip list; jdrosen@dynamicsoft.com
> Subject: [SIP] Delivering Caller-ID through SIP
>
> Consider a SIP UA with a SIP URL userA@example.com which is associated
> with a SIP Phone. This SIP Phone has a public number (444-555-6666).
>
> When a call is initiated by the phone, to a PSTN number, the following
> INVITE will be sent out...
>
>         INVITE sip:4085551111@gateway.company.com SIP/2.0
>       From : UserA 
>         To : Unknown 
>       ...
>
> How can one deliver the calling public number(444-555-6666 in this case)
> to the PSTN as caller-id through the gateway ?
>
> Some generic tag may be used say..."pstn-number: 444-555-6666" in the
> >From header, but this will mean that all gateways must support this tag.
> Is there some other solution to this problem.
>
> Regards
> Sharath
>
> _______________________________________________
> 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.

--------------2158A0E5ACE9763B00AB6A3F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mart.nurmet.vcf"
Content-Description: Card for Mart Nurmet
Content-Disposition: attachment;
 filename="mart.nurmet.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Nurmet;Mart
tel;fax:469 330 4001
tel;home:972 424-9593
tel;work:469 330-4291
x-mozilla-html:TRUE
url:http://www.inet.com
org:Inet Technologies Inc.;NI Product Technology
version:2.1
email;internet:mart.nurmet@inet.com
title:Staff Engineer
adr;quoted-printable:;;1500 N. Greenville Ave.  =0D=0ARoom 619;Richardson;Texas;75081;USA
fn:Mart Nurmet
end:vcard

--------------2158A0E5ACE9763B00AB6A3F--


_______________________________________________
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  Wed Apr 11 12:10:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27284
	for ; Wed, 11 Apr 2001 12:10:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 70A364434A; Wed, 11 Apr 2001 12:10:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 215BC44337
	for ; Wed, 11 Apr 2001 12:09:03 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2L9Z7NG3>; Wed, 11 Apr 2001 09:08:25 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Parolkar, Satish'" ,
        "'Medhavi'" ,
        Sharath Rajasekar ,
        sip list , jdrosen@dynamicsoft.com
Subject: RE: [SIP] Delivering Caller-ID through SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C2A1.A25A6450"
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: Wed, 11 Apr 2001 09:08:23 -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_01C0C2A1.A25A6450
Content-Type: text/plain;
	charset="iso-8859-1"

These issues are addressed in
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-dcsgroup-sip-privacy-02.txt
 

Robert.

-----Original Message-----
From:	Parolkar, Satish [mailto:parolkar@tri.sbc.com]
Sent:	Wednesday, April 11, 2001 3:51 PM
To:	'Medhavi'; Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com
Subject:	RE: [SIP] Delivering Caller-ID through SIP

I wonder if one could use the optional Display Name to deliver the public
number associated with the SIP phone.

When a call is initiated by the SIP phone with public number 444-555-6666,
to a PSTN number 4085551111, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : 4445556666 
	To : Unknown 
      ...

However, the issue remains 
Who is responsible to authenticate the number delivered to the PSTN?
A user can put any number desired. Is the IP/PSTN gateway responsible to
authenticate the Delivered Number?


Comments.

Satish

-----Original Message-----
From: Medhavi [mailto:mbhatia@nextone.com]
Sent: Monday, April 09, 2001 8:38 PM
To: Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com
Subject: RE: [SIP] Delivering Caller-ID through SIP


I think you can use the p= in SDP, as one option.

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar
Sent: Monday, April 09, 2001 9:16 PM
To: sip list; jdrosen@dynamicsoft.com
Subject: [SIP] Delivering Caller-ID through SIP



Consider a SIP UA with a SIP URL userA@example.com which is associated 
with a SIP Phone. This SIP Phone has a public number (444-555-6666). 

When a call is initiated by the phone, to a PSTN number, the following
INVITE will be sent out...

	INVITE sip:4085551111@gateway.company.com SIP/2.0
      From : UserA 
	To : Unknown 
      ...

How can one deliver the calling public number(444-555-6666 in this case) 
to the PSTN as caller-id through the gateway ?
  
Some generic tag may be used say..."pstn-number: 444-555-6666" in the 
>From header, but this will mean that all gateways must support this tag.
Is there some other solution to this problem.


Regards
Sharath



_______________________________________________
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.

------_=_NextPart_001_01C0C2A1.A25A6450
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Delivering Caller-ID through SIP




These issues are addressed in =
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-dcsgroup=
-sip-privacy-02.txt




Robert.




-----Original =
Message-----

From:   Parolkar, Satish =
[mailto:parolkar@tri.sbc.com]

Sent:   Wednesday, April 11, 2001 3:51 PM

To:     'Medhavi'; Sharath Rajasekar; sip list; =
jdrosen@dynamicsoft.com

Subject:       =
 RE: [SIP] Delivering Caller-ID =
through SIP




I wonder if one could use the optional =
Display Name to deliver the public

number associated with the SIP =
phone.




When a call is initiated by the SIP =
phone with public number 444-555-6666,

to a PSTN number 4085551111, the =
following

INVITE will be sent out...




        INVITE sip:4085551111@gateway.company.com SIP/2.0

      From : =
4445556666 <sip:userA@example.com>

        To : Unknown =
<sip:4085551111@gateway.company.com>

      =
...




However, the issue remains 

Who is responsible to authenticate =
the number delivered to the PSTN?

A user can put any number desired. Is =
the IP/PSTN gateway responsible to

authenticate the Delivered =
Number?






Comments.




Satish




-----Original Message-----

From: Medhavi [mailto:mbhatia@nextone.com]

Sent: Monday, April 09, 2001 8:38 =
PM

To: Sharath Rajasekar; sip list; =
jdrosen@dynamicsoft.com

Subject: RE: [SIP] Delivering =
Caller-ID through SIP






I think you can use the p=3D in SDP, =
as one option.




-----Original Message-----

From: =
sip-admin@lists.bell-labs.com

[mailto:sip-admin@lists.bel=
l-labs.com]On Behalf Of Sharath Rajasekar

Sent: Monday, April 09, 2001 9:16 =
PM

To: sip list; =
jdrosen@dynamicsoft.com

Subject: [SIP] Delivering Caller-ID =
through SIP








Consider a SIP UA with a SIP URL =
userA@example.com which is associated 

with a SIP Phone. This SIP Phone has =
a public number (444-555-6666). 




When a call is initiated by the phone, =
to a PSTN number, the following

INVITE will be sent out...




        INVITE sip:4085551111@gateway.company.com SIP/2.0

      From : =
UserA <sip:userA@example.com>

        To : Unknown =
<sip:4085551111@gateway.company.com>

      =
...




How can one deliver the calling public =
number(444-555-6666 in this case) 

to the PSTN as caller-id through the =
gateway ?

  

Some generic tag may be used =
say..."pstn-number: 444-555-6666" in the 

>From header, but this will mean =
that all gateways must support this tag.

Is there some other solution to this =
problem.






Regards

Sharath








_______________________________________________

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.





------_=_NextPart_001_01C0C2A1.A25A6450--

_______________________________________________
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  Wed Apr 11 12:33:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27983
	for ; Wed, 11 Apr 2001 12:33:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 975924435F; Wed, 11 Apr 2001 12:33:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from email1.chelmsford.castlenetworks.com (mailhost1.castlenetworks.com [63.93.189.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C22DF44337
	for ; Wed, 11 Apr 2001 12:32:09 -0400 (EDT)
Received: by email1.chelmsford.castlenetworks.com with Internet Mail Service (5.5.2653.19)
	id <2RDN3XZJ>; Wed, 11 Apr 2001 12:32:09 -0400
Received: from unispherenetworks.com (BOOTES [10.1.1.21]) by email2.chelmsford.castlenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2RCR1QF1; Wed, 11 Apr 2001 12:31:56 -0400
Message-ID: <3AD48723.B35AF1B5@unispherenetworks.com>
From: Sonit Mahey 
Organization: Unisphere Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP Mailing List , jdrosen@dynamicsoft.com,
        hgs@cs.columbia.edu
Content-Type: multipart/mixed;
 boundary="------------2D94B0786202D12D6B48077B"
Subject: [SIP] Delivering CgPN in 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: Wed, 11 Apr 2001 12:32:35 -0400

This is a multi-part message in MIME format.
--------------2D94B0786202D12D6B48077B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

[SMahey] What's more important is the transport of presentation and
screening indicators alongwith CgPN. I guess the need to interwork and
make the underlying signaling transparent to the user, in that the "look
and feel" using VoIP is no different than circuit switching and SS7 -,
would call for SIP being able to deliver capabilities of PSTN/PLMN
protocols, at a minimum. 

Mart Numet wrote:
Further, how will the PSTNs treat this if it was a possibly ported
number when
presented to them?  And let's not forget, that Area 1, dialing plans
don't
necessarily hold for the rest of the world.  Will 15 digit dialing be
standardized soon?  Or other plans.

"Parolkar, Satish" wrote:

> I wonder if one could use the optional Display Name to deliver the public
> number associated with the SIP phone.
>
> When a call is initiated by the SIP phone with public number 444-555-6666,
> to a PSTN number 4085551111, the following
> INVITE will be sent out...
>
>         INVITE sip:4085551111@gateway.company.com SIP/2.0
>       From : 4445556666 
>         To : Unknown 
>       ...
>
> However, the issue remains
> Who is responsible to authenticate the number delivered to the PSTN?
> A user can put any number desired. Is the IP/PSTN gateway responsible to
> authenticate the Delivered Number?
>
> Comments.
>
> Satish
>
> -----Original Message-----
> From: Medhavi [mailto:mbhatia@nextone.com]
> Sent: Monday, April 09, 2001 8:38 PM
> To: Sharath Rajasekar; sip list; jdrosen@dynamicsoft.com
> Subject: RE: [SIP] Delivering Caller-ID through SIP
>
> I think you can use the p= in SDP, as one option.
>
> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Sharath Rajasekar
> Sent: Monday, April 09, 2001 9:16 PM
> To: sip list; jdrosen@dynamicsoft.com
> Subject: [SIP] Delivering Caller-ID through SIP
>
> Consider a SIP UA with a SIP URL userA@example.com which is associated
> with a SIP Phone. This SIP Phone has a public number (444-555-6666).
>
> When a call is initiated by the phone, to a PSTN number, the following
> INVITE will be sent out...
>
>         INVITE sip:4085551111@gateway.company.com SIP/2.0
>       From : UserA 
>         To : Unknown 
>       ...
>
> How can one deliver the calling public number(444-555-6666 in this case)
> to the PSTN as caller-id through the gateway ?
>
> Some generic tag may be used say..."pstn-number: 444-555-6666" in the
> >From header, but this will mean that all gateways must support this tag.
> Is there some other solution to this problem.
>
> Regards
> Sharath
-- 
 S. Mahey	              		
 smahey@unispherenetworks.com 		
 http://www.unispherenetworks.com/      

¦ The reasonable man adapts himself to the ¦
¦ world; the unreasonable one persists in  ¦
¦ trying  to adapt the  world  to himself. ¦
¦ Therefore  all  progress  depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦


--------------2D94B0786202D12D6B48077B
Content-Type: text/x-vcard; charset=us-ascii;
 name="smahey.vcf"
Content-Description: Card for Sonit Mahey
Content-Disposition: attachment;
 filename="smahey.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Mahey;Sonit 
tel;fax:1.978.848.3620
tel;work:1.978.848.0434
x-mozilla-html:TRUE
url:www.unispherenetworks.com
org:Unisphere Networks;Voice Engineering
adr:;;One Executive Drive,;Chelmsford;MA;01824;USA
version:2.1
email;internet:smahey@unispherenetworks.com
title:Member - Technical Staff
fn:Sonit Mahey
end:vcard

--------------2D94B0786202D12D6B48077B--

_______________________________________________
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  Wed Apr 11 13:58:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29897
	for ; Wed, 11 Apr 2001 13:58:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 483FE4435F; Wed, 11 Apr 2001 13:58: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 CEF4F4434A
	for ; Wed, 11 Apr 2001 13:57:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA04547
	for ; Wed, 11 Apr 2001 14:01:06 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 11 Apr 2001 13:57:36 -0400
Message-ID: 
From: Rakesh Shah 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [SIP] NITS Reviewers Needed for These Drafts!
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: Wed, 11 Apr 2001 13:57:36 -0400

I have collected names of people who have volunteered to be NITS and Last
Call Reviewers. I have posted these names and some reference material at
http://www.softarmor.com/sipwg/draftstatus/reviewers.html.

As each draft comes up for review I will solicit the entire list to get
someone interested in the draft to do the NITS review and then the Last Call
review.

If I do not get any interest in two days, I will select someone off of the
volunteer list and ask them to do it.

With that said, here are the drafts that require NITS review:

draft-campbell-sip-e164-00.txt
draft-ietf-sip-cc-transfer-04.txt
draft-ietf-sip-session-timer-04.txt
draft-campbell-sip-cc-framework-02.txt
draft-ietf-sip-call-flows-04.txt
draft-ietf-sip-isup-00.txt
draft-ietf-sip-isup-mime-09.txt

The actual drafts and schedule dates can be seen at
http://www.softarmor.com/sipwg/draftstatus/lc_calendar.html.

Please contact me (rshah@dynamicsoft) directly and we can kick this off.
First come, first serve. :)

Regards,

Rakesh

_______________________________________________
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  Wed Apr 11 16:34:03 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02855
	for ; Wed, 11 Apr 2001 16:34:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BAFAD44337; Wed, 11 Apr 2001 16:34:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 8F07D44336
	for ; Wed, 11 Apr 2001 16:33:13 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsoft.com (8.8.8) id QAA91605; Wed, 11 Apr 2001 16:24:28 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'Mo Zonoun'" , 
Subject: RE: [SIP] transfer call flows
Message-ID: <001a01c0c2c5$a4c16ee0$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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <28560036253BD41191A10000F8BCBD110250C96A@zcard00g.ca.nortel.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: Wed, 11 Apr 2001 16:26:08 -0400
Content-Transfer-Encoding: 7bit

> The accepted solution is to include an 
> Accept_Contact: header in the INVITE, 
> (i.e. as a parameter to the URI in the 
> Refer-To:) indicating the detailed contact 
> address to reach.  For an invitation to 
> another party to join a conference call on 
> a bridge server, for instance, the 
> Accept-Contact would identify not only 
> the bridge server but also the specific 
> bridge serving the conference.

The above solution works when only a single 
Request-URI change is involved in delivery 
of the INVITE to the final UA.

A Refer-To with pre-loaded Route is needed 
when multiple proxies (potentially changing 
Request-URI) are involved in reaching the 
final destination UA.

> > I posted the following question while back 
> > but I didn't get any response.

See 
http://lists.bell-labs.com/pipermail/sip/2001q1/006480.html
 
> > How do you make sure that a new INVITE in 
> > a Call Transfer gets to the correct UA-C 
> > when there are multiple UA candidates, 
> > including the case where the UA-C is a 
> > gateway to another network.


_______________________________________________
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  Wed Apr 11 17:41:02 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03880
	for ; Wed, 11 Apr 2001 17:41:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C4BC044337; Wed, 11 Apr 2001 17:41:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 41C3444336
	for ; Wed, 11 Apr 2001 17:40:28 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id VAA02155
	for ; Wed, 11 Apr 2001 21:40:22 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 11 Apr 2001 21:40:22 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <2VMMRNTR>; Wed, 11 Apr 2001 14:40:21 -0700
Message-ID: 
From: "Beereddy, Srini" 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [SIP] Conflict between Contact Header definition and example
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: Wed, 11 Apr 2001 14:40:19 -0700



There is a conflict between the "Contact" header definition and an example
of it in the section 6.38 2nd paragraph, 2nd line 

"Contact: * ;expires: 0".

According to the definition of Contact header, it can have a "*" or list of
(( name-addr | addr-spec ) *( ";" contact-params ) ).

The "expires" parameter is part of "contact-params" which can only be
present ( name-addr | addr-spec ). So the example in the section is 6.38 is
wrong.

For a quick reference I have added the 2nd paragraph of section 6.38 and
definition of the Contact header

thanks,
Srini Beereddy,
Trillium Digital Systems, an Intel Company.

section 6.38 2nd paragraph
==========================
   A REGISTER request MAY include this header field when deleting
   registrations with "Contact: * ;expires: 0". The Retry-After value
   then indicates when the user might again be reachable. The registrar
   MAY then include this information in responses to future calls.

Contact Header
==============

Contact = ( "Contact" | "m" ) ":" 
    ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))

   name-addr      = [ display-name ] "<" addr-spec ">"
   addr-spec      = SIP-URL | URI
   display-name   = *token | quoted-string

   contact-params = "q"       "=" qvalue
                  | "action"  "=" "proxy" | "redirect"
                  | "expires" "=" delta-seconds | <"> SIP-date <">
                  | contact-extension

   contact-extension = generic-param
   qvalue            = ( "0" [ "." 0*3DIGIT ] )
                     | ( "1" [ "." 0*3("0") ] )






_______________________________________________
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  Wed Apr 11 21:44:09 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07102
	for ; Wed, 11 Apr 2001 21:44:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 60F5344337; Wed, 11 Apr 2001 21:44:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id F411044336
	for ; Wed, 11 Apr 2001 21:43:11 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA02535;
	Wed, 11 Apr 2001 21:43:10 -0400 (EDT)
Message-ID: <3AD5082E.7751C181@cs.columbia.edu>
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Beereddy, Srini" 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Conflict between Contact Header definition and example
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: Wed, 11 Apr 2001 21:43:10 -0400
Content-Transfer-Encoding: 7bit

Thanks for pointing this out. I would say that

Contact: *
Expires: 0

would be sufficient. Indeed, is there any reasonable use for the * URL
beyond expiration, i.e., I'm assuming that somethig like

Contact: *
Expires: 3600

would not be allowed. It's probably too late for that, but one could
probably simplify to have 'Expires: 0' mean

What do implementations do:
1) two headers (Expires: 0  and Contact: *)
2) one header: (Contact: *;expires: 0)
3) ignore the * and just use Expires: 0 [I doubt this is common...] 

I suspect the solution will be to allow  ;expires=something or just
;expires=0 with *.

"Beereddy, Srini" wrote:
> 
> There is a conflict between the "Contact" header definition and an example
> of it in the section 6.38 2nd paragraph, 2nd line
> 
> "Contact: * ;expires: 0".
> 
> According to the definition of Contact header, it can have a "*" or list of
> (( name-addr | addr-spec ) *( ";" contact-params ) ).
> 
> The "expires" parameter is part of "contact-params" which can only be
> present ( name-addr | addr-spec ). So the example in the section is 6.38 is
> wrong.
> 
> For a quick reference I have added the 2nd paragraph of section 6.38 and
> definition of the Contact header
> 
> thanks,
> Srini Beereddy,
> Trillium Digital Systems, an Intel Company.
> 
> section 6.38 2nd paragraph
> ==========================
>    A REGISTER request MAY include this header field when deleting
>    registrations with "Contact: * ;expires: 0". The Retry-After value
>    then indicates when the user might again be reachable. The registrar
>    MAY then include this information in responses to future calls.
> 
> Contact Header
> ==============
> 
> Contact = ( "Contact" | "m" ) ":"
>     ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))
> 
>    name-addr      = [ display-name ] "<" addr-spec ">"
>    addr-spec      = SIP-URL | URI
>    display-name   = *token | quoted-string
> 
>    contact-params = "q"       "=" qvalue
>                   | "action"  "=" "proxy" | "redirect"
>                   | "expires" "=" delta-seconds | <"> SIP-date <">
>                   | contact-extension
> 
>    contact-extension = generic-param
>    qvalue            = ( "0" [ "." 0*3DIGIT ] )
>                      | ( "1" [ "." 0*3("0") ] )
> 
> _______________________________________________
> 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.

-- 
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 Apr 12 01:56:04 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 BAA15489
	for ; Thu, 12 Apr 2001 01:56:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E352E4434B; Thu, 12 Apr 2001 01:56:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id EA4BC44336
	for ; Thu, 12 Apr 2001 01:55:05 -0400 (EDT)
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 f3C5tsM23590;
	Thu, 12 Apr 2001 11:26:09 +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 f3C63nL11531;
	Thu, 12 Apr 2001 11:33:55 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256A2C.00206032 ; Thu, 12 Apr 2001 11:23:37 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Henning G. Schulzrinne" 
Cc: "Beereddy, Srini" , sip@lists.bell-labs.com
Message-ID: <65256A2C.0020600F.00@sampark.hss.hns.com>
Subject: Re: [SIP] Conflict between Contact Header definition and example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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, 12 Apr 2001 11:23:36 +0530




hgs> What do implementations do:
hgs> 1) two headers (Expires: 0  and Contact: *)
hgs> 2) one header: (Contact: *;expires: 0)
hgs> 3) ignore the * and just use Expires: 0 [I doubt this is common...]
hgs>
hgs> I suspect the solution will be to allow  ;expires=something or just
hgs> ;expires=0 with *.

But this solution would break the already existing grammar if we allow
an expires parameter with a Contact *. Since
Contact: *
Expires: 0
has the same effect as Contact:*; expires=0 and it already exists
without breaking the current grammar.
 - my take would be to keep it as it and disallow expires param in contact
*.
(solution 1 )

regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems












"Beereddy, Srini" wrote:
>
> There is a conflict between the "Contact" header definition and an
example
> of it in the section 6.38 2nd paragraph, 2nd line
>
> "Contact: * ;expires: 0".
>
> According to the definition of Contact header, it can have a "*" or list
of
> (( name-addr | addr-spec ) *( ";" contact-params ) ).
>
> The "expires" parameter is part of "contact-params" which can only be
> present ( name-addr | addr-spec ). So the example in the section is 6.38
is
> wrong.
>
> For a quick reference I have added the 2nd paragraph of section 6.38 and
> definition of the Contact header
>
> thanks,
> Srini Beereddy,
> Trillium Digital Systems, an Intel Company.
>
> section 6.38 2nd paragraph
> ==========================
>    A REGISTER request MAY include this header field when deleting
>    registrations with "Contact: * ;expires: 0". The Retry-After value
>    then indicates when the user might again be reachable. The registrar
>    MAY then include this information in responses to future calls.
>
> Contact Header
> ==============
>
> Contact = ( "Contact" | "m" ) ":"
>     ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))
>
>    name-addr      = [ display-name ] "<" addr-spec ">"
>    addr-spec      = SIP-URL | URI
>    display-name   = *token | quoted-string
>
>    contact-params = "q"       "=" qvalue
>                   | "action"  "=" "proxy" | "redirect"
>                   | "expires" "=" delta-seconds | <"> SIP-date <">
>                   | contact-extension
>
>    contact-extension = generic-param
>    qvalue            = ( "0" [ "." 0*3DIGIT ] )
>                      | ( "1" [ "." 0*3("0") ] )
>
> _______________________________________________
> 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.

--
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 Apr 12 08:45:05 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 IAA28339
	for ; Thu, 12 Apr 2001 08:45: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 EC1A94433F; Thu, 12 Apr 2001 08:45:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 9F45844336
	for ; Thu, 12 Apr 2001 08:44:01 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A2BCA501A2; Thu, 12 Apr 2001 08:42:36 -0400
Message-ID: <002101c0c34e$7a6e7aa0$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: , "Henning G. Schulzrinne" 
Cc: "Beereddy, Srini" , 
References: <65256A2C.0020600F.00@sampark.hss.hns.com>
Subject: Re: [SIP] Conflict between Contact Header definition and example
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
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, 12 Apr 2001 08:45:34 -0400
Content-Transfer-Encoding: 7bit



----- Original Message -----
From: 
To: "Henning G. Schulzrinne" 
Cc: "Beereddy, Srini" ; 
Sent: Thursday, April 12, 2001 1:53 AM
Subject: Re: [SIP] Conflict between Contact Header definition and example


>
>
>
> hgs> What do implementations do:
> hgs> 1) two headers (Expires: 0  and Contact: *)
> hgs> 2) one header: (Contact: *;expires: 0)
> hgs> 3) ignore the * and just use Expires: 0 [I doubt this is common...]
> hgs>
> hgs> I suspect the solution will be to allow  ;expires=something or just
> hgs> ;expires=0 with *.
>
> But this solution would break the already existing grammar if we allow
> an expires parameter with a Contact *. Since
> Contact: *
> Expires: 0
> has the same effect as Contact:*; expires=0 and it already exists
> without breaking the current grammar.
>  - my take would be to keep it as it and disallow expires param in contact
> *.
> (solution 1 )
>

Adding an optional "expires=0" parameter to the grammar would not break any
existing implementations. I suspect there may be some implementations that
have used solution 2.

>
> regds
> Arjun
> --
> Arjun Roychowdhury @ Hughes Software Systems
>
>
> "Beereddy, Srini" wrote:
> >
> > There is a conflict between the "Contact" header definition and an
> example
> > of it in the section 6.38 2nd paragraph, 2nd line
> >
> > "Contact: * ;expires: 0".
> >
> > According to the definition of Contact header, it can have a "*" or list
> of
> > (( name-addr | addr-spec ) *( ";" contact-params ) ).
> >
> > The "expires" parameter is part of "contact-params" which can only be
> > present ( name-addr | addr-spec ). So the example in the section is 6.38
> is
> > wrong.
> >
> > For a quick reference I have added the 2nd paragraph of section 6.38 and
> > definition of the Contact header
> >
> > thanks,
> > Srini Beereddy,
> > Trillium Digital Systems, an Intel Company.
> >
> > section 6.38 2nd paragraph
> > ==========================
> >    A REGISTER request MAY include this header field when deleting
> >    registrations with "Contact: * ;expires: 0". The Retry-After value
> >    then indicates when the user might again be reachable. The registrar
> >    MAY then include this information in responses to future calls.
> >
> > Contact Header
> > ==============
> >
> > Contact = ( "Contact" | "m" ) ":"
> >     ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))
> >
> >    name-addr      = [ display-name ] "<" addr-spec ">"
> >    addr-spec      = SIP-URL | URI
> >    display-name   = *token | quoted-string
> >
> >    contact-params = "q"       "=" qvalue
> >                   | "action"  "=" "proxy" | "redirect"
> >                   | "expires" "=" delta-seconds | <"> SIP-date <">
> >                   | contact-extension
> >
> >    contact-extension = generic-param
> >    qvalue            = ( "0" [ "." 0*3DIGIT ] )
> >                      | ( "1" [ "." 0*3("0") ] )
> >
> > _______________________________________________
> > 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.
>
> --
> 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.
>

Bob
d:-)


Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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@lists.bell-labs.com  Thu Apr 12 08:53:04 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 IAA28545
	for ; Thu, 12 Apr 2001 08:53:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6F4F94436E; Thu, 12 Apr 2001 08:53:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 604FD44358
	for ; Thu, 12 Apr 2001 08:52:34 -0400 (EDT)
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 f3CCrg708104;
	Thu, 12 Apr 2001 18:23:43 +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 f3CD1PL29246;
	Thu, 12 Apr 2001 18:31:31 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256A2C.00469A55 ; Thu, 12 Apr 2001 18:21:10 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Bob Penfield" 
Cc: archow@hss.hns.com, "Henning G. Schulzrinne" ,
        "Beereddy, Srini" , sip@lists.bell-labs.com
Message-ID: <65256A2C.00469981.00@sampark.hss.hns.com>
Subject: Re: [SIP] Conflict between Contact Header definition and example
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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, 12 Apr 2001 18:21:07 +0530



bob> Adding an optional "expires=0" parameter to the grammar would not
break any
bob> existing implementations. I suspect there may be some implementations
that
bob> have used solution 2.

Well, the moment you add new rules to the grammar there is always a chance
someone will break.
This is different from adding new tokens which comply to the generic ABNF.
In some cases it may be worth it - but I dont feel so in this case,
especially when
there is another way to do it - which is already complaint to the existing
ABNF .
If solutions have used the extra parameter after Contact *, they must know
that its
possible that a 3rd party registrar might not recognize it, since its not a
part of the standard.
So its not reasonable to say it will work always.

regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems




"Bob Penfield"  on 04/12/2001 06:15:34 PM

To:   archow, "Henning G. Schulzrinne" 
cc:   "Beereddy, Srini" , sip@lists.bell-labs.com

Subject:  Re: [SIP] Conflict between Contact Header definition and example






----- Original Message -----
From: 
To: "Henning G. Schulzrinne" 
Cc: "Beereddy, Srini" ; 
Sent: Thursday, April 12, 2001 1:53 AM
Subject: Re: [SIP] Conflict between Contact Header definition and example


>
>
>
> hgs> What do implementations do:
> hgs> 1) two headers (Expires: 0  and Contact: *)
> hgs> 2) one header: (Contact: *;expires: 0)
> hgs> 3) ignore the * and just use Expires: 0 [I doubt this is common...]
> hgs>
> hgs> I suspect the solution will be to allow  ;expires=something or just
> hgs> ;expires=0 with *.
>
> But this solution would break the already existing grammar if we allow
> an expires parameter with a Contact *. Since
> Contact: *
> Expires: 0
> has the same effect as Contact:*; expires=0 and it already exists
> without breaking the current grammar.
>  - my take would be to keep it as it and disallow expires param in
contact
> *.
> (solution 1 )
>

Adding an optional "expires=0" parameter to the grammar would not break any
existing implementations. I suspect there may be some implementations that
have used solution 2.

>
> regds
> Arjun
> --
> Arjun Roychowdhury @ Hughes Software Systems
>
>
> "Beereddy, Srini" wrote:
> >
> > There is a conflict between the "Contact" header definition and an
> example
> > of it in the section 6.38 2nd paragraph, 2nd line
> >
> > "Contact: * ;expires: 0".
> >
> > According to the definition of Contact header, it can have a "*" or
list
> of
> > (( name-addr | addr-spec ) *( ";" contact-params ) ).
> >
> > The "expires" parameter is part of "contact-params" which can only be
> > present ( name-addr | addr-spec ). So the example in the section is
6.38
> is
> > wrong.
> >
> > For a quick reference I have added the 2nd paragraph of section 6.38
and
> > definition of the Contact header
> >
> > thanks,
> > Srini Beereddy,
> > Trillium Digital Systems, an Intel Company.
> >
> > section 6.38 2nd paragraph
> > ==========================
> >    A REGISTER request MAY include this header field when deleting
> >    registrations with "Contact: * ;expires: 0". The Retry-After value
> >    then indicates when the user might again be reachable. The registrar
> >    MAY then include this information in responses to future calls.
> >
> > Contact Header
> > ==============
> >
> > Contact = ( "Contact" | "m" ) ":"
> >     ("*" | (1# (( name-addr | addr-spec ) *( ";" contact-params ) )))
> >
> >    name-addr      = [ display-name ] "<" addr-spec ">"
> >    addr-spec      = SIP-URL | URI
> >    display-name   = *token | quoted-string
> >
> >    contact-params = "q"       "=" qvalue
> >                   | "action"  "=" "proxy" | "redirect"
> >                   | "expires" "=" delta-seconds | <"> SIP-date <">
> >                   | contact-extension
> >
> >    contact-extension = generic-param
> >    qvalue            = ( "0" [ "." 0*3DIGIT ] )
> >                      | ( "1" [ "." 0*3("0") ] )
> >
> > _______________________________________________
> > 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.
>
> --
> 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.
>

Bob
d:-)


Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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.





_______________________________________________
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 Apr 12 10:27:05 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 KAA01339
	for ; Thu, 12 Apr 2001 10:27:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2403844342; Thu, 12 Apr 2001 10:27:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DB6144336
	for ; Thu, 12 Apr 2001 10:26:09 -0400 (EDT)
Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3CEQ5m11616
	for ; Thu, 12 Apr 2001 09:26:09 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr7.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3CEQ5a05960
	for ; Thu, 12 Apr 2001 09:26:05 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Apr 12 09:26:05 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <2XP2D5BN>; Thu, 12 Apr 2001 09:26:05 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Henning G. Schulzrinne'" ,
        "Beereddy, Srini" 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Conflict between Contact Header definition and example
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C35C.8153BC50"
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, 12 Apr 2001 09:26:04 -0500

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_01C0C35C.8153BC50
Content-Type: text/plain;
	charset="iso-8859-1"

>
>Thanks for pointing this out. I would say that
>
>Contact: *
>Expires: 0
>
>would be sufficient. Indeed, is there any reasonable use for the * URL
>beyond expiration, i.e., 

I don't see one immediately.

>I'm assuming that somethig like
>
>Contact: *
>Expires: 3600
>
>would not be allowed. 

Actually, we allow it. However, I don't encourage this 
behavior :)

>
>What do implementations do:
>1) two headers (Expires: 0  and Contact: *)

This means wipe out all exising Contact:'s 
to us.

>2) one header: (Contact: *;expires: 0)

This is very ugly. I would prefer the two header version.
(Though this will work)

>3) ignore the * and just use Expires: 0 [I doubt this is common...] 

I hope no one does this.

>
>I suspect the solution will be to allow  ;expires=something or just
>;expires=0 with *.

I would prefer not allowing any parameters at all for the 
wildcard.

/sean

------_=_NextPart_001_01C0C35C.8153BC50
Content-Type: text/html;
	charset="iso-8859-1"






RE: [SIP] Conflict between Contact Header definition and example




>

>Thanks for pointing this out. I would say that

>

>Contact: *

>Expires: 0

>

>would be sufficient. Indeed, is there any reasonable use for the * URL

>beyond expiration, i.e., 




I don't see one immediately.




>I'm assuming that somethig like

>

>Contact: *

>Expires: 3600

>

>would not be allowed. 




Actually, we allow it. However, I don't encourage this 

behavior :)




>

>What do implementations do:

>1) two headers (Expires: 0  and Contact: *)




This means wipe out all exising Contact:'s 

to us.




>2) one header: (Contact: *;expires: 0)




This is very ugly. I would prefer the two header version.

(Though this will work)




>3) ignore the * and just use Expires: 0 [I doubt this is common...] 




I hope no one does this.




>

>I suspect the solution will be to allow  ;expires=something or just

>;expires=0 with *.




I would prefer not allowing any parameters at all for the 

wildcard.




/sean





------_=_NextPart_001_01C0C35C.8153BC50--

_______________________________________________
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 Apr 12 11:36:03 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 LAA02920
	for ; Thu, 12 Apr 2001 11:36:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3323044389; Thu, 12 Apr 2001 11:36:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157])
	by lists.bell-labs.com (Postfix) with ESMTP id 7DB614433B
	for ; Thu, 12 Apr 2001 11:10:06 -0400 (EDT)
Received: from SGONG-W2K1.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA01533; Thu, 12 Apr 2001 08:09:18 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010412085712.03e30ef8@localhost>
X-Sender: sgong@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: sip@lists.bell-labs.com
From: Sherman Gong 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Request-uri does not match record-route header...
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, 12 Apr 2001 09:09:06 -0600

Having a problem whereby the request-uri used in the ACK does not match 
that which was in the record-route header in the 200 OK.  Per the SIP bis 
draft (section 6.39 in the 02 version), the first Route header (constructed 
from the record-route header) should be removed and used as the 
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should 
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request 
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for 
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The 
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG 


_______________________________________________
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 Apr 12 12:42: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 MAA04377
	for ; Thu, 12 Apr 2001 12:42: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 7C25044395; Thu, 12 Apr 2001 12:42: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.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 7E5B044395
	for ; Thu, 12 Apr 2001 12:41:07 -0400 (EDT)
Received: from sponge.cisco.com (sponge.cisco.com [171.71.61.25])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA09950;
	Thu, 12 Apr 2001 09:41:30 -0700 (PDT)
Received: from arunvenkwin40 (dhcp-161-44-6-150.cisco.com [161.44.6.150])
	by sponge.cisco.com (Mirapoint)
	with SMTP id AAW06970;
	Thu, 12 Apr 2001 11:41:05 -0500 (CDT)
From: "Arunachalam Venkatraman" 
To: "Sherman Gong" , 
Subject: RE: [SIP] Request-uri does not match record-route header...
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <4.3.2.7.2.20010412085712.03e30ef8@localhost>
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, 12 Apr 2001 11:45:47 -0500
Content-Transfer-Encoding: 7bit

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.


 -----Original Message-----
From: 	sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:	Thursday, April 12, 2001 10:09 AM
To:	sip@lists.bell-labs.com
Subject:	[SIP] Request-uri does not match record-route header...

Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG


_______________________________________________
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 Apr 12 15:10:05 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 PAA07683
	for ; Thu, 12 Apr 2001 15:10:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8181F4433B; Thu, 12 Apr 2001 15:10:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.encc.com (corp1.encc.com [207.20.253.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 1D5A844336
	for ; Thu, 12 Apr 2001 15:09:43 -0400 (EDT)
Received: from encc.com ([206.86.73.78]) by mail.encc.com
          (Netscape Messaging Server 4.1) with ESMTP id GBP18500.MBG for
          ; Thu, 12 Apr 2001 12:09:41 -0700 
Message-ID: <3AD5FD9E.2BB51BA6@encc.com>
From: "Patrick Lam" 
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
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] Does anyone know of any BICC mailing lists or newsgroups?
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, 12 Apr 2001 12:10:22 -0700
Content-Transfer-Encoding: 7bit

I am sorry if this is not the appropriate place to ask, but I just can't find it myself.

Just wondering if anyone knows of any BICC mailing list or newsgroups?

Thanks in advance,



_______________________________________________
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 Apr 12 23:14:46 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17429
	for ; Thu, 12 Apr 2001 23:14:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F353944337; Thu, 12 Apr 2001 23:14:43 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id AB35744336
	for ; Thu, 12 Apr 2001 23:13:21 -0400 (EDT)
Received: from blazer (dwillis3.directlink.net [63.64.250.84])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3CLCpP18205
	for ; Thu, 12 Apr 2001 16:12:51 -0500
Message-ID: <002801c086b9$7ddd49e0$54fa403f@directlink.net>
From: "Dean Willis" 
To: "IETF SIP" 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0025_01C08676.6F0A9000"
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] Slides from SIP WG, IETF-50
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, 25 Jan 2001 02:27:59 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0025_01C08676.6F0A9000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I believe that all slides I received for the meetings of the SIP WG at =
IETF 50 have been posted at:

http://www.softarmor.com/sipwg/meets/ietf50/slides/default.htm

If you think you sent me slides, please check that yours are posted =
correctly. The cutoff date for the proceedings is next Monday.

--
Dean Willis

------=_NextPart_000_0025_01C08676.6F0A9000
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









I believe that all slides I received =
for the=20
meetings of the SIP WG at IETF 50 have been posted at:


 


h=
ttp://www.softarmor.com/sipwg/meets/ietf50/slides/default.htm<=
/DIV>

 


If you think you sent me slides, please =
check that=20
yours are posted correctly. The cutoff date for the proceedings is next=20
Monday.


 


--


Dean Willis


------=_NextPart_000_0025_01C08676.6F0A9000--


_______________________________________________
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 Apr 13 07:25:10 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05200
	for ; Fri, 13 Apr 2001 07:25:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 403B444340; Fri, 13 Apr 2001 07:25:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 2F89D44337
	for ; Fri, 13 Apr 2001 07:24:07 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2L9Z7TJZ>; Fri, 13 Apr 2001 04:24:17 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Arunachalam Venkatraman'" ,
        Sherman Gong , sip@lists.bell-labs.com
Cc: "'Jonathan Rosenberg'" 
Subject: RE: [SIP] Request-uri does not match record-route header...
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0C40C.43A8EE10"
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, 13 Apr 2001 04:24:12 -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_000_01C0C40C.43A8EE10
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C40C.43A8EE10"


------_=_NextPart_001_01C0C40C.43A8EE10
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a)	the proxy knows that it record-routed this call leg
b)	or the Request-URI resolves to the local proxy's address.

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".

For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.

At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?

Robert.

 <<[SIP] new record-route text!>> 
-----Original Message----
From:	Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
Sent:	Thursday, April 12, 2001 5:46 PM
To:	Sherman Gong; sip@lists.bell-labs.com
Subject:	RE: [SIP] Request-uri does not match record-route header...

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.


 -----Original Message-----
From: 	sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:	Thursday, April 12, 2001 10:09 AM
To:	sip@lists.bell-labs.com
Subject:	[SIP] Request-uri does not match record-route header...

Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG


_______________________________________________
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_01C0C40C.43A8EE10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Request-uri does not match record-route =
header...




Hi,




I believe the Record-Route test has =
been completely rewritten (message attached). I personally believe =
however Arunachalam's response should be qualified by the saying that a =
proxy should only use the next Route header if



  1. the proxy knows that it =
record-routed this call leg
    2. 

  2. or the Request-URI resolves to the =
local proxy's address.
    3. 

    



I don't believe this is reflected in =
the new Record-Route text. It touches on an unresolved (or at least =
that was my feeling) discussion a long time about whether a =
Record-Routing's interaction with "Outbound Proxies".



For instance, when a UA or Proxy, puts =
the first Route header in the Request-URI but then sends the message to =
an outbound proxy because the UA lacks DNS capability. The outbound =
proxy may not have Record-Route'd but it must not remove/process the =
next Route header either.



At risk of reopening this discussion, =
did we reach at conclusion on this point, that is, when a proxy should =
use the next Route header and when should it not (if the Request-URI is =
does not resolve to the proxy's address)?



Robert.




 <<[SIP] new record-route text!>> =


-----Original =
Message----

From:   Arunachalam =
Venkatraman [mailto:arunvenk@cisco.com]=


Sent:   Thursday, April 12, 2001 5:46 PM

To:     Sherman Gong; sip@lists.bell-labs.com

Subject:       =
 RE: [SIP] Request-uri does not match =
record-route header...




You are correct in that  the REQ =
URI in ACK of your example should be

192.168.10.114.

However, I don't know what is the =
value of copying the topmost route to the

REQ URI .

If the port of the UAS is different =
from that in the Route, it looks wrong!

The fact is, the REQ URI is not used =
for routing when there is a ROUTE

header in the message.

I have found that the REQ URI in the =
ACK to a proxy I have been testing

with, can be anything (so long as it =
parses ok) when there is a ROUTE

header. The proxy uses the Route =
header for routing and not the REQ URI,

when a ROUTE header is =
present.






 -----Original =
Message-----

From:   =
sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bel=
l-labs.com]

On Behalf Of Sherman Gong

Sent:   Thursday, April 12, =
2001 10:09 AM

To:     =
sip@lists.bell-labs.com

Subject:        [SIP] =
Request-uri does not match record-route header...




Having a problem whereby the =
request-uri used in the ACK does not match

that which was in the record-route =
header in the 200 OK.  Per the SIP bis

draft (section 6.39 in the 02 =
version), the first Route header (constructed

from the record-route header) should =
be removed and used as the

Request-URI.  I included a =
couple of notes below asterisks (******).




I have been getting conflicting =
arguments on which requirement this should

follow.  Need to determine which =
spec. is correct.




1)  6.29 Record-Route




     The =
Record-Route request and response header field is added to a

     request by =
any proxy that insists on being in the path of subsequent

     requests for =
the same call leg. It contains a globally reachable

     Request-URI =
that identifies the proxy server. Each proxy server adds

     its =
Request-URI to the beginning of the list.




      The =
server copies the Record-Route header field unchanged into the

      =
response. (Record-Route is only relevant for 2xx responses.)




      The =
calling user agent client copies the Record-Route header into a

      Route =
header field of subsequent requests within the same call leg,

      =
reversing the order of requests, so that the first entry is =
closest

      to the =
user agent client. If the response contained a Contact header

      field, =
the calling user agent adds its content as the last Route

      =
header. Unless this would cause a loop, any client MUST send any

      =
subsequent requests for this call leg to the first Request-URI in =
the

      Route =
request header field and remove that entry.






    The above describes =
building Route headers from the Record-Route

headers,

    and sending =
subsequent requests to the first Route, removing that entry.






  6.33 Route




      The =
Route request-header field determines the route taken by a

      =
request. Each host removes the first entry and then proxies the

      =
request to the host listed in that entry, also using it as the

      =
Request-URI. The operation is further described in Section 6.29.




    The above notes =
that the Route header used to proxy a request should

also

     be used as =
the Request-URI.  This is the part that is not being done

     correctly by =
the 5300.  The 5300 is building it's own request URI based

on

     the =
destination of the request, rather than using the URI in the =
Route

    header as the =
Request-URI.  Note that the 5300 is sending the request

to the

    correct =
destination, which in our case does not match that in the Route

    header (but they =
don't have to match).






Or






2)  from page 20 of the =
draft




     The maddr =
parameter indicates the server address to be contacted for

this user, overriding the address =
supplied in the host field. This

     address is =
typically, but not necessarily, a multicast address. The

maddr field can be used to force =
requests from traveling users to visit

     a home proxy =
even if an outbound proxy is used.










c5300-3#

*Jan 22 08:34:05.632: ISDN Se0:23: RX =
<-  SETUP pd =3D 8  callref =3D 0x0001

*Jan 22 =
08:34:05.632:         Bearer =
Capability i =3D 0x8090A2

*Jan 22 =
08:34:05.636:         Channel =
ID i =3D 0xA98381

*Jan 22 =
08:34:05.636:         Calling =
Party Number i =3D 0x2180, '2062011001',

Plan:ISDN, Type:National

*Jan 22 =
08:34:05.636:         Called =
Party Number i =3D 0xA1, '3032011001',

Plan:ISDN, Type:National

*Jan 22 08:34:05.652: 0x6221E11C : =
State change from (STATE_NONE,

SUBSTATE_NONE)  to (STATE_IDLE, =
SUBSTATE_NONE)

*Jan 22 08:34:05.652:  Queued =
event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL:  act_idle_call_setup

*Jan 22 08:34:05.652:  =
act_idle_call_setup:Not using Voice Class Codec




*Jan 22 08:34:05.652: =
act_idle_call_setup: preferred_codec set[0] type

:g711ulaw bytes: 160

*Jan 22 08:34:05.652:  Queued =
event from SIP SPI :

SIPSPI_EV_CREATE_CONNECTION

*Jan 22 08:34:05.652: 0x6221E11C : =
State change from (STATE_IDLE,

SUBSTATE_NONE)  to (STATE_IDLE, =
SUBSTATE_CONNECTING)

*Jan 22 08:34:05.652: 0x6221E11C : =
State change from (STATE_IDLE,

SUBSTATE_CONNECTING)  to =
(STATE_IDLE, SUBSTATE_CONNECT

ING)

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL:  act_idle_connection_created

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL:  act_idle_connection_created:

Connid(1) created to =
192.168.10.114:5060, local_p

ort 50727

*Jan 22 08:34:05.656: =
CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP

*Jan 22 08:34:05.656: =
sipSPIAddLocalContact

*Jan 22 08:34:05.656:  Queued =
event from SIP SPI : SIPSPI_EV_SEND_MESSAGE

*Jan 22 08:34:05.656: =
CCSIP-SPI-CONTROL:  sip_stats_method

*Jan 22 08:34:05.656: 0x6221E11C : =
State change from (STATE_IDLE,

SUBSTATE_CONNECTING)  to =
(STATE_SENT_INVITE, SUBSTATE_

NONE)

*Jan 22 08:34:05.660: ISDN Se0:23: TX =
->  CALL_PROC pd =3D 8  callref =3D 0x8001

*Jan 22 =
08:34:05.660:         Channel =
ID i =3D 0xA98381

*Jan 22 08:34:05.660: Sent:

INVITE =
sip:3032011001@192.168.10.114;user=3Dphone SIP/2.0

Via: SIP/2.0/UDP  =
192.168.66.184:50727

From: "2062011001" =
<sip:2062011001@192.168.66.184>

To: =
<sip:3032011001@192.168.10.114;user=3Dphone>

Date: Sat, 22 Jan 2000 01:34:05 =
GMT

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184

Cisco-Guid: =
3954197371-3232041567-0-1845248076

User-Agent: Cisco SIP Gateway =
(UAC)/IOS 12.x

CSeq: 101 INVITE

Max-Forwards: 6

Timestamp: 948530045

Contact: =
<sip:2062011001@192.168.66.184:5060;user=3Dphone>

Expires: 180

Content-Type: application/sdp

Content-Length: 138




v=3D0

o=3DCiscoSystemsSIP-GW-UserAgent 7656 =
9288 IN IP4 192.168.66.184

s=3DSIP Call

c=3DIN IP4 192.168.66.184

t=3D0 0

m=3Daudio 20492 RTP/AVP 0




*Jan 22 08:34:05.672: Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP  =
192.168.66.184:50727

From: "2062011001" =
<sip:2062011001@192.168.66.184>

To: =
<sip:3032011001@192.168.10.114;user=3Dphone>

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184

CSeq: 101 INVITE

Content-Length: 0








*Jan 22 08:34:05.672: =
HandleUdpSocketReads :Msg enqueued for SPI with

IPaddr: 192.168.1.114:34050

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL:  act_sentinvite_new_message

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL:  sipSPICheckResponse

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL:  sip_stats_status_code

*Jan 22 08:34:05.672:  Roundtrip =
delay 16 milliseconds for method INVITE




*Jan 22 08:34:05.672: 0x6221E11C : =
State change from (STATE_SENT_INVITE,

SUBSTATE_NONE)  to =
(STATE_RECD_PROCEEDING, SUBS

TATE_PROCEEDING_PROCEEDING)

*Jan 22 08:34:05.852: =
Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP =
192.168.66.184:50727

From: "2062011001" =
<sip:2062011001@192.168.66.184>

To: =
<sip:3032011001@192.168.10.114;user=3Dphone>

Date:Sat, 22 Jan 2000 08:33:50 =
GMT

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184

Timestamp:948530045

Server:Cisco SIP Gateway (UAS)/IOS =
12.x

CSeq: 101 INVITE

Content-Length: 0








*Jan 22 08:34:05.856: =
HandleUdpSocketReads :Msg enqueued for SPI with

IPaddr: 192.168.1.114:34050

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL:  act_recdproc_new_message

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL:  sipSPICheckResponse

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL:  sip_stats_status_code

*Jan 22 08:34:05.856:  Roundtrip =
delay 200 milliseconds for method INVITE




*Jan 22 08:34:05.856: =
HandleSIP1xxRinging No SDP Body in 180 RINGING - would

wait for 200OK to do =
negotiation.




*Jan 22 08:34:05.856: =
HandleSIP1xxRinging: MediaNegotiation expected in 200

OK




*Jan 22 08:34:05.856: 0x6221E11C : =
State change from (STATE_RECD_PROCEEDING,

SUBSTATE_PROCEEDING_PROCEEDING)  =
to (STATE_

RECD_PROCEEDING, =
SUBSTATE_PROCEEDING_ALERTING)

*Jan 22 08:34:05.856: ISDN Se0:23: TX =
->  ALERTING pd =3D 8  callref =3D 0x8001

*Jan 22 08:34:06.356: =
Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP =
192.168.66.184:50727

From: "2062011001" =
<sip:2062011001@192.168.66.184>

To: =
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820

Date:Sat, 22 Jan 2000 08:33:50 =
GMT

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184

Timestamp:948530045

Server:Cisco SIP Gateway (UAS)/IOS =
12.x

Contact:<sip:3032011001@192.168.67.186:5060;user=3Dpho=
ne>

Record-Route:<sip:3032011001@east.c53005.com:5070;madd=
r=3D192.168.10.141;trans

port=3Dudp>

Record-Route:<sip:3032011001@192.168.10.114:5060;user=3D=
phone;maddr=3D192.168.10

.141;transport=3Dudp>

CSeq: 101 INVITE

Content-Type:application/sdp

Content-Length: 126

Session-Expires:300




v=3D0

o=3DCiscoSystemsSIP-GW-UserAgent 6565 =
3960 IN IP4 10.1.1.2

s=3DSIP Call

t=3D0 0

m=3Daudio 4036 RTP/AVP 0

c=3DIN IP4 209.6.0.2






************************************* =
Note

****************************************

Note that the record route =
header:




Record-Route:<sip:3032011001@192.168.10.114:5060;user=3D=
phone;maddr=3D192.168.10

.141;transport=3Dudp>




  is the one that should be used =
for the subsequent ACK.










*Jan 22 08:34:06.356: =
HandleUdpSocketReads :Msg enqueued for SPI with

IPaddr: 192.168.1.114:34050

*Jan 22 08:34:06.356: =
CCSIP-SPI-CONTROL:  act_recdproc_new_message

*Jan 22 08:34:06.356: =
CCSIP-SPI-CONTROL:  sipSPICheckResponse

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL:  sip_stats_status_code

*Jan 22 08:34:06.360:  Roundtrip =
delay 704 milliseconds for method INVITE




*Jan 22 08:34:06.360: sipSPIGetSdpBody =
: Parse incoming session description

*Jan 22 08:34:06.360: =
sipSPICompareRespMediaInfo No Comparsion needed as 18x

messages did not have SDP

*Jan 22 08:34:06.360: =
sipSPIDoMediaNegotiation: Codec Negotiation Successful




*Jan 22 08:34:06.360: =
sipSPIUpdCcbWithSdpInfo: SDP Media Information:

Negotiated =
Codec      : g711ulaw , bytes :160

Early =
Media           : =
0

Delayed =
Media         : 0

Bridge =
Done           : =
0

New =
Media           &=
nbsp; : 0

DSP DNLD =
Reqd         : 0

Media Dest addr/Port  : =
209.6.0.2:4036




*Jan 22 08:34:06.360: =
sipSPIProcessMediaChanges

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL:  sipSPIReconnectConnection

*Jan 22 08:34:06.360:  Queued =
event from SIP SPI :

SIPSPI_EV_RECONNECT_CONNECTION

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =3D

TRUE Route =
<sip:3032011001@east.c53005.com:5070

;maddr=3D192.168.10.141>, =
<sip:3032011001@192.168.67.186:5060;user=3Dphone>

*Jan 22 08:34:06.360:  Queued =
event from SIP SPI : SIPSPI_EV_SEND_MESSAGE

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL:  sip_stats_method

*Jan 22 08:34:06.360: 0x6221E11C : =
State change from (STATE_RECD_PROCEEDING,

SUBSTATE_PROCEEDING_ALERTING)  =
to (STATE_AC

TIVE, SUBSTATE_NONE)

*Jan 22 08:34:06.360: The Call Setup =
Information is :

  Call Control Block (CCB) : =
0x6221E11C

  State of The =
Call        : STATE_ACTIVE

  TCP Sockets =
Used         : NO

  Calling =
Number           : =
2062011001

  Called =
Number           =
 : 3032011001

  Negotiated =
Codec         : g711ulaw

  Negotiated Codec =
Bytes   : 160

  Negotiated =
Dtmf-relay    : 0

  Source IP Address (Media): =
192.168.66.184

  Source IP =
Port    (Media): 20492

  Destn  IP Address =
(Media): 209.6.0.2

  Destn  IP =
Port    (Media): 4036

  Destn SIP Req Addr:Port  =
: 192.168.10.141:5060

  Destn SIP Resp Addr:Port : =
0.0.0.0:0

  Destination =
Name         : =
192.168.10.114




*Jan 22 08:34:06.364: =
HandleUdpReconnection: Udp socket connected for fd: 1

with 192.168.10.141:5060

*Jan 22 08:34:06.364: Sent:

ACK =
sip:3032011001@192.168.10.141:5060;user=3Dphone SIP/2.0

Via: SIP/2.0/UDP  =
192.168.66.184:50727

From: "2062011001" =
<sip:2062011001@192.168.66.184>

To: =
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820

Date: Sat, 22 Jan 2000 01:34:05 =
GMT

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184

Route: =
<sip:3032011001@east.c53005.com:5070;maddr=3D192.168.10.141>,

<sip:3032011001@192.168.67.186:5060;user=3Dphone>

Max-Forwards: 6

Content-Length: 0

CSeq: 101 ACK








********************************* Note =
***********************************

Request-URI in above ACK has domain =
of 192.168.10.141, should have been

192.168.10.114 when the record-route =
was turned into a Route header,

removed, and used as the =
Request-URI.










*Jan 22 08:34:06.364:  =
sipSPIRtcpUpdates No rtp session in bridge, create a

new one




*Jan 22 08:34:06.364: =
CCSIP-SPI-CONTROL:  ccsip_caps_ind

*Jan 22 08:34:06.364: =
ccsip_get_rtcp_session_parameters: CURRENT VALUES:

ccCallID=3D1276, =
current_seq_num=3D0x217C

*Jan 22 08:34:06.364: =
ccsip_get_rtcp_session_parameters: NEW VALUES:

ccCallID=3D1276, =
current_seq_num=3D0x9EC

*Jan 22 08:34:06.364: ccsip_caps_ind: =
Load DSP with negotiated codec :

g711ulaw, Bytes=3D160

*Jan 22 08:34:06.368: sipSPIGetDTMFRel=
ayMode: set DSP for dtmf-relay =3D

CC_CAP_DTMF_RELAY_INBAND_VOICE

*Jan 22 08:34:06.368: ccsip_caps_ind: =
Load DSP with codec : g711ulaw,

Bytes=3D160

*Jan 22 08:34:06.368: =
CCSIP-SPI-CONTROL:  ccsip_caps_ack

*Jan 22 08:34:06.372: ISDN Se0:23: TX =
->  CONNECT pd =3D 8  callref =3D 0x8001

*Jan 22 =
08:34:06.372:         Progress =
Ind i =3D 0x8182 - Destination address

is non-ISDN

*Jan 22 08:34:06.388: ISDN Se0:23: RX =
<-  CONNECT_ACK pd =3D 8  callref =3D

0x0001

*Jan 22 08:34:06.388: ISDN Se0:23: =
CALL_PROGRESS: CALL_CONNECTED call id

0x227, bchan 0, dsl 0

3w0d: %ISDN-6-CONNECT: Interface =
Serial0:0 is now connected to 2062011001

c5300-3#








Thanks




SG






_______________________________________________

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_01C0C40C.43A8EE10--

------_=_NextPart_000_01C0C40C.43A8EE10
Content-Type: message/rfc822
Content-Description: [SIP] new record-route text!

Message-ID: 
From: Jonathan Rosenberg 
To: "'sip@lists.bell-labs.com'" 
Subject: [SIP] new record-route text!
Date: Fri, 29 Dec 2000 15:32:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Help: 
List-Subscribe: , 
List-Unsubscribe: , 
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_003_01C0C40C.43A8EE10"


------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

I took a stab at the new text for record routing. Its much, much more
verbose than rfc2543, and hopefully, as a result, will make it much clearer
what you need to do. Record-routing remains one of the most oft
misimplemnted features. This text incorporates everything in rfc2543 plus
all the decisions we've made on the list along the way. As you can see, the
structure is much more processing focused, rather than syntactic focused,
and much more explicit as well.

The text is in latex format. If you don't know latex, you should be able to
ignore all the slashes and brackets and still get the idea.

Please comment; alternate text related to those comments is requested.

-Jonathan R.




\section{Record-Routing}
\label{sec:rr}

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
\header{Record-Route} into the initial \INVITE request that begins the
call leg. The user agents use these headers to construct a set of
\header{Route} headers, that gets inserted into subsequent requests in
the call leg. The \header{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.

All user agents \MUST support the processing rules below which apply
to them. As such, they \MUST be able to parse and process both
\header{Record-Route} and \header{Route} headers. Proxies \MAY support
the record routing procedures of Section \ref{sec:rr:proxy}, but they
\MUST support the route header procedures of Section{sec:rr:proxy2}. 

\motivation{This is a change from RFC2543, where all record-route and
route processing was optional for user agents.}

The syntax for the \header{Route} header is described in Section
XXX. The syntax for the \header{Record-Route} header is described in
Section XXX.

\subsection{UAC Processing for initial \INVITE transaction}
\label{sec:rr:uac}

The UAC formulates its {\em initial} \INVITE request for the call leg
as defined in section XXX. If the final response is a 200 class
response, it may contain \header{Record-Route} headers, and may
contain a \header{Contact} header. \annotate{Contact was not mandatory
in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might
not insert the \header{Contact} header. Thats why this text says that
the \header{Contact} may be present in the response. Note also that
this may is lower case; it is NOT saying that a UAS can optionally
insert the \header{Contact} header into the 200 class response.} The
UAC \MUST construct a {\em route set}, defined as a list of URLs, in
the following manner:

\begin{enumerate}
\item The list of URIs present in the \header{Record-Route} headers in
the 200 class response are taken, if present, and their order is reversed. 
\item The URI in the \header{Contact} header from the 200 class response, if
present, is taken, and appended to the end of the list from the
previous step.
\item The list of URIs resulting from the above two operations is
referred to as the {\em route set}.
\end{enumerate}

The UAC \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the 200 class response. NOTE that since there
may be multiple 200 OK responses to an \INVITE request, each response
constitutes a separate call leg, and thus has a separate route
set. The UAC \MUST also remember whether the bottom-most entry in the
route set was constructed from a \header{Contact} header or not. This
is effectively a boolean value, which we refer to as CONTACT_SET.

The \ACK request for the initial \INVITE transaction \MUST be
formulated according to the rules of Section XXX, as if it were a
subsequent request within the call leg. 

OPEN-ISSUE: Handling for non-200 responses, including provisionals
and certain 400 class responses. Are we supporting record-routing for
non-200 class responses? Record-routing for provisional responses is
discussed in the 100rel spec. What needs to be said here?

\subsection{UAS Processing of initial \INVITE transaction}
\label{sec:rr:uas}

When a UAS receives an \INVITE for a new call leg, and it responds
with a 200 class response, it \MUST copy the contents of the
\header{Record-Route} headers from the request to the response. This
includes the URIs, URI parameters, and any \header{Record-Route}
header parameters, whether they are known or unknown to the
UAS. \annotate{Record-Route parameters are very useful for
proxies. They allow the proxy to match the record-route entry in the
response with the one in the request.} The
order of the \header{Record-Route} headers \MUST be preserved in the
response.

The UAS \MUST construct a {\em route set} in the following manner:

\begin{enumerate}
\item The list of URIs in the \header{Record-Route} headers in the
\INVITE request, if present, are taken, including any URI parameters.
\item The URI in the \header{Contact} header from the request, if present,
is
taken, including any URI parameters. The URI is appended to the bottom
of the list of URIs from the previous step.
\item The resulting list of URIs is called the {\em route set}. 
\end{enumerate}

The UAS \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the \INVITE request. The UAS \MUST also
remember whether the bottom-most entry in the route set was
constructed from a \header{Contact} header or not. This is effectively
a boolean value, which we refer to as CONTACT_SET. 

OPEN ISSUE: this new text does not have the record-routes copied into
non-200 responses. RFC2543 talks about other failure codes, but is not
specific enough. Do we really need them in other response codes? If
so, we must list them explicitly.

\subsection{Proxy processing of an initial \INVITE transaction}
\label{sec:rr:proxy}

Each proxy \MAY independently decide to record-route an initial
\INVITE transaction. For a proxy, {\em initial} is defined
as any \INVITE request that does not contain a \header{Route}
header. Generally, the choice about whether to record-route or not is
a tradeoff of features vs. performance. Faster call processing and
higher scalability is achieved when proxies do not record
route. However, provision of certain services may require a proxy to
observe all messages for a call leg. It is \RECOMMENDED that proxies
do not automatically record route. They should do so only if
specifically required.

To record-route, the proxy inserts a \header{Record-Route} header into
the request before proxying it onwards. A forking proxy \MAY insert a
different \header{Record-Route} header into each forked request. The
\header{Record-Route} header that it inserts \MUST be inserted as the
first \header{Record-Route} header, appearing before any existing ones
in the request. The URL in the header \MUST be a SIP
URL. \annotate{This is because the URLs in the Record-Route headers
are used for forwarding requests by other proxies. Since no other URL
but a SIP URL is mandatory, a proxy could not be sure that any other
URL is interpretable by other proxies. Thus, SIP URLs are
mandatory}. The URL \MUSTNOT contain the transport
parameter. \annotate{Thats because only UDP is mandatory. If a proxy
inserts a transport parameter in the URL with TCP or TLS as the
transport, the proxy that ends up using that URL to forward the
request might not support that transport. The result, according to the
``Locating a SIP Server'' procedure, would be for the proxy to give
up.} The URL \MUST have the property that when the processing
described in Section XXX ``locaing a SIP server'' is followed for that
URL, the result of the lookup is an address/port of the proxy server
inserting the
\header{Record-Route}. The URL and the proxy configuration \SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to one of the previous-hop servers that the initial
\INVITE request traversed, including the UAS. \annotate{These two
properties are 
important. The first one guarantees that subsequent requests from the
called party are routed back to this actually proxy. The second property is
there for robustness. It guarantees that the request URI always
contain meaningful information, even if there are no \header{Route}
headers that tell the proxy where to forward the request to next.} The
proxy \MAY insert 
\header{Record-Route} parameters into the request. These will be
returned to the proxy in any 200 class response to the \INVITE, and
are useful for pushing state into the message.

If a 200 class response arrives for a proxied request, the response
will contain the entire list of \header{Record-Route} headers inserted
by proxies along the request path. The proxy \MAY modify the
\header{Record-Route} value matching the one it inserted into the
request. Like the URL in the request, it \MUST be a SIP URL and
\MUSTNOT contain a transport parameter. The URL in this
\header{Record-Route} header \MUST have the
property that when the processing described in Section XXX ``locating
a SIP server'' is followed for that URL, the result of the lookup is
an address/port of the proxy server that inserted the
\header{Record-Route}. The URL in this header, and the proxy configuration
\SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to the same next hop server that the initial
\INVITE request was forwarded to.

The four properties (two for the request, two for the response), can
be satisfied in a number of ways. One way is that the URI inserted
into the \header{Record-Route} in the request is the same as the
\header{Contact} header in the \INVITE (if present, else the
\header{From} field), but with the maddr and port set to
resolve to the proxy. Then, the proxy modifies the URL in the
\header{Record-Route} header in the response, setting it to be the URL
from the \header{Request-URI} of the initial \INVITE, but with the maddr
and port set to resolve to the proxy. 

As an example, consider a proxy at 10.0.1.1 listening on port 5061
which receives the following request (many headers are omitted for
brevity):

\begin{verbatim}
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP callerspc.univ.edu
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The proxy forwards this request to
\header{sip:j_user@div11.example.com}, and record-routes:

\begin{verbatim}
INVITE sip:j_user@div11.example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The 200 response will look like, in part:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The proxy modifies its \header{Record-Route} header in the response to
and forwards the request upstream:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 ;myparam=9877
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The route set computed by the UAS is:

\begin{verbatim}
sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1
sip:caller@callerspc.univ.edu
\end{verbatim}

and the route set computed by the UAC is:

\begin{verbatim}
sip:j_user@example.com:5061;maddr=10.0.1.1
sip:j_user@host32.div11.example.com
\end{verbatim}

There are other ways to meet these requirements. The proxy could
construct a URL for the request which encodes all of the needed
information, by placing it in the user portion, for example. A call
stateful proxy could insert a URL into the request with the form
sip:proxy.example.com, and not modify it in the response. This URL
clearly satisfies the first required property (of getting routed back
to the proxy that inserted it). The second property can be maintained
by being call stateful, and extracting the needed parameters from
local storage.

When a proxy does decide to modify the \header{Record-Route} header in
the response, one of the operations it must perform is to locate the
\header{Record-Route} that it had inserted. If the request spiraled,
and the proxy inserted a \header{Record-Route} in each iteration of
the spiral, locating the correct header in the response (which must be
the proper iteration in the reverse direction) is tricky. One
mechanism that is \RECOMMENDED is for the proxy to insert a
\header{Record-Route} parameter into the new \header{Record-Route} header
in the request each time the request spirals. This parameter \MUST
uniquely identify the proxy. When the 200 class respone arrives, the
proxy looks for the topmost \header{Record-Route} header containing
this parameter. This header is the one for the current iteration. The
proxy \MUST remove this parameter before forwarding the response
upstream. Upon the next iteration, the same algorithm (find the
topmost \header{Record-Route} header with the parameter) will
correctly extract the next \header{Record-Route}
header.


\subsection{UA Processing of Subsequent Requests in a Call Leg}
\label{sec:rr:uasubsequent}

When a UA wishes to send another request for the call-leg (such as a
\header{BYE} or \header{INVITE}), it follows the procedures defined in
this subsection. The
procedures here \MUST also be followed for an \ACK request for a 200
response to the initial \INVITE for the call leg. The procedures here
\MUSTNOT be followed for a \CANCEL request or an \ACK request for a
non-200 response. This implies that \CANCEL never contains a
\header{Route} header, nor does an \ACK for a non-200 response.

The request is constructed as specified in Section XXX. 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 any
URI parameters, are placed into a \header{Route} header into the request,
in order. The procedures of Section XXX ``locating a SIP server'' are
then applied to the URI in the request URI, the the request is
forwarded to the resulting server.

If a UAS has a route set for a call leg, and receives a re-INVITE for
that call leg containing \header{Record-Route} headers, it \MUST copy
those headers into any 200 class response to that request. If the
boolean variable CONTACT_SET is true, the \header{Contact} header in
the re-INVITE (if present) replaces the last 
entry in the route set. If the boolean variable CONTACT_SET is false,
the UAS \MUST add the URL in the 
\header{Contact} header in the re-INVITE to the bottom of the route
set, and then set CONTACT_SET to true. If the re-INVITE did not
contain a \header{Contact} header, the route-set at the UAS remains
unchanged.

Similarly, if a UAC has a route set for a call leg, and receives a 200
class response to a re-INVITE it sent, the \header{Contact} header is
examined. If not present, the route set remains unchanged. If the
re-INVITE response had a \header{Contact} header, and the boolean
variable CONTACT_SET is false, the URL in the \header{Contact} header
in the response is added to the bottom of the route set, and
CONTACT_SET is set to true. If the re-INVITE response had a
\header{Contact} header, and CONTACT_SET is true, the URL in the
\header{Contact} header of the re-INVITE response replaces the bottom
value in the route set.

The above two paragraphs allow a UA to update its \header{Contact}
address mid-call, but proxies cannot update their route address.  Once
on the route, a proxy remains on the route for the duration of the
call leg. \annotate{Why the different treatment for Contact and
Record-Route in a re-INVITE? It has to do with backwards
compatibility. RFC2543 did not mandate that a proxy needs to refresh
its record-route headers. As a result, the lack of a record-route in a
re-INVITE cannot be interpreted to mean that the proxy does not want
to be included on the route any longer. Updating of the Contact header
mid-call is useful for mobility applications, and is also useful for
forms of third party call control}.


OPEN-ISSUE: should the UA remove the maddr param, if present, if the
request is sent to the server at that maddr?

OPEN-ISSUE: should we mention handling of route with local outbound
proxies here? RFC2543 has some text on DNS-less UAs, but there are
issues with this.

\header{Proxy processing of a non-initial request}
\label{sec:rr:proxy2}

The rules in this section \MUST be followed when a proxy receives a request
that contains a \header{Route} header. The \header{Route} header is
used to forward the request to the next hop. It \MUST override any other
routing decisions that the proxy would otherwise make. Proxies \MAY
respond to requests with \header{Route} headers for any reason (in order
to perform proxy authorization, for example). But, if the request is
proxied, the procedures here \MUST be used to determine where the
request is proxied to. The procedures in this section apply indepedent
of the request method. They \MUST be followed even if the request
method is unknown to the proxy. \annotate{This last sentence is
really, really important. It allows for other methods, defined in the
future, to have record-routing applied to them. As an example, an
instant messaging session run over SIP might begin with a MESSAGE
request. That extension can allow for these sessions to be
record-routed by proxies that know of this extension. However, the
record-routing will only work if proxies that don't know about the
extension follow the Route headers properly. As such, supporting
\header{Route} headers for all methods, known or unknown, is very
important for a robust and future proof proxy implementation.}
Since \CANCEL can never contain
\header{Route}, these procedures never apply to \CANCEL. However, they
do apply to \ACK requests for a 200 OK response, which do contain
\header{Route} headers. 

The proxy \MUST remove the top \header{Route} header from the
request. The URI from that \header{Route} \MUST be placed into the
\header{Request-URI} of the proxied request, including URI
parameters. Any URL parameters present in the top \header{Route}
header which are not allowed in the request URI \MUST be removed from
the \header{Request-URI} by the proxy. The procedures of section XXX
``Locating a SIP Server'' \MUST be followed to compute the next hop
server to forward the request to. 

If the request is an \INVITE request (thus, a re-INVITE) for a call
leg that the proxy wishes to receive messages for (very likely the
case, since the request probably arrived at the proxy because the
proxy record routed in the initial \INVITE), the proxy \MUST
re-insert the
\header{Record-Route} header with the same value it placed in the
initial request. Similarly, it should modify the \header{Record-Route}
header in any 200 class response in the same way the
\header{Record-Route} header was modified in the response to the
initial \INVITE (which may be no modifications at all). The purpose of
this is twofold. First, it allows for proper record-routing in the
case of pre-loaded Route headers (see Section XXX). Secondly, it
allows for recovery from a UA crash and restart, in which case the UA
loses call state, and as a result, its route set as well. The result
is that the route set will be re-established through the
re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the
result is a robust way to recover from crashes.

\subsection{Pre-Loaded Route Headers}

Normally, a UA constructs the Route headers in a request from the
route set learned through \header{Record-Route} headers. However, in
some circumstances, it is useful for a UA to insert \header{Route}
headers into an initial \INVITE. These headers may have been learnt by
the UA through some out of bands means. When an initial \INVITE
(initial as far as the UAC and UAS are concerned) contains
\header{Route} headers, this is referred to as a ``pre-loaded
Route''. It is equivalent to strict source routing in IP. Proxies will
often not be able to distinguish this case from the case described in
Section \ref{sec:rr:proxy}, and will therefore properly use these
route headers to forward the request. If the proxies are interested in
receiving subsequent messages for the call leg, their insertion of
\header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will
establish a correct route set at both UAC and UAS. This route set may
end up being different from the pre-loaded Route used by the UAC. As
such, a UAC that inserts a pre-loaded route set \MUST follow the
procedures of Section \ref{sec:rr:uac} in processing the response to
this initial \INVITE.




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

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/html;
	charset="iso-8859-1"






[SIP] new record-route text!




Folks,




I took a stab at the new text for record routing. Its much, much more

verbose than rfc2543, and hopefully, as a result, will make it much clearer

what you need to do. Record-routing remains one of the most oft

misimplemnted features. This text incorporates everything in rfc2543 plus

all the decisions we've made on the list along the way. As you can see, the

structure is much more processing focused, rather than syntactic focused,

and much more explicit as well.




The text is in latex format. If you don't know latex, you should be able to

ignore all the slashes and brackets and still get the idea.




Please comment; alternate text related to those comments is requested.




-Jonathan R.










\section{Record-Routing}

\label{sec:rr}




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

\header{Record-Route} into the initial \INVITE request that begins the

call leg. The user agents use these headers to construct a set of

\header{Route} headers, that gets inserted into subsequent requests in

the call leg. The \header{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.




All user agents \MUST support the processing rules below which apply

to them. As such, they \MUST be able to parse and process both

\header{Record-Route} and \header{Route} headers. Proxies \MAY support

the record routing procedures of Section \ref{sec:rr:proxy}, but they

\MUST support the route header procedures of Section{sec:rr:proxy2}. 




\motivation{This is a change from RFC2543, where all record-route and

route processing was optional for user agents.}




The syntax for the \header{Route} header is described in Section

XXX. The syntax for the \header{Record-Route} header is described in

Section XXX.




\subsection{UAC Processing for initial \INVITE transaction}

\label{sec:rr:uac}




The UAC formulates its {\em initial} \INVITE request for the call leg

as defined in section XXX. If the final response is a 200 class

response, it may contain \header{Record-Route} headers, and may

contain a \header{Contact} header. \annotate{Contact was not mandatory

in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might

not insert the \header{Contact} header. Thats why this text says that

the \header{Contact} may be present in the response. Note also that

this may is lower case; it is NOT saying that a UAS can optionally

insert the \header{Contact} header into the 200 class response.} The

UAC \MUST construct a {\em route set}, defined as a list of URLs, in

the following manner:




\begin{enumerate}

\item The list of URIs present in the \header{Record-Route} headers in

the 200 class response are taken, if present, and their order is reversed. 

\item The URI in the \header{Contact} header from the 200 class response, if

present, is taken, and appended to the end of the list from the

previous step.

\item The list of URIs resulting from the above two operations is

referred to as the {\em route set}.

\end{enumerate}




The UAC \MUST store the route set for the duration of the call

leg. NOTE that it is possible for the route set to be empty. This will

occur if neither \header{Record-Route} headers nor a \header{Contact}

header were present in the 200 class response. NOTE that since there

may be multiple 200 OK responses to an \INVITE request, each response

constitutes a separate call leg, and thus has a separate route

set. The UAC \MUST also remember whether the bottom-most entry in the

route set was constructed from a \header{Contact} header or not. This

is effectively a boolean value, which we refer to as CONTACT_SET.




The \ACK request for the initial \INVITE transaction \MUST be

formulated according to the rules of Section XXX, as if it were a

subsequent request within the call leg. 




OPEN-ISSUE: Handling for non-200 responses, including provisionals

and certain 400 class responses. Are we supporting record-routing for

non-200 class responses? Record-routing for provisional responses is

discussed in the 100rel spec. What needs to be said here?




\subsection{UAS Processing of initial \INVITE transaction}

\label{sec:rr:uas}




When a UAS receives an \INVITE for a new call leg, and it responds

with a 200 class response, it \MUST copy the contents of the

\header{Record-Route} headers from the request to the response. This

includes the URIs, URI parameters, and any \header{Record-Route}

header parameters, whether they are known or unknown to the

UAS. \annotate{Record-Route parameters are very useful for

proxies. They allow the proxy to match the record-route entry in the

response with the one in the request.} The

order of the \header{Record-Route} headers \MUST be preserved in the

response.




The UAS \MUST construct a {\em route set} in the following manner:




\begin{enumerate}

\item The list of URIs in the \header{Record-Route} headers in the

\INVITE request, if present, are taken, including any URI parameters.

\item The URI in the \header{Contact} header from the request, if present,

is

taken, including any URI parameters. The URI is appended to the bottom

of the list of URIs from the previous step.

\item The resulting list of URIs is called the {\em route set}. 

\end{enumerate}




The UAS \MUST store the route set for the duration of the call

leg. NOTE that it is possible for the route set to be empty. This will

occur if neither \header{Record-Route} headers nor a \header{Contact}

header were present in the \INVITE request. The UAS \MUST also

remember whether the bottom-most entry in the route set was

constructed from a \header{Contact} header or not. This is effectively

a boolean value, which we refer to as CONTACT_SET. 




OPEN ISSUE: this new text does not have the record-routes copied into

non-200 responses. RFC2543 talks about other failure codes, but is not

specific enough. Do we really need them in other response codes? If

so, we must list them explicitly.




\subsection{Proxy processing of an initial \INVITE transaction}

\label{sec:rr:proxy}




Each proxy \MAY independently decide to record-route an initial

\INVITE transaction. For a proxy, {\em initial} is defined

as any \INVITE request that does not contain a \header{Route}

header. Generally, the choice about whether to record-route or not is

a tradeoff of features vs. performance. Faster call processing and

higher scalability is achieved when proxies do not record

route. However, provision of certain services may require a proxy to

observe all messages for a call leg. It is \RECOMMENDED that proxies

do not automatically record route. They should do so only if

specifically required.




To record-route, the proxy inserts a \header{Record-Route} header into

the request before proxying it onwards. A forking proxy \MAY insert a

different \header{Record-Route} header into each forked request. The

\header{Record-Route} header that it inserts \MUST be inserted as the

first \header{Record-Route} header, appearing before any existing ones

in the request. The URL in the header \MUST be a SIP

URL. \annotate{This is because the URLs in the Record-Route headers

are used for forwarding requests by other proxies. Since no other URL

but a SIP URL is mandatory, a proxy could not be sure that any other

URL is interpretable by other proxies. Thus, SIP URLs are

mandatory}. The URL \MUSTNOT contain the transport

parameter. \annotate{Thats because only UDP is mandatory. If a proxy

inserts a transport parameter in the URL with TCP or TLS as the

transport, the proxy that ends up using that URL to forward the

request might not support that transport. The result, according to the

``Locating a SIP Server'' procedure, would be for the proxy to give

up.} The URL \MUST have the property that when the processing

described in Section XXX ``locaing a SIP server'' is followed for that

URL, the result of the lookup is an address/port of the proxy server

inserting the

\header{Record-Route}. The URL and the proxy configuration \SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing will cause

it to be forwarded to one of the previous-hop servers that the initial

\INVITE request traversed, including the UAS. \annotate{These two

properties are 

important. The first one guarantees that subsequent requests from the

called party are routed back to this actually proxy. The second property is

there for robustness. It guarantees that the request URI always

contain meaningful information, even if there are no \header{Route}

headers that tell the proxy where to forward the request to next.} The

proxy \MAY insert 

\header{Record-Route} parameters into the request. These will be

returned to the proxy in any 200 class response to the \INVITE, and

are useful for pushing state into the message.




If a 200 class response arrives for a proxied request, the response

will contain the entire list of \header{Record-Route} headers inserted

by proxies along the request path. The proxy \MAY modify the

\header{Record-Route} value matching the one it inserted into the

request. Like the URL in the request, it \MUST be a SIP URL and

\MUSTNOT contain a transport parameter. The URL in this

\header{Record-Route} header \MUST have the

property that when the processing described in Section XXX ``locating

a SIP server'' is followed for that URL, the result of the lookup is

an address/port of the proxy server that inserted the

\header{Record-Route}. The URL in this header, and the proxy configuration

\SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing will cause

it to be forwarded to the same next hop server that the initial

\INVITE request was forwarded to.




The four properties (two for the request, two for the response), can

be satisfied in a number of ways. One way is that the URI inserted

into the \header{Record-Route} in the request is the same as the

\header{Contact} header in the \INVITE (if present, else the

\header{From} field), but with the maddr and port set to

resolve to the proxy. Then, the proxy modifies the URL in the

\header{Record-Route} header in the response, setting it to be the URL

from the \header{Request-URI} of the initial \INVITE, but with the maddr

and port set to resolve to the proxy. 




As an example, consider a proxy at 10.0.1.1 listening on port 5061

which receives the following request (many headers are omitted for

brevity):




\begin{verbatim}

INVITE sip:user@example.com SIP/2.0

Via: SIP/2.0/UDP callerspc.univ.edu

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The proxy forwards this request to

\header{sip:j_user@div11.example.com}, and record-routes:




\begin{verbatim}

INVITE sip:j_user@div11.example.com SIP/2.0

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The 200 response will look like, in part:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The proxy modifies its \header{Record-Route} header in the response to

and forwards the request upstream:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:j_user@example.com:5061;maddr=10.0.1.1>;myparam=9877

Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The route set computed by the UAS is:




\begin{verbatim}

sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1

sip:caller@callerspc.univ.edu

\end{verbatim}




and the route set computed by the UAC is:




\begin{verbatim}

sip:j_user@example.com:5061;maddr=10.0.1.1

sip:j_user@host32.div11.example.com

\end{verbatim}




There are other ways to meet these requirements. The proxy could

construct a URL for the request which encodes all of the needed

information, by placing it in the user portion, for example. A call

stateful proxy could insert a URL into the request with the form

sip:proxy.example.com, and not modify it in the response. This URL

clearly satisfies the first required property (of getting routed back

to the proxy that inserted it). The second property can be maintained

by being call stateful, and extracting the needed parameters from

local storage.




When a proxy does decide to modify the \header{Record-Route} header in

the response, one of the operations it must perform is to locate the

\header{Record-Route} that it had inserted. If the request spiraled,

and the proxy inserted a \header{Record-Route} in each iteration of

the spiral, locating the correct header in the response (which must be

the proper iteration in the reverse direction) is tricky. One

mechanism that is \RECOMMENDED is for the proxy to insert a

\header{Record-Route} parameter into the new \header{Record-Route} header

in the request each time the request spirals. This parameter \MUST

uniquely identify the proxy. When the 200 class respone arrives, the

proxy looks for the topmost \header{Record-Route} header containing

this parameter. This header is the one for the current iteration. The

proxy \MUST remove this parameter before forwarding the response

upstream. Upon the next iteration, the same algorithm (find the

topmost \header{Record-Route} header with the parameter) will

correctly extract the next \header{Record-Route}

header.






\subsection{UA Processing of Subsequent Requests in a Call Leg}

\label{sec:rr:uasubsequent}




When a UA wishes to send another request for the call-leg (such as a

\header{BYE} or \header{INVITE}), it follows the procedures defined in

this subsection. The

procedures here \MUST also be followed for an \ACK request for a 200

response to the initial \INVITE for the call leg. The procedures here

\MUSTNOT be followed for a \CANCEL request or an \ACK request for a

non-200 response. This implies that \CANCEL never contains a

\header{Route} header, nor does an \ACK for a non-200 response.




The request is constructed as specified in Section XXX. 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 any

URI parameters, are placed into a \header{Route} header into the request,

in order. The procedures of Section XXX ``locating a SIP server'' are

then applied to the URI in the request URI, the the request is

forwarded to the resulting server.




If a UAS has a route set for a call leg, and receives a re-INVITE for

that call leg containing \header{Record-Route} headers, it \MUST copy

those headers into any 200 class response to that request. If the

boolean variable CONTACT_SET is true, the \header{Contact} header in

the re-INVITE (if present) replaces the last 

entry in the route set. If the boolean variable CONTACT_SET is false,

the UAS \MUST add the URL in the 

\header{Contact} header in the re-INVITE to the bottom of the route

set, and then set CONTACT_SET to true. If the re-INVITE did not

contain a \header{Contact} header, the route-set at the UAS remains

unchanged.




Similarly, if a UAC has a route set for a call leg, and receives a 200

class response to a re-INVITE it sent, the \header{Contact} header is

examined. If not present, the route set remains unchanged. If the

re-INVITE response had a \header{Contact} header, and the boolean

variable CONTACT_SET is false, the URL in the \header{Contact} header

in the response is added to the bottom of the route set, and

CONTACT_SET is set to true. If the re-INVITE response had a

\header{Contact} header, and CONTACT_SET is true, the URL in the

\header{Contact} header of the re-INVITE response replaces the bottom

value in the route set.




The above two paragraphs allow a UA to update its \header{Contact}

address mid-call, but proxies cannot update their route address.  Once

on the route, a proxy remains on the route for the duration of the

call leg. \annotate{Why the different treatment for Contact and

Record-Route in a re-INVITE? It has to do with backwards

compatibility. RFC2543 did not mandate that a proxy needs to refresh

its record-route headers. As a result, the lack of a record-route in a

re-INVITE cannot be interpreted to mean that the proxy does not want

to be included on the route any longer. Updating of the Contact header

mid-call is useful for mobility applications, and is also useful for

forms of third party call control}.






OPEN-ISSUE: should the UA remove the maddr param, if present, if the

request is sent to the server at that maddr?




OPEN-ISSUE: should we mention handling of route with local outbound

proxies here? RFC2543 has some text on DNS-less UAs, but there are

issues with this.




\header{Proxy processing of a non-initial request}

\label{sec:rr:proxy2}




The rules in this section \MUST be followed when a proxy receives a request

that contains a \header{Route} header. The \header{Route} header is

used to forward the request to the next hop. It \MUST override any other

routing decisions that the proxy would otherwise make. Proxies \MAY

respond to requests with \header{Route} headers for any reason (in order

to perform proxy authorization, for example). But, if the request is

proxied, the procedures here \MUST be used to determine where the

request is proxied to. The procedures in this section apply indepedent

of the request method. They \MUST be followed even if the request

method is unknown to the proxy. \annotate{This last sentence is

really, really important. It allows for other methods, defined in the

future, to have record-routing applied to them. As an example, an

instant messaging session run over SIP might begin with a MESSAGE

request. That extension can allow for these sessions to be

record-routed by proxies that know of this extension. However, the

record-routing will only work if proxies that don't know about the

extension follow the Route headers properly. As such, supporting

\header{Route} headers for all methods, known or unknown, is very

important for a robust and future proof proxy implementation.}

Since \CANCEL can never contain

\header{Route}, these procedures never apply to \CANCEL. However, they

do apply to \ACK requests for a 200 OK response, which do contain

\header{Route} headers. 




The proxy \MUST remove the top \header{Route} header from the

request. The URI from that \header{Route} \MUST be placed into the

\header{Request-URI} of the proxied request, including URI

parameters. Any URL parameters present in the top \header{Route}

header which are not allowed in the request URI \MUST be removed from

the \header{Request-URI} by the proxy. The procedures of section XXX

``Locating a SIP Server'' \MUST be followed to compute the next hop

server to forward the request to. 




If the request is an \INVITE request (thus, a re-INVITE) for a call

leg that the proxy wishes to receive messages for (very likely the

case, since the request probably arrived at the proxy because the

proxy record routed in the initial \INVITE), the proxy \MUST

re-insert the

\header{Record-Route} header with the same value it placed in the

initial request. Similarly, it should modify the \header{Record-Route}

header in any 200 class response in the same way the

\header{Record-Route} header was modified in the response to the

initial \INVITE (which may be no modifications at all). The purpose of

this is twofold. First, it allows for proper record-routing in the

case of pre-loaded Route headers (see Section XXX). Secondly, it

allows for recovery from a UA crash and restart, in which case the UA

loses call state, and as a result, its route set as well. The result

is that the route set will be re-established through the

re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the

result is a robust way to recover from crashes.




\subsection{Pre-Loaded Route Headers}




Normally, a UA constructs the Route headers in a request from the

route set learned through \header{Record-Route} headers. However, in

some circumstances, it is useful for a UA to insert \header{Route}

headers into an initial \INVITE. These headers may have been learnt by

the UA through some out of bands means. When an initial \INVITE

(initial as far as the UAC and UAS are concerned) contains

\header{Route} headers, this is referred to as a ``pre-loaded

Route''. It is equivalent to strict source routing in IP. Proxies will

often not be able to distinguish this case from the case described in

Section \ref{sec:rr:proxy}, and will therefore properly use these

route headers to forward the request. If the proxies are interested in

receiving subsequent messages for the call leg, their insertion of

\header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will

establish a correct route set at both UAC and UAS. This route set may

end up being different from the pre-loaded Route used by the UAC. As

such, a UAC that inserts a pre-loaded route set \MUST follow the

procedures of Section \ref{sec:rr:uac} in processing the response to

this initial \INVITE.










---

Jonathan D. Rosenberg                       72 Eagle Rock Ave.

Chief Scientist                             First Floor

dynamicsoft                                 East Hanover, NJ 07936

jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050

http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000

http://www.dynamicsoft.com

 




_______________________________________________

SIP mailing list

SIP@lists.bell-labs.com

http://lists.bell-labs.com/mailman/listinfo/sip





------_=_NextPart_003_01C0C40C.43A8EE10--

------_=_NextPart_000_01C0C40C.43A8EE10--

_______________________________________________
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 Apr 13 07:46:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05542
	for ; Fri, 13 Apr 2001 07:46:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 47D2944398; Fri, 13 Apr 2001 07:46:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id EF9D54438E
	for ; Fri, 13 Apr 2001 07:45:06 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2L9Z7TKC>; Fri, 13 Apr 2001 04:45:17 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
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_01C0C40F.32A40F20"
Subject: [SIP] 183 in call flows.
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, 13 Apr 2001 04:45:11 -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_01C0C40F.32A40F20
Content-Type: text/plain;
	charset="iso-8859-1"


Hi,

I recently noticed in the call flow documents that it states that early
media sessions can be established by simply returning a 183 without SDP
(giving the argument that the early media is unidirectional and thus only
needs the caller's SDP).

I don't remember this change being discussed on the list and I have not seen
this behavior stated in any of the bis or old-183 drafts. Where did it come
from  and why?

Although strictly speaking, the SDP is not required I still think it should
still be required in the 183 response because:
a)	it  now forms a response-code specific behavior that is in contrast
to the general early media handling for other provisional responses, eg SDP
in 180. 
b)	Does not allow symmetric RTP or any other type of NAT friendly
processing to occur (because the source address is unknown).
c)	Is an unnecessary "saving". Why not send the SDP? Sending the
reverse SDP doesn't hurt and is in line with processing for other early
media sessions (eg 180 with SDP). Just because the both SDP are specified,
does not mean that the UAS need accept any media in the forward direction.

What do other people think? I know we all hate early media but at least
let's make the handling of what we have consistent across all response
codes.

Cheers,

Robert.

------_=_NextPart_001_01C0C40F.32A40F20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






183 in call flows.






Hi,




I recently noticed in the call flow =
documents that it states that early media sessions can be established =
by simply returning a 183 without SDP (giving the argument that the =
early media is unidirectional and thus only needs the caller's =
SDP).



I don't remember this change being =
discussed on the list and I have not seen this behavior stated in any =
of the bis or old-183 drafts. Where did it come from  and =
why?



Although strictly speaking, the SDP is =
not required I still think it should still be required in the 183 =
response because:



  1. it  now forms a =
response-code specific behavior that is in contrast to the general =
early media handling for other provisional responses, eg SDP in 180. =

    2. 

  2. Does not allow symmetric RTP or any =
other type of NAT friendly processing to occur (because the source =
address is unknown).
    3. 

  3. Is an unnecessary "saving". Why not =
send the SDP? Sending the reverse SDP doesn't hurt and is in line with =
processing for other early media sessions (eg 180 with SDP). Just =
because the both SDP are specified, does not mean that the UAS need =
accept any media in the forward direction.
    4. 

    



What do other people think? I know we =
all hate early media but at least let's make the handling of what we =
have consistent across all response codes.



Cheers,




Robert.





------_=_NextPart_001_01C0C40F.32A40F20--

_______________________________________________
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 Apr 13 08:45:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06780
	for ; Fri, 13 Apr 2001 08:45:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3AC384436E; Fri, 13 Apr 2001 08:45:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 1913E44358
	for ; Fri, 13 Apr 2001 08:44:57 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <2L9Z7TL9>; Fri, 13 Apr 2001 05:45:07 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
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_01C0C417.8DC6ECD0"
Subject: [SIP] DTMF/voice forking using Join.
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, 13 Apr 2001 05:45:00 -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_01C0C417.8DC6ECD0
Content-Type: text/plain;
	charset="iso-8859-1"


While I'm on a roll ....

Have people thought about using the soon-to-be-proposed Join to replace the
current DTMF/voice forking model (which still has a number of problems in my
mind). 

For example, UA A calls UA B through proxy/B2BUA C. The application server
at C needs to receive a copy of any DTMF/voice sent from UA A (in addition
to the DTMF/voice being sent from A directly to B). An example would be UA A
pressing "#" three times to return to a calling card server application. C
would simply send a Join to UA A such that UA A sends a copy of voice to C.
This would also allow C to easily play messages to A (eg "You have 1 minute
remaining."). 

To work properly, this would require that the Join mechanism allows the
Joiner to specify whether full or only local-mixing is to be performed by
the joinee. In other words, whether the joinee mixes media only to/from the
local terminal (with the joiner), or whether the joinee mixes media between
all parties (conference bridge style). 

Could not Join also be used to easily meet regulatory eavesdropping
requirements? 

Where is status of Join at the moment?

Regards,

Robert.

------_=_NextPart_001_01C0C417.8DC6ECD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






DTMF/voice forking using Join.






While I'm on a roll ....




Have people thought about using the =
soon-to-be-proposed Join to replace the current DTMF/voice forking =
model (which still has a number of problems in my mind). 



For example, UA A calls UA B through =
proxy/B2BUA C. The application server at C needs to receive a copy of =
any DTMF/voice sent from UA A (in addition to the DTMF/voice being sent =
from A directly to B). An example would be UA A pressing "#" three =
times to return to a calling card server application. C would simply =
send a Join to UA A such that UA A sends a copy of voice to C. This =
would also allow C to easily play messages to A (eg "You have 1 minute =
remaining."). 



To work properly, this would require =
that the Join mechanism allows the Joiner to specify whether full or =
only local-mixing is to be performed by the joinee. In other words, =
whether the joinee mixes media only to/from the local terminal (with =
the joiner), or whether the joinee mixes media between all parties =
(conference bridge style). 



Could not Join also be used to easily =
meet regulatory eavesdropping requirements? 




Where is status of Join at the =
moment?




Regards,




Robert.





------_=_NextPart_001_01C0C417.8DC6ECD0--

_______________________________________________
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 Apr 13 13:47:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15122
	for ; Fri, 13 Apr 2001 13:47: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 A4BD84435A; Fri, 13 Apr 2001 13:47:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A36E44342
	for ; Fri, 13 Apr 2001 13:46:12 -0400 (EDT)
Received: from cowboys (IDENT:root@localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.0/8.11.0) with SMTP id f3DBjgP19739
	for ; Fri, 13 Apr 2001 06:45:42 -0500
Message-ID: <002101c0c441$a084a5e0$ad036e3f@dynamicsoft.com>
From: "Dean Willis" 
To: "IETF SIP (E-mail)" 
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
Subject: [SIP] Draft Minutes for SIP WG at IETF 50 posted
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, 13 Apr 2001 12:46:10 -0500
Content-Transfer-Encoding: 7bit

Draft minutes are posetd at:

http://www.softarmor.com/sipwg/meets/ietf50/minutes/draftminutes.htm

Please review and send me any feedback on errors or misrepresentations by
noon US-CST (1800 GMT) on Monday 16April.

--
Dean


_______________________________________________
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 Apr 13 22:27:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22829
	for ; Fri, 13 Apr 2001 22:27:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 37D1744342; Fri, 13 Apr 2001 22:27:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mip.miptel.com (unknown [210.221.183.2])
	by lists.bell-labs.com (Postfix) with ESMTP id BE0DC44340
	for ; Fri, 13 Apr 2001 22:26:19 -0400 (EDT)
Received: from arnold ([210.221.183.24])
	by mip.miptel.com (8.10.1/8.8.7) with SMTP id f3E2Tnl30559
	for ; Sat, 14 Apr 2001 11:29:49 +0900
Message-ID: <000b01c0c48a$a6d3c040$18b7ddd2@arnold>
From: =?ks_c_5601-1987?B?wMzI8byu?= 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0008_01C0C4D6.169FF100"
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
Subject: [SIP] What does that 'maddr' mean?
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, 14 Apr 2001 11:28:54 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C0C4D6.169FF100
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

VGhpcyBpcyBkcmFmdC1pZXRmLXNpcC1jYWxsLWZsb3dzLTA0LnR4dC4NCg0KMy4xLjUgU3VjY2Vz
c2Z1bCBTSVAgdG8gU0lQIHRocm91Z2ggU0lQIEZpcmV3YWxsIFByb3h5DQoNCiAgIFVzZXIgQSAg
ICAgICAgICBGVyBQcm94eSAgICAgICAgIFByb3h5IDEgICAgICAgICAgVXNlciBCDQogICAgIHwg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAg
fCAgIElOVklURSBGMSAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAg
ICB8LS0tLS0tLS0tLS0tLS0tPnwgICBJTlZJVEUgRjIgICAgfCAgICAgICAgICAgICAgICB8DQog
ICAgIHwgICAgKDEwMCkgRjMgICAgfC0tLS0tLS0tLS0tLS0tLT58ICAgSU5WSVRFIEY0ICAgIHwN
CiAgICAgfDwtLS0tLS0tLS0tLS0tLS18ICAgICgxMDApIEY1ICAgIHwtLS0tLS0tLS0tLS0tLS0+
fA0KICAgICB8ICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tfCAgICAoMTAwKSBGNiAg
ICB8DQogICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0t
LS0tLXwNCiAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAxODAg
RjcgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwgICAgIDE4MCBGOCAgICAgfDwtLS0tLS0t
LS0tLS0tLS18DQogICAgIHwgICAgIDE4MCBGOSAgICAgfDwtLS0tLS0tLS0tLS0tLS18ICAgICAg
ICAgICAgICAgIHwNCiAgICAgfDwtLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgIHwgICAg
ICAyMDAgRjEwICAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwgICAgMjAwIEYxMSAgICAgfDwt
LS0tLS0tLS0tLS0tLS18DQogICAgIHwgICAgIDIwMCBGMTIgICAgfDwtLS0tLS0tLS0tLS0tLS18
ICAgICAgICAgICAgICAgIHwNCiAgICAgfDwtLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAg
IHwgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICBBQ0sgRjEzICAgIHwgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICB8DQogICAgIHwtLS0tLS0tLS0tLS0tLS0+fCAgICAgQUNLIEYx
NCAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAgICB8LS0tLS0tLS0t
LS0tLS0tPnwgICAgIEFDSyBGMTUgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAg
ICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLT58DQogICAgIHwgICAgUlRQIE1lZGlhICAgfCAgICAg
ICAgQm90aCBXYXkgUlRQIE1lZGlhICAgICAgIHwNCiAgICAgfDw9PT09PT09PT09PT09PT58PD09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0+fA0KICAgICB8ICAgICBCWUUgRjE2ICAgIHwg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAgIHwtLS0tLS0tLS0tLS0tLS0+
fCAgICAgQllFIEYxNyAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgfCAgICAgICAgICAgICAg
ICB8LS0tLS0tLS0tLS0tLS0tPnwgICAgIEJZRSBGMTggICAgfA0KICAgICB8ICAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLT58DQogICAgIHwgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAyMDAgRjE5ICAgIHwNCiAgICAgfCAgICAgICAg
ICAgICAgICB8ICAgICAyMDAgRjIwICAgIHw8LS0tLS0tLS0tLS0tLS0tfA0KICAgICB8ICAgICAy
MDAgRjIxICAgIHw8LS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICB8DQogICAgIHw8LS0t
LS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgfCAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KDQpVc2Vy
IEEgc2VuZHMgSU5WSVRFICwgQUNLICwgQllFIG1lc3NhZ2UgdG8gRlcgUHJveHkuDQpJTlZJVEUs
IEFDSyBtZXNzYWdlIGhhdmUgYSBtYWRkciBwYXJhbWV0ZXIgaW4gdGhlaXIgUmVxdWVzdC1VUkks
IA0KYnV0IEJZRSBtZXNzYWdlIGRvZXNuJ3QgaGF2ZSBtYWRkciBwYXJhbWV0ZXIuDQppcyB0aGlz
IHdoeT8NCg0KRmlyc3Qgb2YgYWxsLA0KSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgbWFkZHIg
cGFyYW1ldGVyIGlzIG5lZWRlZCBpbiB0aGlzIGZsb3cuDQphbmQgaSB3YW50IHRvIGtub3cgdGhh
dCBnZW5lcmFsIG1lYW5pbmcgb2YgbWFkZHIgcGFyYW1ldGVyLg0KDQpCZXN0IFJlZ2FyZC4NCkhh
dmUgYSBuaWNlIGRheSEhIQ0KDQo=

------=_NextPart_000_0008_01C0C4D6.169FF100
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoaXMgaXMg
ZHJhZnQtaWV0Zi1zaXAtY2FsbC1mbG93cy0wNC50eHQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+My4xLjUgU3Vj
Y2Vzc2Z1bCBTSVAgdG8gU0lQIHRocm91Z2ggU0lQIEZpcmV3YWxsIA0KUHJveHk8L0ZPTlQ+PC9E
SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7IFVz
ZXIgDQpBJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEZXIA0KUHJveHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgUHJveHkgDQoxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFVzZXIgDQpCPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgSU5WSVRFIEYxJm5ic3A7Jm5ic3A7
Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
LS0tLS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsgSU5WSVRFIA0KRjImbmJzcDsmbmJzcDsm
bmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAoMTAwKSBGMyZuYnNwOyZuYnNw
OyZuYnNwOyANCnwtLS0tLS0tLS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyBJTlZJVEUgRjQmbmJz
cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jmx0Oy0tLS0t
LS0tLS0tLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsgKDEwMCkgDQpGNSZuYnNwOyZuYnNwOyZuYnNw
OyB8LS0tLS0tLS0tLS0tLS0tJmd0O3w8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbHQ7LS0tLS0tLS0tLS0tLS0tfCZu
YnNwOyZuYnNwOyZuYnNwOyAoMTAwKSBGNiZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN
CnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jmx0Oy0tLS0tLS0tLS0tLS0t
LXw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4MCBGNyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTgwIEY4Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IA0KfCZsdDstLS0tLS0tLS0tLS0tLS18PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4MCANCkY5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IA0KfCZsdDstLS0tLS0tLS0tLS0tLS18Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jmx0Oy0tLS0tLS0tLS0tLS0t
LXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDIwMCBGMTAmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDIwMCBGMTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jmx0Oy0tLS0tLS0t
LS0tLS0tLXw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgMjAwIA0KRjEyJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZsdDstLS0tLS0tLS0tLS0tLS18
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgDQp8Jmx0Oy0tLS0tLS0tLS0tLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBQ0sgDQpGMTMm
bmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K
fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB
Q0sgDQpGMTQmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfC0tLS0tLS0tLS0tLS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IEFDSyBGMTUmbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfC0tLS0tLS0tLS0tLS0tLSZndDt8PEJSPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJUUCANCk1lZGlhJm5i
c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQm90
aCBXYXkgUlRQIA0KTWVkaWEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxC
Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jmx0Oz09PT09PT09PT09PT09Jmd0O3wmbHQ7
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZndDt8PEJSPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQllFIEYxNiZuYnNwOyZuYnNwOyZu
YnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0t
LS0tLS0tLS0tLS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJZRSANCkYxNyZuYnNw
OyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJS
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgDQp8LS0tLS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQllF
IEYxOCZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K
fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgDQp8LS0tLS0tLS0tLS0tLS0tJmd0O3w8QlI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIw
MCBGMTkmbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN
CnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDIwMCBGMjAmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jmx0Oy0tLS0tLS0tLS0tLS0tLXw8
QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAw
IA0KRjIxJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZsdDstLS0tLS0tLS0tLS0tLS18Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
DQp8Jmx0Oy0tLS0tLS0tLS0tLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
DQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgDQp8PEJSPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+VXNlciBBIHNlbmRzIElOVklURSAsIEFDSyAsIEJZRSBtZXNzYWdlIHRvIEZX
IA0KUHJveHkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SU5WSVRFLCBBQ0sgbWVz
c2FnZSBoYXZlIGEgbWFkZHIgcGFyYW1ldGVyIGluIHRoZWlyIA0KUmVxdWVzdC1VUkksIDwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmJ1dCBCWUUgbWVzc2FnZSBkb2Vzbid0IGhhdmUg
bWFkZHIgcGFyYW1ldGVyLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmlzIHRoaXMg
d2h5PzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgc2l6ZT0yPkZpcnN0IG9mIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U
IHNpemU9Mj5JIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBtYWRkciBwYXJhbWV0ZXIgaXMgbmVl
ZGVkIGluIHRoaXMgDQpmbG93LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmFuZCBp
IHdhbnQgdG8ga25vdyB0aGF0IGdlbmVyYWwgbWVhbmluZyBvZiBtYWRkciANCnBhcmFtZXRlci48
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9Mj5CZXN0IFJlZ2FyZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9
Mj5IYXZlIGEgbmljZSBkYXkhISE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz
cDs8L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0008_01C0C4D6.169FF100--


_______________________________________________
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 Apr 13 23:54:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24850
	for ; Fri, 13 Apr 2001 23:54:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9EFFD44337; Fri, 13 Apr 2001 23:54:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B82C44336
	for ; Fri, 13 Apr 2001 23:53:29 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GBR00JH9K54ZH@firewall.mcit.com> for sip@lists.bell-labs.com;
 Sat, 14 Apr 2001 03:53:28 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GBR00L01K53OY@pmismtp01.wcomnet.com>;
 Sat, 14 Apr 2001 03:53:28 +0000 (GMT)
Received: from wcom.com ([166.42.32.35])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GBR009JAK4OCK@pmismtp01.wcomnet.com>; Sat,
 14 Apr 2001 03:53:13 +0000 (GMT)
From: Alan Johnston 
Subject: [Fwd: [SIP] What does that 'maddr' mean?]
To: hslee@miptel.com
Cc: SIP List 
Message-id: <3AD7C94B.41A24DE@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=iso-8859-1
X-Accept-Language: en
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, 13 Apr 2001 22:51:40 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id XAA24850

Hi,

In this call flow, the BYE should also have a maddr in the Request-URI.

Maddr can either mean multicast address or, more commonly a second
address.  In this case, it is the latter.  This is because the request
is not being sent directly to the entity identified by the username and
host in the Request-URI, instead it is being sent to a Firewall proxy
(outbound proxy) which is identified by the address in the maddr.  Maddr
is also often used in Record-Route and Route headers for similar
reasons.

A simpler example URL would be of the form
sip:user@1.2.3.4;maddr=5.6.7.8  In this example, the request should be
sent to the secondary IP address 5.6.7.8 instead of the IP address in
the host portion 1.2.3.4.

Hope this helps.

Thanks,
Alan Johnston
WorldCom
sip:alanjohnston@siptest.wcom.com

-------- Original Message --------
Subject: [SIP] What does that 'maddr' mean?
   Date: Sat, 14 Apr 2001 11:28:54 +0900
   From: ÀÌÈñ¼® 
     To: sip@lists.bell-labs.com

This is draft-ietf-sip-call-flows-04.txt. 3.1.5 Successful SIP to SIP
through SIP Firewall Proxy    User A          FW Proxy         Proxy
1          User B
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |    (100) F3    |--------------->|   INVITE F4    |
     |<---------------|    (100) F5    |--------------->|
     |                |<---------------|    (100) F6    |
     |                |                |<---------------|
     |                |                |      180 F7    |
     |                |     180 F8     |<---------------|
     |     180 F9     |<---------------|                |
     |<---------------|                |      200 F10   |
     |                |    200 F11     |<---------------|
     |     200 F12    |<---------------|                |
     |<---------------|                |                |
     |     ACK F13    |                |                |
     |--------------->|     ACK F14    |                |
     |                |--------------->|     ACK F15    |
     |                |                |--------------->|
     |    RTP Media   |        Both Way RTP Media       |
     |<==============>|<===============================>|
     |     BYE F16    |                |                |
     |--------------->|     BYE F17    |                |
     |                |--------------->|     BYE F18    |
     |                |                |--------------->|
     |                |                |     200 F19    |
     |                |     200 F20    |<---------------|
     |     200 F21    |<---------------|                |
     |<---------------|                |                |
     |                |                |                |User A sends
INVITE , ACK , BYE message to FW Proxy.INVITE, ACK message have a maddr
parameter in their Request-URI,but BYE message doesn't have maddr
parameter.is this why? First of all,I don't understand why the maddr
parameter is needed in this flow.and i want to know that general meaning
of maddr parameter. Best Regard.Have a nice day!!!



_______________________________________________
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 Apr 16 09:18:09 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03206
	for ; Mon, 16 Apr 2001 09:18: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 20B384433A; Mon, 16 Apr 2001 09:18: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 22A8C44338
	for ; Mon, 16 Apr 2001 09:17:15 -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 JAA07245;
	Mon, 16 Apr 2001 09:17:13 -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 JAA21468;
	Mon, 16 Apr 2001 09:17:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <2G590T1S>; Mon, 16 Apr 2001 09:17:14 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F46F@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Fairlie-Cuninghame, Robert'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] DTMF/voice forking using Join.
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: Mon, 16 Apr 2001 09:17:12 -0400

>Could not Join also be used to easily meet regulatory eavesdropping
requirements? 
I doubt it.  One of the more interesting aspects of legal intercept is that
neither party, NOR ANY NORMAL TEST TECH, WITH NORMAL TEST EQUIPMENT, can
detect the presence of a tap.  That means that, unless completely encrypted,
with no observable difference in message length, you can't have any
signalling difference anywhere between a tapped and an untapped call.
It probably means that no signalling mechanism can be helpfull in any
way to legal intercept. It's always possible to employ a whole lot of
mechanism to get around this issue, but I suspect it won't be worth it,
as there are more straightforward ways to achieve the goals.

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@lists.bell-labs.com  Mon Apr 16 09:28:09 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03293
	for ; Mon, 16 Apr 2001 09:28:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B07F44338; Mon, 16 Apr 2001 09:28:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 1614E44337
	for ; Mon, 16 Apr 2001 09:27:45 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBB9N7>; Mon, 16 Apr 2001 06:27:35 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Rosen, Brian'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] DTMF/voice forking using Join.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C678.FE2B2730"
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, 16 Apr 2001 06:27:32 -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_01C0C678.FE2B2730
Content-Type: text/plain;
	charset="iso-8859-1"

HI Brian,

That does not preclude this being performed on a SIP-PSTN gateway where the
PSTN subscriber (and the remote SIP subscriber) will be unable to detect the
tap. However, I take you point Brian. Does anyone know if there are any
current legal requirements to tap pure IP-only calls? If not, its probably
only a matter of time before some silly country requires this.

Robert.

-----Original Message-----
From:	Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent:	Monday, April 16, 2001 2:17 PM
To:	'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject:	RE: [SIP] DTMF/voice forking using Join.

>Could not Join also be used to easily meet regulatory eavesdropping
requirements? 
I doubt it.  One of the more interesting aspects of legal intercept is that
neither party, NOR ANY NORMAL TEST TECH, WITH NORMAL TEST EQUIPMENT, can
detect the presence of a tap.  That means that, unless completely encrypted,
with no observable difference in message length, you can't have any
signalling difference anywhere between a tapped and an untapped call.
It probably means that no signalling mechanism can be helpfull in any
way to legal intercept. It's always possible to employ a whole lot of
mechanism to get around this issue, but I suspect it won't be worth it,
as there are more straightforward ways to achieve the goals.

Brian

------_=_NextPart_001_01C0C678.FE2B2730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] DTMF/voice forking using Join.




HI Brian,




That does not preclude this being =
performed on a SIP-PSTN gateway where the PSTN subscriber (and the =
remote SIP subscriber) will be unable to detect the tap. However, I =
take you point Brian. Does anyone know if there are any current legal =
requirements to tap pure IP-only calls? If not, its probably only a =
matter of time before some silly country requires this.



Robert.




-----Original =
Message-----

From:   Rosen, Brian [mailto:Brian.Rosen@marconi.com]

Sent:   Monday, April 16, 2001 2:17 PM

To:     'Fairlie-Cuninghame, Robert'; =
'sip@lists.bell-labs.com'

Subject:       =
 RE: [SIP] DTMF/voice forking using =
Join.




>Could not Join also be used to =
easily meet regulatory eavesdropping

requirements? 

I doubt it.  One of the more =
interesting aspects of legal intercept is that

neither party, NOR ANY NORMAL TEST =
TECH, WITH NORMAL TEST EQUIPMENT, can

detect the presence of a tap.  =
That means that, unless completely encrypted,

with no observable difference in =
message length, you can't have any

signalling difference anywhere =
between a tapped and an untapped call.

It probably means that no signalling =
mechanism can be helpfull in any

way to legal intercept. It's always =
possible to employ a whole lot of

mechanism to get around this issue, =
but I suspect it won't be worth it,

as there are more straightforward =
ways to achieve the goals.




Brian





------_=_NextPart_001_01C0C678.FE2B2730--

_______________________________________________
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 Apr 16 09:54:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03664
	for ; Mon, 16 Apr 2001 09:54:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 564D944356; Mon, 16 Apr 2001 09:54:02 -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 1A2DF4433A
	for ; Mon, 16 Apr 2001 09:53:40 -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 JAA10865;
	Mon, 16 Apr 2001 09:53:38 -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 JAA00360;
	Mon, 16 Apr 2001 09:53:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <2G590VDC>; Mon, 16 Apr 2001 09:53:38 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F473@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Fairlie-Cuninghame, Robert'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] DTMF/voice forking using Join.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C67C.A2ECDBD0"
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, 16 Apr 2001 09:53:37 -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_01C0C67C.A2ECDBD0
Content-Type: text/plain;
	charset="ISO-8859-1"

Sure, but you can't depend on all calls going through such a gateway.
 
I believe there are places that can tap an IP stream.  I think it's just a
matter of time
before that will be legal everywhere.  I also think we will have increased
use of
encryption, which will make it hard (for most LEAs, probably impossible) to
tap.
The observation that we probably WILL have to deal with IP taps leads me to
believe that the tap point is probably the access router.  That idea gives a
lot
of people the willies, but it's the most practical answer.  Among other
things,
if a residential gateway calls another residential gateway, the only place
you 
COULD tap would be the access router.  Better not, for example, see any
IP address difference, any signalling difference, or any management stream
difference in the gateway (which is on the suspect's premises, and thus
assumed to be compromised). 
 
Having said that, I remind everyone that the IETF will not support protocol
mechanisms 
whose only purpose is legal intercept, of any kind. 
 
Brian

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Monday, April 16, 2001 9:28 AM
To: 'Rosen, Brian'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] DTMF/voice forking using Join.



HI Brian, 

That does not preclude this being performed on a SIP-PSTN gateway where the
PSTN subscriber (and the remote SIP subscriber) will be unable to detect the
tap. However, I take you point Brian. Does anyone know if there are any
current legal requirements to tap pure IP-only calls? If not, its probably
only a matter of time before some silly country requires this.

Robert. 

BM__MailData-----Original Message----- 
From:   Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
Sent:   Monday, April 16, 2001 2:17 PM 
To:     'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com' 
Subject:        RE: [SIP] DTMF/voice forking using Join. 

>Could not Join also be used to easily meet regulatory eavesdropping 
requirements? 
I doubt it.  One of the more interesting aspects of legal intercept is that 
neither party, NOR ANY NORMAL TEST TECH, WITH NORMAL TEST EQUIPMENT, can 
detect the presence of a tap.  That means that, unless completely encrypted,

with no observable difference in message length, you can't have any 
signalling difference anywhere between a tapped and an untapped call. 
It probably means that no signalling mechanism can be helpfull in any 
way to legal intercept. It's always possible to employ a whole lot of 
mechanism to get around this issue, but I suspect it won't be worth it, 
as there are more straightforward ways to achieve the goals. 

Brian 


------_=_NextPart_001_01C0C67C.A2ECDBD0
Content-Type: text/html;
	charset="ISO-8859-1"




RE: [SIP] DTMF/voice forking using Join.




Sure, but you 
can't depend on all calls going through such a gateway.


 


I believe 
there are places that can tap an IP stream.  I think it's just a matter of 
time


before that 
will be legal everywhere.  I also think we will have increased use 
of


encryption, 
which will make it hard (for most LEAs, probably impossible) to 
tap.


The 
observation that we probably WILL have to deal with IP taps leads me 
to


believe that 
the tap point is probably the access router.  That idea gives a 
lot


of people the 
willies, but it's the most practical answer.  Among other 
things,


if a 
residential gateway calls another residential gateway, the only place you 



COULD tap 
would be the access router.  Better not, for example, see 
any


IP address 
difference, any signalling difference, or any management 
stream


difference in 
the gateway (which is on the suspect's premises, and thus


assumed to be 
compromised). 


 


Having said 
that, I remind everyone that the IETF will not support protocol mechanisms 



whose only 
purpose is legal intercept, of any 
kind. 


 


Brian



  
-----Original Message-----
From: Fairlie-Cuninghame, Robert 
  [mailto:rfairlie@nuera.com]
Sent: Monday, April 16, 2001 9:28 
  AM
To: 'Rosen, Brian'; 'sip@lists.bell-labs.com'
Subject: 
  RE: [SIP] DTMF/voice forking using Join.


  
HI Brian, 

  
That does not preclude this being performed on a 
  SIP-PSTN gateway where the PSTN subscriber (and the remote SIP subscriber) 
  will be unable to detect the tap. However, I take you point Brian. Does anyone 
  know if there are any current legal requirements to tap pure IP-only calls? If 
  not, its probably only a matter of time before some silly country requires 
  this.

  
Robert. 

  
-----Original 
  Message----- 
From:   
  Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
  
Sent:   Monday, April 16, 2001 2:17 PM 
To:     'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com' 
  
Subject:        RE: [SIP] DTMF/voice forking using Join. 

  
>Could not Join also be used to easily meet 
  regulatory eavesdropping 
requirements? 
  
I doubt it.  One of the more 
  interesting aspects of legal intercept is that 
neither party, NOR ANY NORMAL TEST TECH, WITH NORMAL TEST EQUIPMENT, 
  can 
detect the presence of a tap.  
  That means that, unless completely encrypted, 
with no observable difference in message length, you can't have 
  any 
signalling difference anywhere between 
  a tapped and an untapped call. 
It probably 
  means that no signalling mechanism can be helpfull in any 
way to legal intercept. It's always possible to employ a 
  whole lot of 
mechanism to get around this 
  issue, but I suspect it won't be worth it, 
as there are more straightforward ways to achieve the goals. 


  
Brian 


------_=_NextPart_001_01C0C67C.A2ECDBD0--

_______________________________________________
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 Apr 16 09:59:04 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03755
	for ; Mon, 16 Apr 2001 09:59:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 60F5F44356; Mon, 16 Apr 2001 09:59:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id F021444351
	for ; Mon, 16 Apr 2001 09:58:24 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBB9PN>; Mon, 16 Apr 2001 06:58:15 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Rosen, Brian'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] DTMF/voice forking using Join.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C67D.457CC3B0"
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, 16 Apr 2001 06:58:10 -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_01C0C67D.457CC3B0
Content-Type: text/plain;
	charset="iso-8859-1"

Agreed. This was only an afterthought I had for the usage of Join and not
the main thrust of my email (hence the title of the email). 
 
Regards,
 
Robert.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Monday, April 16, 2001 2:54 PM
To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] DTMF/voice forking using Join.


Sure, but you can't depend on all calls going through such a gateway.
 
I believe there are places that can tap an IP stream.  I think it's just a
matter of time
before that will be legal everywhere.  I also think we will have increased
use of
encryption, which will make it hard (for most LEAs, probably impossible) to
tap.
The observation that we probably WILL have to deal with IP taps leads me to
believe that the tap point is probably the access router.  That idea gives a
lot
of people the willies, but it's the most practical answer.  Among other
things,
if a residential gateway calls another residential gateway, the only place
you 
COULD tap would be the access router.  Better not, for example, see any
IP address difference, any signalling difference, or any management stream
difference in the gateway (which is on the suspect's premises, and thus
assumed to be compromised). 
 
Having said that, I remind everyone that the IETF will not support protocol
mechanisms 
whose only purpose is legal intercept, of any kind. 
 
Brian

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Monday, April 16, 2001 9:28 AM
To: 'Rosen, Brian'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] DTMF/voice forking using Join.



HI Brian, 

That does not preclude this being performed on a SIP-PSTN gateway where the
PSTN subscriber (and the remote SIP subscriber) will be unable to detect the
tap. However, I take you point Brian. Does anyone know if there are any
current legal requirements to tap pure IP-only calls? If not, its probably
only a matter of time before some silly country requires this.

Robert. 

BM__MailData-----Original Message----- 
From:   Rosen, Brian [ mailto:Brian.Rosen@marconi.com
 ] 
Sent:   Monday, April 16, 2001 2:17 PM 
To:     'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com' 
Subject:        RE: [SIP] DTMF/voice forking using Join. 

>Could not Join also be used to easily meet regulatory eavesdropping 
requirements? 
I doubt it.  One of the more interesting aspects of legal intercept is that 
neither party, NOR ANY NORMAL TEST TECH, WITH NORMAL TEST EQUIPMENT, can 
detect the presence of a tap.  That means that, unless completely encrypted,

with no observable difference in message length, you can't have any 
signalling difference anywhere between a tapped and an untapped call. 
It probably means that no signalling mechanism can be helpfull in any 
way to legal intercept. It's always possible to employ a whole lot of 
mechanism to get around this issue, but I suspect it won't be worth it, 
as there are more straightforward ways to achieve the goals. 

Brian 


------_=_NextPart_001_01C0C67D.457CC3B0
Content-Type: text/html;
	charset="iso-8859-1"







RE: [SIP] DTMF/voice forking using Join.




Agreed. This was only an afterthought I had for the usage of Join and not 
the main thrust of my email (hence the title of the email). 


 


Regards,


 


Robert.



    
-----Original Message-----
From: Rosen, Brian 
    [mailto:Brian.Rosen@marconi.com]
Sent: Monday, April 16, 2001 2:54 
    PM
To: 'Fairlie-Cuninghame, Robert'; 
    'sip@lists.bell-labs.com'
Subject: RE: [SIP] DTMF/voice forking 
    using Join.


    
Sure, but 
    you can't depend on all calls going through such a 
    gateway.

    
 

    
I believe 
    there are places that can tap an IP stream.  I think it's just a matter 
    of time

    
before 
    that will be legal everywhere.  I also think we will have increased use 
    of

    
encryption, which will make it hard (for most LEAs, 
    probably impossible) to tap.

    
The 
    observation that we probably WILL have to deal with IP taps leads me 
    to

    
believe 
    that the tap point is probably the access router.  That idea gives a 
    lot

    
of people 
    the willies, but it's the most practical answer.  Among other 
    things,

    
if a 
    residential gateway calls another residential gateway, the only place you 
    

    
COULD tap 
    would be the access router.  Better not, for example, see 
    any

    
IP 
    address difference, any signalling difference, or any management 
    stream

    
difference in the gateway (which is on the 
    suspect's premises, and thus

    
assumed 
    to be compromised). 

    
 

    
Having 
    said that, I remind everyone that the IETF will not support protocol 
    mechanisms 

    
whose 
    only purpose is legal intercept, of any 
    kind. 

    
 

    
Brian

    

        
-----Original Message-----
From: Fairlie-Cuninghame, 
        Robert [mailto:rfairlie@nuera.com]
Sent: Monday, April 16, 
        2001 9:28 AM
To: 'Rosen, Brian'; 
        'sip@lists.bell-labs.com'
Subject: RE: [SIP] DTMF/voice 
        forking using Join.


        
HI Brian, 

        
That does not preclude this being performed 
        on a SIP-PSTN gateway where the PSTN subscriber (and the remote SIP 
        subscriber) will be unable to detect the tap. However, I take you point 
        Brian. Does anyone know if there are any current legal requirements to 
        tap pure IP-only calls? If not, its probably only a matter of time 
        before some silly country requires this.

        
Robert. 

        
-----Original 
        Message----- 
From:   
        Rosen, Brian [mailto:Brian.Rosen@marconi.com] 
        
Sent:   Monday, April 16, 2001 2:17 PM 
To:     'Fairlie-Cuninghame, Robert'; 
        'sip@lists.bell-labs.com' 
Subject:        
        RE: [SIP] DTMF/voice forking using Join. 
        

        
>Could not Join also be used to easily 
        meet regulatory eavesdropping 
requirements? 
I doubt 
        it.  One of the more interesting aspects of legal intercept is 
        that 
neither party, NOR ANY NORMAL 
        TEST TECH, WITH NORMAL TEST EQUIPMENT, can 
detect the presence of a tap.  That means that, unless 
        completely encrypted, 
with no 
        observable difference in message length, you can't have any 
        
signalling difference anywhere between a 
        tapped and an untapped call. 
It 
        probably means that no signalling mechanism can be helpfull in 
        any 
way to legal intercept. It's 
        always possible to employ a whole lot of 
mechanism to get around this issue, but I suspect it won't be 
        worth it, 
as there are more 
        straightforward ways to achieve the goals. 

        
Brian 



------_=_NextPart_001_01C0C67D.457CC3B0--

_______________________________________________
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 Apr 16 16:02:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12865
	for ; Mon, 16 Apr 2001 16:02: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 0745144338; Mon, 16 Apr 2001 16:02:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 97D7844337
	for ; Mon, 16 Apr 2001 15:48:31 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBB0RD>; Mon, 16 Apr 2001 12:48:21 -0700
Message-ID: 
From: "Ryner, Jerry" 
To: "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] 183 in call flows.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C6AE.2E45A820"
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, 16 Apr 2001 12:48:16 -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_01C0C6AE.2E45A820
Content-Type: text/plain;
	charset="iso-8859-1"

Another point to consider on this is that allowing media to be processed in
the absence of a remote SDP is a serious security risk.  Without a remote
SDP to verify received packets, (assuming no encryption), the gateway could
possibly play out ANYTHING that comes into it on that RTP port.  Hackers
will be able to inject audio into any call during the early media phase
simply by sending RTP packets.  A more likely failure case, however, is when
the previous call's media was not terminated properly for any number of
reasons.  A "stuck" channel on a remote gateway from a previous call will
corrupt the audio on the new call attempt. 
 
Nuera has been requested by multiple carriers to never accept media without
a valid SDP in place.
 
Regards,
Jerry Ryner
Nuera Communications, Inc.
 
 
-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 13, 2001 4:45 AM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] 183 in call flows.
 
 
Hi, 
I recently noticed in the call flow documents that it states that early
media sessions can be established by simply returning a 183 without SDP
(giving the argument that the early media is unidirectional and thus only
needs the caller's SDP).
I don't remember this change being discussed on the list and I have not seen
this behavior stated in any of the bis or old-183 drafts. Where did it come
from  and why?
Although strictly speaking, the SDP is not required I still think it should
still be required in the 183 response because:
a.       it  now forms a response-code specific behavior that is in contrast
to the general early media handling for other provisional responses, eg SDP
in 180. 
b.      Does not allow symmetric RTP or any other type of NAT friendly
processing to occur (because the source address is unknown).
c.       Is an unnecessary "saving". Why not send the SDP? Sending the
reverse SDP doesn't hurt and is in line with processing for other early
media sessions (eg 180 with SDP). Just because the both SDP are specified,
does not mean that the UAS need accept any media in the forward direction.
 
What do other people think? I know we all hate early media but at least
let's make the handling of what we have consistent across all response
codes.
Cheers, 
Robert. 

------_=_NextPart_001_01C0C6AE.2E45A820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












183 in call flows.










A=
nother
point to consider on this is that allowing media to be processed in the =
absence
of a remote SDP is a serious security risk.  Without a remote SDP to verify received packets, =
(assuming
no encryption), the gateway could possibly play out ANYTHING that comes =
into it
on that RTP port.  =
Hackers will be
able to inject audio into any call during the early media phase simply =
by
sending RTP packets.  A =
more likely
failure case, however, is when the previous call’s media was not =
terminated
properly for any number of reasons. 
A “stuck” channel on a remote gateway from a =
previous call will corrupt
the audio on the new call attempt. 



<=
![if =
!supportEmptyParas]> 
=



N=
uera has
been requested by multiple carriers to never accept media without a =
valid SDP
in place.



<=
![if =
!supportEmptyParas]> 
=



R=
egards,



J=
erry
Ryner



N=
uera
Communications, Inc.



<=
![if =
!supportEmptyParas]> 
=



<=
![if =
!supportEmptyParas]> 
=



-----Original
Message-----

From: =
Fairlie-Cuninghame, Robert
[mailto:rfairlie@nuera.com]

Sent: Friday, April 13, =
2001 4:45
AM

To: =
'sip@lists.bell-labs.com'

Subject: [SIP] 183 in =
call flows.



 



 =




Hi, =




I recently =
noticed in
the call flow documents that it states that early media sessions can be
established by simply returning a 183 without SDP (giving the argument =
that the
early media is unidirectional and thus only needs the caller's =
SDP).=




I don't =
remember this
change being discussed on the list and I have not seen this behavior =
stated in
any of the bis or old-183 drafts. Where did it come from  and =
why?=




Although =
strictly
speaking, the SDP is not required I still think it should still be =
required in
the 183 response because:=




a.       =
it  now forms a response-code specific behavior that =
is in
contrast to the general early media handling for other provisional =
responses,
eg SDP in 180. 



b.      =
Does not allow symmetric RTP or any other type of NAT =
friendly
processing to occur (because the source address is =
unknown).=




c.       =
Is an unnecessary "saving". Why not send the =
SDP?
Sending the reverse SDP doesn't hurt and is in line with processing for =
other
early media sessions (eg 180 with SDP). Just because the both SDP are =
specified,
does not mean that the UAS need accept any media in the forward =
direction.=




 =




What do other =
people
think? I know we all hate early media but at least let's make the =
handling of
what we have consistent across all response codes.=




Cheers,<=
/font> =




Robert.<=
/font> =










------_=_NextPart_001_01C0C6AE.2E45A820--

_______________________________________________
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  Tue Apr 17 03:06:11 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03957
	for ; Tue, 17 Apr 2001 03:06:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5DBCA44338; Tue, 17 Apr 2001 02:45:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id EE11244337
	for ; Tue, 17 Apr 2001 02:44:15 -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 f3H6iCs29872;
	Tue, 17 Apr 2001 08:44:12 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.86])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3H6h7K10351;
	Tue, 17 Apr 2001 09:43:08 +0300 (EET DST)
Message-ID: <3ADBE5F9.51C416AA@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ryner, Jerry" 
Cc: "Fairlie-Cuninghame, Robert" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] 183 in call flows.
References: 
Content-Type: multipart/mixed;
 boundary="------------B10357484A08F2CA73C7238B"
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, 17 Apr 2001 09:43:05 +0300

This is a multi-part message in MIME format.
--------------B10357484A08F2CA73C7238B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi Robert,

What do you consider as a "valid" SDP?

For example, if dynamic IP address allocation is used, or if one party
is behind a firewall, or in a VPN, it is very difficult to make the
validity test based on the media IP address. And, if it's only about
sending any SDP in the 183 message, I think the hacker can also do that
as well.

Regards,

Christer Holmberg
Ericsson Finland
--------------B10357484A08F2CA73C7238B
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

--------------B10357484A08F2CA73C7238B--


_______________________________________________
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  Tue Apr 17 05:58:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04783
	for ; Tue, 17 Apr 2001 05:58: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 6888D44338; Tue, 17 Apr 2001 05:58:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id AC2D444337
	for ; Tue, 17 Apr 2001 05:57:49 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBCB1Y>; Tue, 17 Apr 2001 02:57:24 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Christer Holmberg'" ,
        "Ryner, Jerry" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] 183 in call flows.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C724.C9CC3F90"
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, 17 Apr 2001 02:57:18 -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_01C0C724.C9CC3F90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Christer,

I did not actually mention security in my original email, however, I don't
think your argument is relevant for 183. If a hacker can sniff the INVITE
and generate a response, why don't they just send a 200 OK with SDP instead
of bothering with a 183 response ? If you want message security use message
authentication or IPSEC.

Additionally, I do not think it is unreasonable that if you are about to
send media then you know the address it will be sent from (assuming that it
will be sent from the same address that you specify in the reverse SDP). Are
you saying that you shouldn't include SDP in a 200 OK because it might be
behind a NAT? Of course you aren't - the SDP in the 183 can only help an ALG
resolve this situation not prevent it. 

Besides, as I pointed out in my original email, I am only trying to make the
handling of early media with 183 Session Progress behave consistently to
early media with other response codes (to simplify the damn thing rather
than complicate it)!

Regards,

Robert.

-----Original Message-----
From:	Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
Sent:	Tuesday, April 17, 2001 7:43 AM
To:	Ryner, Jerry
Cc:	Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com'
Subject:	Re: [SIP] 183 in call flows.

 << File: Card for Christer Holmberg >> 
Hi Robert,

What do you consider as a "valid" SDP?

For example, if dynamic IP address allocation is used, or if one party
is behind a firewall, or in a VPN, it is very difficult to make the
validity test based on the media IP address. And, if it's only about
sending any SDP in the 183 message, I think the hacker can also do that
as well.

Regards,

Christer Holmberg
Ericsson Finland

------_=_NextPart_001_01C0C724.C9CC3F90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] 183 in call flows.




Hi Christer,




I did not actually mention security in =
my original email, however, I don't think your argument is relevant for =
183. If a hacker can sniff the INVITE and generate a response, why =
don't they just send a 200 OK with SDP instead of bothering with a 183 =
response ? If you want message security use message authentication or =
IPSEC.



Additionally, I do not think it is =
unreasonable that if you are about to send media then you know the =
address it will be sent from (assuming that it will be sent from the =
same address that you specify in the reverse SDP). Are you saying that =
you shouldn't include SDP in a 200 OK because it might be behind a NAT? =
Of course you aren't - the SDP in the 183 can only help an ALG resolve =
this situation not prevent it. 





Besides, as I pointed out in my =
original email, I am only trying to make the handling of early media with 183 Session Progress behave consistently to early =
media with other response codes (to simplify the damn thing rather than =
complicate it)!



Regards,




Robert.




-----Original =
Message-----

From:   Christer =
Holmberg [mailto:christer.holmbe=
rg@lmf.ericsson.se]

Sent:   Tuesday, April 17, 2001 7:43 AM

To:     Ryner, Jerry

Cc:     Fairlie-Cuninghame, Robert; =
'sip@lists.bell-labs.com'

Subject:       =
 Re: [SIP] 183 in call flows.




 << File: Card for Christer =
Holmberg >>=20

Hi Robert,




What do you consider as a =
"valid" SDP?




For example, if dynamic IP address =
allocation is used, or if one party

is behind a firewall, or in a VPN, it =
is very difficult to make the

validity test based on the media IP =
address. And, if it's only about

sending any SDP in the 183 message, I =
think the hacker can also do that

as well.




Regards,




Christer Holmberg

Ericsson Finland





------_=_NextPart_001_01C0C724.C9CC3F90--

_______________________________________________
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  Tue Apr 17 06:38:07 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05132
	for ; Tue, 17 Apr 2001 06:38:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 044FB44338; Tue, 17 Apr 2001 06:38:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id B44DF44337
	for ; Tue, 17 Apr 2001 06:37:51 -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 f3HAbnP06003;
	Tue, 17 Apr 2001 12:37:49 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.86])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3HAbmK24208;
	Tue, 17 Apr 2001 13:37:48 +0300 (EET DST)
Message-ID: <3ADC1CF9.20305F4C@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "Ryner, Jerry" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] 183 in call flows.
References: 
Content-Type: multipart/mixed;
 boundary="------------B143F269DECDD3D282E8898A"
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, 17 Apr 2001 13:37:46 +0300

This is a multi-part message in MIME format.
--------------B143F269DECDD3D282E8898A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi Robert,

First, I guess this is related to the discussion about when the UAC
should be able to receive media in the first place.

It has been proposed (I guess this is also what the bis currently says)
that a UAC should be able to receive media as soon as the INVITE has
been sent, ie. it may receive early media even without a 183 provisional
response. Or, even if a 183 provisional response is sent the media may
"reach" the UAC before the 183 (which is the main reason that the media
channel should be opened after the INVITE).

>Additionally, I do not think it is unreasonable that if you are about
>to send media then you know the address it will be sent from (assuming
>that it will be sent from the same address that you specify in the
>reverse SDP). Are you saying that you shouldn't include SDP in a 200
>OK because it might be behind a NAT? Of course you aren't - the SDP in
>the 183 can only help an ALG resolve this situation not prevent it.

You have to include the SDP in the 200 OK response, but my issue was
more about your proposal to add the SDP as a MUST in the 183 provisional
response, and how you can ensure that it is a "valid" SDP.

Also, I guess the SDP may even change in the 200 OK. Would you then
allow the new SDP? 


Regards,

Christer Holmberg
Ericsson Finland

 


 
> Regards,
> 
> Robert.
> 
> -----Original Message-----
> From:   Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent:   Tuesday, April 17, 2001 7:43 AM
> To:     Ryner, Jerry
> Cc:     Fairlie-Cuninghame, Robert; 'sip@lists.bell-labs.com'
> Subject:        Re: [SIP] 183 in call flows.
> 
>  << File: Card for Christer Holmberg >>
> Hi Robert,
> 
> What do you consider as a "valid" SDP?
> 
> For example, if dynamic IP address allocation is used, or if one party
> 
> is behind a firewall, or in a VPN, it is very difficult to make the
> validity test based on the media IP address. And, if it's only about
> sending any SDP in the 183 message, I think the hacker can also do
> that
> as well.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
--------------B143F269DECDD3D282E8898A
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

--------------B143F269DECDD3D282E8898A--


_______________________________________________
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  Tue Apr 17 07:08:13 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05283
	for ; Tue, 17 Apr 2001 07:08:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1BD4644376; Tue, 17 Apr 2001 07:08:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54])
	by lists.bell-labs.com (Postfix) with ESMTP id D631E44337
	for ; Tue, 17 Apr 2001 07:07:09 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Tue, 17 Apr 2001 12:05:18 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-31) id MAA28764; Tue, 17 Apr 2001 12:03:40 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A31.003C48C2 ; Tue, 17 Apr 2001 11:58:27 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" 
To: "Fairlie-Cuninghame, Robert" 
Cc: "'Arunachalam Venkatraman'" ,
        Sherman Gong , sip@lists.bell-labs.com,
        "'Jonathan Rosenberg'" 
Message-ID: <80256A31.003C44DD.00@marconicomms.com>
Subject: RE: [SIP] Request-uri does not match record-route header...
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=RKSQABsvzPHdckvq0q5BlbjFWpznzbRNSad6M2yMQRAiQzwwWopufi1y"
Content-Disposition: inline
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, 17 Apr 2001 11:58:27 +0100

--0__=RKSQABsvzPHdckvq0q5BlbjFWpznzbRNSad6M2yMQRAiQzwwWopufi1y
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello,

Shouldn't the Request-Uri in the ACK should be :

ACK
sip:3032011001@192.168.10.114:5060;maddr=192.168.10.141;transport=udp;user=phone
SIP/2.0

This will then be sent to 192.168.10.141 using the maddr.

It is important that the Request-Uri in the subsequent messages is that given in
the Record-Route
as stateful proxies may well use this to identify the correct state machine to
process the request.

Like Robert, I think this touches upon the issues with Route headers, outbound
proxies and UA
without DNS capability which I feel hasn't yet been resolved.

Regards,

Keith Robinson









"Fairlie-Cuninghame, Robert"  on 13/04/2001 12:24:12
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      "'Arunachalam Venkatraman'" ,   
          Sherman Gong ,                     
          sip@lists.bell-labs.com                             
                                                              
 cc:      "'Jonathan Rosenberg'"                              
          (bcc: Keith                
          Robinson/MAIN/MC1)                                  
                                                              
                                                              
                                                              
 Subject: RE: [SIP] Request-uri does not match record-route   
          header...                                           
                                                              







Hi,

I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a)   the proxy knows that it record-routed this call leg
b)   or the Request-URI resolves to the local proxy's address.

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".

For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.

At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?

Robert.

 <<[SIP] new record-route text!>>
-----Original Message----
From:     Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
Sent:     Thursday, April 12, 2001 5:46 PM
To:  Sherman Gong; sip@lists.bell-labs.com
Subject:  RE: [SIP] Request-uri does not match record-route header...

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.


 -----Original Message-----
From:     sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:     Thursday, April 12, 2001 10:09 AM
To:  sip@lists.bell-labs.com
Subject:  [SIP] Request-uri does not match record-route header...

Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG


_______________________________________________
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.


--0__=RKSQABsvzPHdckvq0q5BlbjFWpznzbRNSad6M2yMQRAiQzwwWopufi1y
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+UkU6IFtT
SVBdIFJlcXVlc3QtdXJpIGRvZXMgbm90IG1hdGNoIHJlY29yZC1yb3V0ZSBoZWFkZXIuLi48L1RJ
VExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SGks
PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkkgYmVsaWV2ZSB0
aGUgUmVjb3JkLVJvdXRlIHRlc3QgaGFzIGJlZW4gY29tcGxldGVseSByZXdyaXR0ZW4gKG1lc3Nh
Z2UgYXR0YWNoZWQpLiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSBob3dldmVyIEFydW5hY2hhbGFtJ3Mg
cmVzcG9uc2Ugc2hvdWxkIGJlIHF1YWxpZmllZCBieSB0aGUgc2F5aW5nIHRoYXQgYSBwcm94eSBz
aG91bGQgb25seSB1c2UgdGhlIG5leHQgUm91dGUgaGVhZGVyIGlmPC9GT05UPjwvUD4NCg0KPE9M
IFRZUEU9YT48TEk+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50aGUgcHJveHkga25vd3MgdGhh
dCBpdCByZWNvcmQtcm91dGVkIHRoaXMgY2FsbCBsZWc8L0ZPTlQ+PC9MST4NCjxMST48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPm9yIHRoZSBSZXF1ZXN0LVVSSSByZXNvbHZlcyB0byB0aGUgbG9j
YWwgcHJveHkncyBhZGRyZXNzLjwvRk9OVD48L0xJPg0KPEJSPg0KPC9PTD4NCjxQPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+SSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgcmVmbGVjdGVkIGluIHRo
ZSBuZXcgUmVjb3JkLVJvdXRlIHRleHQuIEl0IHRvdWNoZXMgb24gYW4gdW5yZXNvbHZlZCAob3Ig
YXQgbGVhc3QgdGhhdCB3YXMgbXkgZmVlbGluZykgZGlzY3Vzc2lvbiBhIGxvbmcgdGltZSBhYm91
dCB3aGV0aGVyIGEgUmVjb3JkLVJvdXRpbmcncyBpbnRlcmFjdGlvbiB3aXRoICJPdXRib3VuZCBQ
cm94aWVzIi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZvciBp
bnN0YW5jZSwgd2hlbiBhIFVBIG9yIFByb3h5LCBwdXRzIHRoZSBmaXJzdCBSb3V0ZSBoZWFkZXIg
aW4gdGhlIFJlcXVlc3QtVVJJIGJ1dCB0aGVuIHNlbmRzIHRoZSBtZXNzYWdlIHRvIGFuIG91dGJv
dW5kIHByb3h5IGJlY2F1c2UgdGhlIFVBIGxhY2tzIEROUyBjYXBhYmlsaXR5LiBUaGUgb3V0Ym91
bmQgcHJveHkgbWF5IG5vdCBoYXZlIFJlY29yZC1Sb3V0ZSdkIGJ1dCBpdCBtdXN0IG5vdCByZW1v
dmUvcHJvY2VzcyB0aGUgbmV4dCBSb3V0ZSBoZWFkZXIgZWl0aGVyLjwvRk9OVD48L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QXQgcmlzayBvZiByZW9wZW5pbmcgdGhpcyBkaXNj
dXNzaW9uLCBkaWQgd2UgcmVhY2ggYXQgY29uY2x1c2lvbiBvbiB0aGlzIHBvaW50LCB0aGF0IGlz
LCB3aGVuIGEgcHJveHkgc2hvdWxkIHVzZSB0aGUgbmV4dCBSb3V0ZSBoZWFkZXIgYW5kIHdoZW4g
c2hvdWxkIGl0IG5vdCAoaWYgdGhlIFJlcXVlc3QtVVJJIGlzIGRvZXMgbm90IHJlc29sdmUgdG8g
dGhlIHByb3h5J3MgYWRkcmVzcyk/PC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5Sb2JlcnQuPC9GT05UPg0KPC9QPg0KDQo8UD48QSBOQU1FPSJfTWFpbERhdGEiPjxG
T05UIEZBQ0U9IkFyaWFsIiBTSVpFPTIgQ09MT1I9IiMwMDAwMDAiPiAmbHQ7Jmx0O1tTSVBdIG5l
dyByZWNvcmQtcm91dGUgdGV4dCEmZ3Q7Jmd0OyA8L0ZPTlQ+PFU+PC9VPjwvQT4NCjxCUj48VT48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS08L0ZPTlQ+
PC9VPg0KPEJSPjxCPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDsg
QXJ1bmFjaGFsYW0gVmVua2F0cmFtYW4gWzxBIEhSRUY9Im1haWx0bzphcnVudmVua0BjaXNjby5j
b20iPm1haWx0bzphcnVudmVua0BjaXNjby5jb208L0E+XTwvRk9OVD48L0I+DQo8QlI+PEI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+VGh1cnNkYXksIEFwcmlsIDEyLCAyMDAxIDU6NDYgUE08L0ZP
TlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlNoZXJtYW4gR29u
Zzsgc2lwQGxpc3RzLmJlbGwtbGFicy5jb208L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UkU6IFtTSVBdIFJlcXVl
c3QtdXJpIGRvZXMgbm90IG1hdGNoIHJlY29yZC1yb3V0ZSBoZWFkZXIuLi48L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+WW91IGFyZSBjb3JyZWN0IGluIHRoYXQm
bmJzcDsgdGhlIFJFUSBVUkkgaW4gQUNLIG9mIHlvdXIgZXhhbXBsZSBzaG91bGQgYmU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4xOTIuMTY4LjEwLjExNC48L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ib3dldmVyLCBJIGRvbid0IGtub3cgd2hhdCBp
cyB0aGUgdmFsdWUgb2YgY29weWluZyB0aGUgdG9wbW9zdCByb3V0ZSB0byB0aGU8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SRVEgVVJJIC48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGUgcG9ydCBvZiB0aGUgVUFTIGlzIGRpZmZlcmVudCBm
cm9tIHRoYXQgaW4gdGhlIFJvdXRlLCBpdCBsb29rcyB3cm9uZyE8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgZmFjdCBpcywgdGhlIFJFUSBVUkkgaXMgbm90IHVzZWQg
Zm9yIHJvdXRpbmcgd2hlbiB0aGVyZSBpcyBhIFJPVVRFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+aGVhZGVyIGluIHRoZSBtZXNzYWdlLjwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPkkgaGF2ZSBmb3VuZCB0aGF0IHRoZSBSRVEgVVJJIGluIHRoZSBB
Q0sgdG8gYSBwcm94eSBJIGhhdmUgYmVlbiB0ZXN0aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+d2l0aCwgY2FuIGJlIGFueXRoaW5nIChzbyBsb25nIGFzIGl0IHBhcnNl
cyBvaykgd2hlbiB0aGVyZSBpcyBhIFJPVVRFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+aGVhZGVyLiBUaGUgcHJveHkgdXNlcyB0aGUgUm91dGUgaGVhZGVyIGZvciByb3V0
aW5nIGFuZCBub3QgdGhlIFJFUSBVUkksPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+d2hlbiBhIFJPVVRFIGhlYWRlciBpcyBwcmVzZW50LjwvRk9OVD4NCjwvUD4NCjxCUj4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDstLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZyb206ICZuYnNw
OyBzaXAtYWRtaW5AbGlzdHMuYmVsbC1sYWJzLmNvbSBbPEEgSFJFRj0ibWFpbHRvOnNpcC1hZG1p
bkBsaXN0cy5iZWxsLWxhYnMuY29tIj5tYWlsdG86c2lwLWFkbWluQGxpc3RzLmJlbGwtbGFicy5j
b208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk9uIEJlaGFsZiBP
ZiBTaGVybWFuIEdvbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50
OiZuYnNwOyZuYnNwOyBUaHVyc2RheSwgQXByaWwgMTIsIDIwMDEgMTA6MDkgQU08L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
c2lwQGxpc3RzLmJlbGwtbGFicy5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb
U0lQXSBSZXF1ZXN0LXVyaSBkb2VzIG5vdCBtYXRjaCByZWNvcmQtcm91dGUgaGVhZGVyLi4uPC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhhdmluZyBhIHByb2Js
ZW0gd2hlcmVieSB0aGUgcmVxdWVzdC11cmkgdXNlZCBpbiB0aGUgQUNLIGRvZXMgbm90IG1hdGNo
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhhdCB3aGljaCB3YXMgaW4g
dGhlIHJlY29yZC1yb3V0ZSBoZWFkZXIgaW4gdGhlIDIwMCBPSy4mbmJzcDsgUGVyIHRoZSBTSVAg
YmlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZHJhZnQgKHNlY3Rpb24g
Ni4zOSBpbiB0aGUgMDIgdmVyc2lvbiksIHRoZSBmaXJzdCBSb3V0ZSBoZWFkZXIgKGNvbnN0cnVj
dGVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZnJvbSB0aGUgcmVjb3Jk
LXJvdXRlIGhlYWRlcikgc2hvdWxkIGJlIHJlbW92ZWQgYW5kIHVzZWQgYXMgdGhlPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVxdWVzdC1VUkkuJm5ic3A7IEkgaW5jbHVk
ZWQgYSBjb3VwbGUgb2Ygbm90ZXMgYmVsb3cgYXN0ZXJpc2tzICgqKioqKiopLjwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGhhdmUgYmVlbiBnZXR0aW5nIGNv
bmZsaWN0aW5nIGFyZ3VtZW50cyBvbiB3aGljaCByZXF1aXJlbWVudCB0aGlzIHNob3VsZDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmZvbGxvdy4mbmJzcDsgTmVlZCB0byBk
ZXRlcm1pbmUgd2hpY2ggc3BlYy4gaXMgY29ycmVjdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+MSkmbmJzcDsgNi4yOSBSZWNvcmQtUm91dGU8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFRoZSBSZWNvcmQtUm91dGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIGlz
IGFkZGVkIHRvIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBieSBhbnkgcHJveHkgdGhhdCBpbnNpc3RzIG9uIGJl
aW5nIGluIHRoZSBwYXRoIG9mIHN1YnNlcXVlbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdHMgZm9yIHRoZSBzYW1l
IGNhbGwgbGVnLiBJdCBjb250YWlucyBhIGdsb2JhbGx5IHJlYWNoYWJsZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXF1ZXN0
LVVSSSB0aGF0IGlkZW50aWZpZXMgdGhlIHByb3h5IHNlcnZlci4gRWFjaCBwcm94eSBzZXJ2ZXIg
YWRkczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBpdHMgUmVxdWVzdC1VUkkgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgbGlzdC48
L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzZXJ2ZXIgY29waWVzIHRoZSBSZWNvcmQtUm91dGUgaGVh
ZGVyIGZpZWxkIHVuY2hhbmdlZCBpbnRvIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZS4gKFJlY29y
ZC1Sb3V0ZSBpcyBvbmx5IHJlbGV2YW50IGZvciAyeHggcmVzcG9uc2VzLik8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFRoZSBjYWxsaW5nIHVzZXIgYWdlbnQgY2xpZW50IGNvcGllcyB0aGUgUmVjb3JkLVJv
dXRlIGhlYWRlciBpbnRvIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUgaGVhZGVyIGZpZWxkIG9mIHN1YnNl
cXVlbnQgcmVxdWVzdHMgd2l0aGluIHRoZSBzYW1lIGNhbGwgbGVnLDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXZl
cnNpbmcgdGhlIG9yZGVyIG9mIHJlcXVlc3RzLCBzbyB0aGF0IHRoZSBmaXJzdCBlbnRyeSBpcyBj
bG9zZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSB1c2VyIGFnZW50IGNsaWVudC4gSWYgdGhlIHJlc3Bv
bnNlIGNvbnRhaW5lZCBhIENvbnRhY3QgaGVhZGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpZWxkLCB0aGUgY2Fs
bGluZyB1c2VyIGFnZW50IGFkZHMgaXRzIGNvbnRlbnQgYXMgdGhlIGxhc3QgUm91dGU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgaGVhZGVyLiBVbmxlc3MgdGhpcyB3b3VsZCBjYXVzZSBhIGxvb3AsIGFueSBjbGllbnQg
TVVTVCBzZW5kIGFueTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWJzZXF1ZW50IHJlcXVlc3RzIGZvciB0aGlzIGNh
bGwgbGVnIHRvIHRoZSBmaXJzdCBSZXF1ZXN0LVVSSSBpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUg
cmVxdWVzdCBoZWFkZXIgZmllbGQgYW5kIHJlbW92ZSB0aGF0IGVudHJ5LjwvRk9OVD4NCjwvUD4N
CjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsg
VGhlIGFib3ZlIGRlc2NyaWJlcyBidWlsZGluZyBSb3V0ZSBoZWFkZXJzIGZyb20gdGhlIFJlY29y
ZC1Sb3V0ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmhlYWRlcnMsPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFu
ZCBzZW5kaW5nIHN1YnNlcXVlbnQgcmVxdWVzdHMgdG8gdGhlIGZpcnN0IFJvdXRlLCByZW1vdmlu
ZyB0aGF0IGVudHJ5LjwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj4mbmJzcDsgNi4zMyBSb3V0ZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFJvdXRlIHJl
cXVlc3QtaGVhZGVyIGZpZWxkIGRldGVybWluZXMgdGhlIHJvdXRlIHRha2VuIGJ5IGE8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcmVxdWVzdC4gRWFjaCBob3N0IHJlbW92ZXMgdGhlIGZpcnN0IGVudHJ5IGFuZCB0aGVu
IHByb3hpZXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgdG8gdGhlIGhvc3QgbGlzdGVkIGluIHRo
YXQgZW50cnksIGFsc28gdXNpbmcgaXQgYXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlcXVlc3QtVVJJLiBU
aGUgb3BlcmF0aW9uIGlzIGZ1cnRoZXIgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4yOS48L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFRoZSBhYm92ZSBub3RlcyB0aGF0IHRoZSBSb3V0ZSBoZWFkZXIgdXNlZCB0byBwcm94eSBhIHJl
cXVlc3Qgc2hvdWxkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YWxzbzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBiZSB1c2VkIGFzIHRoZSBSZXF1ZXN0LVVSSS4mbmJzcDsgVGhpcyBpcyB0aGUgcGFydCB0
aGF0IGlzIG5vdCBiZWluZyBkb25lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlY3RseSBieSB0aGUgNTMwMC4mbmJzcDsg
VGhlIDUzMDAgaXMgYnVpbGRpbmcgaXQncyBvd24gcmVxdWVzdCBVUkkgYmFzZWQ8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZGVzdGluYXRpb24gb2Yg
dGhlIHJlcXVlc3QsIHJhdGhlciB0aGFuIHVzaW5nIHRoZSBVUkkgaW4gdGhlIFJvdXRlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhlYWRl
ciBhcyB0aGUgUmVxdWVzdC1VUkkuJm5ic3A7IE5vdGUgdGhhdCB0aGUgNTMwMCBpcyBzZW5kaW5n
IHRoZSByZXF1ZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dG8gdGhl
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGNvcnJlY3QgZGVzdGluYXRpb24sIHdoaWNoIGluIG91ciBjYXNlIGRvZXMgbm90IG1hdGNoIHRo
YXQgaW4gdGhlIFJvdXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGhlYWRlciAoYnV0IHRoZXkgZG9uJ3QgaGF2ZSB0byBtYXRjaCkuPC9G
T05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk9yPC9GT05U
Pg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjIpJm5ic3A7IGZy
b20gcGFnZSAyMCBvZiB0aGUgZHJhZnQ8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBtYWRkciBwYXJhbWV0ZXIg
aW5kaWNhdGVzIHRoZSBzZXJ2ZXIgYWRkcmVzcyB0byBiZSBjb250YWN0ZWQgZm9yPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhpcyB1c2VyLCBvdmVycmlkaW5nIHRoZSBh
ZGRyZXNzIHN1cHBsaWVkIGluIHRoZSBob3N0IGZpZWxkLiBUaGlzPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgaXMg
dHlwaWNhbGx5LCBidXQgbm90IG5lY2Vzc2FyaWx5LCBhIG11bHRpY2FzdCBhZGRyZXNzLiBUaGU8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5tYWRkciBmaWVsZCBjYW4gYmUg
dXNlZCB0byBmb3JjZSByZXF1ZXN0cyBmcm9tIHRyYXZlbGluZyB1c2VycyB0byB2aXNpdDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBhIGhvbWUgcHJveHkgZXZlbiBpZiBhbiBvdXRib3VuZCBwcm94eSBpcyB1c2VkLjwvRk9OVD4N
CjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5j
NTMwMC0zIzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDUuNjMyOiBJU0ROIFNlMDoyMzogUlggJmx0Oy0mbmJzcDsgU0VUVVAgcGQgPSA4Jm5ic3A7
IGNhbGxyZWYgPSAweDAwMDE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4q
SmFuIDIyIDA4OjM0OjA1LjYzMjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgQmVhcmVyIENhcGFiaWxpdHkgaSA9IDB4ODA5MEEyPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42MzY6Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYW5uZWwgSUQgaSA9IDB4QTk4
MzgxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42MzY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENh
bGxpbmcgUGFydHkgTnVtYmVyIGkgPSAweDIxODAsICcyMDYyMDExMDAxJyw8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QbGFuOklTRE4sIFR5cGU6TmF0aW9uYWw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1LjYzNjombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FsbGVkIFBhcnR5
IE51bWJlciBpID0gMHhBMSwgJzMwMzIwMTEwMDEnLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPlBsYW46SVNETiwgVHlwZTpOYXRpb25hbDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUyOiAweDYyMjFFMTFDIDogU3Rh
dGUgY2hhbmdlIGZyb20gKFNUQVRFX05PTkUsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+U1VCU1RBVEVfTk9ORSkmbmJzcDsgdG8gKFNUQVRFX0lETEUsIFNVQlNUQVRFX05P
TkUpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42NTI6Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJUCBTUEkgOiBTSVBTUElfRVZfQ0NfQ0FM
TF9TRVRVUDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDUuNjUyOiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgYWN0X2lkbGVfY2FsbF9zZXR1cDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUy
OiZuYnNwOyBhY3RfaWRsZV9jYWxsX3NldHVwOk5vdCB1c2luZyBWb2ljZSBDbGFzcyBDb2RlYzwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0
OjA1LjY1MjogYWN0X2lkbGVfY2FsbF9zZXR1cDogcHJlZmVycmVkX2NvZGVjIHNldFswXSB0eXBl
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Omc3MTF1bGF3IGJ5dGVzOiAx
NjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1
LjY1MjombmJzcDsgUXVldWVkIGV2ZW50IGZyb20gU0lQIFNQSSA6PC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+U0lQU1BJX0VWX0NSRUFURV9DT05ORUNUSU9OPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTI6IDB4NjIy
MUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RBVEVfSURMRSw8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5TVUJTVEFURV9OT05FKSZuYnNwOyB0byAoU1RBVEVfSURMRSwg
U1VCU1RBVEVfQ09OTkVDVElORyk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij4qSmFuIDIyIDA4OjM0OjA1LjY1MjogMHg2MjIxRTExQyA6IFN0YXRlIGNoYW5nZSBmcm9tIChT
VEFURV9JRExFLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlNVQlNUQVRF
X0NPTk5FQ1RJTkcpJm5ic3A7IHRvIChTVEFURV9JRExFLCBTVUJTVEFURV9DT05ORUNUPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU5HKTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUyOiBDQ1NJUC1TUEktQ09OVFJP
TDombmJzcDsgYWN0X2lkbGVfY29ubmVjdGlvbl9jcmVhdGVkPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTI6IENDU0lQLVNQSS1DT05UUk9M
OiZuYnNwOyBhY3RfaWRsZV9jb25uZWN0aW9uX2NyZWF0ZWQ6PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q29ubmlkKDEpIGNyZWF0ZWQgdG8gMTkyLjE2OC4xMC4xMTQ6NTA2
MCwgbG9jYWxfcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm9ydCA1MDcy
NzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUu
NjU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJT3V0Z29pbmdDYWxsU0RQPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTY6IHNp
cFNQSUFkZExvY2FsQ29udGFjdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PipKYW4gMjIgMDg6MzQ6MDUuNjU2OiZuYnNwOyBRdWV1ZWQgZXZlbnQgZnJvbSBTSVAgU1BJIDog
U0lQU1BJX0VWX1NFTkRfTUVTU0FHRTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPipKYW4gMjIgMDg6MzQ6MDUuNjU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwX3N0
YXRzX21ldGhvZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIg
MDg6MzQ6MDUuNjU2OiAweDYyMjFFMTFDIDogU3RhdGUgY2hhbmdlIGZyb20gKFNUQVRFX0lETEUs
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U1VCU1RBVEVfQ09OTkVDVElO
RykmbmJzcDsgdG8gKFNUQVRFX1NFTlRfSU5WSVRFLCBTVUJTVEFURV88L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OT05FKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjYwOiBJU0ROIFNlMDoyMzogVFggLSZndDsmbmJz
cDsgQ0FMTF9QUk9DIHBkID0gOCZuYnNwOyBjYWxscmVmID0gMHg4MDAxPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NjA6Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYW5uZWwgSUQgaSA9IDB4QTk4
MzgxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42NjA6IFNlbnQ6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU5WSVRF
IHNpcDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUgU0lQLzIuMDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAmbmJzcDsgMTky
LjE2OC42Ni4xODQ6NTA3Mjc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5G
cm9tOiAmcXVvdDsyMDYyMDExMDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2
LjE4NCZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3Np
cDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGF0ZTogU2F0LCAyMiBKYW4gMjAwMCAwMTozNDowNSBH
TVQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5DYWxsLUlEOiBFQkIwNDM3
Qi1DMEE1MEE2MS0wLTZERkM0MDU4QDE5Mi4xNjguNjYuMTg0PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q2lzY28tR3VpZDogMzk1NDE5NzM3MS0zMjMyMDQxNTY3LTAtMTg0
NTI0ODA3NjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlVzZXItQWdlbnQ6
IENpc2NvIFNJUCBHYXRld2F5IChVQUMpL0lPUyAxMi54PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+Q1NlcTogMTAxIElOVklURTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPk1heC1Gb3J3YXJkczogNjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPlRpbWVzdGFtcDogOTQ4NTMwMDQ1PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Q29udGFjdDogJmx0O3NpcDoyMDYyMDExMDAxQDE5Mi4xNjguNjYuMTg0OjUw
NjA7dXNlcj1waG9uZSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5F
eHBpcmVzOiAxODA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL3NkcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPkNvbnRlbnQtTGVuZ3RoOiAxMzg8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+dj0wPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+bz1D
aXNjb1N5c3RlbXNTSVAtR1ctVXNlckFnZW50IDc2NTYgOTI4OCBJTiBJUDQgMTkyLjE2OC42Ni4x
ODQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5zPVNJUCBDYWxsPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Yz1JTiBJUDQgMTkyLjE2OC42Ni4xODQ8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50PTAgMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm09YXVkaW8gMjA0OTIgUlRQL0FWUCAwPC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcy
OiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4w
IDEwMCBUcnlpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5WaWE6IFNJ
UC8yLjAvVURQJm5ic3A7IDE5Mi4xNjguNjYuMTg0OjUwNzI3PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+RnJvbTogJnF1b3Q7MjA2MjAxMTAwMSZxdW90OyAmbHQ7c2lwOjIw
NjIwMTEwMDFAMTkyLjE2OC42Ni4xODQmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+VG86ICZsdDtzaXA6MzAzMjAxMTAwMUAxOTIuMTY4LjEwLjExNDt1c2VyPXBob25l
Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkNhbGwtSUQ6IEVCQjA0
MzdCLUMwQTUwQTYxLTAtNkRGQzQwNThAMTkyLjE2OC42Ni4xODQ8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5DU2VxOiAxMDEgSU5WSVRFPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q29udGVudC1MZW5ndGg6IDA8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8
QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6
IEhhbmRsZVVkcFNvY2tldFJlYWRzIDpNc2cgZW5xdWV1ZWQgZm9yIFNQSSB3aXRoPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SVBhZGRyOiAxOTIuMTY4LjEuMTE0OjM0MDUw
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42
NzI6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBhY3Rfc2VudGludml0ZV9uZXdfbWVzc2FnZTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcy
OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJQ2hlY2tSZXNwb25zZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcyOiBDQ1NJUC1T
UEktQ09OVFJPTDombmJzcDsgc2lwX3N0YXRzX3N0YXR1c19jb2RlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6Jm5ic3A7IFJvdW5kdHJp
cCBkZWxheSAxNiBtaWxsaXNlY29uZHMgZm9yIG1ldGhvZCBJTlZJVEU8L0ZPTlQ+DQo8L1A+DQoN
CjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6IDB4NjIy
MUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RBVEVfU0VOVF9JTlZJVEUsPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U1VCU1RBVEVfTk9ORSkmbmJzcDsgdG8gKFNUQVRF
X1JFQ0RfUFJPQ0VFRElORywgU1VCUzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPlRBVEVfUFJPQ0VFRElOR19QUk9DRUVESU5HKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuODUyOiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4wIDE4MCBSaW5naW5nPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjY2LjE4
NDo1MDcyNzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZyb206ICZxdW90
OzIwNjIwMTEwMDEmcXVvdDsgJmx0O3NpcDoyMDYyMDExMDAxQDE5Mi4xNjguNjYuMTg0Jmd0Ozwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvOiAmbHQ7c2lwOjMwMzIwMTEw
MDFAMTkyLjE2OC4xMC4xMTQ7dXNlcj1waG9uZSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5EYXRlOlNhdCwgMjIgSmFuIDIwMDAgMDg6MzM6NTAgR01UPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q2FsbC1JRDogRUJCMDQzN0ItQzBBNTBBNjEt
MC02REZDNDA1OEAxOTIuMTY4LjY2LjE4NDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPlRpbWVzdGFtcDo5NDg1MzAwNDU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5TZXJ2ZXI6Q2lzY28gU0lQIEdhdGV3YXkgKFVBUykvSU9TIDEyLng8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5DU2VxOiAxMDEgSU5WSVRFPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q29udGVudC1MZW5ndGg6IDA8L0ZPTlQ+DQo8L1A+
DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODoz
NDowNS44NTY6IEhhbmRsZVVkcFNvY2tldFJlYWRzIDpNc2cgZW5xdWV1ZWQgZm9yIFNQSSB3aXRo
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SVBhZGRyOiAxOTIuMTY4LjEu
MTE0OjM0MDUwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAw
ODozNDowNS44NTY6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBhY3RfcmVjZHByb2NfbmV3X21l
c3NhZ2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0
OjA1Ljg1NjogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IHNpcFNQSUNoZWNrUmVzcG9uc2U8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1Ljg1Njog
Q0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IHNpcF9zdGF0c19zdGF0dXNfY29kZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuODU2OiZuYnNwOyBS
b3VuZHRyaXAgZGVsYXkgMjAwIG1pbGxpc2Vjb25kcyBmb3IgbWV0aG9kIElOVklURTwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1Ljg1
NjogSGFuZGxlU0lQMXh4UmluZ2luZyBObyBTRFAgQm9keSBpbiAxODAgUklOR0lORyAtIHdvdWxk
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d2FpdCBmb3IgMjAwT0sgdG8g
ZG8gbmVnb3RpYXRpb24uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPipKYW4gMjIgMDg6MzQ6MDUuODU2OiBIYW5kbGVTSVAxeHhSaW5naW5nOiBNZWRpYU5lZ290
aWF0aW9uIGV4cGVjdGVkIGluIDIwMDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPk9LPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDUuODU2OiAweDYyMjFFMTFDIDogU3RhdGUgY2hhbmdlIGZyb20gKFNUQVRFX1JF
Q0RfUFJPQ0VFRElORyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TVUJT
VEFURV9QUk9DRUVESU5HX1BST0NFRURJTkcpJm5ic3A7IHRvIChTVEFURV88L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SRUNEX1BST0NFRURJTkcsIFNVQlNUQVRFX1BST0NF
RURJTkdfQUxFUlRJTkcpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Kkph
biAyMiAwODozNDowNS44NTY6IElTRE4gU2UwOjIzOiBUWCAtJmd0OyZuYnNwOyBBTEVSVElORyBw
ZCA9IDgmbmJzcDsgY2FsbHJlZiA9IDB4ODAwMTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzU2OiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4wIDIwMCBPSzwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAgMTkyLjE2OC42Ni4xODQ6NTA3Mjc8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Gcm9tOiAmcXVvdDsyMDYyMDEx
MDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2LjE4NCZndDs8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3NpcDozMDMyMDExMDAxQDE5Mi4x
NjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7O3RhZz02REZDMkM1OC04MjA8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5EYXRlOlNhdCwgMjIgSmFuIDIwMDAgMDg6MzM6NTAgR01U
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q2FsbC1JRDogRUJCMDQzN0It
QzBBNTBBNjEtMC02REZDNDA1OEAxOTIuMTY4LjY2LjE4NDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlRpbWVzdGFtcDo5NDg1MzAwNDU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5TZXJ2ZXI6Q2lzY28gU0lQIEdhdGV3YXkgKFVBUykvSU9TIDEyLng8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250YWN0OiZsdDtzaXA6MzAz
MjAxMTAwMUAxOTIuMTY4LjY3LjE4Njo1MDYwO3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVjb3JkLVJvdXRlOiZsdDtzaXA6MzAzMjAxMTAwMUBl
YXN0LmM1MzAwNS5jb206NTA3MDttYWRkcj0xOTIuMTY4LjEwLjE0MTt0cmFuczwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnBvcnQ9dWRwJmd0OzwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJlY29yZC1Sb3V0ZTombHQ7c2lwOjMwMzIwMTEwMDFAMTky
LjE2OC4xMC4xMTQ6NTA2MDt1c2VyPXBob25lO21hZGRyPTE5Mi4xNjguMTA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4uMTQxO3RyYW5zcG9ydD11ZHAmZ3Q7PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q1NlcTogMTAxIElOVklURTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkNvbnRlbnQtVHlwZTphcHBsaWNhdGlvbi9zZHA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250ZW50LUxlbmd0aDogMTI2
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U2Vzc2lvbi1FeHBpcmVzOjMw
MDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj52PTA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vPUNpc2NvU3lzdGVtc1NJUC1HVy1Vc2Vy
QWdlbnQgNjU2NSAzOTYwIElOIElQNCAxMC4xLjEuMjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPnM9U0lQIENhbGw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj50PTAgMDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm09YXVkaW8g
NDAzNiBSVFAvQVZQIDA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jPUlO
IElQNCAyMDkuNi4wLjI8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiBOb3RlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk5v
dGUgdGhhdCB0aGUgcmVjb3JkIHJvdXRlIGhlYWRlcjo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVjb3JkLVJvdXRlOiZsdDtzaXA6MzAzMjAxMTAwMUAxOTIu
MTY4LjEwLjExNDo1MDYwO3VzZXI9cGhvbmU7bWFkZHI9MTkyLjE2OC4xMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi4xNDE7dHJhbnNwb3J0PXVkcCZndDs8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IGlzIHRoZSBvbmUgdGhh
dCBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIHN1YnNlcXVlbnQgQUNLLjwvRk9OVD4NCjwvUD4NCjxC
Uj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4
OjM0OjA2LjM1NjogSGFuZGxlVWRwU29ja2V0UmVhZHMgOk1zZyBlbnF1ZXVlZCBmb3IgU1BJIHdp
dGg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JUGFkZHI6IDE5Mi4xNjgu
MS4xMTQ6MzQwNTA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIy
IDA4OjM0OjA2LjM1NjogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IGFjdF9yZWNkcHJvY19uZXdf
bWVzc2FnZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDYuMzU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJQ2hlY2tSZXNwb25zZTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYw
OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwX3N0YXRzX3N0YXR1c19jb2RlPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6Jm5ic3A7
IFJvdW5kdHJpcCBkZWxheSA3MDQgbWlsbGlzZWNvbmRzIGZvciBtZXRob2QgSU5WSVRFPC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzYwOiBzaXBTUElHZXRTZHBCb2R5IDogUGFyc2UgaW5jb21pbmcgc2Vzc2lvbiBkZXNjcmlwdGlv
bjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzYwOiBzaXBTUElDb21wYXJlUmVzcE1lZGlhSW5mbyBObyBDb21wYXJzaW9uIG5lZWRlZCBhcyAx
OHg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5tZXNzYWdlcyBkaWQgbm90
IGhhdmUgU0RQPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAw
ODozNDowNi4zNjA6IHNpcFNQSURvTWVkaWFOZWdvdGlhdGlvbjogQ29kZWMgTmVnb3RpYXRpb24g
U3VjY2Vzc2Z1bDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4q
SmFuIDIyIDA4OjM0OjA2LjM2MDogc2lwU1BJVXBkQ2NiV2l0aFNkcEluZm86IFNEUCBNZWRpYSBJ
bmZvcm1hdGlvbjo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OZWdvdGlh
dGVkIENvZGVjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZzcxMXVsYXcgLCBieXRl
cyA6MTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RWFybHkgTWVkaWEm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGVsYXllZCBNZWRp
YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5CcmlkZ2UgRG9uZSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OZXcgTWVkaWEmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RFNQIEROTEQgUmVx
ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5NZWRpYSBEZXN0IGFkZHIvUG9ydCZu
YnNwOyA6IDIwOS42LjAuMjo0MDM2PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYwOiBzaXBTUElQcm9jZXNzTWVkaWFDaGFuZ2Vz
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4z
NjA6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBzaXBTUElSZWNvbm5lY3RDb25uZWN0aW9uPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6
Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJUCBTUEkgOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlNJUFNQSV9FVl9SRUNPTk5FQ1RfQ09OTkVDVElPTjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYwOiBDQ1NJUC1T
UEktQ09OVFJPTDombmJzcDsgc2lwU1BJUHJvY2VzczIwME9LZm9yaW52aXRlPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IENDU0lQLVNQ
SS1DT05UUk9MOiZuYnNwOyBzaXBTUElBZGRSb3V0ZUhlYWRlcnMgc3RhdHVzID08L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UUlVFIFJvdXRlICZsdDtzaXA6MzAzMjAxMTAw
MUBlYXN0LmM1MzAwNS5jb206NTA3MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPjttYWRkcj0xOTIuMTY4LjEwLjE0MSZndDssICZsdDtzaXA6MzAzMjAxMTAwMUAxOTIuMTY4
LjY3LjE4Njo1MDYwO3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJ
UCBTUEkgOiBTSVBTUElfRVZfU0VORF9NRVNTQUdFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNw
OyBzaXBfc3RhdHNfbWV0aG9kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
KkphbiAyMiAwODozNDowNi4zNjA6IDB4NjIyMUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RB
VEVfUkVDRF9QUk9DRUVESU5HLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PlNVQlNUQVRFX1BST0NFRURJTkdfQUxFUlRJTkcpJm5ic3A7IHRvIChTVEFURV9BQzwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRJVkUsIFNVQlNUQVRFX05PTkUpPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IFRo
ZSBDYWxsIFNldHVwIEluZm9ybWF0aW9uIGlzIDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDsgQ2FsbCBDb250cm9sIEJsb2NrIChDQ0IpIDogMHg2MjIxRTExQzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBTdGF0ZSBvZiBUaGUg
Q2FsbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFNUQVRFX0FD
VElWRTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBUQ1AgU29j
a2V0cyBVc2VkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDogTk88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgQ2FsbGlu
ZyBOdW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgOiAyMDYyMDExMDAxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Jm5ic3A7IENhbGxlZCBOdW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAzMDMyMDExMDAxPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IE5lZ290aWF0ZWQgQ29kZWMmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBnNzExdWxhdzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBOZWdvdGlhdGVkIENv
ZGVjIEJ5dGVzJm5ic3A7Jm5ic3A7IDogMTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Jm5ic3A7IE5lZ290aWF0ZWQgRHRtZi1yZWxheSZuYnNwOyZuYnNwOyZuYnNwOyA6
IDA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgU291cmNlIElQ
IEFkZHJlc3MgKE1lZGlhKTogMTkyLjE2OC42Ni4xODQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsgU291cmNlIElQIFBvcnQmbmJzcDsmbmJzcDsmbmJzcDsgKE1l
ZGlhKTogMjA0OTI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsg
RGVzdG4mbmJzcDsgSVAgQWRkcmVzcyAoTWVkaWEpOiAyMDkuNi4wLjI8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgRGVzdG4mbmJzcDsgSVAgUG9ydCZuYnNwOyZu
YnNwOyZuYnNwOyAoTWVkaWEpOiA0MDM2PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Jm5ic3A7IERlc3RuIFNJUCBSZXEgQWRkcjpQb3J0Jm5ic3A7IDogMTkyLjE2OC4xMC4x
NDE6NTA2MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBEZXN0
biBTSVAgUmVzcCBBZGRyOlBvcnQgOiAwLjAuMC4wOjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsgRGVzdGluYXRpb24gTmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE5Mi4xNjguMTAuMTE0PC9GT05UPg0KPC9Q
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzY0OiBI
YW5kbGVVZHBSZWNvbm5lY3Rpb246IFVkcCBzb2NrZXQgY29ubmVjdGVkIGZvciBmZDogMTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPndpdGggMTkyLjE2OC4xMC4xNDE6NTA2
MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzY0OiBTZW50OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFDSyBzaXA6
MzAzMjAxMTAwMUAxOTIuMTY4LjEwLjE0MTo1MDYwO3VzZXI9cGhvbmUgU0lQLzIuMDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAmbmJzcDsgMTky
LjE2OC42Ni4xODQ6NTA3Mjc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5G
cm9tOiAmcXVvdDsyMDYyMDExMDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2
LjE4NCZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3Np
cDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7O3RhZz02REZDMkM1OC04
MjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5EYXRlOiBTYXQsIDIyIEph
biAyMDAwIDAxOjM0OjA1IEdNVDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PkNhbGwtSUQ6IEVCQjA0MzdCLUMwQTUwQTYxLTAtNkRGQzQwNThAMTkyLjE2OC42Ni4xODQ8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Sb3V0ZTogJmx0O3NpcDozMDMyMDEx
MDAxQGVhc3QuYzUzMDA1LmNvbTo1MDcwO21hZGRyPTE5Mi4xNjguMTAuMTQxJmd0Oyw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbHQ7c2lwOjMwMzIwMTEwMDFAMTkyLjE2
OC42Ny4xODY6NTA2MDt1c2VyPXBob25lJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPk1heC1Gb3J3YXJkczogNjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPkNvbnRlbnQtTGVuZ3RoOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Q1NlcTogMTAxIEFDSzwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogTm90
ZSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlJlcXVlc3QtVVJJIGluIGFib3ZlIEFDSyBoYXMgZG9tYWluIG9m
IDE5Mi4xNjguMTAuMTQxLCBzaG91bGQgaGF2ZSBiZWVuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+MTkyLjE2OC4xMC4xMTQgd2hlbiB0aGUgcmVjb3JkLXJvdXRlIHdhcyB0
dXJuZWQgaW50byBhIFJvdXRlIGhlYWRlciw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5yZW1vdmVkLCBhbmQgdXNlZCBhcyB0aGUgUmVxdWVzdC1VUkkuPC9GT05UPg0KPC9Q
Pg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDYuMzY0OiZuYnNwOyBzaXBTUElSdGNwVXBkYXRlcyBObyBydHAgc2Vzc2lvbiBp
biBicmlkZ2UsIGNyZWF0ZSBhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
bmV3IG9uZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFu
IDIyIDA4OjM0OjA2LjM2NDogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IGNjc2lwX2NhcHNfaW5k
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4z
NjQ6IGNjc2lwX2dldF9ydGNwX3Nlc3Npb25fcGFyYW1ldGVyczogQ1VSUkVOVCBWQUxVRVM6PC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Y2NDYWxsSUQ9MTI3NiwgY3VycmVu
dF9zZXFfbnVtPTB4MjE3QzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipK
YW4gMjIgMDg6MzQ6MDYuMzY0OiBjY3NpcF9nZXRfcnRjcF9zZXNzaW9uX3BhcmFtZXRlcnM6IE5F
VyBWQUxVRVM6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Y2NDYWxsSUQ9
MTI3NiwgY3VycmVudF9zZXFfbnVtPTB4OUVDPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjQ6IGNjc2lwX2NhcHNfaW5kOiBMb2FkIERTUCB3
aXRoIG5lZ290aWF0ZWQgY29kZWMgOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPmc3MTF1bGF3LCBCeXRlcz0xNjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj4qSmFuIDIyIDA4OjM0OjA2LjM2ODogc2lwU1BJR2V0RFRNRlJlbGF5TW9kZTogc2V0IERT
UCBmb3IgZHRtZi1yZWxheSA9PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Q0NfQ0FQX0RUTUZfUkVMQVlfSU5CQU5EX1ZPSUNFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjg6IGNjc2lwX2NhcHNfaW5kOiBMb2FkIERT
UCB3aXRoIGNvZGVjIDogZzcxMXVsYXcsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Qnl0ZXM9MTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Kkph
biAyMiAwODozNDowNi4zNjg6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBjY3NpcF9jYXBzX2Fj
azwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzcyOiBJU0ROIFNlMDoyMzogVFggLSZndDsmbmJzcDsgQ09OTkVDVCBwZCA9IDgmbmJzcDsgY2Fs
bHJlZiA9IDB4ODAwMTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDYuMzcyOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBQcm9ncmVzcyBJbmQgaSA9IDB4ODE4MiAtIERlc3RpbmF0aW9uIGFkZHJlc3M8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5pcyBub24tSVNETjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzg4OiBJU0ROIFNl
MDoyMzogUlggJmx0Oy0mbmJzcDsgQ09OTkVDVF9BQ0sgcGQgPSA4Jm5ic3A7IGNhbGxyZWYgPTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjB4MDAwMTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzg4OiBJU0ROIFNlMDoy
MzogQ0FMTF9QUk9HUkVTUzogQ0FMTF9DT05ORUNURUQgY2FsbCBpZDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPjB4MjI3LCBiY2hhbiAwLCBkc2wgMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjN3MGQ6ICVJU0ROLTYtQ09OTkVDVDogSW50ZXJmYWNl
IFNlcmlhbDA6MCBpcyBub3cgY29ubmVjdGVkIHRvIDIwNjIwMTEwMDE8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jNTMwMC0zIzwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3M8L0ZPTlQ+DQo8L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U0c8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGlz
IGxpc3QgaXMgZm9yIGNvbnRpbnVpbmcgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbC48
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgc2lwLWltcGxlbWVudG9y
J3MgbGlzdCBpcyB0aGUgcGxhY2UgdG8gZGlzY3VzcyBpbXBsZW1lbnRhdGlvbiw8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5hbmQgdG8gcmVjZWl2ZSBhZHZpY2Ugb24gdW5k
ZXJzdGFuZGluZyBleGlzdGluZyBzaXAuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+VG8gc3Vic2NyaWJlIHRvIGl0LCBzZW5kIG1haWwgdG88L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5zaXAtaW1wbGVtZW50b3JzLXJlcXVlc3RAY3MuY29sdW1iaWEu
ZWR1IHdpdGggJnF1b3Q7c3Vic2NyaWJlJnF1b3Q7IGluIHRoZSBib2R5LjwvRk9OVD4NCjwvUD4N
CjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPlRoaXMgbGlzdCBpcyBmb3IgY29udGludWluZyBkZXZlbG9wbWVudCBvZiB0aGUg
U0lQIHByb3RvY29sLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZSBz
aXAtaW1wbGVtZW50b3IncyBsaXN0IGlzIHRoZSBwbGFjZSB0byBkaXNjdXNzIGltcGxlbWVudGF0
aW9uLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmFuZCB0byByZWNlaXZl
IGFkdmljZSBvbiB1bmRlcnN0YW5kaW5nIGV4aXN0aW5nIHNpcC48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5UbyBzdWJzY3JpYmUgdG8gaXQsIHNlbmQgbWFpbCB0byA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5zaXAtaW1wbGVtZW50b3JzLXJlcXVl
c3RAY3MuY29sdW1iaWEuZWR1IHdpdGggJnF1b3Q7c3Vic2NyaWJlJnF1b3Q7IGluIHRoZSBib2R5
LjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg==

--0__=RKSQABsvzPHdckvq0q5BlbjFWpznzbRNSad6M2yMQRAiQzwwWopufi1y
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Content-Type: multipart/alternative;
boundary="----_=_NextPart_003_01C0C40C.43A8EE10"



------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/plain;
     charset="iso-8859-1"

Folks,

I took a stab at the new text for record routing. Its much, much more
verbose than rfc2543, and hopefully, as a result, will make it much clearer
what you need to do. Record-routing remains one of the most oft
misimplemnted features. This text incorporates everything in rfc2543 plus
all the decisions we've made on the list along the way. As you can see, the
structure is much more processing focused, rather than syntactic focused,
and much more explicit as well.

The text is in latex format. If you don't know latex, you should be able to
ignore all the slashes and brackets and still get the idea.

Please comment; alternate text related to those comments is requested.

-Jonathan R.




\section{Record-Routing}
\label{sec:rr}

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
\header{Record-Route} into the initial \INVITE request that begins the
call leg. The user agents use these headers to construct a set of
\header{Route} headers, that gets inserted into subsequent requests in
the call leg. The \header{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.

All user agents \MUST support the processing rules below which apply
to them. As such, they \MUST be able to parse and process both
\header{Record-Route} and \header{Route} headers. Proxies \MAY support
the record routing procedures of Section \ref{sec:rr:proxy}, but they
\MUST support the route header procedures of Section{sec:rr:proxy2}.

\motivation{This is a change from RFC2543, where all record-route and
route processing was optional for user agents.}

The syntax for the \header{Route} header is described in Section
XXX. The syntax for the \header{Record-Route} header is described in
Section XXX.

\subsection{UAC Processing for initial \INVITE transaction}
\label{sec:rr:uac}

The UAC formulates its {\em initial} \INVITE request for the call leg
as defined in section XXX. If the final response is a 200 class
response, it may contain \header{Record-Route} headers, and may
contain a \header{Contact} header. \annotate{Contact was not mandatory
in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might
not insert the \header{Contact} header. Thats why this text says that
the \header{Contact} may be present in the response. Note also that
this may is lower case; it is NOT saying that a UAS can optionally
insert the \header{Contact} header into the 200 class response.} The
UAC \MUST construct a {\em route set}, defined as a list of URLs, in
the following manner:

\begin{enumerate}
\item The list of URIs present in the \header{Record-Route} headers in
the 200 class response are taken, if present, and their order is reversed.
\item The URI in the \header{Contact} header from the 200 class response, if
present, is taken, and appended to the end of the list from the
previous step.
\item The list of URIs resulting from the above two operations is
referred to as the {\em route set}.
\end{enumerate}

The UAC \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the 200 class response. NOTE that since there
may be multiple 200 OK responses to an \INVITE request, each response
constitutes a separate call leg, and thus has a separate route
set. The UAC \MUST also remember whether the bottom-most entry in the
route set was constructed from a \header{Contact} header or not. This
is effectively a boolean value, which we refer to as CONTACT_SET.

The \ACK request for the initial \INVITE transaction \MUST be
formulated according to the rules of Section XXX, as if it were a
subsequent request within the call leg.

OPEN-ISSUE: Handling for non-200 responses, including provisionals
and certain 400 class responses. Are we supporting record-routing for
non-200 class responses? Record-routing for provisional responses is
discussed in the 100rel spec. What needs to be said here?

\subsection{UAS Processing of initial \INVITE transaction}
\label{sec:rr:uas}

When a UAS receives an \INVITE for a new call leg, and it responds
with a 200 class response, it \MUST copy the contents of the
\header{Record-Route} headers from the request to the response. This
includes the URIs, URI parameters, and any \header{Record-Route}
header parameters, whether they are known or unknown to the
UAS. \annotate{Record-Route parameters are very useful for
proxies. They allow the proxy to match the record-route entry in the
response with the one in the request.} The
order of the \header{Record-Route} headers \MUST be preserved in the
response.

The UAS \MUST construct a {\em route set} in the following manner:

\begin{enumerate}
\item The list of URIs in the \header{Record-Route} headers in the
\INVITE request, if present, are taken, including any URI parameters.
\item The URI in the \header{Contact} header from the request, if present,
is
taken, including any URI parameters. The URI is appended to the bottom
of the list of URIs from the previous step.
\item The resulting list of URIs is called the {\em route set}.
\end{enumerate}

The UAS \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the \INVITE request. The UAS \MUST also
remember whether the bottom-most entry in the route set was
constructed from a \header{Contact} header or not. This is effectively
a boolean value, which we refer to as CONTACT_SET.

OPEN ISSUE: this new text does not have the record-routes copied into
non-200 responses. RFC2543 talks about other failure codes, but is not
specific enough. Do we really need them in other response codes? If
so, we must list them explicitly.

\subsection{Proxy processing of an initial \INVITE transaction}
\label{sec:rr:proxy}

Each proxy \MAY independently decide to record-route an initial
\INVITE transaction. For a proxy, {\em initial} is defined
as any \INVITE request that does not contain a \header{Route}
header. Generally, the choice about whether to record-route or not is
a tradeoff of features vs. performance. Faster call processing and
higher scalability is achieved when proxies do not record
route. However, provision of certain services may require a proxy to
observe all messages for a call leg. It is \RECOMMENDED that proxies
do not automatically record route. They should do so only if
specifically required.

To record-route, the proxy inserts a \header{Record-Route} header into
the request before proxying it onwards. A forking proxy \MAY insert a
different \header{Record-Route} header into each forked request. The
\header{Record-Route} header that it inserts \MUST be inserted as the
first \header{Record-Route} header, appearing before any existing ones
in the request. The URL in the header \MUST be a SIP
URL. \annotate{This is because the URLs in the Record-Route headers
are used for forwarding requests by other proxies. Since no other URL
but a SIP URL is mandatory, a proxy could not be sure that any other
URL is interpretable by other proxies. Thus, SIP URLs are
mandatory}. The URL \MUSTNOT contain the transport
parameter. \annotate{Thats because only UDP is mandatory. If a proxy
inserts a transport parameter in the URL with TCP or TLS as the
transport, the proxy that ends up using that URL to forward the
request might not support that transport. The result, according to the
``Locating a SIP Server'' procedure, would be for the proxy to give
up.} The URL \MUST have the property that when the processing
described in Section XXX ``locaing a SIP server'' is followed for that
URL, the result of the lookup is an address/port of the proxy server
inserting the
\header{Record-Route}. The URL and the proxy configuration \SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to one of the previous-hop servers that the initial
\INVITE request traversed, including the UAS. \annotate{These two
properties are
important. The first one guarantees that subsequent requests from the
called party are routed back to this actually proxy. The second property is
there for robustness. It guarantees that the request URI always
contain meaningful information, even if there are no \header{Route}
headers that tell the proxy where to forward the request to next.} The
proxy \MAY insert
\header{Record-Route} parameters into the request. These will be
returned to the proxy in any 200 class response to the \INVITE, and
are useful for pushing state into the message.

If a 200 class response arrives for a proxied request, the response
will contain the entire list of \header{Record-Route} headers inserted
by proxies along the request path. The proxy \MAY modify the
\header{Record-Route} value matching the one it inserted into the
request. Like the URL in the request, it \MUST be a SIP URL and
\MUSTNOT contain a transport parameter. The URL in this
\header{Record-Route} header \MUST have the
property that when the processing described in Section XXX ``locating
a SIP server'' is followed for that URL, the result of the lookup is
an address/port of the proxy server that inserted the
\header{Record-Route}. The URL in this header, and the proxy configuration
\SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to the same next hop server that the initial
\INVITE request was forwarded to.

The four properties (two for the request, two for the response), can
be satisfied in a number of ways. One way is that the URI inserted
into the \header{Record-Route} in the request is the same as the
\header{Contact} header in the \INVITE (if present, else the
\header{From} field), but with the maddr and port set to
resolve to the proxy. Then, the proxy modifies the URL in the
\header{Record-Route} header in the response, setting it to be the URL
from the \header{Request-URI} of the initial \INVITE, but with the maddr
and port set to resolve to the proxy.

As an example, consider a proxy at 10.0.1.1 listening on port 5061
which receives the following request (many headers are omitted for
brevity):

\begin{verbatim}
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP callerspc.univ.edu
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The proxy forwards this request to
\header{sip:j_user@div11.example.com}, and record-routes:

\begin{verbatim}
INVITE sip:j_user@div11.example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The 200 response will look like, in part:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The proxy modifies its \header{Record-Route} header in the response to
and forwards the request upstream:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 ;myparam=9877
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The route set computed by the UAS is:

\begin{verbatim}
sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1
sip:caller@callerspc.univ.edu
\end{verbatim}

and the route set computed by the UAC is:

\begin{verbatim}
sip:j_user@example.com:5061;maddr=10.0.1.1
sip:j_user@host32.div11.example.com
\end{verbatim}

There are other ways to meet these requirements. The proxy could
construct a URL for the request which encodes all of the needed
information, by placing it in the user portion, for example. A call
stateful proxy could insert a URL into the request with the form
sip:proxy.example.com, and not modify it in the response. This URL
clearly satisfies the first required property (of getting routed back
to the proxy that inserted it). The second property can be maintained
by being call stateful, and extracting the needed parameters from
local storage.

When a proxy does decide to modify the \header{Record-Route} header in
the response, one of the operations it must perform is to locate the
\header{Record-Route} that it had inserted. If the request spiraled,
and the proxy inserted a \header{Record-Route} in each iteration of
the spiral, locating the correct header in the response (which must be
the proper iteration in the reverse direction) is tricky. One
mechanism that is \RECOMMENDED is for the proxy to insert a
\header{Record-Route} parameter into the new \header{Record-Route} header
in the request each time the request spirals. This parameter \MUST
uniquely identify the proxy. When the 200 class respone arrives, the
proxy looks for the topmost \header{Record-Route} header containing
this parameter. This header is the one for the current iteration. The
proxy \MUST remove this parameter before forwarding the response
upstream. Upon the next iteration, the same algorithm (find the
topmost \header{Record-Route} header with the parameter) will
correctly extract the next \header{Record-Route}
header.


\subsection{UA Processing of Subsequent Requests in a Call Leg}
\label{sec:rr:uasubsequent}

When a UA wishes to send another request for the call-leg (such as a
\header{BYE} or \header{INVITE}), it follows the procedures defined in
this subsection. The
procedures here \MUST also be followed for an \ACK request for a 200
response to the initial \INVITE for the call leg. The procedures here
\MUSTNOT be followed for a \CANCEL request or an \ACK request for a
non-200 response. This implies that \CANCEL never contains a
\header{Route} header, nor does an \ACK for a non-200 response.

The request is constructed as specified in Section XXX. 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 any
URI parameters, are placed into a \header{Route} header into the request,
in order. The procedures of Section XXX ``locating a SIP server'' are
then applied to the URI in the request URI, the the request is
forwarded to the resulting server.

If a UAS has a route set for a call leg, and receives a re-INVITE for
that call leg containing \header{Record-Route} headers, it \MUST copy
those headers into any 200 class response to that request. If the
boolean variable CONTACT_SET is true, the \header{Contact} header in
the re-INVITE (if present) replaces the last
entry in the route set. If the boolean variable CONTACT_SET is false,
the UAS \MUST add the URL in the
\header{Contact} header in the re-INVITE to the bottom of the route
set, and then set CONTACT_SET to true. If the re-INVITE did not
contain a \header{Contact} header, the route-set at the UAS remains
unchanged.

Similarly, if a UAC has a route set for a call leg, and receives a 200
class response to a re-INVITE it sent, the \header{Contact} header is
examined. If not present, the route set remains unchanged. If the
re-INVITE response had a \header{Contact} header, and the boolean
variable CONTACT_SET is false, the URL in the \header{Contact} header
in the response is added to the bottom of the route set, and
CONTACT_SET is set to true. If the re-INVITE response had a
\header{Contact} header, and CONTACT_SET is true, the URL in the
\header{Contact} header of the re-INVITE response replaces the bottom
value in the route set.

The above two paragraphs allow a UA to update its \header{Contact}
address mid-call, but proxies cannot update their route address.  Once
on the route, a proxy remains on the route for the duration of the
call leg. \annotate{Why the different treatment for Contact and
Record-Route in a re-INVITE? It has to do with backwards
compatibility. RFC2543 did not mandate that a proxy needs to refresh
its record-route headers. As a result, the lack of a record-route in a
re-INVITE cannot be interpreted to mean that the proxy does not want
to be included on the route any longer. Updating of the Contact header
mid-call is useful for mobility applications, and is also useful for
forms of third party call control}.


OPEN-ISSUE: should the UA remove the maddr param, if present, if the
request is sent to the server at that maddr?

OPEN-ISSUE: should we mention handling of route with local outbound
proxies here? RFC2543 has some text on DNS-less UAs, but there are
issues with this.

\header{Proxy processing of a non-initial request}
\label{sec:rr:proxy2}

The rules in this section \MUST be followed when a proxy receives a request
that contains a \header{Route} header. The \header{Route} header is
used to forward the request to the next hop. It \MUST override any other
routing decisions that the proxy would otherwise make. Proxies \MAY
respond to requests with \header{Route} headers for any reason (in order
to perform proxy authorization, for example). But, if the request is
proxied, the procedures here \MUST be used to determine where the
request is proxied to. The procedures in this section apply indepedent
of the request method. They \MUST be followed even if the request
method is unknown to the proxy. \annotate{This last sentence is
really, really important. It allows for other methods, defined in the
future, to have record-routing applied to them. As an example, an
instant messaging session run over SIP might begin with a MESSAGE
request. That extension can allow for these sessions to be
record-routed by proxies that know of this extension. However, the
record-routing will only work if proxies that don't know about the
extension follow the Route headers properly. As such, supporting
\header{Route} headers for all methods, known or unknown, is very
important for a robust and future proof proxy implementation.}
Since \CANCEL can never contain
\header{Route}, these procedures never apply to \CANCEL. However, they
do apply to \ACK requests for a 200 OK response, which do contain
\header{Route} headers.

The proxy \MUST remove the top \header{Route} header from the
request. The URI from that \header{Route} \MUST be placed into the
\header{Request-URI} of the proxied request, including URI
parameters. Any URL parameters present in the top \header{Route}
header which are not allowed in the request URI \MUST be removed from
the \header{Request-URI} by the proxy. The procedures of section XXX
``Locating a SIP Server'' \MUST be followed to compute the next hop
server to forward the request to.

If the request is an \INVITE request (thus, a re-INVITE) for a call
leg that the proxy wishes to receive messages for (very likely the
case, since the request probably arrived at the proxy because the
proxy record routed in the initial \INVITE), the proxy \MUST
re-insert the
\header{Record-Route} header with the same value it placed in the
initial request. Similarly, it should modify the \header{Record-Route}
header in any 200 class response in the same way the
\header{Record-Route} header was modified in the response to the
initial \INVITE (which may be no modifications at all). The purpose of
this is twofold. First, it allows for proper record-routing in the
case of pre-loaded Route headers (see Section XXX). Secondly, it
allows for recovery from a UA crash and restart, in which case the UA
loses call state, and as a result, its route set as well. The result
is that the route set will be re-established through the
re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the
result is a robust way to recover from crashes.

\subsection{Pre-Loaded Route Headers}

Normally, a UA constructs the Route headers in a request from the
route set learned through \header{Record-Route} headers. However, in
some circumstances, it is useful for a UA to insert \header{Route}
headers into an initial \INVITE. These headers may have been learnt by
the UA through some out of bands means. When an initial \INVITE
(initial as far as the UAC and UAS are concerned) contains
\header{Route} headers, this is referred to as a ``pre-loaded
Route''. It is equivalent to strict source routing in IP. Proxies will
often not be able to distinguish this case from the case described in
Section \ref{sec:rr:proxy}, and will therefore properly use these
route headers to forward the request. If the proxies are interested in
receiving subsequent messages for the call leg, their insertion of
\header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will
establish a correct route set at both UAC and UAS. This route set may
end up being different from the pre-loaded Route used by the UAC. As
such, a UAC that inserts a pre-loaded route set \MUST follow the
procedures of Section \ref{sec:rr:uac} in processing the response to
this initial \INVITE.




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


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/html;
     charset="iso-8859-1"






[SIP] new record-route text!




Folks,




I took a stab at the new text for record routing. Its much, much
more

verbose than rfc2543, and hopefully, as a result, will make it
much clearer

what you need to do. Record-routing remains one of the most
oft

misimplemnted features. This text incorporates everything in
rfc2543 plus

all the decisions we've made on the list along the way. As you
can see, the

structure is much more processing focused, rather than
syntactic focused,

and much more explicit as well.




The text is in latex format. If you don't know latex, you should
be able to

ignore all the slashes and brackets and still get the
idea.




Please comment; alternate text related to those comments is
requested.




-Jonathan R.










\section{Record-Routing}

\label{sec:rr}




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

\header{Record-Route} into the initial \INVITE request that
begins the

call leg. The user agents use these headers to construct a set
of

\header{Route} headers, that gets inserted into subsequent
requests in

the call leg. The \header{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.




All user agents \MUST support the processing rules below which
apply

to them. As such, they \MUST be able to parse and process
both

\header{Record-Route} and \header{Route} headers. Proxies \MAY
support

the record routing procedures of Section \ref{sec:rr:proxy},
but they

\MUST support the route header procedures of
Section{sec:rr:proxy2}. 




\motivation{This is a change from RFC2543, where all
record-route and

route processing was optional for user agents.}




The syntax for the \header{Route} header is described in
Section

XXX. The syntax for the \header{Record-Route} header is
described in

Section XXX.




\subsection{UAC Processing for initial \INVITE
transaction}

\label{sec:rr:uac}




The UAC formulates its {\em initial} \INVITE request for the
call leg

as defined in section XXX. If the final response is a 200
class

response, it may contain \header{Record-Route} headers, and
may

contain a \header{Contact} header. \annotate{Contact was not
mandatory

in RFC2543. Thus, if the UAC is talking to an older UAS, the
UAS might

not insert the \header{Contact} header. Thats why this text
says that

the \header{Contact} may be present in the response. Note also
that

this may is lower case; it is NOT saying that a UAS can
optionally

insert the \header{Contact} header into the 200 class
response.} The

UAC \MUST construct a {\em route set}, defined as a list of
URLs, in

the following manner:




\begin{enumerate}

\item The list of URIs present in the \header{Record-Route}
headers in

the 200 class response are taken, if present, and their order
is reversed. 

\item The URI in the \header{Contact} header from the 200 class
response, if

present, is taken, and appended to the end of the list from
the

previous step.

\item The list of URIs resulting from the above two operations
is

referred to as the {\em route set}.

\end{enumerate}




The UAC \MUST store the route set for the duration of the
call

leg. NOTE that it is possible for the route set to be empty.
This will

occur if neither \header{Record-Route} headers nor a
\header{Contact}

header were present in the 200 class response. NOTE that since
there

may be multiple 200 OK responses to an \INVITE request, each
response

constitutes a separate call leg, and thus has a separate
route

set. The UAC \MUST also remember whether the bottom-most entry
in the

route set was constructed from a \header{Contact} header or
not. This

is effectively a boolean value, which we refer to as
CONTACT_SET.




The \ACK request for the initial \INVITE transaction \MUST
be

formulated according to the rules of Section XXX, as if it were
a

subsequent request within the call leg. 




OPEN-ISSUE: Handling for non-200 responses, including
provisionals

and certain 400 class responses. Are we supporting
record-routing for

non-200 class responses? Record-routing for provisional
responses is

discussed in the 100rel spec. What needs to be said
here?




\subsection{UAS Processing of initial \INVITE
transaction}

\label{sec:rr:uas}




When a UAS receives an \INVITE for a new call leg, and it
responds

with a 200 class response, it \MUST copy the contents of
the

\header{Record-Route} headers from the request to the response.
This

includes the URIs, URI parameters, and any
\header{Record-Route}

header parameters, whether they are known or unknown to
the

UAS. \annotate{Record-Route parameters are very useful
for

proxies. They allow the proxy to match the record-route entry
in the

response with the one in the request.} The

order of the \header{Record-Route} headers \MUST be preserved
in the

response.




The UAS \MUST construct a {\em route set} in the following
manner:




\begin{enumerate}

\item The list of URIs in the \header{Record-Route} headers in
the

\INVITE request, if present, are taken, including any URI
parameters.

\item The URI in the \header{Contact} header from the request,
if present,

is

taken, including any URI parameters. The URI is appended to the
bottom

of the list of URIs from the previous step.

\item The resulting list of URIs is called the {\em route set}.


\end{enumerate}




The UAS \MUST store the route set for the duration of the
call

leg. NOTE that it is possible for the route set to be empty.
This will

occur if neither \header{Record-Route} headers nor a
\header{Contact}

header were present in the \INVITE request. The UAS \MUST
also

remember whether the bottom-most entry in the route set
was

constructed from a \header{Contact} header or not. This is
effectively

a boolean value, which we refer to as CONTACT_SET. 




OPEN ISSUE: this new text does not have the record-routes copied
into

non-200 responses. RFC2543 talks about other failure codes, but
is not

specific enough. Do we really need them in other response
codes? If

so, we must list them explicitly.




\subsection{Proxy processing of an initial \INVITE
transaction}

\label{sec:rr:proxy}




Each proxy \MAY independently decide to record-route an
initial

\INVITE transaction. For a proxy, {\em initial} is
defined

as any \INVITE request that does not contain a
\header{Route}

header. Generally, the choice about whether to record-route or
not is

a tradeoff of features vs. performance. Faster call processing
and

higher scalability is achieved when proxies do not
record

route. However, provision of certain services may require a
proxy to

observe all messages for a call leg. It is \RECOMMENDED that
proxies

do not automatically record route. They should do so only
if

specifically required.




To record-route, the proxy inserts a \header{Record-Route}
header into

the request before proxying it onwards. A forking proxy \MAY
insert a

different \header{Record-Route} header into each forked
request. The

\header{Record-Route} header that it inserts \MUST be inserted
as the

first \header{Record-Route} header, appearing before any
existing ones

in the request. The URL in the header \MUST be a SIP

URL. \annotate{This is because the URLs in the Record-Route
headers

are used for forwarding requests by other proxies. Since no
other URL

but a SIP URL is mandatory, a proxy could not be sure that any
other

URL is interpretable by other proxies. Thus, SIP URLs
are

mandatory}. The URL \MUSTNOT contain the transport

parameter. \annotate{Thats because only UDP is mandatory. If a
proxy

inserts a transport parameter in the URL with TCP or TLS as
the

transport, the proxy that ends up using that URL to forward
the

request might not support that transport. The result, according
to the

``Locating a SIP Server'' procedure, would be for the proxy to
give

up.} The URL \MUST have the property that when the
processing

described in Section XXX ``locaing a SIP server'' is followed
for that

URL, the result of the lookup is an address/port of the proxy
server

inserting the

\header{Record-Route}. The URL and the proxy configuration
\SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing
will cause

it to be forwarded to one of the previous-hop servers that the
initial

\INVITE request traversed, including the UAS. \annotate{These
two

properties are 

important. The first one guarantees that subsequent requests
from the

called party are routed back to this actually proxy. The second
property is

there for robustness. It guarantees that the request URI
always

contain meaningful information, even if there are no
\header{Route}

headers that tell the proxy where to forward the request to
next.} The

proxy \MAY insert 

\header{Record-Route} parameters into the request. These will
be

returned to the proxy in any 200 class response to the \INVITE,
and

are useful for pushing state into the message.




If a 200 class response arrives for a proxied request, the
response

will contain the entire list of \header{Record-Route} headers
inserted

by proxies along the request path. The proxy \MAY modify
the

\header{Record-Route} value matching the one it inserted into
the

request. Like the URL in the request, it \MUST be a SIP URL
and

\MUSTNOT contain a transport parameter. The URL in this

\header{Record-Route} header \MUST have the

property that when the processing described in Section XXX
``locating

a SIP server'' is followed for that URL, the result of the
lookup is

an address/port of the proxy server that inserted the

\header{Record-Route}. The URL in this header, and the proxy
configuration

\SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing
will cause

it to be forwarded to the same next hop server that the
initial

\INVITE request was forwarded to.




The four properties (two for the request, two for the response),
can

be satisfied in a number of ways. One way is that the URI
inserted

into the \header{Record-Route} in the request is the same as
the

\header{Contact} header in the \INVITE (if present, else
the

\header{From} field), but with the maddr and port set to

resolve to the proxy. Then, the proxy modifies the URL in
the

\header{Record-Route} header in the response, setting it to be
the URL

from the \header{Request-URI} of the initial \INVITE, but with
the maddr

and port set to resolve to the proxy. 




As an example, consider a proxy at 10.0.1.1 listening on port
5061

which receives the following request (many headers are omitted
for

brevity):




\begin{verbatim}

INVITE sip:user@example.com SIP/2.0

Via: SIP/2.0/UDP callerspc.univ.edu

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The proxy forwards this request to

\header{sip:j_user@div11.example.com}, and
record-routes:




\begin{verbatim}

INVITE sip:j_user@div11.example.com SIP/2.0

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The 200 response will look like, in part:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The proxy modifies its \header{Record-Route} header in the
response to

and forwards the request upstream:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:j_user@example.com:5061;maddr=10.0.1.1>;myparam=9877


Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The route set computed by the UAS is:




\begin{verbatim}

sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1

sip:caller@callerspc.univ.edu

\end{verbatim}




and the route set computed by the UAC is:




\begin{verbatim}

sip:j_user@example.com:5061;maddr=10.0.1.1

sip:j_user@host32.div11.example.com

\end{verbatim}




There are other ways to meet these requirements. The proxy
could

construct a URL for the request which encodes all of the
needed

information, by placing it in the user portion, for example. A
call

stateful proxy could insert a URL into the request with the
form

sip:proxy.example.com, and not modify it in the response. This
URL

clearly satisfies the first required property (of getting
routed back

to the proxy that inserted it). The second property can be
maintained

by being call stateful, and extracting the needed parameters
from

local storage.




When a proxy does decide to modify the \header{Record-Route}
header in

the response, one of the operations it must perform is to
locate the

\header{Record-Route} that it had inserted. If the request
spiraled,

and the proxy inserted a \header{Record-Route} in each
iteration of

the spiral, locating the correct header in the response (which
must be

the proper iteration in the reverse direction) is tricky.
One

mechanism that is \RECOMMENDED is for the proxy to insert
a

\header{Record-Route} parameter into the new
\header{Record-Route} header

in the request each time the request spirals. This parameter
\MUST

uniquely identify the proxy. When the 200 class respone
arrives, the

proxy looks for the topmost \header{Record-Route} header
containing

this parameter. This header is the one for the current
iteration. The

proxy \MUST remove this parameter before forwarding the
response

upstream. Upon the next iteration, the same algorithm (find
the

topmost \header{Record-Route} header with the parameter)
will

correctly extract the next \header{Record-Route}

header.






\subsection{UA Processing of Subsequent Requests in a Call
Leg}

\label{sec:rr:uasubsequent}




When a UA wishes to send another request for the call-leg (such
as a

\header{BYE} or \header{INVITE}), it follows the procedures
defined in

this subsection. The

procedures here \MUST also be followed for an \ACK request for
a 200

response to the initial \INVITE for the call leg. The
procedures here

\MUSTNOT be followed for a \CANCEL request or an \ACK request
for a

non-200 response. This implies that \CANCEL never contains
a

\header{Route} header, nor does an \ACK for a non-200
response.




The request is constructed as specified in Section XXX. 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
any

URI parameters, are placed into a \header{Route} header into
the request,

in order. The procedures of Section XXX ``locating a SIP
server'' are

then applied to the URI in the request URI, the the request
is

forwarded to the resulting server.




If a UAS has a route set for a call leg, and receives a
re-INVITE for

that call leg containing \header{Record-Route} headers, it
\MUST copy

those headers into any 200 class response to that request. If
the

boolean variable CONTACT_SET is true, the \header{Contact}
header in

the re-INVITE (if present) replaces the last 

entry in the route set. If the boolean variable CONTACT_SET is
false,

the UAS \MUST add the URL in the 

\header{Contact} header in the re-INVITE to the bottom of the
route

set, and then set CONTACT_SET to true. If the re-INVITE did
not

contain a \header{Contact} header, the route-set at the UAS
remains

unchanged.




Similarly, if a UAC has a route set for a call leg, and receives
a 200

class response to a re-INVITE it sent, the \header{Contact}
header is

examined. If not present, the route set remains unchanged. If
the

re-INVITE response had a \header{Contact} header, and the
boolean

variable CONTACT_SET is false, the URL in the \header{Contact}
header

in the response is added to the bottom of the route set,
and

CONTACT_SET is set to true. If the re-INVITE response had
a

\header{Contact} header, and CONTACT_SET is true, the URL in
the

\header{Contact} header of the re-INVITE response replaces the
bottom

value in the route set.




The above two paragraphs allow a UA to update its
\header{Contact}

address mid-call, but proxies cannot update their route
address.  Once

on the route, a proxy remains on the route for the duration of
the

call leg. \annotate{Why the different treatment for Contact
and

Record-Route in a re-INVITE? It has to do with backwards

compatibility. RFC2543 did not mandate that a proxy needs to
refresh

its record-route headers. As a result, the lack of a
record-route in a

re-INVITE cannot be interpreted to mean that the proxy does not
want

to be included on the route any longer. Updating of the Contact
header

mid-call is useful for mobility applications, and is also
useful for

forms of third party call control}.






OPEN-ISSUE: should the UA remove the maddr param, if present, if
the

request is sent to the server at that maddr?




OPEN-ISSUE: should we mention handling of route with local
outbound

proxies here? RFC2543 has some text on DNS-less UAs, but there
are

issues with this.




\header{Proxy processing of a non-initial request}

\label{sec:rr:proxy2}




The rules in this section \MUST be followed when a proxy
receives a request

that contains a \header{Route} header. The \header{Route}
header is

used to forward the request to the next hop. It \MUST override
any other

routing decisions that the proxy would otherwise make. Proxies
\MAY

respond to requests with \header{Route} headers for any reason
(in order

to perform proxy authorization, for example). But, if the
request is

proxied, the procedures here \MUST be used to determine where
the

request is proxied to. The procedures in this section apply
indepedent

of the request method. They \MUST be followed even if the
request

method is unknown to the proxy. \annotate{This last sentence
is

really, really important. It allows for other methods, defined
in the

future, to have record-routing applied to them. As an example,
an

instant messaging session run over SIP might begin with a
MESSAGE

request. That extension can allow for these sessions to
be

record-routed by proxies that know of this extension. However,
the

record-routing will only work if proxies that don't know about
the

extension follow the Route headers properly. As such,
supporting

\header{Route} headers for all methods, known or unknown, is
very

important for a robust and future proof proxy
implementation.}

Since \CANCEL can never contain

\header{Route}, these procedures never apply to \CANCEL.
However, they

do apply to \ACK requests for a 200 OK response, which do
contain

\header{Route} headers. 




The proxy \MUST remove the top \header{Route} header from
the

request. The URI from that \header{Route} \MUST be placed into
the

\header{Request-URI} of the proxied request, including
URI

parameters. Any URL parameters present in the top
\header{Route}

header which are not allowed in the request URI \MUST be
removed from

the \header{Request-URI} by the proxy. The procedures of
section XXX

``Locating a SIP Server'' \MUST be followed to compute the next
hop

server to forward the request to. 




If the request is an \INVITE request (thus, a re-INVITE) for a
call

leg that the proxy wishes to receive messages for (very likely
the

case, since the request probably arrived at the proxy because
the

proxy record routed in the initial \INVITE), the proxy
\MUST

re-insert the

\header{Record-Route} header with the same value it placed in
the

initial request. Similarly, it should modify the
\header{Record-Route}

header in any 200 class response in the same way the

\header{Record-Route} header was modified in the response to
the

initial \INVITE (which may be no modifications at all). The
purpose of

this is twofold. First, it allows for proper record-routing in
the

case of pre-loaded Route headers (see Section XXX). Secondly,
it

allows for recovery from a UA crash and restart, in which case
the UA

loses call state, and as a result, its route set as well. The
result

is that the route set will be re-established through the

re-INVITE. When coupled with the Session Timer \cite{RFCXXX},
the

result is a robust way to recover from crashes.




\subsection{Pre-Loaded Route Headers}




Normally, a UA constructs the Route headers in a request from
the

route set learned through \header{Record-Route} headers.
However, in

some circumstances, it is useful for a UA to insert
\header{Route}

headers into an initial \INVITE. These headers may have been
learnt by

the UA through some out of bands means. When an initial
\INVITE

(initial as far as the UAC and UAS are concerned)
contains

\header{Route} headers, this is referred to as a
``pre-loaded

Route''. It is equivalent to strict source routing in IP.
Proxies will

often not be able to distinguish this case from the case
described in

Section \ref{sec:rr:proxy}, and will therefore properly use
these

route headers to forward the request. If the proxies are
interested in

receiving subsequent messages for the call leg, their insertion
of

\header{Record-Route} as mandated by Section \ref{sec:rr:proxy}
will

establish a correct route set at both UAC and UAS. This route
set may

end up being different from the pre-loaded Route used by the
UAC. As

such, a UAC that inserts a pre-loaded route set \MUST follow
the

procedures of Section \ref{sec:rr:uac} in processing the
response to

this initial \INVITE.










---

Jonathan D.
Rosenberg                      

72 Eagle Rock Ave.

Chief
Scientist                            

First Floor

dynamicsoft                                

East Hanover, NJ 07936

jdrosen@dynamicsoft.com                    

FAX:   (973) 952-5050

http://www.cs.columbia.edu/~jdrosen        

PHONE: (973) 952-5000

http://www.dynamicsoft.com

 




_______________________________________________

SIP mailing list

SIP@lists.bell-labs.com

http://lists.bell-labs.com/mailman/listinfo/sip





------_=_NextPart_003_01C0C40C.43A8EE10--



--0__=RKSQABsvzPHdckvq0q5BlbjFWpznzbRNSad6M2yMQRAiQzwwWopufi1y--


_______________________________________________
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  Tue Apr 17 10:37:34 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08757
	for ; Tue, 17 Apr 2001 10:37:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8340B44338; Tue, 17 Apr 2001 10:37:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lists.bell-labs.com (Postfix) with ESMTP id A8C5D44337
	for ; Tue, 17 Apr 2001 10:36:57 -0400 (EDT)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3HEZ5f11086;
	Tue, 17 Apr 2001 07:35:05 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f3HEad929291;
	Tue, 17 Apr 2001 07:36:39 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256A31.00503F9C ; Tue, 17 Apr 2001 07:36:31 -0700
X-Lotus-FromDomain: 3COM
From: Deepak_Pant@3com.com
To: "Keith Robinson" 
Cc: "Fairlie-Cuninghame, Robert" ,
        "'Arunachalam Venkatraman'" ,
        Sherman Gong , sip@lists.bell-labs.com,
        "'Jonathan Rosenberg'" 
Message-ID: <88256A31.00503F41.00@hqoutbound.ops.3com.com>
Subject: RE: [SIP] Request-uri does not match record-route header...
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58"
Content-Disposition: inline
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, 17 Apr 2001 09:35:53 -0500

--0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



(See attached file: loop.doc)
It is important to have the same ReqURI in the ACK as presented in the
RouteHeader because
this will also help in the loop detection. As in the attached diagram although
the two sip requests
may have identical CallIds, they may have different ReqURI on account of number
translation
being done at one of the intermediate proxies and the call looping back to the
proxy. As Keith
pointed out having the ReqURI identical to the INVITE will help determine the
correct state
machine for processing the call.

-Deepak




"Keith Robinson"  on 04/17/2001 05:58:27 AM

Sent by:  "Keith Robinson" 


To:   "Fairlie-Cuninghame, Robert" 
cc:   "'Arunachalam Venkatraman'" , Sherman Gong
      , sip@lists.bell-labs.com, "'Jonathan Rosenberg'"
       (Deepak Pant/MW/US/3Com)
Subject:  RE: [SIP] Request-uri does not match record-route header...





Hello,

Shouldn't the Request-Uri in the ACK should be :

ACK
sip:3032011001@192.168.10.114:5060;maddr=192.168.10.141;transport=udp;user=phone
SIP/2.0

This will then be sent to 192.168.10.141 using the maddr.

It is important that the Request-Uri in the subsequent messages is that given in
the Record-Route
as stateful proxies may well use this to identify the correct state machine to
process the request.

Like Robert, I think this touches upon the issues with Route headers, outbound
proxies and UA
without DNS capability which I feel hasn't yet been resolved.

Regards,

Keith Robinson









"Fairlie-Cuninghame, Robert"  on 13/04/2001 12:24:12








 To:      "'Arunachalam Venkatraman'" ,
          Sherman Gong ,
          sip@lists.bell-labs.com

 cc:      "'Jonathan Rosenberg'"
          (bcc: Keith
          Robinson/MAIN/MC1)



 Subject: RE: [SIP] Request-uri does not match record-route
          header...








Hi,

I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a)   the proxy knows that it record-routed this call leg
b)   or the Request-URI resolves to the local proxy's address.

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".

For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.

At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?

Robert.

 <<[SIP] new record-route text!>>
-----Original Message----
From:     Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
Sent:     Thursday, April 12, 2001 5:46 PM
To:  Sherman Gong; sip@lists.bell-labs.com
Subject:  RE: [SIP] Request-uri does not match record-route header...

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.


 -----Original Message-----
From:     sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:     Thursday, April 12, 2001 10:09 AM
To:  sip@lists.bell-labs.com
Subject:  [SIP] Request-uri does not match record-route header...

Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG


_______________________________________________
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.



--0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+UkU6IFtT
SVBdIFJlcXVlc3QtdXJpIGRvZXMgbm90IG1hdGNoIHJlY29yZC1yb3V0ZSBoZWFkZXIuLi48L1RJ
VExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SGks
PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkkgYmVsaWV2ZSB0
aGUgUmVjb3JkLVJvdXRlIHRlc3QgaGFzIGJlZW4gY29tcGxldGVseSByZXdyaXR0ZW4gKG1lc3Nh
Z2UgYXR0YWNoZWQpLiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSBob3dldmVyIEFydW5hY2hhbGFtJ3Mg
cmVzcG9uc2Ugc2hvdWxkIGJlIHF1YWxpZmllZCBieSB0aGUgc2F5aW5nIHRoYXQgYSBwcm94eSBz
aG91bGQgb25seSB1c2UgdGhlIG5leHQgUm91dGUgaGVhZGVyIGlmPC9GT05UPjwvUD4NCg0KPE9M
IFRZUEU9YT48TEk+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50aGUgcHJveHkga25vd3MgdGhh
dCBpdCByZWNvcmQtcm91dGVkIHRoaXMgY2FsbCBsZWc8L0ZPTlQ+PC9MST4NCjxMST48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPm9yIHRoZSBSZXF1ZXN0LVVSSSByZXNvbHZlcyB0byB0aGUgbG9j
YWwgcHJveHkncyBhZGRyZXNzLjwvRk9OVD48L0xJPg0KPEJSPg0KPC9PTD4NCjxQPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+SSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgcmVmbGVjdGVkIGluIHRo
ZSBuZXcgUmVjb3JkLVJvdXRlIHRleHQuIEl0IHRvdWNoZXMgb24gYW4gdW5yZXNvbHZlZCAob3Ig
YXQgbGVhc3QgdGhhdCB3YXMgbXkgZmVlbGluZykgZGlzY3Vzc2lvbiBhIGxvbmcgdGltZSBhYm91
dCB3aGV0aGVyIGEgUmVjb3JkLVJvdXRpbmcncyBpbnRlcmFjdGlvbiB3aXRoICJPdXRib3VuZCBQ
cm94aWVzIi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZvciBp
bnN0YW5jZSwgd2hlbiBhIFVBIG9yIFByb3h5LCBwdXRzIHRoZSBmaXJzdCBSb3V0ZSBoZWFkZXIg
aW4gdGhlIFJlcXVlc3QtVVJJIGJ1dCB0aGVuIHNlbmRzIHRoZSBtZXNzYWdlIHRvIGFuIG91dGJv
dW5kIHByb3h5IGJlY2F1c2UgdGhlIFVBIGxhY2tzIEROUyBjYXBhYmlsaXR5LiBUaGUgb3V0Ym91
bmQgcHJveHkgbWF5IG5vdCBoYXZlIFJlY29yZC1Sb3V0ZSdkIGJ1dCBpdCBtdXN0IG5vdCByZW1v
dmUvcHJvY2VzcyB0aGUgbmV4dCBSb3V0ZSBoZWFkZXIgZWl0aGVyLjwvRk9OVD48L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QXQgcmlzayBvZiByZW9wZW5pbmcgdGhpcyBkaXNj
dXNzaW9uLCBkaWQgd2UgcmVhY2ggYXQgY29uY2x1c2lvbiBvbiB0aGlzIHBvaW50LCB0aGF0IGlz
LCB3aGVuIGEgcHJveHkgc2hvdWxkIHVzZSB0aGUgbmV4dCBSb3V0ZSBoZWFkZXIgYW5kIHdoZW4g
c2hvdWxkIGl0IG5vdCAoaWYgdGhlIFJlcXVlc3QtVVJJIGlzIGRvZXMgbm90IHJlc29sdmUgdG8g
dGhlIHByb3h5J3MgYWRkcmVzcyk/PC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5Sb2JlcnQuPC9GT05UPg0KPC9QPg0KDQo8UD48QSBOQU1FPSJfTWFpbERhdGEiPjxG
T05UIEZBQ0U9IkFyaWFsIiBTSVpFPTIgQ09MT1I9IiMwMDAwMDAiPiAmbHQ7Jmx0O1tTSVBdIG5l
dyByZWNvcmQtcm91dGUgdGV4dCEmZ3Q7Jmd0OyA8L0ZPTlQ+PFU+PC9VPjwvQT4NCjxCUj48VT48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS08L0ZPTlQ+
PC9VPg0KPEJSPjxCPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDsg
QXJ1bmFjaGFsYW0gVmVua2F0cmFtYW4gWzxBIEhSRUY9Im1haWx0bzphcnVudmVua0BjaXNjby5j
b20iPm1haWx0bzphcnVudmVua0BjaXNjby5jb208L0E+XTwvRk9OVD48L0I+DQo8QlI+PEI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+VGh1cnNkYXksIEFwcmlsIDEyLCAyMDAxIDU6NDYgUE08L0ZP
TlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlNoZXJtYW4gR29u
Zzsgc2lwQGxpc3RzLmJlbGwtbGFicy5jb208L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UkU6IFtTSVBdIFJlcXVl
c3QtdXJpIGRvZXMgbm90IG1hdGNoIHJlY29yZC1yb3V0ZSBoZWFkZXIuLi48L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+WW91IGFyZSBjb3JyZWN0IGluIHRoYXQm
bmJzcDsgdGhlIFJFUSBVUkkgaW4gQUNLIG9mIHlvdXIgZXhhbXBsZSBzaG91bGQgYmU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4xOTIuMTY4LjEwLjExNC48L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ib3dldmVyLCBJIGRvbid0IGtub3cgd2hhdCBp
cyB0aGUgdmFsdWUgb2YgY29weWluZyB0aGUgdG9wbW9zdCByb3V0ZSB0byB0aGU8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SRVEgVVJJIC48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGUgcG9ydCBvZiB0aGUgVUFTIGlzIGRpZmZlcmVudCBm
cm9tIHRoYXQgaW4gdGhlIFJvdXRlLCBpdCBsb29rcyB3cm9uZyE8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgZmFjdCBpcywgdGhlIFJFUSBVUkkgaXMgbm90IHVzZWQg
Zm9yIHJvdXRpbmcgd2hlbiB0aGVyZSBpcyBhIFJPVVRFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+aGVhZGVyIGluIHRoZSBtZXNzYWdlLjwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPkkgaGF2ZSBmb3VuZCB0aGF0IHRoZSBSRVEgVVJJIGluIHRoZSBB
Q0sgdG8gYSBwcm94eSBJIGhhdmUgYmVlbiB0ZXN0aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+d2l0aCwgY2FuIGJlIGFueXRoaW5nIChzbyBsb25nIGFzIGl0IHBhcnNl
cyBvaykgd2hlbiB0aGVyZSBpcyBhIFJPVVRFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+aGVhZGVyLiBUaGUgcHJveHkgdXNlcyB0aGUgUm91dGUgaGVhZGVyIGZvciByb3V0
aW5nIGFuZCBub3QgdGhlIFJFUSBVUkksPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+d2hlbiBhIFJPVVRFIGhlYWRlciBpcyBwcmVzZW50LjwvRk9OVD4NCjwvUD4NCjxCUj4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDstLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZyb206ICZuYnNw
OyBzaXAtYWRtaW5AbGlzdHMuYmVsbC1sYWJzLmNvbSBbPEEgSFJFRj0ibWFpbHRvOnNpcC1hZG1p
bkBsaXN0cy5iZWxsLWxhYnMuY29tIj5tYWlsdG86c2lwLWFkbWluQGxpc3RzLmJlbGwtbGFicy5j
b208L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk9uIEJlaGFsZiBP
ZiBTaGVybWFuIEdvbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TZW50
OiZuYnNwOyZuYnNwOyBUaHVyc2RheSwgQXByaWwgMTIsIDIwMDEgMTA6MDkgQU08L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
c2lwQGxpc3RzLmJlbGwtbGFicy5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb
U0lQXSBSZXF1ZXN0LXVyaSBkb2VzIG5vdCBtYXRjaCByZWNvcmQtcm91dGUgaGVhZGVyLi4uPC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhhdmluZyBhIHByb2Js
ZW0gd2hlcmVieSB0aGUgcmVxdWVzdC11cmkgdXNlZCBpbiB0aGUgQUNLIGRvZXMgbm90IG1hdGNo
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhhdCB3aGljaCB3YXMgaW4g
dGhlIHJlY29yZC1yb3V0ZSBoZWFkZXIgaW4gdGhlIDIwMCBPSy4mbmJzcDsgUGVyIHRoZSBTSVAg
YmlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZHJhZnQgKHNlY3Rpb24g
Ni4zOSBpbiB0aGUgMDIgdmVyc2lvbiksIHRoZSBmaXJzdCBSb3V0ZSBoZWFkZXIgKGNvbnN0cnVj
dGVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZnJvbSB0aGUgcmVjb3Jk
LXJvdXRlIGhlYWRlcikgc2hvdWxkIGJlIHJlbW92ZWQgYW5kIHVzZWQgYXMgdGhlPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVxdWVzdC1VUkkuJm5ic3A7IEkgaW5jbHVk
ZWQgYSBjb3VwbGUgb2Ygbm90ZXMgYmVsb3cgYXN0ZXJpc2tzICgqKioqKiopLjwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGhhdmUgYmVlbiBnZXR0aW5nIGNv
bmZsaWN0aW5nIGFyZ3VtZW50cyBvbiB3aGljaCByZXF1aXJlbWVudCB0aGlzIHNob3VsZDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmZvbGxvdy4mbmJzcDsgTmVlZCB0byBk
ZXRlcm1pbmUgd2hpY2ggc3BlYy4gaXMgY29ycmVjdC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+MSkmbmJzcDsgNi4yOSBSZWNvcmQtUm91dGU8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFRoZSBSZWNvcmQtUm91dGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIGlz
IGFkZGVkIHRvIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBieSBhbnkgcHJveHkgdGhhdCBpbnNpc3RzIG9uIGJl
aW5nIGluIHRoZSBwYXRoIG9mIHN1YnNlcXVlbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWVzdHMgZm9yIHRoZSBzYW1l
IGNhbGwgbGVnLiBJdCBjb250YWlucyBhIGdsb2JhbGx5IHJlYWNoYWJsZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXF1ZXN0
LVVSSSB0aGF0IGlkZW50aWZpZXMgdGhlIHByb3h5IHNlcnZlci4gRWFjaCBwcm94eSBzZXJ2ZXIg
YWRkczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBpdHMgUmVxdWVzdC1VUkkgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgbGlzdC48
L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzZXJ2ZXIgY29waWVzIHRoZSBSZWNvcmQtUm91dGUgaGVh
ZGVyIGZpZWxkIHVuY2hhbmdlZCBpbnRvIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZS4gKFJlY29y
ZC1Sb3V0ZSBpcyBvbmx5IHJlbGV2YW50IGZvciAyeHggcmVzcG9uc2VzLik8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFRoZSBjYWxsaW5nIHVzZXIgYWdlbnQgY2xpZW50IGNvcGllcyB0aGUgUmVjb3JkLVJv
dXRlIGhlYWRlciBpbnRvIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUgaGVhZGVyIGZpZWxkIG9mIHN1YnNl
cXVlbnQgcmVxdWVzdHMgd2l0aGluIHRoZSBzYW1lIGNhbGwgbGVnLDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXZl
cnNpbmcgdGhlIG9yZGVyIG9mIHJlcXVlc3RzLCBzbyB0aGF0IHRoZSBmaXJzdCBlbnRyeSBpcyBj
bG9zZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIHRoZSB1c2VyIGFnZW50IGNsaWVudC4gSWYgdGhlIHJlc3Bv
bnNlIGNvbnRhaW5lZCBhIENvbnRhY3QgaGVhZGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpZWxkLCB0aGUgY2Fs
bGluZyB1c2VyIGFnZW50IGFkZHMgaXRzIGNvbnRlbnQgYXMgdGhlIGxhc3QgUm91dGU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgaGVhZGVyLiBVbmxlc3MgdGhpcyB3b3VsZCBjYXVzZSBhIGxvb3AsIGFueSBjbGllbnQg
TVVTVCBzZW5kIGFueTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWJzZXF1ZW50IHJlcXVlc3RzIGZvciB0aGlzIGNh
bGwgbGVnIHRvIHRoZSBmaXJzdCBSZXF1ZXN0LVVSSSBpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91dGUg
cmVxdWVzdCBoZWFkZXIgZmllbGQgYW5kIHJlbW92ZSB0aGF0IGVudHJ5LjwvRk9OVD4NCjwvUD4N
CjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsg
VGhlIGFib3ZlIGRlc2NyaWJlcyBidWlsZGluZyBSb3V0ZSBoZWFkZXJzIGZyb20gdGhlIFJlY29y
ZC1Sb3V0ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmhlYWRlcnMsPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFu
ZCBzZW5kaW5nIHN1YnNlcXVlbnQgcmVxdWVzdHMgdG8gdGhlIGZpcnN0IFJvdXRlLCByZW1vdmlu
ZyB0aGF0IGVudHJ5LjwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj4mbmJzcDsgNi4zMyBSb3V0ZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFJvdXRlIHJl
cXVlc3QtaGVhZGVyIGZpZWxkIGRldGVybWluZXMgdGhlIHJvdXRlIHRha2VuIGJ5IGE8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcmVxdWVzdC4gRWFjaCBob3N0IHJlbW92ZXMgdGhlIGZpcnN0IGVudHJ5IGFuZCB0aGVu
IHByb3hpZXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgdG8gdGhlIGhvc3QgbGlzdGVkIGluIHRo
YXQgZW50cnksIGFsc28gdXNpbmcgaXQgYXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlcXVlc3QtVVJJLiBU
aGUgb3BlcmF0aW9uIGlzIGZ1cnRoZXIgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4yOS48L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFRoZSBhYm92ZSBub3RlcyB0aGF0IHRoZSBSb3V0ZSBoZWFkZXIgdXNlZCB0byBwcm94eSBhIHJl
cXVlc3Qgc2hvdWxkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YWxzbzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBiZSB1c2VkIGFzIHRoZSBSZXF1ZXN0LVVSSS4mbmJzcDsgVGhpcyBpcyB0aGUgcGFydCB0
aGF0IGlzIG5vdCBiZWluZyBkb25lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlY3RseSBieSB0aGUgNTMwMC4mbmJzcDsg
VGhlIDUzMDAgaXMgYnVpbGRpbmcgaXQncyBvd24gcmVxdWVzdCBVUkkgYmFzZWQ8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZGVzdGluYXRpb24gb2Yg
dGhlIHJlcXVlc3QsIHJhdGhlciB0aGFuIHVzaW5nIHRoZSBVUkkgaW4gdGhlIFJvdXRlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhlYWRl
ciBhcyB0aGUgUmVxdWVzdC1VUkkuJm5ic3A7IE5vdGUgdGhhdCB0aGUgNTMwMCBpcyBzZW5kaW5n
IHRoZSByZXF1ZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dG8gdGhl
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGNvcnJlY3QgZGVzdGluYXRpb24sIHdoaWNoIGluIG91ciBjYXNlIGRvZXMgbm90IG1hdGNoIHRo
YXQgaW4gdGhlIFJvdXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGhlYWRlciAoYnV0IHRoZXkgZG9uJ3QgaGF2ZSB0byBtYXRjaCkuPC9G
T05UPg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk9yPC9GT05U
Pg0KPC9QPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjIpJm5ic3A7IGZy
b20gcGFnZSAyMCBvZiB0aGUgZHJhZnQ8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBtYWRkciBwYXJhbWV0ZXIg
aW5kaWNhdGVzIHRoZSBzZXJ2ZXIgYWRkcmVzcyB0byBiZSBjb250YWN0ZWQgZm9yPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhpcyB1c2VyLCBvdmVycmlkaW5nIHRoZSBh
ZGRyZXNzIHN1cHBsaWVkIGluIHRoZSBob3N0IGZpZWxkLiBUaGlzPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgaXMg
dHlwaWNhbGx5LCBidXQgbm90IG5lY2Vzc2FyaWx5LCBhIG11bHRpY2FzdCBhZGRyZXNzLiBUaGU8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5tYWRkciBmaWVsZCBjYW4gYmUg
dXNlZCB0byBmb3JjZSByZXF1ZXN0cyBmcm9tIHRyYXZlbGluZyB1c2VycyB0byB2aXNpdDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBhIGhvbWUgcHJveHkgZXZlbiBpZiBhbiBvdXRib3VuZCBwcm94eSBpcyB1c2VkLjwvRk9OVD4N
CjwvUD4NCjxCUj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5j
NTMwMC0zIzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDUuNjMyOiBJU0ROIFNlMDoyMzogUlggJmx0Oy0mbmJzcDsgU0VUVVAgcGQgPSA4Jm5ic3A7
IGNhbGxyZWYgPSAweDAwMDE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4q
SmFuIDIyIDA4OjM0OjA1LjYzMjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgQmVhcmVyIENhcGFiaWxpdHkgaSA9IDB4ODA5MEEyPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42MzY6Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYW5uZWwgSUQgaSA9IDB4QTk4
MzgxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42MzY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENh
bGxpbmcgUGFydHkgTnVtYmVyIGkgPSAweDIxODAsICcyMDYyMDExMDAxJyw8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QbGFuOklTRE4sIFR5cGU6TmF0aW9uYWw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1LjYzNjombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FsbGVkIFBhcnR5
IE51bWJlciBpID0gMHhBMSwgJzMwMzIwMTEwMDEnLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPlBsYW46SVNETiwgVHlwZTpOYXRpb25hbDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUyOiAweDYyMjFFMTFDIDogU3Rh
dGUgY2hhbmdlIGZyb20gKFNUQVRFX05PTkUsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+U1VCU1RBVEVfTk9ORSkmbmJzcDsgdG8gKFNUQVRFX0lETEUsIFNVQlNUQVRFX05P
TkUpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42NTI6Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJUCBTUEkgOiBTSVBTUElfRVZfQ0NfQ0FM
TF9TRVRVUDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDUuNjUyOiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgYWN0X2lkbGVfY2FsbF9zZXR1cDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUy
OiZuYnNwOyBhY3RfaWRsZV9jYWxsX3NldHVwOk5vdCB1c2luZyBWb2ljZSBDbGFzcyBDb2RlYzwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0
OjA1LjY1MjogYWN0X2lkbGVfY2FsbF9zZXR1cDogcHJlZmVycmVkX2NvZGVjIHNldFswXSB0eXBl
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Omc3MTF1bGF3IGJ5dGVzOiAx
NjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1
LjY1MjombmJzcDsgUXVldWVkIGV2ZW50IGZyb20gU0lQIFNQSSA6PC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+U0lQU1BJX0VWX0NSRUFURV9DT05ORUNUSU9OPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTI6IDB4NjIy
MUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RBVEVfSURMRSw8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5TVUJTVEFURV9OT05FKSZuYnNwOyB0byAoU1RBVEVfSURMRSwg
U1VCU1RBVEVfQ09OTkVDVElORyk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij4qSmFuIDIyIDA4OjM0OjA1LjY1MjogMHg2MjIxRTExQyA6IFN0YXRlIGNoYW5nZSBmcm9tIChT
VEFURV9JRExFLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlNVQlNUQVRF
X0NPTk5FQ1RJTkcpJm5ic3A7IHRvIChTVEFURV9JRExFLCBTVUJTVEFURV9DT05ORUNUPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU5HKTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjUyOiBDQ1NJUC1TUEktQ09OVFJP
TDombmJzcDsgYWN0X2lkbGVfY29ubmVjdGlvbl9jcmVhdGVkPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTI6IENDU0lQLVNQSS1DT05UUk9M
OiZuYnNwOyBhY3RfaWRsZV9jb25uZWN0aW9uX2NyZWF0ZWQ6PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q29ubmlkKDEpIGNyZWF0ZWQgdG8gMTkyLjE2OC4xMC4xMTQ6NTA2
MCwgbG9jYWxfcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm9ydCA1MDcy
NzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUu
NjU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJT3V0Z29pbmdDYWxsU0RQPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NTY6IHNp
cFNQSUFkZExvY2FsQ29udGFjdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PipKYW4gMjIgMDg6MzQ6MDUuNjU2OiZuYnNwOyBRdWV1ZWQgZXZlbnQgZnJvbSBTSVAgU1BJIDog
U0lQU1BJX0VWX1NFTkRfTUVTU0FHRTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPipKYW4gMjIgMDg6MzQ6MDUuNjU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwX3N0
YXRzX21ldGhvZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIg
MDg6MzQ6MDUuNjU2OiAweDYyMjFFMTFDIDogU3RhdGUgY2hhbmdlIGZyb20gKFNUQVRFX0lETEUs
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U1VCU1RBVEVfQ09OTkVDVElO
RykmbmJzcDsgdG8gKFNUQVRFX1NFTlRfSU5WSVRFLCBTVUJTVEFURV88L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OT05FKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjYwOiBJU0ROIFNlMDoyMzogVFggLSZndDsmbmJz
cDsgQ0FMTF9QUk9DIHBkID0gOCZuYnNwOyBjYWxscmVmID0gMHg4MDAxPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NjA6Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYW5uZWwgSUQgaSA9IDB4QTk4
MzgxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDow
NS42NjA6IFNlbnQ6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU5WSVRF
IHNpcDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUgU0lQLzIuMDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAmbmJzcDsgMTky
LjE2OC42Ni4xODQ6NTA3Mjc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5G
cm9tOiAmcXVvdDsyMDYyMDExMDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2
LjE4NCZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3Np
cDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGF0ZTogU2F0LCAyMiBKYW4gMjAwMCAwMTozNDowNSBH
TVQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5DYWxsLUlEOiBFQkIwNDM3
Qi1DMEE1MEE2MS0wLTZERkM0MDU4QDE5Mi4xNjguNjYuMTg0PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q2lzY28tR3VpZDogMzk1NDE5NzM3MS0zMjMyMDQxNTY3LTAtMTg0
NTI0ODA3NjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlVzZXItQWdlbnQ6
IENpc2NvIFNJUCBHYXRld2F5IChVQUMpL0lPUyAxMi54PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+Q1NlcTogMTAxIElOVklURTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPk1heC1Gb3J3YXJkczogNjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPlRpbWVzdGFtcDogOTQ4NTMwMDQ1PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Q29udGFjdDogJmx0O3NpcDoyMDYyMDExMDAxQDE5Mi4xNjguNjYuMTg0OjUw
NjA7dXNlcj1waG9uZSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5F
eHBpcmVzOiAxODA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL3NkcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPkNvbnRlbnQtTGVuZ3RoOiAxMzg8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+dj0wPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+bz1D
aXNjb1N5c3RlbXNTSVAtR1ctVXNlckFnZW50IDc2NTYgOTI4OCBJTiBJUDQgMTkyLjE2OC42Ni4x
ODQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5zPVNJUCBDYWxsPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Yz1JTiBJUDQgMTkyLjE2OC42Ni4xODQ8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50PTAgMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm09YXVkaW8gMjA0OTIgUlRQL0FWUCAwPC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcy
OiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4w
IDEwMCBUcnlpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5WaWE6IFNJ
UC8yLjAvVURQJm5ic3A7IDE5Mi4xNjguNjYuMTg0OjUwNzI3PC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+RnJvbTogJnF1b3Q7MjA2MjAxMTAwMSZxdW90OyAmbHQ7c2lwOjIw
NjIwMTEwMDFAMTkyLjE2OC42Ni4xODQmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+VG86ICZsdDtzaXA6MzAzMjAxMTAwMUAxOTIuMTY4LjEwLjExNDt1c2VyPXBob25l
Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkNhbGwtSUQ6IEVCQjA0
MzdCLUMwQTUwQTYxLTAtNkRGQzQwNThAMTkyLjE2OC42Ni4xODQ8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5DU2VxOiAxMDEgSU5WSVRFPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Q29udGVudC1MZW5ndGg6IDA8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8
QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6
IEhhbmRsZVVkcFNvY2tldFJlYWRzIDpNc2cgZW5xdWV1ZWQgZm9yIFNQSSB3aXRoPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SVBhZGRyOiAxOTIuMTY4LjEuMTE0OjM0MDUw
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42
NzI6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBhY3Rfc2VudGludml0ZV9uZXdfbWVzc2FnZTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcy
OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJQ2hlY2tSZXNwb25zZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuNjcyOiBDQ1NJUC1T
UEktQ09OVFJPTDombmJzcDsgc2lwX3N0YXRzX3N0YXR1c19jb2RlPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6Jm5ic3A7IFJvdW5kdHJp
cCBkZWxheSAxNiBtaWxsaXNlY29uZHMgZm9yIG1ldGhvZCBJTlZJVEU8L0ZPTlQ+DQo8L1A+DQoN
CjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNS42NzI6IDB4NjIy
MUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RBVEVfU0VOVF9JTlZJVEUsPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U1VCU1RBVEVfTk9ORSkmbmJzcDsgdG8gKFNUQVRF
X1JFQ0RfUFJPQ0VFRElORywgU1VCUzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPlRBVEVfUFJPQ0VFRElOR19QUk9DRUVESU5HKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuODUyOiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4wIDE4MCBSaW5naW5nPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjY2LjE4
NDo1MDcyNzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkZyb206ICZxdW90
OzIwNjIwMTEwMDEmcXVvdDsgJmx0O3NpcDoyMDYyMDExMDAxQDE5Mi4xNjguNjYuMTg0Jmd0Ozwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvOiAmbHQ7c2lwOjMwMzIwMTEw
MDFAMTkyLjE2OC4xMC4xMTQ7dXNlcj1waG9uZSZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5EYXRlOlNhdCwgMjIgSmFuIDIwMDAgMDg6MzM6NTAgR01UPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q2FsbC1JRDogRUJCMDQzN0ItQzBBNTBBNjEt
MC02REZDNDA1OEAxOTIuMTY4LjY2LjE4NDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPlRpbWVzdGFtcDo5NDg1MzAwNDU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5TZXJ2ZXI6Q2lzY28gU0lQIEdhdGV3YXkgKFVBUykvSU9TIDEyLng8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5DU2VxOiAxMDEgSU5WSVRFPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q29udGVudC1MZW5ndGg6IDA8L0ZPTlQ+DQo8L1A+
DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODoz
NDowNS44NTY6IEhhbmRsZVVkcFNvY2tldFJlYWRzIDpNc2cgZW5xdWV1ZWQgZm9yIFNQSSB3aXRo
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SVBhZGRyOiAxOTIuMTY4LjEu
MTE0OjM0MDUwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAw
ODozNDowNS44NTY6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBhY3RfcmVjZHByb2NfbmV3X21l
c3NhZ2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0
OjA1Ljg1NjogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IHNpcFNQSUNoZWNrUmVzcG9uc2U8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1Ljg1Njog
Q0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IHNpcF9zdGF0c19zdGF0dXNfY29kZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDUuODU2OiZuYnNwOyBS
b3VuZHRyaXAgZGVsYXkgMjAwIG1pbGxpc2Vjb25kcyBmb3IgbWV0aG9kIElOVklURTwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4OjM0OjA1Ljg1
NjogSGFuZGxlU0lQMXh4UmluZ2luZyBObyBTRFAgQm9keSBpbiAxODAgUklOR0lORyAtIHdvdWxk
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d2FpdCBmb3IgMjAwT0sgdG8g
ZG8gbmVnb3RpYXRpb24uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPipKYW4gMjIgMDg6MzQ6MDUuODU2OiBIYW5kbGVTSVAxeHhSaW5naW5nOiBNZWRpYU5lZ290
aWF0aW9uIGV4cGVjdGVkIGluIDIwMDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPk9LPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDUuODU2OiAweDYyMjFFMTFDIDogU3RhdGUgY2hhbmdlIGZyb20gKFNUQVRFX1JF
Q0RfUFJPQ0VFRElORyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TVUJT
VEFURV9QUk9DRUVESU5HX1BST0NFRURJTkcpJm5ic3A7IHRvIChTVEFURV88L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SRUNEX1BST0NFRURJTkcsIFNVQlNUQVRFX1BST0NF
RURJTkdfQUxFUlRJTkcpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Kkph
biAyMiAwODozNDowNS44NTY6IElTRE4gU2UwOjIzOiBUWCAtJmd0OyZuYnNwOyBBTEVSVElORyBw
ZCA9IDgmbmJzcDsgY2FsbHJlZiA9IDB4ODAwMTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzU2OiBSZWNlaXZlZDo8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TSVAvMi4wIDIwMCBPSzwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAgMTkyLjE2OC42Ni4xODQ6NTA3Mjc8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Gcm9tOiAmcXVvdDsyMDYyMDEx
MDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2LjE4NCZndDs8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3NpcDozMDMyMDExMDAxQDE5Mi4x
NjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7O3RhZz02REZDMkM1OC04MjA8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5EYXRlOlNhdCwgMjIgSmFuIDIwMDAgMDg6MzM6NTAgR01U
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q2FsbC1JRDogRUJCMDQzN0It
QzBBNTBBNjEtMC02REZDNDA1OEAxOTIuMTY4LjY2LjE4NDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlRpbWVzdGFtcDo5NDg1MzAwNDU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5TZXJ2ZXI6Q2lzY28gU0lQIEdhdGV3YXkgKFVBUykvSU9TIDEyLng8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250YWN0OiZsdDtzaXA6MzAz
MjAxMTAwMUAxOTIuMTY4LjY3LjE4Njo1MDYwO3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVjb3JkLVJvdXRlOiZsdDtzaXA6MzAzMjAxMTAwMUBl
YXN0LmM1MzAwNS5jb206NTA3MDttYWRkcj0xOTIuMTY4LjEwLjE0MTt0cmFuczwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnBvcnQ9dWRwJmd0OzwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJlY29yZC1Sb3V0ZTombHQ7c2lwOjMwMzIwMTEwMDFAMTky
LjE2OC4xMC4xMTQ6NTA2MDt1c2VyPXBob25lO21hZGRyPTE5Mi4xNjguMTA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4uMTQxO3RyYW5zcG9ydD11ZHAmZ3Q7PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q1NlcTogMTAxIElOVklURTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkNvbnRlbnQtVHlwZTphcHBsaWNhdGlvbi9zZHA8
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Db250ZW50LUxlbmd0aDogMTI2
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U2Vzc2lvbi1FeHBpcmVzOjMw
MDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj52PTA8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vPUNpc2NvU3lzdGVtc1NJUC1HVy1Vc2Vy
QWdlbnQgNjU2NSAzOTYwIElOIElQNCAxMC4xLjEuMjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPnM9U0lQIENhbGw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj50PTAgMDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm09YXVkaW8g
NDAzNiBSVFAvQVZQIDA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jPUlO
IElQNCAyMDkuNi4wLjI8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiBOb3RlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk5v
dGUgdGhhdCB0aGUgcmVjb3JkIHJvdXRlIGhlYWRlcjo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVjb3JkLVJvdXRlOiZsdDtzaXA6MzAzMjAxMTAwMUAxOTIu
MTY4LjEwLjExNDo1MDYwO3VzZXI9cGhvbmU7bWFkZHI9MTkyLjE2OC4xMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi4xNDE7dHJhbnNwb3J0PXVkcCZndDs8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IGlzIHRoZSBvbmUgdGhh
dCBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIHN1YnNlcXVlbnQgQUNLLjwvRk9OVD4NCjwvUD4NCjxC
Uj4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIyIDA4
OjM0OjA2LjM1NjogSGFuZGxlVWRwU29ja2V0UmVhZHMgOk1zZyBlbnF1ZXVlZCBmb3IgU1BJIHdp
dGg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JUGFkZHI6IDE5Mi4xNjgu
MS4xMTQ6MzQwNTA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFuIDIy
IDA4OjM0OjA2LjM1NjogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IGFjdF9yZWNkcHJvY19uZXdf
bWVzc2FnZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6
MzQ6MDYuMzU2OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwU1BJQ2hlY2tSZXNwb25zZTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYw
OiBDQ1NJUC1TUEktQ09OVFJPTDombmJzcDsgc2lwX3N0YXRzX3N0YXR1c19jb2RlPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6Jm5ic3A7
IFJvdW5kdHJpcCBkZWxheSA3MDQgbWlsbGlzZWNvbmRzIGZvciBtZXRob2QgSU5WSVRFPC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzYwOiBzaXBTUElHZXRTZHBCb2R5IDogUGFyc2UgaW5jb21pbmcgc2Vzc2lvbiBkZXNjcmlwdGlv
bjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzYwOiBzaXBTUElDb21wYXJlUmVzcE1lZGlhSW5mbyBObyBDb21wYXJzaW9uIG5lZWRlZCBhcyAx
OHg8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5tZXNzYWdlcyBkaWQgbm90
IGhhdmUgU0RQPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAw
ODozNDowNi4zNjA6IHNpcFNQSURvTWVkaWFOZWdvdGlhdGlvbjogQ29kZWMgTmVnb3RpYXRpb24g
U3VjY2Vzc2Z1bDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4q
SmFuIDIyIDA4OjM0OjA2LjM2MDogc2lwU1BJVXBkQ2NiV2l0aFNkcEluZm86IFNEUCBNZWRpYSBJ
bmZvcm1hdGlvbjo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OZWdvdGlh
dGVkIENvZGVjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZzcxMXVsYXcgLCBieXRl
cyA6MTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RWFybHkgTWVkaWEm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGVsYXllZCBNZWRp
YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5CcmlkZ2UgRG9uZSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5OZXcgTWVkaWEmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RFNQIEROTEQgUmVx
ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5NZWRpYSBEZXN0IGFkZHIvUG9ydCZu
YnNwOyA6IDIwOS42LjAuMjo0MDM2PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYwOiBzaXBTUElQcm9jZXNzTWVkaWFDaGFuZ2Vz
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4z
NjA6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBzaXBTUElSZWNvbm5lY3RDb25uZWN0aW9uPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6
Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJUCBTUEkgOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlNJUFNQSV9FVl9SRUNPTk5FQ1RfQ09OTkVDVElPTjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzYwOiBDQ1NJUC1T
UEktQ09OVFJPTDombmJzcDsgc2lwU1BJUHJvY2VzczIwME9LZm9yaW52aXRlPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IENDU0lQLVNQ
SS1DT05UUk9MOiZuYnNwOyBzaXBTUElBZGRSb3V0ZUhlYWRlcnMgc3RhdHVzID08L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UUlVFIFJvdXRlICZsdDtzaXA6MzAzMjAxMTAw
MUBlYXN0LmM1MzAwNS5jb206NTA3MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPjttYWRkcj0xOTIuMTY4LjEwLjE0MSZndDssICZsdDtzaXA6MzAzMjAxMTAwMUAxOTIuMTY4
LjY3LjE4Njo1MDYwO3VzZXI9cGhvbmUmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6Jm5ic3A7IFF1ZXVlZCBldmVudCBmcm9tIFNJ
UCBTUEkgOiBTSVBTUElfRVZfU0VORF9NRVNTQUdFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNw
OyBzaXBfc3RhdHNfbWV0aG9kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
KkphbiAyMiAwODozNDowNi4zNjA6IDB4NjIyMUUxMUMgOiBTdGF0ZSBjaGFuZ2UgZnJvbSAoU1RB
VEVfUkVDRF9QUk9DRUVESU5HLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PlNVQlNUQVRFX1BST0NFRURJTkdfQUxFUlRJTkcpJm5ic3A7IHRvIChTVEFURV9BQzwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRJVkUsIFNVQlNUQVRFX05PTkUpPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjA6IFRo
ZSBDYWxsIFNldHVwIEluZm9ybWF0aW9uIGlzIDo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDsgQ2FsbCBDb250cm9sIEJsb2NrIChDQ0IpIDogMHg2MjIxRTExQzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBTdGF0ZSBvZiBUaGUg
Q2FsbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFNUQVRFX0FD
VElWRTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBUQ1AgU29j
a2V0cyBVc2VkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDogTk88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgQ2FsbGlu
ZyBOdW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgOiAyMDYyMDExMDAxPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Jm5ic3A7IENhbGxlZCBOdW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAzMDMyMDExMDAxPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IE5lZ290aWF0ZWQgQ29kZWMmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBnNzExdWxhdzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBOZWdvdGlhdGVkIENv
ZGVjIEJ5dGVzJm5ic3A7Jm5ic3A7IDogMTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Jm5ic3A7IE5lZ290aWF0ZWQgRHRtZi1yZWxheSZuYnNwOyZuYnNwOyZuYnNwOyA6
IDA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgU291cmNlIElQ
IEFkZHJlc3MgKE1lZGlhKTogMTkyLjE2OC42Ni4xODQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsgU291cmNlIElQIFBvcnQmbmJzcDsmbmJzcDsmbmJzcDsgKE1l
ZGlhKTogMjA0OTI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsg
RGVzdG4mbmJzcDsgSVAgQWRkcmVzcyAoTWVkaWEpOiAyMDkuNi4wLjI8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsgRGVzdG4mbmJzcDsgSVAgUG9ydCZuYnNwOyZu
YnNwOyZuYnNwOyAoTWVkaWEpOiA0MDM2PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Jm5ic3A7IERlc3RuIFNJUCBSZXEgQWRkcjpQb3J0Jm5ic3A7IDogMTkyLjE2OC4xMC4x
NDE6NTA2MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyBEZXN0
biBTSVAgUmVzcCBBZGRyOlBvcnQgOiAwLjAuMC4wOjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj4mbmJzcDsgRGVzdGluYXRpb24gTmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE5Mi4xNjguMTAuMTE0PC9GT05UPg0KPC9Q
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzY0OiBI
YW5kbGVVZHBSZWNvbm5lY3Rpb246IFVkcCBzb2NrZXQgY29ubmVjdGVkIGZvciBmZDogMTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPndpdGggMTkyLjE2OC4xMC4xNDE6NTA2
MDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzY0OiBTZW50OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFDSyBzaXA6
MzAzMjAxMTAwMUAxOTIuMTY4LjEwLjE0MTo1MDYwO3VzZXI9cGhvbmUgU0lQLzIuMDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlZpYTogU0lQLzIuMC9VRFAmbmJzcDsgMTky
LjE2OC42Ni4xODQ6NTA3Mjc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5G
cm9tOiAmcXVvdDsyMDYyMDExMDAxJnF1b3Q7ICZsdDtzaXA6MjA2MjAxMTAwMUAxOTIuMTY4LjY2
LjE4NCZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UbzogJmx0O3Np
cDozMDMyMDExMDAxQDE5Mi4xNjguMTAuMTE0O3VzZXI9cGhvbmUmZ3Q7O3RhZz02REZDMkM1OC04
MjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5EYXRlOiBTYXQsIDIyIEph
biAyMDAwIDAxOjM0OjA1IEdNVDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PkNhbGwtSUQ6IEVCQjA0MzdCLUMwQTUwQTYxLTAtNkRGQzQwNThAMTkyLjE2OC42Ni4xODQ8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Sb3V0ZTogJmx0O3NpcDozMDMyMDEx
MDAxQGVhc3QuYzUzMDA1LmNvbTo1MDcwO21hZGRyPTE5Mi4xNjguMTAuMTQxJmd0Oyw8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbHQ7c2lwOjMwMzIwMTEwMDFAMTkyLjE2
OC42Ny4xODY6NTA2MDt1c2VyPXBob25lJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPk1heC1Gb3J3YXJkczogNjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPkNvbnRlbnQtTGVuZ3RoOiAwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Q1NlcTogMTAxIEFDSzwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogTm90
ZSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPlJlcXVlc3QtVVJJIGluIGFib3ZlIEFDSyBoYXMgZG9tYWluIG9m
IDE5Mi4xNjguMTAuMTQxLCBzaG91bGQgaGF2ZSBiZWVuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+MTkyLjE2OC4xMC4xMTQgd2hlbiB0aGUgcmVjb3JkLXJvdXRlIHdhcyB0
dXJuZWQgaW50byBhIFJvdXRlIGhlYWRlciw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5yZW1vdmVkLCBhbmQgdXNlZCBhcyB0aGUgUmVxdWVzdC1VUkkuPC9GT05UPg0KPC9Q
Pg0KPEJSPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDYuMzY0OiZuYnNwOyBzaXBTUElSdGNwVXBkYXRlcyBObyBydHAgc2Vzc2lvbiBp
biBicmlkZ2UsIGNyZWF0ZSBhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
bmV3IG9uZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4qSmFu
IDIyIDA4OjM0OjA2LjM2NDogQ0NTSVAtU1BJLUNPTlRST0w6Jm5ic3A7IGNjc2lwX2NhcHNfaW5k
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4z
NjQ6IGNjc2lwX2dldF9ydGNwX3Nlc3Npb25fcGFyYW1ldGVyczogQ1VSUkVOVCBWQUxVRVM6PC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Y2NDYWxsSUQ9MTI3NiwgY3VycmVu
dF9zZXFfbnVtPTB4MjE3QzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipK
YW4gMjIgMDg6MzQ6MDYuMzY0OiBjY3NpcF9nZXRfcnRjcF9zZXNzaW9uX3BhcmFtZXRlcnM6IE5F
VyBWQUxVRVM6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Y2NDYWxsSUQ9
MTI3NiwgY3VycmVudF9zZXFfbnVtPTB4OUVDPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjQ6IGNjc2lwX2NhcHNfaW5kOiBMb2FkIERTUCB3
aXRoIG5lZ290aWF0ZWQgY29kZWMgOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPmc3MTF1bGF3LCBCeXRlcz0xNjA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj4qSmFuIDIyIDA4OjM0OjA2LjM2ODogc2lwU1BJR2V0RFRNRlJlbGF5TW9kZTogc2V0IERT
UCBmb3IgZHRtZi1yZWxheSA9PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Q0NfQ0FQX0RUTUZfUkVMQVlfSU5CQU5EX1ZPSUNFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+KkphbiAyMiAwODozNDowNi4zNjg6IGNjc2lwX2NhcHNfaW5kOiBMb2FkIERT
UCB3aXRoIGNvZGVjIDogZzcxMXVsYXcsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Qnl0ZXM9MTYwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Kkph
biAyMiAwODozNDowNi4zNjg6IENDU0lQLVNQSS1DT05UUk9MOiZuYnNwOyBjY3NpcF9jYXBzX2Fj
azwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYu
MzcyOiBJU0ROIFNlMDoyMzogVFggLSZndDsmbmJzcDsgQ09OTkVDVCBwZCA9IDgmbmJzcDsgY2Fs
bHJlZiA9IDB4ODAwMTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4g
MjIgMDg6MzQ6MDYuMzcyOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBQcm9ncmVzcyBJbmQgaSA9IDB4ODE4MiAtIERlc3RpbmF0aW9uIGFkZHJlc3M8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5pcyBub24tSVNETjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzg4OiBJU0ROIFNl
MDoyMzogUlggJmx0Oy0mbmJzcDsgQ09OTkVDVF9BQ0sgcGQgPSA4Jm5ic3A7IGNhbGxyZWYgPTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjB4MDAwMTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPipKYW4gMjIgMDg6MzQ6MDYuMzg4OiBJU0ROIFNlMDoy
MzogQ0FMTF9QUk9HUkVTUzogQ0FMTF9DT05ORUNURUQgY2FsbCBpZDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPjB4MjI3LCBiY2hhbiAwLCBkc2wgMDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjN3MGQ6ICVJU0ROLTYtQ09OTkVDVDogSW50ZXJmYWNl
IFNlcmlhbDA6MCBpcyBub3cgY29ubmVjdGVkIHRvIDIwNjIwMTEwMDE8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jNTMwMC0zIzwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3M8L0ZPTlQ+DQo8L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+U0c8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGlz
IGxpc3QgaXMgZm9yIGNvbnRpbnVpbmcgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbC48
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgc2lwLWltcGxlbWVudG9y
J3MgbGlzdCBpcyB0aGUgcGxhY2UgdG8gZGlzY3VzcyBpbXBsZW1lbnRhdGlvbiw8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5hbmQgdG8gcmVjZWl2ZSBhZHZpY2Ugb24gdW5k
ZXJzdGFuZGluZyBleGlzdGluZyBzaXAuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+VG8gc3Vic2NyaWJlIHRvIGl0LCBzZW5kIG1haWwgdG88L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5zaXAtaW1wbGVtZW50b3JzLXJlcXVlc3RAY3MuY29sdW1iaWEu
ZWR1IHdpdGggJnF1b3Q7c3Vic2NyaWJlJnF1b3Q7IGluIHRoZSBib2R5LjwvRk9OVD4NCjwvUD4N
CjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPlRoaXMgbGlzdCBpcyBmb3IgY29udGludWluZyBkZXZlbG9wbWVudCBvZiB0aGUg
U0lQIHByb3RvY29sLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZSBz
aXAtaW1wbGVtZW50b3IncyBsaXN0IGlzIHRoZSBwbGFjZSB0byBkaXNjdXNzIGltcGxlbWVudGF0
aW9uLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmFuZCB0byByZWNlaXZl
IGFkdmljZSBvbiB1bmRlcnN0YW5kaW5nIGV4aXN0aW5nIHNpcC48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5UbyBzdWJzY3JpYmUgdG8gaXQsIHNlbmQgbWFpbCB0byA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5zaXAtaW1wbGVtZW50b3JzLXJlcXVl
c3RAY3MuY29sdW1iaWEuZWR1IHdpdGggJnF1b3Q7c3Vic2NyaWJlJnF1b3Q7IGluIHRoZSBib2R5
LjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg==

--0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





Content-Type: multipart/alternative;
boundary="----_=_NextPart_003_01C0C40C.43A8EE10"



------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/plain;
     charset="iso-8859-1"

Folks,

I took a stab at the new text for record routing. Its much, much more
verbose than rfc2543, and hopefully, as a result, will make it much clearer
what you need to do. Record-routing remains one of the most oft
misimplemnted features. This text incorporates everything in rfc2543 plus
all the decisions we've made on the list along the way. As you can see, the
structure is much more processing focused, rather than syntactic focused,
and much more explicit as well.

The text is in latex format. If you don't know latex, you should be able to
ignore all the slashes and brackets and still get the idea.

Please comment; alternate text related to those comments is requested.

-Jonathan R.




\section{Record-Routing}
\label{sec:rr}

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
\header{Record-Route} into the initial \INVITE request that begins the
call leg. The user agents use these headers to construct a set of
\header{Route} headers, that gets inserted into subsequent requests in
the call leg. The \header{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.

All user agents \MUST support the processing rules below which apply
to them. As such, they \MUST be able to parse and process both
\header{Record-Route} and \header{Route} headers. Proxies \MAY support
the record routing procedures of Section \ref{sec:rr:proxy}, but they
\MUST support the route header procedures of Section{sec:rr:proxy2}.

\motivation{This is a change from RFC2543, where all record-route and
route processing was optional for user agents.}

The syntax for the \header{Route} header is described in Section
XXX. The syntax for the \header{Record-Route} header is described in
Section XXX.

\subsection{UAC Processing for initial \INVITE transaction}
\label{sec:rr:uac}

The UAC formulates its {\em initial} \INVITE request for the call leg
as defined in section XXX. If the final response is a 200 class
response, it may contain \header{Record-Route} headers, and may
contain a \header{Contact} header. \annotate{Contact was not mandatory
in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might
not insert the \header{Contact} header. Thats why this text says that
the \header{Contact} may be present in the response. Note also that
this may is lower case; it is NOT saying that a UAS can optionally
insert the \header{Contact} header into the 200 class response.} The
UAC \MUST construct a {\em route set}, defined as a list of URLs, in
the following manner:

\begin{enumerate}
\item The list of URIs present in the \header{Record-Route} headers in
the 200 class response are taken, if present, and their order is reversed.
\item The URI in the \header{Contact} header from the 200 class response, if
present, is taken, and appended to the end of the list from the
previous step.
\item The list of URIs resulting from the above two operations is
referred to as the {\em route set}.
\end{enumerate}

The UAC \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the 200 class response. NOTE that since there
may be multiple 200 OK responses to an \INVITE request, each response
constitutes a separate call leg, and thus has a separate route
set. The UAC \MUST also remember whether the bottom-most entry in the
route set was constructed from a \header{Contact} header or not. This
is effectively a boolean value, which we refer to as CONTACT_SET.

The \ACK request for the initial \INVITE transaction \MUST be
formulated according to the rules of Section XXX, as if it were a
subsequent request within the call leg.

OPEN-ISSUE: Handling for non-200 responses, including provisionals
and certain 400 class responses. Are we supporting record-routing for
non-200 class responses? Record-routing for provisional responses is
discussed in the 100rel spec. What needs to be said here?

\subsection{UAS Processing of initial \INVITE transaction}
\label{sec:rr:uas}

When a UAS receives an \INVITE for a new call leg, and it responds
with a 200 class response, it \MUST copy the contents of the
\header{Record-Route} headers from the request to the response. This
includes the URIs, URI parameters, and any \header{Record-Route}
header parameters, whether they are known or unknown to the
UAS. \annotate{Record-Route parameters are very useful for
proxies. They allow the proxy to match the record-route entry in the
response with the one in the request.} The
order of the \header{Record-Route} headers \MUST be preserved in the
response.

The UAS \MUST construct a {\em route set} in the following manner:

\begin{enumerate}
\item The list of URIs in the \header{Record-Route} headers in the
\INVITE request, if present, are taken, including any URI parameters.
\item The URI in the \header{Contact} header from the request, if present,
is
taken, including any URI parameters. The URI is appended to the bottom
of the list of URIs from the previous step.
\item The resulting list of URIs is called the {\em route set}.
\end{enumerate}

The UAS \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the \INVITE request. The UAS \MUST also
remember whether the bottom-most entry in the route set was
constructed from a \header{Contact} header or not. This is effectively
a boolean value, which we refer to as CONTACT_SET.

OPEN ISSUE: this new text does not have the record-routes copied into
non-200 responses. RFC2543 talks about other failure codes, but is not
specific enough. Do we really need them in other response codes? If
so, we must list them explicitly.

\subsection{Proxy processing of an initial \INVITE transaction}
\label{sec:rr:proxy}

Each proxy \MAY independently decide to record-route an initial
\INVITE transaction. For a proxy, {\em initial} is defined
as any \INVITE request that does not contain a \header{Route}
header. Generally, the choice about whether to record-route or not is
a tradeoff of features vs. performance. Faster call processing and
higher scalability is achieved when proxies do not record
route. However, provision of certain services may require a proxy to
observe all messages for a call leg. It is \RECOMMENDED that proxies
do not automatically record route. They should do so only if
specifically required.

To record-route, the proxy inserts a \header{Record-Route} header into
the request before proxying it onwards. A forking proxy \MAY insert a
different \header{Record-Route} header into each forked request. The
\header{Record-Route} header that it inserts \MUST be inserted as the
first \header{Record-Route} header, appearing before any existing ones
in the request. The URL in the header \MUST be a SIP
URL. \annotate{This is because the URLs in the Record-Route headers
are used for forwarding requests by other proxies. Since no other URL
but a SIP URL is mandatory, a proxy could not be sure that any other
URL is interpretable by other proxies. Thus, SIP URLs are
mandatory}. The URL \MUSTNOT contain the transport
parameter. \annotate{Thats because only UDP is mandatory. If a proxy
inserts a transport parameter in the URL with TCP or TLS as the
transport, the proxy that ends up using that URL to forward the
request might not support that transport. The result, according to the
``Locating a SIP Server'' procedure, would be for the proxy to give
up.} The URL \MUST have the property that when the processing
described in Section XXX ``locaing a SIP server'' is followed for that
URL, the result of the lookup is an address/port of the proxy server
inserting the
\header{Record-Route}. The URL and the proxy configuration \SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to one of the previous-hop servers that the initial
\INVITE request traversed, including the UAS. \annotate{These two
properties are
important. The first one guarantees that subsequent requests from the
called party are routed back to this actually proxy. The second property is
there for robustness. It guarantees that the request URI always
contain meaningful information, even if there are no \header{Route}
headers that tell the proxy where to forward the request to next.} The
proxy \MAY insert
\header{Record-Route} parameters into the request. These will be
returned to the proxy in any 200 class response to the \INVITE, and
are useful for pushing state into the message.

If a 200 class response arrives for a proxied request, the response
will contain the entire list of \header{Record-Route} headers inserted
by proxies along the request path. The proxy \MAY modify the
\header{Record-Route} value matching the one it inserted into the
request. Like the URL in the request, it \MUST be a SIP URL and
\MUSTNOT contain a transport parameter. The URL in this
\header{Record-Route} header \MUST have the
property that when the processing described in Section XXX ``locating
a SIP server'' is followed for that URL, the result of the lookup is
an address/port of the proxy server that inserted the
\header{Record-Route}. The URL in this header, and the proxy configuration
\SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to the same next hop server that the initial
\INVITE request was forwarded to.

The four properties (two for the request, two for the response), can
be satisfied in a number of ways. One way is that the URI inserted
into the \header{Record-Route} in the request is the same as the
\header{Contact} header in the \INVITE (if present, else the
\header{From} field), but with the maddr and port set to
resolve to the proxy. Then, the proxy modifies the URL in the
\header{Record-Route} header in the response, setting it to be the URL
from the \header{Request-URI} of the initial \INVITE, but with the maddr
and port set to resolve to the proxy.

As an example, consider a proxy at 10.0.1.1 listening on port 5061
which receives the following request (many headers are omitted for
brevity):

\begin{verbatim}
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP callerspc.univ.edu
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The proxy forwards this request to
\header{sip:j_user@div11.example.com}, and record-routes:

\begin{verbatim}
INVITE sip:j_user@div11.example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:caller@callerspc.univ.edu
\end{verbatim}

The 200 response will look like, in part:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The proxy modifies its \header{Record-Route} header in the response to
and forwards the request upstream:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 ;myparam=9877
Contact: sip:j_user@host32.div11.example.com
\end{verbatim}

The route set computed by the UAS is:

\begin{verbatim}
sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1
sip:caller@callerspc.univ.edu
\end{verbatim}

and the route set computed by the UAC is:

\begin{verbatim}
sip:j_user@example.com:5061;maddr=10.0.1.1
sip:j_user@host32.div11.example.com
\end{verbatim}

There are other ways to meet these requirements. The proxy could
construct a URL for the request which encodes all of the needed
information, by placing it in the user portion, for example. A call
stateful proxy could insert a URL into the request with the form
sip:proxy.example.com, and not modify it in the response. This URL
clearly satisfies the first required property (of getting routed back
to the proxy that inserted it). The second property can be maintained
by being call stateful, and extracting the needed parameters from
local storage.

When a proxy does decide to modify the \header{Record-Route} header in
the response, one of the operations it must perform is to locate the
\header{Record-Route} that it had inserted. If the request spiraled,
and the proxy inserted a \header{Record-Route} in each iteration of
the spiral, locating the correct header in the response (which must be
the proper iteration in the reverse direction) is tricky. One
mechanism that is \RECOMMENDED is for the proxy to insert a
\header{Record-Route} parameter into the new \header{Record-Route} header
in the request each time the request spirals. This parameter \MUST
uniquely identify the proxy. When the 200 class respone arrives, the
proxy looks for the topmost \header{Record-Route} header containing
this parameter. This header is the one for the current iteration. The
proxy \MUST remove this parameter before forwarding the response
upstream. Upon the next iteration, the same algorithm (find the
topmost \header{Record-Route} header with the parameter) will
correctly extract the next \header{Record-Route}
header.


\subsection{UA Processing of Subsequent Requests in a Call Leg}
\label{sec:rr:uasubsequent}

When a UA wishes to send another request for the call-leg (such as a
\header{BYE} or \header{INVITE}), it follows the procedures defined in
this subsection. The
procedures here \MUST also be followed for an \ACK request for a 200
response to the initial \INVITE for the call leg. The procedures here
\MUSTNOT be followed for a \CANCEL request or an \ACK request for a
non-200 response. This implies that \CANCEL never contains a
\header{Route} header, nor does an \ACK for a non-200 response.

The request is constructed as specified in Section XXX. 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 any
URI parameters, are placed into a \header{Route} header into the request,
in order. The procedures of Section XXX ``locating a SIP server'' are
then applied to the URI in the request URI, the the request is
forwarded to the resulting server.

If a UAS has a route set for a call leg, and receives a re-INVITE for
that call leg containing \header{Record-Route} headers, it \MUST copy
those headers into any 200 class response to that request. If the
boolean variable CONTACT_SET is true, the \header{Contact} header in
the re-INVITE (if present) replaces the last
entry in the route set. If the boolean variable CONTACT_SET is false,
the UAS \MUST add the URL in the
\header{Contact} header in the re-INVITE to the bottom of the route
set, and then set CONTACT_SET to true. If the re-INVITE did not
contain a \header{Contact} header, the route-set at the UAS remains
unchanged.

Similarly, if a UAC has a route set for a call leg, and receives a 200
class response to a re-INVITE it sent, the \header{Contact} header is
examined. If not present, the route set remains unchanged. If the
re-INVITE response had a \header{Contact} header, and the boolean
variable CONTACT_SET is false, the URL in the \header{Contact} header
in the response is added to the bottom of the route set, and
CONTACT_SET is set to true. If the re-INVITE response had a
\header{Contact} header, and CONTACT_SET is true, the URL in the
\header{Contact} header of the re-INVITE response replaces the bottom
value in the route set.

The above two paragraphs allow a UA to update its \header{Contact}
address mid-call, but proxies cannot update their route address.  Once
on the route, a proxy remains on the route for the duration of the
call leg. \annotate{Why the different treatment for Contact and
Record-Route in a re-INVITE? It has to do with backwards
compatibility. RFC2543 did not mandate that a proxy needs to refresh
its record-route headers. As a result, the lack of a record-route in a
re-INVITE cannot be interpreted to mean that the proxy does not want
to be included on the route any longer. Updating of the Contact header
mid-call is useful for mobility applications, and is also useful for
forms of third party call control}.


OPEN-ISSUE: should the UA remove the maddr param, if present, if the
request is sent to the server at that maddr?

OPEN-ISSUE: should we mention handling of route with local outbound
proxies here? RFC2543 has some text on DNS-less UAs, but there are
issues with this.

\header{Proxy processing of a non-initial request}
\label{sec:rr:proxy2}

The rules in this section \MUST be followed when a proxy receives a request
that contains a \header{Route} header. The \header{Route} header is
used to forward the request to the next hop. It \MUST override any other
routing decisions that the proxy would otherwise make. Proxies \MAY
respond to requests with \header{Route} headers for any reason (in order
to perform proxy authorization, for example). But, if the request is
proxied, the procedures here \MUST be used to determine where the
request is proxied to. The procedures in this section apply indepedent
of the request method. They \MUST be followed even if the request
method is unknown to the proxy. \annotate{This last sentence is
really, really important. It allows for other methods, defined in the
future, to have record-routing applied to them. As an example, an
instant messaging session run over SIP might begin with a MESSAGE
request. That extension can allow for these sessions to be
record-routed by proxies that know of this extension. However, the
record-routing will only work if proxies that don't know about the
extension follow the Route headers properly. As such, supporting
\header{Route} headers for all methods, known or unknown, is very
important for a robust and future proof proxy implementation.}
Since \CANCEL can never contain
\header{Route}, these procedures never apply to \CANCEL. However, they
do apply to \ACK requests for a 200 OK response, which do contain
\header{Route} headers.

The proxy \MUST remove the top \header{Route} header from the
request. The URI from that \header{Route} \MUST be placed into the
\header{Request-URI} of the proxied request, including URI
parameters. Any URL parameters present in the top \header{Route}
header which are not allowed in the request URI \MUST be removed from
the \header{Request-URI} by the proxy. The procedures of section XXX
``Locating a SIP Server'' \MUST be followed to compute the next hop
server to forward the request to.

If the request is an \INVITE request (thus, a re-INVITE) for a call
leg that the proxy wishes to receive messages for (very likely the
case, since the request probably arrived at the proxy because the
proxy record routed in the initial \INVITE), the proxy \MUST
re-insert the
\header{Record-Route} header with the same value it placed in the
initial request. Similarly, it should modify the \header{Record-Route}
header in any 200 class response in the same way the
\header{Record-Route} header was modified in the response to the
initial \INVITE (which may be no modifications at all). The purpose of
this is twofold. First, it allows for proper record-routing in the
case of pre-loaded Route headers (see Section XXX). Secondly, it
allows for recovery from a UA crash and restart, in which case the UA
loses call state, and as a result, its route set as well. The result
is that the route set will be re-established through the
re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the
result is a robust way to recover from crashes.

\subsection{Pre-Loaded Route Headers}

Normally, a UA constructs the Route headers in a request from the
route set learned through \header{Record-Route} headers. However, in
some circumstances, it is useful for a UA to insert \header{Route}
headers into an initial \INVITE. These headers may have been learnt by
the UA through some out of bands means. When an initial \INVITE
(initial as far as the UAC and UAS are concerned) contains
\header{Route} headers, this is referred to as a ``pre-loaded
Route''. It is equivalent to strict source routing in IP. Proxies will
often not be able to distinguish this case from the case described in
Section \ref{sec:rr:proxy}, and will therefore properly use these
route headers to forward the request. If the proxies are interested in
receiving subsequent messages for the call leg, their insertion of
\header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will
establish a correct route set at both UAC and UAS. This route set may
end up being different from the pre-loaded Route used by the UAC. As
such, a UAC that inserts a pre-loaded route set \MUST follow the
procedures of Section \ref{sec:rr:uac} in processing the response to
this initial \INVITE.




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


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/html;
     charset="iso-8859-1"






[SIP] new record-route text!




Folks,




I took a stab at the new text for record routing. Its much, much
more

verbose than rfc2543, and hopefully, as a result, will make it
much clearer

what you need to do. Record-routing remains one of the most
oft

misimplemnted features. This text incorporates everything in
rfc2543 plus

all the decisions we've made on the list along the way. As you
can see, the

structure is much more processing focused, rather than
syntactic focused,

and much more explicit as well.




The text is in latex format. If you don't know latex, you should
be able to

ignore all the slashes and brackets and still get the
idea.




Please comment; alternate text related to those comments is
requested.




-Jonathan R.










\section{Record-Routing}

\label{sec:rr}




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

\header{Record-Route} into the initial \INVITE request that
begins the

call leg. The user agents use these headers to construct a set
of

\header{Route} headers, that gets inserted into subsequent
requests in

the call leg. The \header{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.




All user agents \MUST support the processing rules below which
apply

to them. As such, they \MUST be able to parse and process
both

\header{Record-Route} and \header{Route} headers. Proxies \MAY
support

the record routing procedures of Section \ref{sec:rr:proxy},
but they

\MUST support the route header procedures of
Section{sec:rr:proxy2}. 




\motivation{This is a change from RFC2543, where all
record-route and

route processing was optional for user agents.}




The syntax for the \header{Route} header is described in
Section

XXX. The syntax for the \header{Record-Route} header is
described in

Section XXX.




\subsection{UAC Processing for initial \INVITE
transaction}

\label{sec:rr:uac}




The UAC formulates its {\em initial} \INVITE request for the
call leg

as defined in section XXX. If the final response is a 200
class

response, it may contain \header{Record-Route} headers, and
may

contain a \header{Contact} header. \annotate{Contact was not
mandatory

in RFC2543. Thus, if the UAC is talking to an older UAS, the
UAS might

not insert the \header{Contact} header. Thats why this text
says that

the \header{Contact} may be present in the response. Note also
that

this may is lower case; it is NOT saying that a UAS can
optionally

insert the \header{Contact} header into the 200 class
response.} The

UAC \MUST construct a {\em route set}, defined as a list of
URLs, in

the following manner:




\begin{enumerate}

\item The list of URIs present in the \header{Record-Route}
headers in

the 200 class response are taken, if present, and their order
is reversed. 

\item The URI in the \header{Contact} header from the 200 class
response, if

present, is taken, and appended to the end of the list from
the

previous step.

\item The list of URIs resulting from the above two operations
is

referred to as the {\em route set}.

\end{enumerate}




The UAC \MUST store the route set for the duration of the
call

leg. NOTE that it is possible for the route set to be empty.
This will

occur if neither \header{Record-Route} headers nor a
\header{Contact}

header were present in the 200 class response. NOTE that since
there

may be multiple 200 OK responses to an \INVITE request, each
response

constitutes a separate call leg, and thus has a separate
route

set. The UAC \MUST also remember whether the bottom-most entry
in the

route set was constructed from a \header{Contact} header or
not. This

is effectively a boolean value, which we refer to as
CONTACT_SET.




The \ACK request for the initial \INVITE transaction \MUST
be

formulated according to the rules of Section XXX, as if it were
a

subsequent request within the call leg. 




OPEN-ISSUE: Handling for non-200 responses, including
provisionals

and certain 400 class responses. Are we supporting
record-routing for

non-200 class responses? Record-routing for provisional
responses is

discussed in the 100rel spec. What needs to be said
here?




\subsection{UAS Processing of initial \INVITE
transaction}

\label{sec:rr:uas}




When a UAS receives an \INVITE for a new call leg, and it
responds

with a 200 class response, it \MUST copy the contents of
the

\header{Record-Route} headers from the request to the response.
This

includes the URIs, URI parameters, and any
\header{Record-Route}

header parameters, whether they are known or unknown to
the

UAS. \annotate{Record-Route parameters are very useful
for

proxies. They allow the proxy to match the record-route entry
in the

response with the one in the request.} The

order of the \header{Record-Route} headers \MUST be preserved
in the

response.




The UAS \MUST construct a {\em route set} in the following
manner:




\begin{enumerate}

\item The list of URIs in the \header{Record-Route} headers in
the

\INVITE request, if present, are taken, including any URI
parameters.

\item The URI in the \header{Contact} header from the request,
if present,

is

taken, including any URI parameters. The URI is appended to the
bottom

of the list of URIs from the previous step.

\item The resulting list of URIs is called the {\em route set}.


\end{enumerate}




The UAS \MUST store the route set for the duration of the
call

leg. NOTE that it is possible for the route set to be empty.
This will

occur if neither \header{Record-Route} headers nor a
\header{Contact}

header were present in the \INVITE request. The UAS \MUST
also

remember whether the bottom-most entry in the route set
was

constructed from a \header{Contact} header or not. This is
effectively

a boolean value, which we refer to as CONTACT_SET. 




OPEN ISSUE: this new text does not have the record-routes copied
into

non-200 responses. RFC2543 talks about other failure codes, but
is not

specific enough. Do we really need them in other response
codes? If

so, we must list them explicitly.




\subsection{Proxy processing of an initial \INVITE
transaction}

\label{sec:rr:proxy}




Each proxy \MAY independently decide to record-route an
initial

\INVITE transaction. For a proxy, {\em initial} is
defined

as any \INVITE request that does not contain a
\header{Route}

header. Generally, the choice about whether to record-route or
not is

a tradeoff of features vs. performance. Faster call processing
and

higher scalability is achieved when proxies do not
record

route. However, provision of certain services may require a
proxy to

observe all messages for a call leg. It is \RECOMMENDED that
proxies

do not automatically record route. They should do so only
if

specifically required.




To record-route, the proxy inserts a \header{Record-Route}
header into

the request before proxying it onwards. A forking proxy \MAY
insert a

different \header{Record-Route} header into each forked
request. The

\header{Record-Route} header that it inserts \MUST be inserted
as the

first \header{Record-Route} header, appearing before any
existing ones

in the request. The URL in the header \MUST be a SIP

URL. \annotate{This is because the URLs in the Record-Route
headers

are used for forwarding requests by other proxies. Since no
other URL

but a SIP URL is mandatory, a proxy could not be sure that any
other

URL is interpretable by other proxies. Thus, SIP URLs
are

mandatory}. The URL \MUSTNOT contain the transport

parameter. \annotate{Thats because only UDP is mandatory. If a
proxy

inserts a transport parameter in the URL with TCP or TLS as
the

transport, the proxy that ends up using that URL to forward
the

request might not support that transport. The result, according
to the

``Locating a SIP Server'' procedure, would be for the proxy to
give

up.} The URL \MUST have the property that when the
processing

described in Section XXX ``locaing a SIP server'' is followed
for that

URL, the result of the lookup is an address/port of the proxy
server

inserting the

\header{Record-Route}. The URL and the proxy configuration
\SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing
will cause

it to be forwarded to one of the previous-hop servers that the
initial

\INVITE request traversed, including the UAS. \annotate{These
two

properties are 

important. The first one guarantees that subsequent requests
from the

called party are routed back to this actually proxy. The second
property is

there for robustness. It guarantees that the request URI
always

contain meaningful information, even if there are no
\header{Route}

headers that tell the proxy where to forward the request to
next.} The

proxy \MAY insert 

\header{Record-Route} parameters into the request. These will
be

returned to the proxy in any 200 class response to the \INVITE,
and

are useful for pushing state into the message.




If a 200 class response arrives for a proxied request, the
response

will contain the entire list of \header{Record-Route} headers
inserted

by proxies along the request path. The proxy \MAY modify
the

\header{Record-Route} value matching the one it inserted into
the

request. Like the URL in the request, it \MUST be a SIP URL
and

\MUSTNOT contain a transport parameter. The URL in this

\header{Record-Route} header \MUST have the

property that when the processing described in Section XXX
``locating

a SIP server'' is followed for that URL, the result of the
lookup is

an address/port of the proxy server that inserted the

\header{Record-Route}. The URL in this header, and the proxy
configuration

\SHOULD be

such that if a request is received with this URL in the

\header{Request-URI}, the proxy's normal request processing
will cause

it to be forwarded to the same next hop server that the
initial

\INVITE request was forwarded to.




The four properties (two for the request, two for the response),
can

be satisfied in a number of ways. One way is that the URI
inserted

into the \header{Record-Route} in the request is the same as
the

\header{Contact} header in the \INVITE (if present, else
the

\header{From} field), but with the maddr and port set to

resolve to the proxy. Then, the proxy modifies the URL in
the

\header{Record-Route} header in the response, setting it to be
the URL

from the \header{Request-URI} of the initial \INVITE, but with
the maddr

and port set to resolve to the proxy. 




As an example, consider a proxy at 10.0.1.1 listening on port
5061

which receives the following request (many headers are omitted
for

brevity):




\begin{verbatim}

INVITE sip:user@example.com SIP/2.0

Via: SIP/2.0/UDP callerspc.univ.edu

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The proxy forwards this request to

\header{sip:j_user@div11.example.com}, and
record-routes:




\begin{verbatim}

INVITE sip:j_user@div11.example.com SIP/2.0

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:caller@callerspc.univ.edu

\end{verbatim}




The 200 response will look like, in part:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.1.1:5061

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1>

Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The proxy modifies its \header{Record-Route} header in the
response to

and forwards the request upstream:




\begin{verbatim}

SIP/2.0 200 OK

Via: SIP/2.0/UDP callerspc.univ.edu

Record-Route:

 <sip:j_user@example.com:5061;maddr=10.0.1.1>;myparam=9877



Contact: sip:j_user@host32.div11.example.com

\end{verbatim}




The route set computed by the UAS is:




\begin{verbatim}

sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1

sip:caller@callerspc.univ.edu

\end{verbatim}




and the route set computed by the UAC is:




\begin{verbatim}

sip:j_user@example.com:5061;maddr=10.0.1.1

sip:j_user@host32.div11.example.com

\end{verbatim}




There are other ways to meet these requirements. The proxy
could

construct a URL for the request which encodes all of the
needed

information, by placing it in the user portion, for example. A
call

stateful proxy could insert a URL into the request with the
form

sip:proxy.example.com, and not modify it in the response. This
URL

clearly satisfies the first required property (of getting
routed back

to the proxy that inserted it). The second property can be
maintained

by being call stateful, and extracting the needed parameters
from

local storage.




When a proxy does decide to modify the \header{Record-Route}
header in

the response, one of the operations it must perform is to
locate the

\header{Record-Route} that it had inserted. If the request
spiraled,

and the proxy inserted a \header{Record-Route} in each
iteration of

the spiral, locating the correct header in the response (which
must be

the proper iteration in the reverse direction) is tricky.
One

mechanism that is \RECOMMENDED is for the proxy to insert
a

\header{Record-Route} parameter into the new
\header{Record-Route} header

in the request each time the request spirals. This parameter
\MUST

uniquely identify the proxy. When the 200 class respone
arrives, the

proxy looks for the topmost \header{Record-Route} header
containing

this parameter. This header is the one for the current
iteration. The

proxy \MUST remove this parameter before forwarding the
response

upstream. Upon the next iteration, the same algorithm (find
the

topmost \header{Record-Route} header with the parameter)
will

correctly extract the next \header{Record-Route}

header.






\subsection{UA Processing of Subsequent Requests in a Call
Leg}

\label{sec:rr:uasubsequent}




When a UA wishes to send another request for the call-leg (such
as a

\header{BYE} or \header{INVITE}), it follows the procedures
defined in

this subsection. The

procedures here \MUST also be followed for an \ACK request for
a 200

response to the initial \INVITE for the call leg. The
procedures here

\MUSTNOT be followed for a \CANCEL request or an \ACK request
for a

non-200 response. This implies that \CANCEL never contains
a

\header{Route} header, nor does an \ACK for a non-200
response.




The request is constructed as specified in Section XXX. 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
any

URI parameters, are placed into a \header{Route} header into
the request,

in order. The procedures of Section XXX ``locating a SIP
server'' are

then applied to the URI in the request URI, the the request
is

forwarded to the resulting server.




If a UAS has a route set for a call leg, and receives a
re-INVITE for

that call leg containing \header{Record-Route} headers, it
\MUST copy

those headers into any 200 class response to that request. If
the

boolean variable CONTACT_SET is true, the \header{Contact}
header in

the re-INVITE (if present) replaces the last 

entry in the route set. If the boolean variable CONTACT_SET is
false,

the UAS \MUST add the URL in the 

\header{Contact} header in the re-INVITE to the bottom of the
route

set, and then set CONTACT_SET to true. If the re-INVITE did
not

contain a \header{Contact} header, the route-set at the UAS
remains

unchanged.




Similarly, if a UAC has a route set for a call leg, and receives
a 200

class response to a re-INVITE it sent, the \header{Contact}
header is

examined. If not present, the route set remains unchanged. If
the

re-INVITE response had a \header{Contact} header, and the
boolean

variable CONTACT_SET is false, the URL in the \header{Contact}
header

in the response is added to the bottom of the route set,
and

CONTACT_SET is set to true. If the re-INVITE response had
a

\header{Contact} header, and CONTACT_SET is true, the URL in
the

\header{Contact} header of the re-INVITE response replaces the
bottom

value in the route set.




The above two paragraphs allow a UA to update its
\header{Contact}

address mid-call, but proxies cannot update their route
address.  Once

on the route, a proxy remains on the route for the duration of
the

call leg. \annotate{Why the different treatment for Contact
and

Record-Route in a re-INVITE? It has to do with backwards

compatibility. RFC2543 did not mandate that a proxy needs to
refresh

its record-route headers. As a result, the lack of a
record-route in a

re-INVITE cannot be interpreted to mean that the proxy does not
want

to be included on the route any longer. Updating of the Contact
header

mid-call is useful for mobility applications, and is also
useful for

forms of third party call control}.






OPEN-ISSUE: should the UA remove the maddr param, if present, if
the

request is sent to the server at that maddr?




OPEN-ISSUE: should we mention handling of route with local
outbound

proxies here? RFC2543 has some text on DNS-less UAs, but there
are

issues with this.




\header{Proxy processing of a non-initial request}

\label{sec:rr:proxy2}




The rules in this section \MUST be followed when a proxy
receives a request

that contains a \header{Route} header. The \header{Route}
header is

used to forward the request to the next hop. It \MUST override
any other

routing decisions that the proxy would otherwise make. Proxies
\MAY

respond to requests with \header{Route} headers for any reason
(in order

to perform proxy authorization, for example). But, if the
request is

proxied, the procedures here \MUST be used to determine where
the

request is proxied to. The procedures in this section apply
indepedent

of the request method. They \MUST be followed even if the
request

method is unknown to the proxy. \annotate{This last sentence
is

really, really important. It allows for other methods, defined
in the

future, to have record-routing applied to them. As an example,
an

instant messaging session run over SIP might begin with a
MESSAGE

request. That extension can allow for these sessions to
be

record-routed by proxies that know of this extension. However,
the

record-routing will only work if proxies that don't know about
the

extension follow the Route headers properly. As such,
supporting

\header{Route} headers for all methods, known or unknown, is
very

important for a robust and future proof proxy
implementation.}

Since \CANCEL can never contain

\header{Route}, these procedures never apply to \CANCEL.
However, they

do apply to \ACK requests for a 200 OK response, which do
contain

\header{Route} headers. 




The proxy \MUST remove the top \header{Route} header from
the

request. The URI from that \header{Route} \MUST be placed into
the

\header{Request-URI} of the proxied request, including
URI

parameters. Any URL parameters present in the top
\header{Route}

header which are not allowed in the request URI \MUST be
removed from

the \header{Request-URI} by the proxy. The procedures of
section XXX

``Locating a SIP Server'' \MUST be followed to compute the next
hop

server to forward the request to. 




If the request is an \INVITE request (thus, a re-INVITE) for a
call

leg that the proxy wishes to receive messages for (very likely
the

case, since the request probably arrived at the proxy because
the

proxy record routed in the initial \INVITE), the proxy
\MUST

re-insert the

\header{Record-Route} header with the same value it placed in
the

initial request. Similarly, it should modify the
\header{Record-Route}

header in any 200 class response in the same way the

\header{Record-Route} header was modified in the response to
the

initial \INVITE (which may be no modifications at all). The
purpose of

this is twofold. First, it allows for proper record-routing in
the

case of pre-loaded Route headers (see Section XXX). Secondly,
it

allows for recovery from a UA crash and restart, in which case
the UA

loses call state, and as a result, its route set as well. The
result

is that the route set will be re-established through the

re-INVITE. When coupled with the Session Timer \cite{RFCXXX},
the

result is a robust way to recover from crashes.




\subsection{Pre-Loaded Route Headers}




Normally, a UA constructs the Route headers in a request from
the

route set learned through \header{Record-Route} headers.
However, in

some circumstances, it is useful for a UA to insert
\header{Route}

headers into an initial \INVITE. These headers may have been
learnt by

the UA through some out of bands means. When an initial
\INVITE

(initial as far as the UAC and UAS are concerned)
contains

\header{Route} headers, this is referred to as a
``pre-loaded

Route''. It is equivalent to strict source routing in IP.
Proxies will

often not be able to distinguish this case from the case
described in

Section \ref{sec:rr:proxy}, and will therefore properly use
these

route headers to forward the request. If the proxies are
interested in

receiving subsequent messages for the call leg, their insertion
of

\header{Record-Route} as mandated by Section \ref{sec:rr:proxy}
will

establish a correct route set at both UAC and UAS. This route
set may

end up being different from the pre-loaded Route used by the
UAC. As

such, a UAC that inserts a pre-loaded route set \MUST follow
the

procedures of Section \ref{sec:rr:uac} in processing the
response to

this initial \INVITE.










---

Jonathan D.
Rosenberg                      


72 Eagle Rock Ave.

Chief
Scientist                            


First Floor

dynamicsoft                                


East Hanover, NJ 07936

jdrosen@dynamicsoft.com                    


FAX:   (973) 952-5050

http://www.cs.columbia.edu/~jdrosen        


PHONE: (973) 952-5000

http://www.dynamicsoft.com

 




_______________________________________________

SIP mailing list

SIP@lists.bell-labs.com

http://lists.bell-labs.com/mailman/listinfo/sip





------_=_NextPart_003_01C0C40C.43A8EE10--






--0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58
Content-type: application/msword; 
	name="loop.doc"
Content-Disposition: attachment; filename="loop.doc"
Content-Description: Mac Word 3.0
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAFAAAAAAAAAAA
EAAAFgAAAAEAAAD+////AAAAABMAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWQAJBAAACBK/AAAAAAAAEAAAAAAABAAAIgQAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA
AAAJBBYALhQAAJE9AQCRPQEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA
AAAAAAAAkgAAAAAAAADiAAAAAAAAAOIAAAAAAAAA4gAAABQAAAAAAAAAAAAAAPYAAAAAAAAA9gAA
AAAAAAD2AAAAAAAAAPYAAAAAAAAA9gAAAAwAAAACAQAADAAAAPYAAAAAAAAAMgMAALYAAAAaAQAA
AAAAABoBAAAAAAAAGgEAAAAAAAAaAQAAAAAAADABAAAAAAAAsQIAAAAAAACxAgAAAAAAALECAAAA
AAAA9wIAAAIAAAD5AgAAAAAAAPkCAAAAAAAA+QIAAAAAAAD5AgAAAAAAAPkCAAAAAAAA+QIAACQA
AADoAwAA9AEAANwFAAA2AAAAHQMAABUAAAAAAAAAAAAAAAAAAAAAAAAA4gAAAAAAAACxAgAAAAAA
AAAAAAAAAAAAAAAAAAAAAACPAgAAIgAAALECAAAAAAAAsQIAAAAAAACxAgAAAAAAAB0DAAAAAAAA
0QIAAAAAAACSAAAAAAAAAJIAAAAAAAAAGgEAAAAAAAAAAAAAAAAAADABAABfAQAAGgEAAAAAAADR
AgAAAAAAANECAAAAAAAA0QIAAAAAAACxAgAAEAAAAJIAAAA4AAAAGgEAABYAAADiAAAAAAAAADAB
AAAAAAAA9wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9gAAAAAAAAD2AAAAAAAAAJIAAAAAAAAAkgAA
AAAAAACSAAAAAAAAAJIAAAAAAAAAsQIAAAAAAAD3AgAAAAAAANECAAAmAAAA0QIAAAAAAAAAAAAA
AAAAAPcCAAAAAAAAygAAABgAAADiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9wIAAAAAAAAwAQAAAAAAAA4BAAAMAAAAUC9dQErH
wAH2AAAAAAAAAPYAAAAAAAAAwQIAABAAAAD3AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA0T
IEVNQkVEIFZpc2lvLkRyYXdpbmcuNiAgFAEVDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA
AQQAAAIEAAADBAAAGwQAABwEAAAeBAAAIgQAAPoA+gDy+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwNqd4qGPgoIAVUIAVYIAQkDagAAAABVCAEABwAEAAAC
BAAAHwQAACAEAAAhBAAAIgQAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAFAAQAAAIE
AAAhBAAA/v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQIcAB+w0C8g
sOA9IbAIByKwCAcjkKAFJJCgBSWwAABgIRvwCAgAAH08TgbJfZuvk3wrzPT/BkiOIQAAAAAAAAAA
AAAqEAAA0gYAAGAhYADYpCgA1gcAAAD+eJztWWtsVEUUPnP3zuNCa9stLdVUXR7FQnTdXVrbGklL
EIKJaCJSizZxeWmaVF2olookamLA4CNiJDFpwfjP4A/RgiEgPhIN+IBsDEj84yuSxmdt0FiVUs+5
j927u/eyu7X4nu3sOTNzzuzMOec7M/eWgQEQOFwOMAUGpgIW+p4jyiA8/ZZlSxYx6gIGpT9bFKBk
utllUmo/grUeK84DZ8oA3heQKp3XAgzVAoQWL1tC0qTzNPZLrCgKa225N4MAe2tQl+ZlkFHa4TpY
jvVG5K+FDbAKNkIX3A132uN1pINVATzk8Bz5m5Bez6w1DoyPj7vnfCr9G6GFOGcXztoNEy5vPv5j
EF44HYSBJ0Y3NmC7Ddsrr/zE5Ee/GXvwR/y9L7FvGlZAW2uotHn1UehEOhiEPlzeWAL5l5GvWR/o
Uyg3+AH0kU0fR0qys+NHQb7aEAdrf/D1e99t5PYCqswdlUM5yniVEPZ34pyzbmuOO1svX+st6xSW
KoG4Y1fSdfgL0Mb1rv4pYG4tVQy7PQe/jmNMzEG+1palorlk3fMHPXiSvQxrjUvPcWmdS6YdLMVT
wvr9hfi1DgdakB8STewrUc2GxU8wKo4Dl/ugSj4L9XIztMo10CGXQY9sge1yLuyRtZCUlTAiS6FS
TYVGVQrtqhJ6VS3sUHNhULXAMbUMhtQaOKs2Q4XxLMww9kHYOA5Nxk+wwKhmrUYTW2CsZE3GJhY2
+tkM4wCrME6ys+o0G1Il2jE1UxtUV2k71BKtVy3X2lWn1qhWa5VqjTYiV2tJ2antkcu17XKJ1iOv
0jrkTK1Vlmj18jSrkicZlwfYqOjH/WzCfa1ktD83Fty+ceOi3mWvC22ebOnghfrPL16Ogv7xe+bv
2rH/RgjSsZ/8PjP2SRZlxkm2Ffuo/Vm3FbvPtL1tUke3ZjgITbbuZbauI5vmg3Dk4rfhwuCsOK3h
OOoEhqEv/oVGaxlvxvZjzW23k+zBillxU8fWbVvjj5k0XmbF3THp8KVo+2qbr4HMuK2xeYDM+L8Z
K9n5eUyYpdjxCDo2Yee0FSu2ti0c2NpGYyuYlROuz1rTuF06kF9k+qwbohCDpdhuxlpt12bIxJp7
zRPB7S1YZ2PtwdqIHScRjy12bN0HTexEgbHqhf+s4wG8chPNSbngcqxJ/O0QI/wD3IBUN/tCJl6S
4gZGvN8Z4l6XF1bO/9nyx7GSXFk4VhzZNF8YVkiWsGLq2LrFYsXtPz+sMDg3VojZhmQM60vo73gW
VmhsMXZcAv5YeRQobrsgAVdDo4mWKETwY31HoA25BjxRwkhpNGyOEI3BfByJQRpTtTYtpN6R1c7W
zdfOh9+AvU8v/AYg/7mrp+2UoUv97nP3Ht06d+keaJ27O/lX4gE+LG7lo6KFc3kRr5Jjer38XG+V
R/QO+YreI3fp2+WT+h75sJ6UffqI3KBXqvV6o9qgt6s+vVc9rO9QT+qDapd+TL2iD6kj+ln1uV5h
jOkzjIt42GjhTcatfIHxAG81diJ9HdufYj+IGcalosK4RpxVHWJIrRfH1FYxqPrFDvWi6FX7Rbt6
SzSqw6JSvStG5GGRlG+JPXK/2C5fFD2yX3TIraJVrhf1skNUyWsEl5eKUQFiWHyK+3qd0/68clkA
vM9dspdXLqH+PzOXdI8EIQTF5ZJQZ+G5xJFN84XlEpKlXGLq2LrF5hId8ucSHQo7d3u4de5+xHPP
3YO8mHMXHprIuVsMbuncjYD1PGaeu+iQ5+w10n30hFl/0eYB1cLi1olP6j/0N4/PRBH3woTrXpgo
4l6YsO+FCftemJjAvdBtY7/4DEBmfHrFhvP85xUbHLzvZOTnfm7dySg2SJdi4YRPHuOQ/07GIbPU
eehm38m2cOtOtpc7d7ItZi5Nir2c+Hx3MprbK49S//95dHLyqNt/fnHKIf+dbB2S1Si4Df39TlYe
pbHdvNg7Wcy8i8X+4Xcy51WZF34FeON3gWHh99uyNH7pzvN1mTd+BeTHr+uVXc4avPB7qszCL73v
c/B7qmwLP4NrOFW2lxOfD780txd+qf/vjt8fphSOX0c2zReGX5Il/Jo6tm6x+HX7zw+/AvLjd5Nh
4fe5slz80th/Db8XIJ1m77Hc5gkDAabMfDjVBDRxJdqHYl45YgB+1bhjE1P2Cma9Bz+jOcFt9TJz
Fb9pAzYCUrEfWriha9W5ot7S12z9cnN2gNec5KItv7/n3nV35dMPmPQHnMdadTo7OfMT1XCdFtXs
XThPhpaUDr1IZwda/hPvXR1/OpZzPGm1dTMSmEb2OR++ZZo2szDf6iYNs5rUfLQyQ3MkyKv0f5nY
lBXseUlji1Z1d0dhKaKhGj/NKZ8783nHCE/NRuN1AS311i/TUjzDUu5Yyp2NtErMmNJz3t+5Z03b
nU+a3bmP/biH/RpM+y1m28yM2NOVuLoxGotGIvgXaYs2tISj0Vg4GomFY/MbYqZNa7Hmfu6waa0P
LcwToiC0Shda//1vazJjUGRFjZy0qBE+USN8UXeQ/xHUydRsdD7VBbjnM3/m7mXWqXNognuVPnuV
WXv1X73KyRnOU2nmilVBOcORcueMzOdL75yhJs37ysciyjdn7Obr3DkjFonE/pKcYeR4wnm+yPSE
UZAnjBxPZD8peHvCmDRPGD6eMM7hiU3Gn+sJ6y3f78huhP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAgAAEQAZAAAAAAA
AAACAAAAAAAAAAAAAAAAAMEmYxDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP
AATwMAAAALIECvAIAAAAAQQAAAAKAAAjAAvwDAAAAARBAQAAAP8BAAAIAAAAEPAEAAAAAAAAwDIA
B/A0CAAAAwR9PE4GyX2br5N8K8z0/wZI/wAQCAAAAQAAAEQAAAAAAJ4CYCEb8AgIAAB9PE4GyX2b
r5N8K8z0/wZIjiEAAAAAAAAAAAAAKhAAANIGAABgIWAA2KQoANYHAAAA/nic7VlrbFRFFD5z987j
QmvbLS3VVF0exUJ03V1a2xpJSxCCiWgiUos2cXlpmlRdqJaKJGpiwOAjYiQxacH4z+AP0YIhID4S
DfiAbAxI/OMrksZnbdBYlVLPuY/du7v3sru1+J7t7Dkzc87szDnnOzP3loEBEDhcDjAFBqYCFvqe
I8ogPP2WZUsWMeoCBqU/WxSgZLrZZVJqP4K1HivOA2fKAN4XkCqd1wIM1QKEFi9bQtKk8zT2S6wo
CmttuTeDAHtrUJfmZZBR2uE6WI71RuSvhQ2wCjZCF9wNd9rjdaSDVQE85PAc+ZuQXs+sNQ6Mj4+7
53wq/RuhhThnF87aDRMubz7+YxBeOB2EgSdGNzZguw3bK6/8xORHvxl78Ef8vS+xbxpWQFtrqLR5
9VHoRDoYhD5c3lgC+ZeRr1kf6FMoN/gB9JFNH0dKsrPjR0G+2hAHa3/w9XvfbeT2AqrMHZVDOcp4
lRD2d+Kcs25rjjtbL1/rLesUliqBuGNX0nX4C9DG9a7+KWBuLVUMuz0Hv45jTMxBvtaWpaK5ZN3z
Bz14kr0Ma41Lz3FpnUumHSzFU8L6/YX4tQ4HWpAfEk3sK1HNhsVPMCqOA5f7oEo+C/VyM7TKNdAh
l0GPbIHtci7skbWQlJUwIkuhUk2FRlUK7aoSelUt7FBzYVC1wDG1DIbUGjirNkOF8SzMMPZB2DgO
TcZPsMCoZq1GE1tgrGRNxiYWNvrZDOMAqzBOsrPqNBtSJdoxNVMbVFdpO9QSrVct19pVp9aoVmuV
ao02IldrSdmp7ZHLte1yidYjr9I65EytVZZo9fI0q5InGZcH2Kjox/1swn2tZLQ/NxbcvnHjot5l
rwttnmzp4IX6zy9ejoL+8Xvm79qx/0YI0rGf/D4z9kkWZcZJthX7qP1ZtxW7z7S9bVJHt2Y4CE22
7mW2riOb5oNw5OK34cLgrDit4TjqBIahL/6FRmsZb8b2Y81tt5PswYpZcVPH1m1b44+ZNF5mxd0x
6fClaPtqm6+BzLitsXmAzPi/GSvZ+XlMmKXY8Qg6NmHntBUrtrYtHNjaRmMrmJUTrs9a07hdOpBf
ZPqsG6IQg6XYbsZabddmyMSae80Twe0tWGdj7cHaiB0nEY8tdmzdB03sRIGx6oX/rOMBvHITzUm5
4HKsSfztECP8A9yAVDf7QiZekuIGRrzfGeJelxdWzv/Z8sexklxZOFYc2TRfGFZIlrBi6ti6xWLF
7T8/rDA4N1aI2YZkDOtL6O94FlZobDF2XAL+WHkUKG67IAFXQ6OJlihE8GN9R6ANuQY8UcJIaTRs
jhCNwXwciUEaU7U2LaTekdXO1s3XzoffgL1PL/wGIP+5q6ftlKFL/e5z9x7dOnfpHmiduzv5V+IB
Pixu5aOihXN5Ea+SY3q9/FxvlUf0DvmK3iN36dvlk/oe+bCelH36iNygV6r1eqPaoLerPr1XPazv
UE/qg2qXfky9og+pI/pZ9bleYYzpM4yLeNho4U3GrXyB8QBvNXYifR3bn2I/iBnGpaLCuEacVR1i
SK0Xx9RWMaj6xQ71ouhV+0W7eks0qsOiUr0rRuRhkZRviT1yv9guXxQ9sl90yK2iVa4X9bJDVMlr
BJeXilEBYlh8ivt6ndP+vHJZALzPXbKXVy6h/j8zl3SPBCEExeWSUGfhucSRTfOF5RKSpVxi6ti6
xeYSHfLnEh0KO3d7uHXufsRzz92DvJhzFx6ayLlbDG7p3I2A9TxmnrvokOfsNdJ99IRZf9HmAdXC
4taJT+o/9DePz0QR98KE616YKOJemLDvhQn7XpiYwL3QbWO/+AxAZnx6xYbz/OcVGxy872Tk535u
3ckoNkiXYuGETx7jkP9OxiGz1HnoZt/JtnDrTraXO3eyLWYuTYq9nPh8dzKa2yuPUv//eXRy8qjb
f35xyiH/nWwdktUouA39/U5WHqWx3bzYO1nMvIvF/uF3MudVmRd+BXjjd4Fh4ffbsjR+6c7zdZk3
fgXkx6/rlV3OGrzwe6rMwi+973Pwe6psCz+DazhVtpcTnw+/NLcXfqn/747fH6YUjl9HNs0Xhl+S
JfyaOrZusfh1+88PvwLy43eTYeH3ubJc/NLYfw2/FyCdZu+x3OYJAwGmzHw41QQ0cSXah2JeOWIA
ftW4YxNT9gpmvQc/oznBbfUycxW/aQM2AlKxH1q4oWvVuaLe0tds/XJzdoDXnOSiLb+/5951d+XT
D5j0B5zHWnU6OznzE9VwnRbV7F04T4aWlA69SGcHWv4T710dfzqWczxptXUzEphG9jkfvmWaNrMw
3+omDbOa1Hy0MkNzJMir9H+Z2JQV7HlJY4tWdXdHYSmioRo/zSmfO/N5xwhPzUbjdQEt9dYv01I8
w1LuWMqdjbRKzJjSc97fuWdN251Pmt25j/24h/0aTPstZtvMjNjTlbi6MRqLRiL4F2mLNrSEo9FY
OBqJhWPzG2KmTWux5n7usGmtDy3ME6IgtEoXWv/9b2syY1BkRY2ctKgRPlEjfFF3kP8R1MnUbHQ+
1QW45zN/5u5l1qlzaIJ7lT57lVl79V+9yskZzlNp5opVQTnDkXLnjMznS++coSbN+8rHIso3Z+zm
69w5IxaJxP6SnGHkeMJ5vsj0hFGQJ4wcT2Q/KXh7wpg0Txg+njDO4YlNxp/rCest3+/IboT/AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAA
BgAAAAcAAAAIAAAACQAAAAoAAAD+////DAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAAP7////9
////FQAAABgAAAD+////OQAAADoAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA
AAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAA/v//
/zEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA/v///zsAAAD+////PAAAAD0AAAA+AAAA
PwAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////w0A
AAAGCQIAAAAAAMAAAAAAAABGAAAAAOANNUBKx8ABkDxgQErHwAEXAAAAgA0AAAAAAABEAGEAdABh
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAA
EAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAaAAIBDAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAC4UAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQEPAAAA/////wQAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAFAvXUBKx8ABkDxgQErHwAEAAAAAAAAAAAAAAABfADEAMAA0ADkAMAAwADQANgA2ADMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAABAf//////////BgAA
ABMaAgAAAAAAwAAAAAAAAEYAAAAAUC9dQErHwAFQL11ASsfAAQAAAAAAAAAAAAAAAAEATwBsAGUA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK
AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQA
AAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAABIAAgEFAAAACAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAAcQAAAAAAAAADAE8AYgBqAEkAbgBmAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAEAAAAAAAAAP7///8CAAAA/v////7////+////BgAA
AAcAAAAIAAAACQAAAAoAAAALAAAADAAAAP7///8OAAAADwAAABAAAAARAAAAEgAAAP7///8UAAAA
FQAAABYAAAAXAAAAGAAAABkAAAAaAAAA/v///xwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAj
AAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEA
AAAyAAAAMwAAAP7///81AAAA/v//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////AQAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////xMaAgAA
AAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFZpc2lvIERyYXdpbmcAEQAAAFZJU0lPIDYuMCBTaGFw
ZXMAEAAAAFZpc2lvLkRyYXdpbmcuNgD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQA
AAAF1c3VnC4bEJOXCAArLPmuJgEAAOIAAAAHAAAAAQAAAEAAAAAAAACASAAAAA4AAABQAAAADwAA
AFwAAAACAAAAaAAAAAwAAAB0AAAADQAAAKwAAAACAAAA5AQAABMAAAAJBAAAHgAAAAEAAAAAAAAA
HgAAAAEAAAAAAAAAHgAAAAEAAAAAAAAADBAAAAQAAABWAGkAcwBpAG8ARABvAGMAdQBtAGUAbgB0
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAACAAcAAAAKAAAA/////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAAD9LAAAAAAAAFYAaQBzAGkAbwBJ
AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAIA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABwAAAAA
AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACgAAgEJAAAACwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAwAAAAGBAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A
cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAUAAADiAQAAAAAAAFZpc2lvIChUTSkgRHJhd2luZw0KAAAAAAAA
BgD9LAAAAIQBABQAAABkmegvfCsAAIEBAABSAAAAAADtbOrxAxrp8v///4MA//by//P78AcB+PEA
iYDq8RYEgBYAIAAZAID/AMDAwADm5ub/AM3NzQCzs7PvAJqamiEAgABm/2ZmAE1NTQAz/zMzABoa
GgDvf+/vAPr6+gAFJOvwGNz/BAoFJOvwGNz/BApVGOvw//LwMevwOOjzQPr0Bw8ZD+H69vHq8Rnj
+P0M6/ABAFRkAAD/IAAAQXJpYWzqQAIR5/QQTgUCAgC/AFdpbmdkegBz6kACG+f0FW0JTW9u/290
eXBlIFNvq3J0gQMr5/QNTgMA/nQCU3ltYm9sADVU6/A/6PPQP/L/BAba6vEg6PNZQBoGAAAZAS0A
MQ8AAFUa6/D/8vAf6/Ac6POg+vQHD+vw9vHq8Urn9AQ66/BE6/ABAFQxAejzgPLxRQ9XD/Lx4Pst
AerxaOrn9A/r8FTr8AIAVIUY6/A83/yMAYwB5vUBrpECAAADKgQF6/AGquvwB+vwCOvwCevwCqrr
8Avr8Azr8A3r8A7q6/CT4/gvwAJVAQH5AboB3wECAGIBANX+DRIBExYCExYDYk8AAP6FuATq8YkA
E/8wehSuR+F6hKU/tgNA5vW/AQI4ExBAkQJIFhYVMhAhF2sSA1cWrhYTBGICFRQFgRYGKoEWB4EW
CKURhrwE6vEBVQAUsgrsGA0eghorF58UJBQVrhKHwATq8dkAE1AT4OvwTC9eJjkTXiTgPyAMeyDy
8O9B6BhrE14mjhMVAZksApksA5knJS+NFIkGdiaOEwd/JsYVghUJKoEWCjERoHkI4AATCw8AuQMN
FIIVgBmCFSApghWuH1DAGw4/IDINEguBFgyBFlUNgRYOgRYPgRYQgRZVEYEWEoEWEzERpMgEiurx
7TI//WsCORLbAQKvAGEA/kJCAUhFAqpIRQNIRQRIRQVIRQaCSEUHSECgP7I+1z/pOmBUMhBCQhFI
RRJIRRNIRVUUSEUVSEUWSEUXSEUlGEhAhMwE6vERJU85Egmj0ATq8UYAEzdBT1lAO1ANE8xBFxNz
VgJzVgPMQSGn1ARnFUxUa1m32ATq8Y33ABMgIFcWzV9XFggRCN9f/F/6FyAVFiFgsyOolRePHWsS
BDRsBZUcBoNiCJQ2dWBrEvJXjhMJKjRsCjRsC5UXvdwE6vH9sSVZ8D+IE4gTUDo/LVwNF6MjIe4r
AhJ8UQMSdEtmMnwFMnwGMnxJBzJ3ike+4ATq8VEAFEECHFXzbxAbphBUTQFlRSTWdHRBv+QE6vHS
JV8IjwA4FUJPVE9mT3hPik+yP8Q/SKxP6D/6N8DoBOrx3LsAWPp1uwFXFMA/643Q/I5Z2A6e8ohz
VTSR5TKWAAqPVJ8YjyqPPI9Oj2CPco9AhI+WgRQVoo+0hGsSECGWSo4TERCsEv2GjhMTMKypFA+W
jhMVUKwWEKwXJhCsGCAzlY4TGZCnDRKVGoEWGzERkuwE6vGdAPd/3K/urwC/Er8kvza/4/x3Aw0Z
wAQBABtbtQMBabgEuwH68ZQEfAWzCS7kFwAAlOP4vMuvaRA3JwAwNJJVxVAS/WkQVz9pP3s0THrw
eRSRMvcjVMm2epMIeJUJeJUKeJWlC3iVDHiQCqMwlhZqULwEdr+Iv+P4leP4yLK3bF4vy8YhM97C
879qxkJqxgE2RIwvni+wL/4kUQwwcN7EPxNNZGrHXmNqxxCMNBQVwhjMQWtbtn7PkM8C5faI4/gk
WWtVMRElAbsFADEP/t8E4sMBEu1Gu9UVhAUCLQEokQdrEXANndm7CfMJQS4AHxIfJBSNljUZLUIf
EAJpYBjvt9EZI94d6BzvtwI5KZtGL1D/4vl2L4gvDt8AIN++L3U/hzJ0wXK/nN+czwJLtlO4zzUP
3M/uxzIQ+8kAjDfh0XjF7d+iDxHvI+82GARA5WixJE3n7nVMtWixygkA5dWD75Xvp++578vv3e/v
7wAB/xP/Jf/e1IrVkQ/3H/0SAPMVDym5HzzpjxGA8E/lmVUAhxsRGyMfNR9HH4uYOvHcBb4681Uy
HMdxySCsAT/IL9om3AN3/4n+2iaj9AoVPAIVPAMVN+HRSOHp3wD0H7EPww8x70+yHFFqwVDkAFPh
SLkcUZt5d+lI4RxBdC+Qhi+YL1kfT7JHwiRf6QBwf6WNGg80y/sBYgQlRiEXoh+0H8YfOPtxwi/U
I1A/D5hD8i+J/QJO3ANe3AUEwnGkaOhFIQlAZCluAwTcAnuUAely9TFQsQMxCUCBBx8vq09xldZ0
fVGElAEh/m6/+v8MD6S6PbK5a+VAxrHshal7hUInxBGmyYJYAVbZUF8wVLFOSmfl2TL1MQD1MZRS
1TVQIpRRlFFbwU8iAFAhtKFxklvBinK0obSh7nIAinGKcdOC7nHuccKi04HTgQEPULHCocKhV+L9
Yf1hN9EkVuJX4RLF1TfRE1CxJHEiJHEUULExcTFxFVCxPnEiPnEWULFLcUtxF1CxWHEAWHHFMmVx
ZXFascQyU+FvYgBasVqxZLFTslSx4VFjsmSxER1QseFR4VEeULHh0dkxBEjhWzwEaz/odKth9n1Z
7yDgD/IPBB8WH020LwZPGE/oKkT5t2QZM3EUTxvoL7SBTmsHUwFcT5L1ALiGOfKYRcEvAJ/lLwxf
CT8AGz8tPz891V/nX/lfpLqxhAS4vhCUvNG3J8PglnPPlp9kqJ+py0ksD0+vADBSDwDdN24FT7KG
3xSvJq+82qthAMyX4dGrYVc/T+DofwkvGy8Aoj8qjzyPTo9gj3KEd4B8j3KOjwOksWQfVTB7eRkI
xo8/Z6EcN6FNt0a6SKO5AH1FoIKFn6evua8LanAUz54LMFWswsU4bt7UUCHNfwDff+rGrCH4zQ6P
NS9HL1kvAGsvbI+fv7G/oo+0j+e/2I8AT89hz3PPup+Xz96f8J8CrwD73w3vOK9Kr1yvbq+Ar5Kv
AHXvh+/Ir9qtulPwr+PPFL8AJr84v0q/XL9uv4C/kr+B3wC2v8i/2r/sv/6/EMYkctwCBCPPBQES
Cg5Lzwb/GP8a7wCTz6XPt8++Q8/P4c9OFslhAFwdEN8i3zTfRt9Y32rfAw8AFQ+g37LfSw/W37MP
xQ/XDwAe7/sPQu9U72bvXy9xL5zvAK7vwO/S7+Tv9u/ZL+svLP8A2q3JYVL/ZP92/4j/mv+s/wC+
/9D/4v/0/+MfGA8qDzwPgCsvYA8OyP1i/WKHD2lBDwBuRgFVrw9qP3w/fi/3DwkfABsfIkO2P8g/
slbjYcBd9z8ECUmEYSgaRwpycGwvWURFQGExTE/XH3BP+x+fI1EUL4itSRxTv0cGFFHbjYRCBAJR
ZghRYc5Jf3FfVYIP9YUIeWoQnx9/AbUSKJ8dyIRCBwViAhZfKF86X4EvXl8ApS+3L8bC1FGXX6lf
B4ZhMQAVjdhfCU8bTy1PtEbBH1pPAFFvfk3OQQslEsTqb48LQ8UApQyOQbUVmk+sT75NZ395fyCL
f05fr39yX7zMDk+UNxwBAQCP6JRagfadZ5+GH5gfQKofvB86b52Pr48ELEuAbwAtn1h5Q8WuYsNk
ZHDNZGRwAMfB4UHNn9+f8Z8DrxWvJ69AOa9Lr12vFsR2r0HHAkLLKI5Ps69ulgShbATFwz0jAO5/
G7/cP+4/No9Ij1qPbI8Alb+Qj3+vtI/GjvUn4Y+2vwAFnxefvK87n02fX59xn4OfCJWfp58fHREg
zzLPRM9WzwBoz3rPjM+ez7DPws/Uz+bPAPjPCt8c3y7fQN9S32Tfdt8AiN+a36zfvt/Q3+LfIxl9
AQAE7xbvKO8670zvXu9w74LvIJTvpu+478rv3O9VyZHbjwKSBw74jyL/NP9G/1j/av9AfP+O/6D/
sv/E/4hYE+L/APT/Bg8YDyoPPA9OD2APcg8AhA+WD6gPug/r794PD/8CHwAUHyYfOB9KH1wfbh+A
H5IfBKQfh1kUwx/VH+cf+R8LLwAdLy8vQS9TL2Uvdy+JL5svEN1G4fG6L/xMEtwv7i8APwASPyQ/
Nj9IP1o/bD9+P5A/AwAVpD+2P8g/2j/sP/4/ABBPIk80T0ZPWE9qT3xPzA8AoE/wD8RP1k/oT/pP
DF8eXyAwX0JfVF9mX72ZFoVfl18AqV+7X81f31/xXwNvFW8nbwA5b0tvXW+ORnhvqU+cb65vAMBv
0m/kb/ZvCH8afyx/Pn8EUH+BUBdmf3h/in+cf65/AMB/0n/kf/Z/CI8ajyyPPo8gbqGXQnNnY468
RQGSZoaPAJiPqo+8j86P4I/yjwSfFp8AKJ/02bSRSp9cn26fgJ+SnwCkn7afyJ/an+yf/p8QryKv
AJFPZY+1T2qvfK+Or6Cvsq9AxK/Wr+iv+q8Mv/fWGSi/ADq/TL9ev3C/gr+Uv6a/uL8Qyr/cv+6/
AMxCqyN20ViEuFSHK8GEU2KgAInAYn/hAHqEAABAdo8ANsBNz1/HVINvz4HGNsCNzwCfz7HPw8/V
xRbC4s9p7d3xARoJ3xvfLd8/31HfY9913wCH35nfq9+938/fAM+tLALrAMovLe8/72XBWYNb74HG
r/CAee+L753vr+/B79Pv5ewbAPXvB/8Z/yv/Pf9P/2H/c/8Ahf+X/6n/u//h3xLGCNHs/xQxxYRS
ARbk6x7pFQ9azABzYzwPgcaTYFoPbA9+D5APANXFc2KvDzYtnzFSI9sP7Q8A/w8RHyMfNR9HH1kf
ax99HwCPH6Ef0v+mBs4feDs2xQEvAEbvJS9q70kvWy9tL38vkS8Eoy+1KR3CL9Qv5i/4Lwo/ABw/
Lj9AP1I/ZD92P4g/mj8AoAZZj1RWDQV8j+o/Ys8OTwCGzzJPRE9WT87Pek/yz2FxAR6jT7VPx0/Z
T+tP/U8PXwAhXzNfRV9XX2lfe1+NX59fALFfw1/VX+df+V8Lbx1vL28AQW99eF5vSwz/DAEAAFxc
M0P/T00tQ09SUFz/aHA1c2lfbmH7dDLk9wEEAQOcfwBwAANzAQAcAX4MBAAPAFgCAh0A/iwBAABM
ZXR0ZcFy3P9PD2EPcw/m9SAAjf+QACUD6POQAZABAL8AEgAEABGPAAFFAJUBAasCIAGsAQKbBtzL
D6ADAAAY6fIQJwDsAeoBfAX9PuvwCAARACgA/wEAd2luc3Bv/29sAFxcM0NP/00tQ09SUFxo/3A1
c2lfbmF0fzIATmUwMTrc/lVG6/D/8vAC6/BE6PNm+vQAAvHyDg///+rxUB8N4Pv28erxaD4IIOvw
LwEAVBjr8Ag2D0QGqurxAevwkuP4gwYCVW1B6PMIQJsNwD+tBdu/Sejz8D+/BgQAwQhZAdcP6Q/7
D3sH/wPS6vG3gQTq8U+VAxAQMUDm9TMfRRYEBEUfYh9PAcMAZYEEhAEcWgehBAgdHxiQBeb1CpUD
BQLr8EgFEuslAerxIPPwAAAX/u/ylf9W+A/////wA///wAH///+AAP//AAB//m8AAD/8FwMf+B8P
BCkFGQF/PgEWABEADAEIAf0HBQAf6/8B+IP/iIz/gwACCIj/iv8HAH///3D/CI+I/wHwhf/3AvCI
cAAHhf8DL/cIj4ZxAId1AYMA7QeHAPcIgwAPiP+vAgiPhHUAf5kAcA6dAAHwiXUApw+5D50FGwFw
lQMBD4wB4gSGAOMB8HkB3gRzAAFwitv/BmkCD4tgAAEPA9b//Tvr8EdlbmVyaf9jIGNpcmNsZf8g
b3IgZWxsaf9wc2Ugd2l0aP8gdGV4dCBhbv9kIGNvbm5lY/90aW9uIHBvaR9udHMuAACtYuP44L/0
9D/8/L//G+i0gU4b4L9FHBUDPxwFFAXn9MA0Cw3w+/Twv5VI6/D/8vAE6/Tr8ERE6/D28QPp8vLx
EQ0G7/QkIwnk9wECBD0FaOf09vEtKD4CVBjr8BDf/PbxVEUFPQUCBgSb4/hFQQBvAgBVQejz+D+n
DdXwuA7gygdRNgnPA20WiQEEdYwAYCDMBZsF/uwCBXUJAPYJajYGAQIFPgQBBB4R6vEDBwAeFTAT
jAEwEwkBMBMk9vE6FwodEl4SBUYVYhOKchIFGBIDHhZtEiwSAQAyFpsSQBKbEkoSmxJUEqUWIQqH
EmgchxJ8E4Q+BOrxtR2JAlU1DQAMiQECf4BMAABA/qOJBErq8Xv5E/3y8C8h/jQk/DULpwECAWA3
Q2//cHlyaWdodCD/MTk5OSBWaXP/aW8gQ29ycG//cmF0aW9uLiDfIEFsbCBZInMg/3Jlc2VydmVk
by4A/hyJAmASZCD/X1NCbC5jaG3/ISMyMjQ1MAAb/qAGBgAAZAH8HDkJiWw+CF0DVWQPdg+ICYm4
4/gJAfwRAQeK7RhapLcjpwQATCLPAgHrIgJdAPICYgAAABQBCB2q7CEDRRYK6yIDrxYKiwGQHSia
OzrJD9IG8PM/UOb19wTwPwEQklU5AWI/+wkC8g1VMgMkCBLxNwXyAggSBvEymzHCriWSOz+6P+jz
0j8BEPUPiQJyQQEKAMD+GpNCAZlDAcALTx1OYTbKN04OHSgNXgPm9XRlT3h0AHEGBB4RLF4HQRTf
/B4RKBWEDfbxmeP4yVZVSsc4QOb1eVYAAAH8PCJBAewCWjO8TWoz8TIEVFHwFVxhX84DeV+LX/IP
APg/u1MgJWBbSDjiX/RZVT8AGG+7U64lYF9TbVpv/V+mXwB6YlRRRQWha7U4um9jb+w/AAhr1cDr
8Ejr8Gzr8CcA9y0AAunyn/AFBfUD6/D/DAAAAL0h/wDAT3mOYQAA/QH99AAAR0XTEVMBtA4B5PcG
5/RG6/D/jJ3oL04PAADdouvw1gAj6/D8AlfpL/BLAMg/Agrr8D8Em+gvuBBAA2QDX2SU6C/+bwAB
6/D3RAAr6/Akn+gv5f9vACk/AvLxvJ7ovy8oEQAAh/7w1gEAlR7r8ALr8B3z9OnyIQQABPLxAFVG
6/D/8vAD6/BE6PNm+vQAAfHyDg///+rx0B8N4Pv28erxaAIGAAAtHAYCVBjr8ATf/FUB1FUB5vWS
4/iU6/ACAFtVQOjzCECXBj/o89vAP6kFv0no8/A/YLsGZA3cD+4PAB8B92ICdRGRAQOpBhP+b3EI
qFkPaw/n9Kjj+FGRA/1o8vB1ETIDATMQAQF1EeoFAvz28BORAmAJQ/9vbm5lY3RvcvcA/gqRAQFg
AAAV/pYSCpwaZZECMR9DH3J3CoPj+KkSAFUF6/ABSAES66QB6vEg8/AAAJb+7/KN/16Af////79/
//4Df//8+gsA+AsA8AAAB/T/A3/39Ad/9/e1nyAAHyAEgAAtA/99fDUMcBf3/2BJAt4WAf//YB9W
AD//3/99g/8BYAEBwf//AfiDeAF/i/f/AfdhAI+K/wb/8zgzM/9/iv//gwADA/+Pif//B/MP//8D
/3/vif8Fh44AB4eH/wGPg/8Hfw/53pABhf8Bf6AAjwCfmZAP/4+qAJ8C/5n5XQCpBv8AjgC3B/D+
wgcDj//wgzMBz4ODM4K5AhMBhgCTBAPDAHUBhcsBkAD/gp8AAakAvgAMEQIfFB+P3/8zkzM/LBbw
CfeZAD8eFvD/n/D+RxGHeAZw///w5XiTAAZeENwAiv8Cf3/wgwCL/wQmEO+PjP8EBAB/jP8Ng50A
tP/9Q+vwVGhpcyBj/29ubmVjdG9y/yBhdXRvbWF0/2ljYWxseSBy/291dGVzIGJl/3R3ZWVuIHRo
v2Ugc2hhcBMAaQ109vVzLq1i4/jgv/T0P/z8v/8b6LSBThvgvwUcFQM/HAUUBfT/BguVSOvw//Lw
A+v06/BEiuvwBOvwAeny8vERDQxA7/QjCeT3CQH28T0FaOf0tQjr8DgGAlQY6/AgkN/8WQFZATkJ
AkIEBQEFquvwB+vwBuvwm+P4Rt4JAAIAVUDo8/g/qrcN8MgGv7cE4L8F4Nu/UDYKAhyJAnUK7wAA
YHUjAGAD5P9iAgAGgEEAALtA/vwCAXULBBENSgkcF4kBAgcSAhIELhhRAyMSHhJEFBpCAQKYAeYJ
AQEEmAEjAQEAG9aJAQR1jABgaATgP1UFXBgDaBYFchYBfBJTBXX28IYeFYkBBu0GWhITDokBB2Ha
GQjnFR2dBgYAAI6JArYF0AZ7AEAZLfA/AQ9iEkiXAmwSOycCYhxFLQFoFpJvJwOXHHkonIkE6vEH
/LEK4ggychzHcRx/x+E/QJ/0Sc0ga88/wyTRyyW/P+0Kp0AAFv0Dgxv+9iIBVrcc/io1E0wEEIEJ
Ab0tFBBiBQBy6vEDLwfABYGMAQleG3YS1JwSdhIE9iIDKDJ1HyYEEIAuFBH2IgRxMgE4aRCYFnYS
BfYiBXVoAAIAOaBCCGQBtAAAJjwGBwBPL00AowIE6vF7CiOJ/fLw9jH++zQ1C/wDYP8SVmlzX1NC
bP8uY2htISMyMp80NzQA/hMQGxBg/zdDb3B5cmln/2h0IDE5OTkg/hxAaW8gQ29ycP9vcmF0aW9u
Lr8gIEFsbCA8QnP/IHJlc2VydmUfZC4A/qSVBOrxNBKPAFUIAowBoiP+MQJ/AAEIIwQAp50Emurx
EfA3AQAfEBdBAU8wAP6EmQTq8SvFNFDe/WondhJROGw+CCQGAkFVZAEzC0MDRQWECYkZXF60AAEB
D4r+GDQKKkwUENQVAQCSMfokYpYACJEyEDSEUoufKF5b0Ah3WwhEIIhazFFpiQQJAfwBYQSo5zU5
Ccw5lOP4M8xPAN8AECcAMsUicbwBPy9nOzLpR9XA6/BI6/Bs6/B1APctAALp8iT6BQX1G+vw/wwA
AAC9If8AwE95jmEAAPcBAB3+8wBHRdOnERm0DgHk9wbn9Eb+6/BcnekvWxQAuwDO6/DWACPz8bv/
6i8pFQAANwH6QAEK6/AUmOkvYCEWJAA/AmYB6vGnbwDq8fdEACvr8ISo6S/ygAEiPwLy8Tym6S81
yW8Az/7w1gAAAB0AAAAAAFVs6/A06/As5/QB9/X/PvwHcwZvG0D/EnTaQKcNB0DS4/gCHwTq8Qvr
8EQwf+ovLxoAAAbr8JVBLQIkMwA1NwAiAUEA+fYAACEAAAAAAAAAAABVbOvwNOvwLOf0Afv1/z78
B3MGbxtA/xJ02kCnDQdA0uP4Ah8E6vEL6/B8MX/qL30aAAAG6/AVQS0CjDMAgzcG+vVVVuvwFOvw
Nt/8A+f0/UDr8Jwx6i83GpcAAEbr8FLc/w0CjC806i+JFwBCGwIFQOvwNNz/BA8WDygCBUDr8DTc
/wQPFg8oAlVW6/AU6/A23/wD5/T9QOvw1DPqL/galwAADevwUtz/DQIUHzXqLwUbGAWVouvwKOvw
btz/4foC6uvwBef0HuvwbJzovy+vEwAAmevwU/sAyevwNJ3oL0i3FAAAKwAAQiECTP+X6S+YGQAA
l/ovAj/r8CQx6i/L7xoAAC3r8FIARHxHAV0AEhsAACtlAgASBQUg6/AU3P8EBlUV6/D/8vCB6/BQ
6PN4+vTx8tz/AADwvw8PUDQP5Pf28erxRuf0BOvwnUTr8AEAVGUB6vEDgPHyeQ8LA4oN4PthAerx
aGrn9ALr8CC9AlQY6/ChCN/8wAHAAeb1Aevwkvrj+INxAlVJPvwH/3MGbxtASRJ0f9pApw0HQD/o
81vAPxgVv0kbBD8qFuDvAT8fUR9jH+L5Af8DUmABm+wE6vGRABNA5vWGnB3wP64doxgBBesCz+MD
EHEB4wLvAQEEFpa9AQR1wABgxAHp8gXV/uESA+cWBfESBXUkDCD7GW/oFevwHMUHsAVU5wk8Gajj
+FEAE/3y8DR3IZ0DAe8AAQF3IesC9fwMIBO9AmAJQ2//bm5lY3RvcgD7/gq9AQFgAAD+qpgiCp4q
Zb0EBuvwMADFB8sB4vnQIdAh5wnAAQwhgmEBBfwE5vWrIQMQ7wFIAPoGPBUfNAwhKjfjBR80wAEA
KjcMIhw3YQEqN7AFHzQPMaAqNw8xGzjQISozyWs4hsq9AlAMIR3VNO8BER8Y6/DlMcABESHr8PIx
YQEBEXAfEE8iTzRPRk8pMu8BALc1aQRhAfMjPBXy8Q8xfA9AiAfpB/MlDzG4BQwhJMUHgQzf/Awh
bjX7KYkR5vVF+pYUQAgSC0BACDo/baDTBgNArh/AFHHgMldwIecGDwCEihiYGBEDEEgtAC4IIgc1
AYUCflYDYQGCUmACglIBpaTgCBdhWTwT/psCAQrDASiKGDzFAzwfGQYYFFvwP5FP///vAXG9BAoP
MSzFBxTf/A8xqDX7LwcAAJnj+NQhmRc6Vr4fAMFX6vFmYeNVcm81W5JvpGYi4wVklh/Ib9pvGnEC
fl9rAQMvcgE1fwEDZmEAbjW1b54fHH9lYrAF+GsxX5iPfyp4kl8BAUlz738BwwEOazgdgcgA5vVD
YR9sbDEAaQqGNy9JL+rl9pTj+CNhXwAAEK8nADJVmoLFGBIBxYDr8GwMNGEB0FECAEFVywHhEaQN
VYn/KYnZTsJwIYqKGDZh/G85UAAABZDgCDizf79vLRPSFvwUAP1RK5FuNTebBn/JeGKfKDMAzCVm
T+AIg0+VT6dPuUnAD5jSD+QM/E9VQAcTFlAQH+i0gU4bgG9Fn0NfsFVfZ18IIq+FAQLhpgMo0CGW
U/WmAdBfVOMJ718AAW9CtSyhH28xb0NvVW9nbwBQn8t/nW+lv5efyb/lb/dvAP+/Ec8tdeGvR3Vu
z2F/8r8AhX8Wz6l/j6/DzyV99a8BhQAo3xuPLY8/j1GPY491j4ePAJmPq4+9j8+P4Y/dSsmhBJ8A
N88on+7P+r9en3Cfgp+C78Cmn7iaBzXNnG4zQr///wDQISv95QuwBe8BJKVgv3K/yNlMe9X4TQ7v
AL/hfvj/D+YM3vg/QAZEGlXjAwYgVb/A4wP23Oh/RBdddNFFx9xRbwGIAy0poQJ11ED7YHWrIGAE
5GICrwAHdQ0EAQsJBgNdgP4wQP4iKaEGEghmAgiAEiUBslECAAcCKgICAw0BBkoDARcCEgIcWwTx
H+A/BXgDHCqLAWDhEwwh6xMHI6sGBZ2KGP0IsfTgw38wZ/BPxj9ABBpVEFMHF1fXAQMp/fJw/yUH
AN0ABBcBAIAYAEB6CTMlAf4CAwQfFh7JQTNzCDEjqwaqBwZQEqoHXx9xFQBOcusSnRdpHboHpx9x
ELehQhy1K7vfKnd9X49QhWs4rrrUME8bfaFrN7MBUgTWAkgiPyKH4MhHCVO9MsfVMhzHcXEgrLE/
Zy/jUze04D8woOAGK/DvQVP07pHk0RthxUfg9tLUT+ZPLKEn71UBAaUPPekqvO9T9AJ5AgAMfwm3
QP6LTKgPNcr+KD+mPLEF/mLTQ+MnY9tz/2lwOjUxMjEw/TCfMDBAMTQ5Lv8xMTIuMTAyLgcyMzR2
0qsFg9+V36ffALnfy9/d1FpBnFXNnByzO0UA6p9bS/vXTfksoSSlO6GowQA0pDehA0n/oTupLhj+
ohXx8l+pkwlUuPP/P0AMf3TaQKcN9z9TNLcPwEA7o/6/UzT/Db8AVO6/5uZW80sCAQkJgKIgSQQD
Egg7U6UD7NFKxSEB+tIDkVJiUgHFCem4bKTrAw/yB0CAD7//wZzBqz97pgGBDP4COBPs0TYVvFIa
HwEAt1/JXlhXrBOlAnrWEWRtUiKvAgOlAgiCLWOcTKhYsXhQNwdQ+9PovzJycSK/4T9An/RJcmDP
FT9oZNFwZb+a51bzZzl/+N5777333owFrQGVA6SZvmHZjAC/QtYoJvs44jnQPfvSpxWoNCQA1AH9
K/ABAGkAK6AfYAEwAP63ocZB6B/A+h0Jjwe/NKDOPSy/8L8GW0///+zR5NHCRZND9tIAnk8md1X1
FCVRQf+h7S//LTAWMRM/+qJnPwCAr2tFhyhAMdklHoXhm3LPA9c3i/9zEEIIIYSwvwBNj1+H48Vx
jmBlio+cj71nAEAxiPUehfhG1Y9vO/WPB5WAP/UXngFVMJ9Cn3M72SUJAIo7BfLo1Qb/Uk8q/zz/
Tv8gYP9y/4T/lv+o/Xy58vVAAKdVJYTxALnM9UDe7vb/CA8AGg8sDz4PUA9iD3QPhg+YD8CRwq8J
frbED9YAnl5APoDsBadW/QU+ETIV2LbNXwMA178/H2nG3jN+tn23cxQpzwA7zofCxhNXz7oVcc87
yeAfADZ/BCPRlTvDGC8qLzwvTi8AYC9yL4Qvli+oL7ovzC/eLwD/fwI/I49jPzg/4N2jqPvfOHc/
iT+bMTIwMHLgpT8Atz/JP9s/7T//PxFP2JLKQQDVn+ef+Z8Lrx2vL69Br1Ov/GWvd69VQB/+gzkH
g3cVxbcm766vwK/SrwDkr/avCL8avyy/Pr9Qv2K/AHS3ykGCuagGl7+psL6zklAMvva18jcbxbiw
VRHB5VUEAhbtvwEBHxLPUGKoBlIXEKcHRsRTH2UeAagGmhdmHQC3B6QfsM/Q70V2++V/E1xzAPHP
A98V3yffOd9L313fb98Agd+T36Xft9/J3xjv7d//3wAR7yPvIj9H71nva+9974/vAKHvs+/F79fv
6esBAAAAAgAAAAIAAAAAAAAAEVUS6fIC6/Ad6/Af6/ABIdzwAAAAAAAAVWzr8DTr8Czn9ATr8P0B
//E+/AdzBm//G0ASdNpApw1LB0Dj+AIfBOrxC+vw/wwx6i+xJAAA9RHr8EMtAjQw6i8VwjcABuvw
QenyAgFVMuvwFOvwEt/8Aef0/UDr8PQp6i/IJDcAAE3r8FIABUjr8Dzc/wQPFg8oClUy6/AU6/AS
3/wB5/T9RevwRCrqLzQlNwAADevwUgBVbOvwFOvwTOP4Aevw9QTn9BXr8HS/6C//qxsAAPUIAAD3
0wDJ6/Acregv36AkAAAR6/BAAP0/6/Bkr+gvFSV3AAAf6/BSAETr8AXUEwBBOwZVAQUk6/AY3P8E
CgU06/Ao3P8EDxYIVTHr8P/y8Afr8Cjo8zUc6/AM3P8AA+vw9vGq5vUB6/AC6/BPIghEwiYCVT0B
6PPy8VEP//8gSgVmCeD7KQHq8WgiCAEBLwIAVBjr8AR5D4cGKurxvOP4KxYCVXYP6w++JwAHBgAA
yYUIHoImAlEtAbcKGQEZAS0BAAFIKgQ5DygAVA9ZExkBZx2gqQ+MD54PsA/p8pvj+EUCFgJR7g/w
HwIvFCwBAAAAR3VpZGUAAQAAAFRoZURvYwABAAAAUGFnZS0xAPUT6/AB6/BHZXN0/3VyZSBGb3Jt
B2F0AAEAAABCbG9jayBOb3JtYWwAAQAAAFZpc2lvIDEwAAEAAABCbG9jayBTaGFkb3cAAQAAAFZp
c2lvIDEyAPUU6/AB6/BCbG9jf2sgSGlnaGz98AN0AAEAAABWaXNpbyAxMQABAAAAQ29ubmVjdG9y
AAEAAABWaXNpbyA5MAD1EuvwAevwRG90IP9Db25uZWN0bwNyAPUU6/AB6/BDb25u/2VjdG9yIEFy
D3JvdwABAAAAVmlzaW8gMDAAAQAAAFZpc2lvIDAxAAEAAABWaXNpbyAwMgABAAAAVmlzaW8gMDMA
AQAAAFZpc2lvIDEzAAEAAABWaXNpbyAyMAABAAAAVmlzaW8gMjEAAQAAAFZpc2lvIDIyAAEAAABW
aXNpbyAyMwABAAAAVmlzaW8gNTAAAQAAAFZpc2lvIDUxAAEAAABWaXNpbyA1MgABAAAAVmlzaW8g
NTMAAQAAAFZpc2lvIDcwAAEAAABWaXNpbyA4MAACAAAAQ2lyY2xlAAAAAAABAAAAQ2lyY2xlLjIA
AAAAAPUW6/AC6/BEeW5h/21pYyBjb25uP2VjdG9yAN8QAwAAGOvw7AKXAAAe4/giAwTq8TP+6/CM
gOkvayYAqwAK6/BFEQKcFwB1qhsACx8GvBcAgC0KpE+B6S+LGwDy8Uc1A+pNAKMbABEfBoyC6asv
tBsADR8GzHEAwepjCuRxANJ1CiyG6asv31EKRKcA93UKXL6nAAQnAAAOHwZ0UqcAEs8AeAeMpwAf
zwBVF1UGpKcANs8AGVUH+qcAT+EK1IfpL1zq4QrsJRBp4QoEiOmrL3bhChxJEIPhCjSqSRCQ4QpM
SRCd4QpkqkkQquEKfEkQt+EKtPpJEMThCvSL6S/RvuEKDIzpL97hCiSq2RDr4Qo82RD44QpUJtkQ
BSiaCk0AEhMgMAdVbNkQHRMgBB8GhNkQVSETKnwXAC43KrzZECUyEyAbVQLq8QHr8PfwqQDv8Dki
BevwBuvwB4rr8Ajr8Anr8B4BMAEMiOvweAHSAQ/r8evwZgESquvwE+vwFOvwFevwFpDr8PYB8vEI
ERrr8HAhHFLr8B3r8PrxH+vwIOvwASHc8BUS6fIV4/gB3PBVauX2BOvwBevwBuvwVQfr8Ajr8Anr
8Arr8FUL6/AM6/AN6/AO6/BVD+vwEOvwEevwEuvwVRPr8BTr8BXr8Bbr8FUX6/AY6/AZ6/Aa6/AF
G+vwHNzwAAAAAAAAVWzr8DTr8Czn9Brr8P0B//E+/AdzBm//G0ASdNpApw1LB0Dj+AIfBOrxC+vw
/7xF6i/gKQAA1VXr8EMtAqwzADUqFwAABuvwQenyAgEAAAEAAAADAAAAAABVbOvwNOvwLOf0Atz/
6N3+/vH+9Qvr8HQv6r8viCoAAArr8EFKLQJsMwCSNwD+8UHp8gEBEABfHAEAABTr8Pzf/IEO3P8Y
DyoPPA9OD+f0QP7r8Iw16i87KgALAE3r8FJWD4oPnA+uD/DAD9IP5A9nAuyB6S8FlHEANnUCBUjr
8Dzc/wQPFg8oCgVI6/A83P8EDxYPKApfHAEAABTr8Pzf/IEO3P8YDyoPPA9OD+f0Rf7r8NQ16i8Q
KwALAA3r8FJWD4oPnA+uD/DAD9IP5A9nAjSC6S8BHXEGBSDr8BTc/wQGAAAwF/0ce4YC6/ABAAB6
8/BO4PsBAAPr8AoFBOvwFQnr8Gfz8CLc/zQPRg8YWA/5/uT3GAiEA40P6PP/KB9vaY7MEOI/QChl
nSuPqwGdD86vBsDay3kKgwEr6dUv5vUV5/QW6/B0mtfoLzrr8F3r8FIAfRfr8JST6C+XFwS+ChP0
mOgvoBUWGL7r8BQe6S+p6/Bx7uvw0gAm6/BMm+jrLxrz8CHr8EIAGr7r8NyM6S878/BR9Q0+ERvr
8FCDGABfjA4AAIpPEhzr8P+wMxgAFg8AAPU4TxIdDRGf6C89qmYQZQcSJOvwzI8QovRmEBgTJ+vw
pKzoL59gJQAAUwcSThGsT8DoL7O3EBgTKZ0Rr87oL7y3EAsHEjFeDRHG6C/HtxCkPRLt/+vwZETo
B2AAMv6vEVbpL00oAADdifPwVgA89xET6esv1tIQCuvwRgA/PsERIekvyiooIQgR/URDESnpLyor
AOsAQwcSPevw7B3p4y9tRyAYE0ohBDDqay92RyAG6/BEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADo
DwAACAAAAAEAAABIAAAABAAAAFAAAAAGAAAAYAAAAAUAAABsAAAAAwAAAHgAAAAHAAAAhAAAAAIA
AACQAAAAEQAAAJwAAAACAAAA5AQAAB4AAAAGAAAAZHBhbnQAAAAeAAAAAQAAAAAAAAAeAAAAAQAA
AAAAAAAeAAAAAQAAAAAAAAAeAAAAAQAAAAAAAAAeAAAAAQAAAAAAAABHAAAARA8AAP////8OAAAA
AQAAAIQAAAAEAAAAAgAAAK4BAAC2AAAAAAAAAAAAAABcRAAA5xwAACBFTUYAAAEAPA8AAIoAAAAE
AAAADwAAAGQAAAAAAAAAIAMAAFgCAABAAQAA8AAAAAAAAAAAAAAAAAAAAFYASQBTAEkATwAAAEQA
cgBhAHcAaQBuAGcAAAAAAAAAJQAAAAwAAAAIAACAJQAAAAwAAAAFAACACgAAABAAAAAAAAAAAAAA
AAkAAAAQAAAAswEAALgAAAAmAAAAHAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAJQAAAAwAAAABAAAA
EgAAAAwAAAABAAAAEgAAAAwAAAACAAAAJwAAABgAAAACAAAAAAAAAP///wAAAAAAJQAAAAwAAAAC
AAAAVgAAAGgAAAC5AAAAAgAAAPkAAABAAAAAEwAAALkAIQC7ABYAwQANAMkABQDUAAIA3gACAOkA
BQDxAA0A9wAWAPkAIQD3ACwA8QA1AOkAPADeAEAA1ABAAMkAPADBADUAuwAsALkAIQAlAAAADAAA
AAgAAIAoAAAADAAAAAEAAAAlAAAADAAAAAUAAIAoAAAADAAAAAIAAAAZAAAADAAAAP///wBSAAAA
TAEAAAIAAAD1////AAAAAAAAAAAAAAAAkAEAAAAAAAAAAAAgQQByAGkAYQBsAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQEBAQEBAQEjYCUAAAAMAAAAAgAAACUA
AAAMAAAADQAAgBYAAAAMAAAAGAAAACUAAAAMAAAAAgAAABgAAAAMAAAAAAAAABIAAAAMAAAAAQAA
AFQAAABsAAAAzQAAABkAAADjAAAAJgAAAAEAAAAAACBCAAAgQs0AAAAkAAAABQAAAEwAAAAAAAAA
AAAAAAAAAAD//////////1gAAABDAGEAbABsADEAAAAHAAAABgAAAAIAAAACAAAABgAAABIAAAAM
AAAAAgAAACUAAAAMAAAADQAAgCYAAAAcAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAlAAAADAAAAAEA
AAASAAAADAAAAAEAAABXAAAAJAAAAAwAAAAhAAAAtwAAACEAAAACAAAADAAhALcAIQAlAAAADAAA
AAgAAIAoAAAADAAAAAEAAAAlAAAADAAAAAUAAIASAAAADAAAAAIAAAAnAAAAGAAAAAEAAAAAAAAA
AAAAAAAAAAAlAAAADAAAAAEAAAAlAAAADAAAAAgAAIBWAAAALAAAALcAAAAeAAAAuQAAACMAAAAE
AAAAtwAeALkAIQC3ACMAtwAeACUAAAAMAAAACAAAgCUAAAAMAAAABQAAgCgAAAAMAAAAAQAAABkA
AAAMAAAA////ACUAAAAMAAAAAgAAACUAAAAMAAAADQAAgBYAAAAMAAAAGAAAACUAAAAMAAAAAgAA
ABgAAAAMAAAAAAAAABIAAAAMAAAAAQAAAFQAAAAAAQAADgAAABcAAAC2AAAAJAAAAAEAAAAAACBC
AAAgQg4AAAAiAAAAHgAAAEwAAAAAAAAAAAAAAAAAAAD//////////4gAAABzAGkAcAA6ADUAMQAy
ADEAMAAwADEAMAAwADAAQAAxADQAOQAuADEAMQAyAC4AMQAwADIALgAyADMANAAGAAAAAgAAAAYA
AAADAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAsAAAAGAAAABgAA
AAYAAAADAAAABgAAAAYAAAAGAAAAAwAAAAYAAAAGAAAABgAAAAMAAAAGAAAABgAAAAYAAAASAAAA
DAAAAAIAAAAlAAAADAAAAA0AAIAmAAAAHAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAJQAAAAwAAAAB
AAAAEgAAAAwAAAABAAAAEgAAAAwAAAACAAAAJwAAABgAAAADAAAAAAAAAP///wAAAAAAJQAAAAwA
AAADAAAAVgAAAGgAAAC5AAAAeAAAAPkAAAC2AAAAEwAAALkAlwC7AIwAwQCDAMkAfADUAHgA3gB4
AOkAfADxAIMA9wCMAPkAlwD3AKIA8QCrAOkAswDeALYA1AC2AMkAswDBAKsAuwCiALkAlwAlAAAA
DAAAAAgAAIAoAAAADAAAAAEAAAAlAAAADAAAAAUAAIAoAAAADAAAAAMAAAAZAAAADAAAAP///wAl
AAAADAAAAAIAAAAlAAAADAAAAA0AAIAWAAAADAAAABgAAAAlAAAADAAAAAIAAAAYAAAADAAAAAAA
AAASAAAADAAAAAEAAABUAAAAbAAAAM0AAACPAAAA4wAAAJwAAAABAAAAAAAgQgAAIELNAAAAmgAA
AAUAAABMAAAAAAAAAAAAAAAAAAAA//////////9YAAAAQwBhAGwAbAAxAAB4BwAAAAYAAAACAAAA
AgAAAAYAAAASAAAADAAAAAIAAAAlAAAADAAAAA0AAIAmAAAAHAAAAAMAAAAAAAAAAQAAAAAAAAAA
AAAAJQAAAAwAAAADAAAAEgAAAAwAAAABAAAAVwAAADAAAAAEAAAAIQAAAAgBAACXAAAABQAAAPkA
IQAIASEACAFQAAQAUAAEAJcAJQAAAAwAAAAIAACAKAAAAAwAAAADAAAAJQAAAAwAAAAFAACAUgAA
AEwBAAADAAAA+f///wAAAAAAAAAAAAAAAJABAAAAAAAAAAAAIEEAcgBpAGEAbAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQEBAQEBAQEBI2AlAAAADAAAAAMAAAAl
AAAADAAAAA0AAIAWAAAADAAAABgAAAAlAAAADAAAAAMAAAAYAAAADAAAAAAAAAAlAAAADAAAAA0A
AIAmAAAAHAAAAAEAAAAAAAAAAQAAAAAAAAAAAAAAJQAAAAwAAAABAAAAEgAAAAwAAAABAAAAVwAA
ACQAAAAEAAAAlwAAALcAAACXAAAAAgAAAAQAlwC3AJcAJQAAAAwAAAAIAACAKAAAAAwAAAABAAAA
JQAAAAwAAAAFAACAEgAAAAwAAAACAAAAJwAAABgAAAABAAAAAAAAAAAAAAAAAAAAJQAAAAwAAAAB
AAAAJQAAAAwAAAAIAACAVgAAACwAAAC3AAAAlQAAALkAAACaAAAABAAAALcAlQC5AJcAtwCaALcA
lQAlAAAADAAAAAgAAIAlAAAADAAAAAUAAIAoAAAADAAAAAEAAAAZAAAADAAAAP///wAlAAAADAAA
AAIAAAAlAAAADAAAAA0AAIAWAAAADAAAABgAAAAlAAAADAAAAAIAAAAYAAAADAAAAAAAAAASAAAA
DAAAAAEAAABUAAAAAAEAAAoAAACOAAAAsgAAAJsAAAABAAAAAAAgQgAAIEIKAAAAmQAAAB4AAABM
AAAAAAAAAAAAAAAAAAAA//////////+IAAAAcwBpAHAAOgA1ADEAMgAyADAAMAAyADAAMAAwAEAA
MQA0ADkALgAxADEAMgAuADEAMAAyAC4AMgAzADQABgAAAAIAAAAGAAAAAwAAAAYAAAAGAAAABgAA
AAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAALAAAABgAAAAYAAAAGAAAAAwAAAAYAAAAGAAAA
BgAAAAMAAAAGAAAABgAAAAYAAAADAAAABgAAAAYAAAAGAAAAEgAAAAwAAAACAAAAJQAAAAwAAAAN
AACAJgAAABwAAAABAAAAAAAAAAEAAAAAAAAAAAAAACUAAAAMAAAAAQAAABIAAAAMAAAAAQAAAFcA
AAAkAAAA+QAAAJcAAACsAQAAlwAAAAIAAAD5AJcArAGXACUAAAAMAAAACAAAgCgAAAAMAAAAAQAA
ACUAAAAMAAAABQAAgBIAAAAMAAAAAgAAACcAAAAYAAAAAQAAAAAAAAAAAAAAAAAAACUAAAAMAAAA
AQAAACUAAAAMAAAACAAAgFYAAAAsAAAArAEAAJUAAACuAQAAmgAAAAQAAACsAZUArgGXAKwBmgCs
AZUAJQAAAAwAAAAIAACAJQAAAAwAAAAFAACAKAAAAAwAAAABAAAAGQAAAAwAAAD///8AJQAAAAwA
AAACAAAAJQAAAAwAAAANAACAFgAAAAwAAAAYAAAAJQAAAAwAAAACAAAAGAAAAAwAAAAAAAAAEgAA
AAwAAAABAAAAVAAAAAABAAD/AAAAjgAAAKcBAACbAAAAAQAAAAAAIEIAACBC/wAAAJkAAAAeAAAA
TAAAAAAAAAAAAAAAAAAAAP//////////iAAAAHMAaQBwADoANQAxADIAMgAwADAAMgAwADAAMABA
ADEANAA5AC4AMQAxADIALgAxADAAMgAuADIAMwA0AAYAAAACAAAABgAAAAMAAAAGAAAABgAAAAYA
AAAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAACwAAAAYAAAAGAAAABgAAAAMAAAAGAAAABgAA
AAYAAAADAAAABgAAAAYAAAAGAAAAAwAAAAYAAAAGAAAABgAAABIAAAAMAAAAAgAAACUAAAAMAAAA
DQAAgA4AAAAUAAAAAAAAABAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAe
AAAABgAAAFBhZ2VzAAMAAAABAAAAHgAAAAgAAABNYXN0ZXJzAAMAAAACAAAAAAAeEAAAAwAAAAgA
AABQYWdlLTEAAAgAAABDaXJjbGUAABIAAABEeW5hbWljIGNvbm5lY3RvcgC8AAAABgAAAAAAAAA4
AAAAAQAAAIwAAAAAAACAlAAAAAIAAACcAAAAAwAAAKgAAAAEAAAAtAAAAAMAAAAEAAAAEAAAAF9W
UElEX1BSRVZJRVdTAAADAAAAGAAAAF9WUElEX0FMVEVSTkFURU5BTUVTAAAAAAIAAAAQAAAAX1BJ
RF9MSU5LQkFTRQAAAAIAAADkBAAAEwAAAAkEAABBAAAABAAAAAAAAAAeAAAAAQAAAAAAAAAMEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAA
AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAEgBAAAQAAAAAQAAAIgAAAACAAAAkAAAAAMAAACcAAAA
BAAAAKgAAAAFAAAAtAAAAAcAAADAAAAACAAAANAAAAAJAAAA3AAAABIAAADoAAAACgAAAAQBAAAM
AAAAEAEAAA0AAAAcAQAADgAAACgBAAAPAAAAMAEAABAAAAA4AQAAEwAAAEABAAACAAAA5AQAADEA
VABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAOAAIAAQAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
GwAAABIGAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAADgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAANAAAAeAEAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5
AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMAAADIAQAAAAAAAAEAQwBvAG0AcABPAGIAagAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAGoAAAAAAAAAHgAA
AAEAAAAAAHMAHgAAAAEAAAAAAHMAHgAAAAQAAAB4eHgAHgAAAAEAAAAAeHgAHgAAAAcAAABOb3Jt
YWwAAB4AAAAEAAAAeHh4AB4AAAACAAAAMQB4AB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABA
AAAAAAAAAAAAAABAAAAAAMY2L0rHwAFAAAAAAMY2L0rHwAEDAAAAAQAAAAMAAAAAAAAAAwAAAAEA
AAADAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cI
ACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjABAADsAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAA
gAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4
AAAADQAAAMAAAAAMAAAAzQAAAAIAAADkBAAAHgAAAAUAAAAzQ29tAGl0bAMAAAABAAAAAwAAAAEA
AAADAAAAAQAAAAMAAABqEAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA
AAEAAAAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAAAAAAACAAAAABAAAA
NgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADIANAA4
ADEAMgA1ADAAMgAtADMAMwAzAEMALQAxADEARAA1AC0AQgAzADgANQAtADAAMAAwADEAMAAyADYA
OQA3ADgAQgBGAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwACAAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIA
bQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBh
AHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAeAAAA
IgAAAAEAAAAAAAAAAAD/////AgQAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAh
AAAAAAAAAAAI//8AAAAAAAAAACIAAAAGAAAMAAAAAP////8ABAAAIgQAAAMAAAAABAAAIgQAAAQA
AAAABAAAIQQAAAUAAAAAAAAAGQAAABsAAAAhAAAAEzqU/5WADwAA8GwAAAAAAAbwGAAAAAIIAAAC
AAAAAgAAAAEAAAABAAAAAwAAAB8AAfAsAAAAMgAH8CQAAAADBH08TgbJfZuvk3wrzPT/Bkj/ABAI
AAABAAAAHgwAAAAAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8OIAAAAQAAjwCAAAAAIA
AAACBAAADwAD8IAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQA
AAUAAAAPAATwSAAAALIECvAIAAAAAgQAABAKAABDAAvwGAAAAARBAQAAAAsBAAABAD8BAAABAP8B
AAAIAAAAEPAEAAAAAAAAAAAAEfAEAAAAAQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/Ae
AAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAAAAAACIAAAACBAAA
AAAAAAAAAADBJgAAYxAAADQAAAAAAAAAAAACAAAAIwAAAAcABwAAAAAAAgAAACMAAAAHAAcA//8C
AAAAAwB4AHgAeAALAEMAOgBcAGwAbwBvAHAALgBkAG8AYwD/QAOAAQAAAAAAAAAAAHCO7AABAAAA
AAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAAACIAAABgAAAIAEAAAAMAAABHFpABAAACAgYDBQQFAgME
hwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1
FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB
AAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAAIgAEAPAIiBgA
ANACAABoAQAAAABZilRGWYpURgAAAAABAAAAAAAAAAAAAQAAAAEAAQAAAAQAAxABAAAAAAAAAAAA
AAABAAEAAAABAAAAAAAAACEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQA
gAByMAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAAAAAAAAAAAAADAHgA
eAB4AAMAeAB4AHgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNy
b3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy
cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

--0__=iXBR1N1FtGJE5IkiX3wnW5db9DddjwQGp9jpEoGoATuvL5Me3TUmZS58--


_______________________________________________
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  Tue Apr 17 10:58:09 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09265
	for ; Tue, 17 Apr 2001 10:58:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B78744349; Tue, 17 Apr 2001 10:58:03 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 6A96B44337
	for ; Tue, 17 Apr 2001 10:57:28 -0400 (EDT)
Received: from sponge.cisco.com (sponge.cisco.com [171.71.61.25])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27632;
	Tue, 17 Apr 2001 07:57:22 -0700 (PDT)
Received: from arunvenkwin40 (dhcp-161-44-6-150.cisco.com [161.44.6.150])
	by sponge.cisco.com (Mirapoint)
	with SMTP id ABP01038;
	Tue, 17 Apr 2001 09:57:17 -0500 (CDT)
From: "Arunachalam Venkatraman" 
To: , "Keith Robinson" 
Cc: "Fairlie-Cuninghame, Robert" ,
        "Sherman Gong" , ,
        "'Jonathan Rosenberg'" 
Subject: RE: [SIP] Request-uri does not match record-route header...
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <88256A31.00503F41.00@hqoutbound.ops.3com.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: Tue, 17 Apr 2001 10:02:48 -0500
Content-Transfer-Encoding: 7bit

I understand the routing rule to be (from 6.39 of bis) - Once a Route is
established, at every host, copy the topmost route to the req-uri and then
use the maddr part to route the call.
So, where is the translation occurring?  Each host is using the maddr of the
topmost Route to route the request; the Req-URI seems to be irrelevant here.
The last Route entry, the Contact, ensures the request is ultimately
delivered to the UAS.
Once a route is established, why is translation required?


 -----Original Message-----
From: 	Deepak_Pant@3com.com [mailto:Deepak_Pant@3com.com]
Sent:	Tuesday, April 17, 2001 9:36 AM
To:	Keith Robinson
Cc:	Fairlie-Cuninghame, Robert; 'Arunachalam Venkatraman'; Sherman Gong;
sip@lists.bell-labs.com; 'Jonathan Rosenberg'
Subject:	RE: [SIP] Request-uri does not match record-route header...

 << File: att1.htm >> << File: ATT00281.txt >> << File: loop.doc >>

(See attached file: loop.doc)
It is important to have the same ReqURI in the ACK as presented in the
RouteHeader because
this will also help in the loop detection. As in the attached diagram
although
the two sip requests
may have identical CallIds, they may have different ReqURI on account of
number
translation
being done at one of the intermediate proxies and the call looping back to
the
proxy. As Keith
pointed out having the ReqURI identical to the INVITE will help determine
the
correct state
machine for processing the call.

-Deepak




"Keith Robinson"  on 04/17/2001 05:58:27 AM

Sent by:  "Keith Robinson" 


To:   "Fairlie-Cuninghame, Robert" 
cc:   "'Arunachalam Venkatraman'" , Sherman Gong
      , sip@lists.bell-labs.com, "'Jonathan Rosenberg'"
       (Deepak Pant/MW/US/3Com)
Subject:  RE: [SIP] Request-uri does not match record-route header...





Hello,

Shouldn't the Request-Uri in the ACK should be :

ACK
sip:3032011001@192.168.10.114:5060;maddr=192.168.10.141;transport=udp;user=p
hone
SIP/2.0

This will then be sent to 192.168.10.141 using the maddr.

It is important that the Request-Uri in the subsequent messages is that
given in
the Record-Route
as stateful proxies may well use this to identify the correct state machine
to
process the request.

Like Robert, I think this touches upon the issues with Route headers,
outbound
proxies and UA
without DNS capability which I feel hasn't yet been resolved.

Regards,

Keith Robinson









"Fairlie-Cuninghame, Robert"  on 13/04/2001 12:24:12








 To:      "'Arunachalam Venkatraman'" ,
          Sherman Gong ,
          sip@lists.bell-labs.com

 cc:      "'Jonathan Rosenberg'"
          (bcc: Keith
          Robinson/MAIN/MC1)



 Subject: RE: [SIP] Request-uri does not match record-route
          header...








Hi,

I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a)   the proxy knows that it record-routed this call leg
b)   or the Request-URI resolves to the local proxy's address.

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".

For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.

At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?

Robert.

 <<[SIP] new record-route text!>>
-----Original Message----
From:     Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
Sent:     Thursday, April 12, 2001 5:46 PM
To:  Sherman Gong; sip@lists.bell-labs.com
Subject:  RE: [SIP] Request-uri does not match record-route header...

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.


 -----Original Message-----
From:     sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:     Thursday, April 12, 2001 10:09 AM
To:  sip@lists.bell-labs.com
Subject:  [SIP] Request-uri does not match record-route header...

Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.


    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.


  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).


Or


2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.




c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0



*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2


************************************* Note
****************************************
Note that the record route header:

Record-Route:

  is the one that should be used for the subsequent ACK.




*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK



********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.




*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#



Thanks

SG


_______________________________________________
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@lists.bell-labs.com  Tue Apr 17 11:09:15 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09596
	for ; Tue, 17 Apr 2001 11:09:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 42FBE4437E; Tue, 17 Apr 2001 11:09:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 7BEE044349
	for ; Tue, 17 Apr 2001 11:08:14 -0400 (EDT)
Received: from sponge.cisco.com (sponge.cisco.com [171.71.61.25])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05321;
	Tue, 17 Apr 2001 08:08:13 -0700 (PDT)
Received: from arunvenkwin40 (dhcp-161-44-6-150.cisco.com [161.44.6.150])
	by sponge.cisco.com (Mirapoint)
	with SMTP id ABP01195;
	Tue, 17 Apr 2001 10:08:05 -0500 (CDT)
From: "Arunachalam Venkatraman" 
To: "Fairlie-Cuninghame, Robert" ,
        "Sherman Gong" , 
Cc: "'Jonathan Rosenberg'" 
Subject: RE: [SIP] Request-uri does not match record-route header...
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0120_01C0C727.11365800"
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 V5.00.2314.1300
In-Reply-To: 
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, 17 Apr 2001 10:13:37 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0120_01C0C727.11365800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

How does the proxy know if the client is DNS capable? If the proxy know it
is the default proxy and should not Record Route, it can then simply route
the call based on the maddr in the Route. Again, the name-addr in the
Req-URI is irrelevant.

I want to clarify that what I meant to say was that the name-addr part of
the REQ-URI seems to be irrelevant when the toptmost Route entry is copied.
The maddr and the port in the name-addr is used to route the call to the
next hop. The name-addr of the Req-URI can be anything so long as the port
is correct. I am not suggesting mangling the name-addr, though. I am
pointing out why your request will get correctly routed whether you specify
the REQ-URI to be

            ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0

Or

ACK sip:3032011001@192.168.10.114:5060;user=phone SIP/2.0

If the routing is done based on the maddr=192.168.10.141 in the route entry
of the Route Set built from the Record Route
(and the Contact) Received.

Record-Route:
Record-Route:



-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 13, 2001 6:24 AM
To: 'Arunachalam Venkatraman'; Sherman Gong; sip@lists.bell-labs.com
Cc: 'Jonathan Rosenberg'
Subject: RE: [SIP] Request-uri does not match record-route header...

Hi,
I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a.       the proxy knows that it record-routed this call leg
b.      or the Request-URI resolves to the local proxy's address.

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".
For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.
At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?
Robert.
<<[SIP] new record-route text!>>
-----Original Message----
From:   Arunachalam Venkatraman [ mailto:arunvenk@cisco.com]
Sent:   Thursday, April 12, 2001 5:46 PM
To:     Sherman Gong; sip@lists.bell-labs.com
Subject:        RE: [SIP] Request-uri does not match record-route header...
You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.

 -----Original Message-----
From:   sip-admin@lists.bell-labs.com
 mailto:sip-admin@lists.bell-labs.com]
On Behalf Of Sherman Gong
Sent:   Thursday, April 12, 2001 10:09 AM
To:     sip@lists.bell-labs.com
Subject:        [SIP] Request-uri does not match record-route header...
Having a problem whereby the request-uri used in the ACK does not match
that which was in the record-route header in the 200 OK.  Per the SIP bis
draft (section 6.39 in the 02 version), the first Route header (constructed
from the record-route header) should be removed and used as the
Request-URI.  I included a couple of notes below asterisks (******).
I have been getting conflicting arguments on which requirement this should
follow.  Need to determine which spec. is correct.
1)  6.29 Record-Route
     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.
      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)
      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.

    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.

  6.33 Route
      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.
    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).

Or

2)  from page 20 of the draft
     The maddr parameter indicates the server address to be contacted for
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.



c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec
*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: 
Expires: 180
Content-Type: application/sdp
Content-Length: 138
v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0
*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
CSeq: 101 INVITE
Content-Length: 0

*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE
*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: 
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0

*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE
*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.
*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK
*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:
Record-Route:
Record-Route:
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300
v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2

************************************* Note
****************************************
Note that the record route header:
Record-Route:
  is the one that should be used for the subsequent ACK.



*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE
*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful
*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036
*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route , 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114
*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" 
To: ;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184
Route: ,

Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK

********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.



*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one
*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#

Thanks
SG

_______________________________________________
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_000_0120_01C0C727.11365800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










RE: [SIP] Request-uri does not match record-route =
header...










Ho=
w does
the proxy know if the client is DNS capable? If the proxy know it is the
default proxy and should not Record Route, it can then simply route the =
call
based on the maddr in the Route. Again, the name-addr in the Req-URI is
irrelevant.



 



I =
want to
clarify that what I meant to say was that the name-addr part of the =
REQ-URI seems
to be irrelevant when the toptmost Route entry is copied. The maddr and =
the
port in the name-addr is used to route the call to the next hop. The =
name-addr
of the Req-URI can be anything so long as the port is correct. I am not
suggesting mangling the name-addr, though. I am pointing out why your =
request will
get correctly routed whether you specify the REQ-URI to be =




 



        =
;    ACK sip:3032011001@192.168.10.141:5060;user=3Dphone =
SIP/2.0



 



Or 



 



ACK =
sip:3032011001@192.168.10.114:5060;user=3Dphone
SIP/2.0=




 



If the routing =
is done
based on the maddr=3D192.168.10.141 in the route entry of the Route Set =
built
from the Record Route



(and the =
Contact) Received.



 



Record-Route:<sip:3032011001@east=
.c53005.com:5070;maddr=3D192.168.10.141;trans 

port=3Dudp> 

Record-Route:<sip:3032011001@192.168.10.=
114:5060;user=3Dphone;maddr=3D192.168.10 

.141;transport=3Dudp> 







 



-----Original
Message-----

From: Fairlie-Cuninghame, =
Robert
[mailto:rfairlie@nuera.com]

Sent: Friday, April 13, =
2001 6:24
AM

To: 'Arunachalam =
Venkatraman';
Sherman Gong; sip@lists.bell-labs.com

Cc: 'Jonathan =
Rosenberg'

Subject: RE: [SIP] =
Request-uri
does not match record-route header...



 



Hi, <=
/p>


I believe the
Record-Route test has been completely rewritten (message attached). I
personally believe however Arunachalam's response should be qualified by =
the
saying that a proxy should only use the next Route header =
if<=
/p>


a.       =
the proxy knows that it record-routed this call =
leg<=
/p>


b.      =
or the Request-URI resolves to the local proxy's =
address.<=
/p>


 <=
/p>


I don't believe =
this is
reflected in the new Record-Route text. It touches on an unresolved (or =
at
least that was my feeling) discussion a long time about whether a
Record-Routing's interaction with "Outbound =
Proxies".<=
/p>


For instance, =
when a UA
or Proxy, puts the first Route header in the Request-URI but then sends =
the
message to an outbound proxy because the UA lacks DNS capability. The =
outbound
proxy may not have Record-Route'd but it must not remove/process the =
next Route
header either.



At risk of =
reopening
this discussion, did we reach at conclusion on this point, that is, when =
a
proxy should use the next Route header and when should it not (if the
Request-URI is does not resolve to the proxy's =
address)?<=
/p>


Robert. <=
/p>


<<[SIP] =
new
record-route text!>> 

-----Original =
Message---- 

From:  
Arunachalam Venkatraman [mailto:arunvenk@cisco.com]<=
/font> 

Sent:  <=
/span> Thursday,
April 12, 2001 5:46 PM


To:  &nb=
sp;  Sherman
Gong; sip@lists.bell-labs.com 

Subject: &nbs=
p;      RE:
[SIP] Request-uri does not match record-route =
header... <=
/p>


You are correct =
in
that  the REQ URI in ACK of your example should =
be 

192.168.10.114. 

However, I don't know what is the value =
of
copying the topmost route to the 

REQ URI . 

If the port of the UAS is different from =
that in
the Route, it looks wrong! 

The fact is, the REQ URI is not used for =
routing
when there is a ROUTE


header in the message. 

I have found that the REQ URI in the ACK =
to a
proxy I have been testing 

with, can be anything (so long as it =
parses ok)
when there is a ROUTE


header. The proxy uses the Route header =
for
routing and not the REQ URI, 

when a ROUTE header is =
present. <=
/p>


 <=
/p>


 -----Origi=
nal
Message----- 

From:   =
sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell=
-labs.com] 

On Behalf Of Sherman =
Gong 

Sent:   Thursday, April 12, =
2001 10:09
AM 

To:    
sip@lists.bell-labs.com


Subject:     &nbs=
p; 
[SIP] Request-uri does not match record-route =
header... <=
/p>


Having a =
problem whereby
the request-uri used in the ACK does not match 

that which was in the record-route header =
in the
200 OK.  Per the SIP bis 

draft (section 6.39 in the 02 version), =
the
first Route header (constructed 

from the record-route header) should be =
removed
and used as the 

Request-URI.  I included a couple of =
notes
below asterisks (******). 



I have been =
getting
conflicting arguments on which requirement this =
should 

follow.  Need to determine which =
spec. is
correct. =
<=
/p>


1)  6.29
Record-Route <=
/p>


  &nbs=
p; 
The Record-Route request and response header field is added to =
a 

     request by any =
proxy
that insists on being in the path of subsequent 

     requests for the =
same
call leg. It contains a globally reachable 

     Request-URI that
identifies the proxy server. Each proxy server adds 

     its Request-URI =
to the
beginning of the list.
<=
/p>


  &nbs=
p;  
The server copies the Record-Route header field unchanged into =
the 

      response.
(Record-Route is only relevant for 2xx responses.) <=
/p>


  &nbs=
p;  
The calling user agent client copies the Record-Route header into =
a 

      Route =
header
field of subsequent requests within the same call =
leg, 

      reversing =
the
order of requests, so that the first entry is closest 

      to the =
user agent
client. If the response contained a Contact header 

      field, the
calling user agent adds its content as the last Route 

      header. =
Unless
this would cause a loop, any client MUST send any 

      subsequent
requests for this call leg to the first Request-URI in =
the 

      Route =
request
header field and remove that entry. 



 <=
/p>


  &nbs=
p; The
above describes building Route headers from the =
Record-Route 

headers, 

    and sending subsequent
requests to the first Route, removing that entry. <=
/p>


 <=
/p>


  6.33 =
Route <=
/p>


  &nbs=
p;  
The Route request-header field determines the route taken by =
a 

      request. =
Each
host removes the first entry and then proxies the 

      request to =
the
host listed in that entry, also using it as the 

      =
Request-URI. The
operation is further described in Section 6.29. 



  &nbs=
p; The
above notes that the Route header used to proxy a request =
should 

also 

     be used as the
Request-URI.  This is the part that is not being =
done 

     correctly by the =
5300. 
The 5300 is building it's own request URI based 

on 

     the destination =
of the
request, rather than using the URI in the Route 

    header as the
Request-URI.  Note that the 5300 is sending the =
request 

to the 

    correct destination, =
which in
our case does not match that in the Route 

    header (but they don't =
have
to match). =
<=
/p>


 <=
/p>


Or=
 <=
/p>


 <=
/p>


2)  from =
page 20 of
the draft =
<=
/p>


  &nbs=
p; 
The maddr parameter indicates the server address to be contacted =
for 

this user, overriding the address =
supplied in
the host field. This 

     address is =
typically,
but not necessarily, a multicast address. The 

maddr field can be used to force requests =
from
traveling users to visit 

     a home proxy =
even if an
outbound proxy is used.
<=
/p>










c5300-3#<=
/font> 

*Jan 22 08:34:05.632: ISDN Se0:23: RX
<-  SETUP pd =3D 8  callref =3D 0x0001 

*Jan 22
08:34:05.632:         Bearer =
Capability
i =3D 0x8090A2 

*Jan 22
08:34:05.636:         Channel ID =
i =3D
0xA98381 =


*Jan 22
08:34:05.636:         Calling =
Party
Number i =3D 0x2180, '2062011001', 

Plan:ISDN, =
Type:National 

*Jan 22
08:34:05.636:         Called =
Party
Number i =3D 0xA1, '3032011001', 

Plan:ISDN, =
Type:National 

*Jan 22 08:34:05.652: 0x6221E11C : State =
change
from (STATE_NONE, 

SUBSTATE_NONE)  to (STATE_IDLE,
SUBSTATE_NONE) 

*Jan 22 08:34:05.652:  Queued event =
from
SIP SPI : SIPSPI_EV_CC_CALL_SETUP 

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL: 
act_idle_call_setup 

*Jan 22 08:34:05.652: 
act_idle_call_setup:Not using Voice Class Codec 



*Jan 22 =
08:34:05.652:
act_idle_call_setup: preferred_codec set[0] type 

:g711ulaw bytes: 160 

*Jan 22 08:34:05.652:  Queued event =
from
SIP SPI : =


SIPSPI_EV_CREATE_CONNECTION<=
font
color=3Dblack> 

*Jan 22 08:34:05.652: 0x6221E11C : State =
change
from (STATE_IDLE, 

SUBSTATE_NONE)  to (STATE_IDLE,
SUBSTATE_CONNECTING) 

*Jan 22 08:34:05.652: 0x6221E11C : State =
change
from (STATE_IDLE, 

SUBSTATE_CONNECTING)  to =
(STATE_IDLE,
SUBSTATE_CONNECT 

ING) 

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL: 
act_idle_connection_created 

*Jan 22 08:34:05.652: =
CCSIP-SPI-CONTROL: 
act_idle_connection_created: 

Connid(1) created to 192.168.10.114:5060,
local_p =


ort 50727 

*Jan 22 08:34:05.656: =
CCSIP-SPI-CONTROL: 
sipSPIOutgoingCallSDP


*Jan 22 08:34:05.656: =
sipSPIAddLocalContact 

*Jan 22 08:34:05.656:  Queued event =
from
SIP SPI : SIPSPI_EV_SEND_MESSAGE 

*Jan 22 08:34:05.656: =
CCSIP-SPI-CONTROL: 
sip_stats_method 

*Jan 22 08:34:05.656: 0x6221E11C : State =
change
from (STATE_IDLE, 

SUBSTATE_CONNECTING)  to
(STATE_SENT_INVITE, SUBSTATE_ 

NONE) 

*Jan 22 08:34:05.660: ISDN Se0:23: TX
->  CALL_PROC pd =3D 8  callref =3D =
0x8001 

*Jan 22 =
08:34:05.660:        
Channel ID i =3D 0xA98381


*Jan 22 08:34:05.660: =
Sent: 

INVITE =
sip:3032011001@192.168.10.114;user=3Dphone
SIP/2.0 =


Via: SIP/2.0/UDP  =
192.168.66.184:50727 

From: "2062011001"
<sip:2062011001@192.168.66.184> 

To: =
<sip:3032011001@192.168.10.114;user=3Dphone> 

Date: Sat, 22 Jan 2000 01:34:05 =
GMT 

Call-ID:
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 

Cisco-Guid: =
3954197371-3232041567-0-1845248076 

User-Agent: Cisco SIP Gateway (UAC)/IOS =
12.x 

CSeq: 101 INVITE 

Max-Forwards: 6 

Timestamp: 948530045 

Contact:
<sip:2062011001@192.168.66.184:5060;user=3Dphone> 

Expires: 180 

Content-Type: =
application/sdp 

Content-Length: 138 <=
/p>


v=3D0 

o=3DCiscoSystemsSIP-GW-UserAgent 7656 =
9288 IN IP4
192.168.66.184 

s=3DSIP Call 

c=3DIN IP4 =
192.168.66.184 

t=3D0 0 

m=3Daudio 20492 RTP/AVP =
0 <=
/p>


*Jan 22 =
08:34:05.672:
Received: =


SIP/2.0 100 Trying 

Via: SIP/2.0/UDP  =
192.168.66.184:50727 

From: "2062011001"
<sip:2062011001@192.168.66.184> 

To:
<sip:3032011001@192.168.10.114;user=3Dphone> 

Call-ID:
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 

CSeq: 101 INVITE 

Content-Length: 0 <=
/p>


 <=
/p>


*Jan 22 =
08:34:05.672:
HandleUdpSocketReads :Msg enqueued for SPI with 

IPaddr: =
192.168.1.114:34050 

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL: 
act_sentinvite_new_message 

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL: 
sipSPICheckResponse 

*Jan 22 08:34:05.672: =
CCSIP-SPI-CONTROL: 
sip_stats_status_code


*Jan 22 08:34:05.672:  Roundtrip =
delay 16
milliseconds for method INVITE 



*Jan 22 =
08:34:05.672:
0x6221E11C : State change from (STATE_SENT_INVITE, 

SUBSTATE_NONE)  to =
(STATE_RECD_PROCEEDING,
SUBS 

TATE_PROCEEDING_PROCEEDING)<=
font
color=3Dblack> 

*Jan 22 08:34:05.852: =
Received: 

SIP/2.0 180 Ringing 

Via: SIP/2.0/UDP =
192.168.66.184:50727 

From: "2062011001"
<sip:2062011001@192.168.66.184> 

To:
<sip:3032011001@192.168.10.114;user=3Dphone> 

Date:Sat, 22 Jan 2000 08:33:50 =
GMT 

Call-ID:
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 

Timestamp:948530045 

Server:Cisco SIP Gateway (UAS)/IOS =
12.x 

CSeq: 101 INVITE 

Content-Length: 0 <=
/p>


 <=
/p>


*Jan 22 =
08:34:05.856:
HandleUdpSocketReads :Msg enqueued for SPI with 

IPaddr: =
192.168.1.114:34050 

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL: 
act_recdproc_new_message 

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL: 
sipSPICheckResponse 

*Jan 22 08:34:05.856: =
CCSIP-SPI-CONTROL: 
sip_stats_status_code


*Jan 22 08:34:05.856:  Roundtrip =
delay 200
milliseconds for method INVITE 



*Jan 22 =
08:34:05.856:
HandleSIP1xxRinging No SDP Body in 180 RINGING - =
would 

wait for 200OK to do =
negotiation. <=
/p>


*Jan 22 =
08:34:05.856:
HandleSIP1xxRinging: MediaNegotiation expected in 200 

OK 



*Jan 22 =
08:34:05.856:
0x6221E11C : State change from =
(STATE_RECD_PROCEEDING, 

SUBSTATE_PROCEEDING_PROCEEDING)  to =
(STATE_ 

RECD_PROCEEDING, =
SUBSTATE_PROCEEDING_ALERTING) 

*Jan 22 08:34:05.856: ISDN Se0:23: TX
->  ALERTING pd =3D 8  callref =3D =
0x8001 

*Jan 22 08:34:06.356: =
Received: 

SIP/2.0 200 OK 

Via: SIP/2.0/UDP =
192.168.66.184:50727 

From: "2062011001"
<sip:2062011001@192.168.66.184> 

To:
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820 

Date:Sat, 22 Jan 2000 08:33:50 =
GMT 

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 

Timestamp:948530045 

Server:Cisco SIP Gateway (UAS)/IOS =
12.x 

Contact:<sip:3032011001@192.168.67.186:=
5060;user=3Dphone> 

Record-Route:<sip:3032011001@east.c5300=
5.com:5070;maddr=3D192.168.10.141;trans 

port=3Dudp> 

Record-Route:<sip:3032011001@192.168.10=
.114:5060;user=3Dphone;maddr=3D192.168.10 

.141;transport=3Dudp> 

CSeq: 101 INVITE 

Content-Type:application/sdp=
 

Content-Length: 126 

Session-Expires:300 <=
/p>


v=3D0 

o=3DCiscoSystemsSIP-GW-UserAgent 6565 =
3960 IN IP4
10.1.1.2 =


s=3DSIP Call 

t=3D0 0 

m=3Daudio 4036 RTP/AVP =
0 

c=3DIN IP4 209.6.0.2 <=
/p>


 <=
/p>


****************=
*********************
Note 

**************************************** 

Note that the record route =
header: <=
/p>


Record-Route:<=
;sip:3032011001@192.168.10.114:5060;user=3Dphone;maddr=3D192.168.10 

.141;transport=3Dudp> <=
/p>


  is the =
one that
should be used for the subsequent ACK. 











*Jan 22 =
08:34:06.356:
HandleUdpSocketReads :Msg enqueued for SPI with 

IPaddr: =
192.168.1.114:34050 

*Jan 22 08:34:06.356: =
CCSIP-SPI-CONTROL: 
act_recdproc_new_message 

*Jan 22 08:34:06.356: =
CCSIP-SPI-CONTROL: 
sipSPICheckResponse 

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL: 
sip_stats_status_code


*Jan 22 08:34:06.360:  Roundtrip =
delay 704
milliseconds for method INVITE 



*Jan 22 =
08:34:06.360:
sipSPIGetSdpBody : Parse incoming session description 

*Jan 22 08:34:06.360: =
sipSPICompareRespMediaInfo
No Comparsion needed as 18x 

messages did not have =
SDP 

*Jan 22 08:34:06.360: =
sipSPIDoMediaNegotiation:
Codec Negotiation Successful 



*Jan 22 =
08:34:06.360:
sipSPIUpdCcbWithSdpInfo: SDP Media Information: 

Negotiated =
Codec      :
g711ulaw , bytes :160


Early
Media           : =
0 

Delayed
Media         : =
0 

Bridge
Done           : =
0 

New
Media           &n=
bsp; :
0 

DSP DNLD
Reqd         : =
0 

Media Dest addr/Port  : =
209.6.0.2:4036 <=
/p>


*Jan 22 =
08:34:06.360:
sipSPIProcessMediaChanges 

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL: 
sipSPIReconnectConnection 

*Jan 22 08:34:06.360:  Queued event =
from
SIP SPI : =


SIPSPI_EV_RECONNECT_CONNECTION 

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL: 
sipSPIProcess200OKforinvite 

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL: 
sipSPIAddRouteHeaders status =3D 

TRUE Route
<sip:3032011001@east.c53005.com:5070 

;maddr=3D192.168.10.141>,
<sip:3032011001@192.168.67.186:5060;user=3Dphone> 

*Jan 22 08:34:06.360:  Queued event =
from
SIP SPI : SIPSPI_EV_SEND_MESSAGE 

*Jan 22 08:34:06.360: =
CCSIP-SPI-CONTROL: 
sip_stats_method 

*Jan 22 08:34:06.360: 0x6221E11C : State =
change
from (STATE_RECD_PROCEEDING, 

SUBSTATE_PROCEEDING_ALERTING)  to =
(STATE_AC 

TIVE, SUBSTATE_NONE) 

*Jan 22 08:34:06.360: The Call Setup =
Information
is : 

  Call Control Block (CCB) : =
0x6221E11C 

  State of The
Call        : =
STATE_ACTIVE 

  TCP Sockets
Used         : =
NO 

  Calling
Number           : =
2062011001 

  Called
Number            =
:
3032011001 =


  Negotiated
Codec         : =
g711ulaw 

  Negotiated Codec Bytes   =
: 160 

  Negotiated =
Dtmf-relay    :
0 

  Source IP Address (Media): =
192.168.66.184 

  Source IP Port    =
(Media):
20492 

  Destn  IP Address (Media): =
209.6.0.2 

  Destn  IP =
Port   
(Media): 4036 

  Destn SIP Req Addr:Port  : =
192.168.10.141:5060 

  Destn SIP Resp Addr:Port : =
0.0.0.0:0 

  Destination
Name         : =
192.168.10.114 <=
/p>


*Jan 22 =
08:34:06.364:
HandleUdpReconnection: Udp socket connected for fd: 1 

with =
192.168.10.141:5060 

*Jan 22 08:34:06.364: =
Sent: 

ACK =
sip:3032011001@192.168.10.141:5060;user=3Dphone
SIP/2.0 =


Via: SIP/2.0/UDP  =
192.168.66.184:50727 

From: "2062011001"
<sip:2062011001@192.168.66.184> 

To:
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820 

Date: Sat, 22 Jan 2000 01:34:05 =
GMT 

Call-ID: =
EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 

Route:
<sip:3032011001@east.c53005.com:5070;maddr=3D192.168.10.141>, 

<sip:3032011001@192.168.67.186:5060;use=
r=3Dphone> 

Max-Forwards: 6 

Content-Length: 0 

CSeq: 101 ACK 



 <=
/p>


****************=
*****************
Note *********************************** 

Request-URI in above ACK has domain of
192.168.10.141, should have been 

192.168.10.114 when the record-route was =
turned
into a Route header, 

removed, and used as the =
Request-URI. <=
/p>










*Jan 22
08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create =
a 

new one 



*Jan 22 =
08:34:06.364:
CCSIP-SPI-CONTROL:  ccsip_caps_ind 

*Jan 22 08:34:06.364:
ccsip_get_rtcp_session_parameters: CURRENT VALUES: 

ccCallID=3D1276, =
current_seq_num=3D0x217C 

*Jan 22 08:34:06.364:
ccsip_get_rtcp_session_parameters: NEW VALUES: 

ccCallID=3D1276, =
current_seq_num=3D0x9EC 

*Jan 22 08:34:06.364: ccsip_caps_ind: =
Load DSP
with negotiated codec :


g711ulaw, Bytes=3D160 

*Jan 22 08:34:06.368: =
sipSPIGetDTMFRelayMode:
set DSP for dtmf-relay =3D 

CC_CAP_DTMF_RELAY_INBAND_VOICE 

*Jan 22 08:34:06.368: ccsip_caps_ind: =
Load DSP
with codec : g711ulaw,


Bytes=3D160 

*Jan 22 08:34:06.368: =
CCSIP-SPI-CONTROL: 
ccsip_caps_ack 

*Jan 22 08:34:06.372: ISDN Se0:23: TX
->  CONNECT pd =3D 8  callref =3D 0x8001 

*Jan 22
08:34:06.372:         Progress =
Ind i =3D
0x8182 - Destination address 

is non-ISDN 

*Jan 22 08:34:06.388: ISDN Se0:23: RX
<-  CONNECT_ACK pd =3D 8  callref =3D 

0x0001 

*Jan 22 08:34:06.388: ISDN Se0:23:
CALL_PROGRESS: CALL_CONNECTED call id 

0x227, bchan 0, dsl 0 

3w0d: %ISDN-6-CONNECT: Interface =
Serial0:0 is
now connected to 2062011001 

c5300-3# 



 <=
/p>


Thanks <=
/p>


SG=
 <=
/p>


 <=
/p>


________________=
_______________________________ 

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. 



 <=
/p>


________________=
_______________________________ 

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_000_0120_01C0C727.11365800--


_______________________________________________
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  Tue Apr 17 11:26:06 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10096
	for ; Tue, 17 Apr 2001 11:26: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 CF6DC4437E; Tue, 17 Apr 2001 11:26:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from brahma01.netbrahma.com (unknown [164.164.70.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 033FC44338
	for ; Tue, 17 Apr 2001 11:25:07 -0400 (EDT)
Received: from netbrahma.com (SUNILK [172.16.72.151]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 23F75YXT; Tue, 17 Apr 2001 20:55:36 +0530
Message-ID: <3ADC609D.E17A7505@netbrahma.com>
From: "T.Sunil Kumar" 
Organization: Netbrahma Technologies Pvt. Ltd
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bell - SIP 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] multicast in 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, 17 Apr 2001 20:56:21 +0530
Content-Transfer-Encoding: 7bit

Hi,

What is the purpose of multicast sessions - is it to achieve CONFERENCE
among many parties or anything else?

Similarly, what is the role of MCU (Multipoint Control Unit) and
fully-meshed interconnection - to achieve CONFERENCE or ??

Pl. throw some light on these.

Thanks,
--Sunil
_____________________________________
T.SUNIL KUMAR
Net Brahma Technologies
Internext Networking Software
A Microland Group Venture
sunilk@netbrahma.com
http://www.netbrahma.com
Tel :  91.80. 552 1451/5011/5012/5014
              Ext : 269/270
Fax :  91.80. 553 7233

e-card: http://www.ecardfile.com/tskr
_____________________________________

_______________________________________________
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  Tue Apr 17 11:31:17 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10200
	for ; Tue, 17 Apr 2001 11:31:10 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4E844437B; Tue, 17 Apr 2001 11:31:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 5F61344379
	for ; Tue, 17 Apr 2001 11:30:52 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <27SBCBWP>; Tue, 17 Apr 2001 08:30:26 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Arunachalam Venkatraman'" ,
        Sherman Gong , sip@lists.bell-labs.com
Cc: "'Jonathan Rosenberg'" 
Subject: RE: [SIP] Request-uri does not match record-route header...
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0C753.50CA1D90"
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, 17 Apr 2001 08:30:21 -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_01C0C753.50CA1D90
Content-Type: text/plain;
	charset="iso-8859-1"

That exactly the point - a proxy can't know whether the UA is DNS or
whatever. It must merely follow a set of rules (including decisions based on
transaction state information).
 
Before I start, I think that the use of the maddr parameter in Record-Route
is not a good idea as it causes these sort of problems!! I think it should
be removed from the call flow. For instance if a proxy Record-Routes with
the Contact and its own maddr in the Route and the maddr in the Request-Uri
gets stripped by the previous hop (as often seems to happen), then the
request-uri will no longer resolve to the proxy's address. Now this creates
all sorts of headaches for spiral routes and use of outbound proxies.
 
If there is a Route header present and the address of request-uri does not
evaluate to the proxy's address then (IMO) it should simply forward it to
the specified destination (and not remove any Route's). This should be done
even if the proxy has record-routed the call (as it's Record-Route may not
have been the topmost Route entry).
 
Regards,
 
Robert.
 
 
-----Original Message-----
From: Arunachalam Venkatraman [mailto:arunvenk@cisco.com]
Sent: Tuesday, April 17, 2001 4:14 PM
To: Fairlie-Cuninghame, Robert; Sherman Gong; sip@lists.bell-labs.com
Cc: 'Jonathan Rosenberg'
Subject: RE: [SIP] Request-uri does not match record-route header...



How does the proxy know if the client is DNS capable? If the proxy know it
is the default proxy and should not Record Route, it can then simply route
the call based on the maddr in the Route. Again, the name-addr in the
Req-URI is irrelevant.

 

I want to clarify that what I meant to say was that the name-addr part of
the REQ-URI seems to be irrelevant when the toptmost Route entry is copied.
The maddr and the port in the name-addr is used to route the call to the
next hop. The name-addr of the Req-URI can be anything so long as the port
is correct. I am not suggesting mangling the name-addr, though. I am
pointing out why your request will get correctly routed whether you specify
the REQ-URI to be 

 

            ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0

 

Or 

 

ACK sip:3032011001@192.168.10.114:5060;user=phone SIP/2.0

 

If the routing is done based on the maddr=192.168.10.141 in the route entry
of the Route Set built from the Record Route

(and the Contact) Received.

 

Record-Route: 
Record-Route: 



 

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 13, 2001 6:24 AM
To: 'Arunachalam Venkatraman'; Sherman Gong; sip@lists.bell-labs.com
Cc: 'Jonathan Rosenberg'
Subject: RE: [SIP] Request-uri does not match record-route header...

 

Hi, 

I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if

a.       the proxy knows that it record-routed this call leg

b.      or the Request-URI resolves to the local proxy's address.

 

I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".

For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.

At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?

Robert. 

<<[SIP] new record-route text!>> 
-----Original Message---- 
From:   Arunachalam Venkatraman [ mailto:arunvenk@cisco.com
 ] 
Sent:   Thursday, April 12, 2001 5:46 PM 
To:     Sherman Gong; sip@lists.bell-labs.com 
Subject:        RE: [SIP] Request-uri does not match record-route header... 

You are correct in that  the REQ URI in ACK of your example should be 
192.168.10.114. 
However, I don't know what is the value of copying the topmost route to the 
REQ URI . 
If the port of the UAS is different from that in the Route, it looks wrong! 
The fact is, the REQ URI is not used for routing when there is a ROUTE 
header in the message. 
I have found that the REQ URI in the ACK to a proxy I have been testing 
with, can be anything (so long as it parses ok) when there is a ROUTE 
header. The proxy uses the Route header for routing and not the REQ URI, 
when a ROUTE header is present. 

 

 -----Original Message----- 
From:   sip-admin@lists.bell-labs.com [ mailto:sip-admin@lists.bell-labs.com
 ] 
On Behalf Of Sherman Gong 
Sent:   Thursday, April 12, 2001 10:09 AM 
To:     sip@lists.bell-labs.com 
Subject:        [SIP] Request-uri does not match record-route header... 

Having a problem whereby the request-uri used in the ACK does not match 
that which was in the record-route header in the 200 OK.  Per the SIP bis 
draft (section 6.39 in the 02 version), the first Route header (constructed 
from the record-route header) should be removed and used as the 
Request-URI.  I included a couple of notes below asterisks (******). 

I have been getting conflicting arguments on which requirement this should 
follow.  Need to determine which spec. is correct. 

1)  6.29 Record-Route 

     The Record-Route request and response header field is added to a 
     request by any proxy that insists on being in the path of subsequent 
     requests for the same call leg. It contains a globally reachable 
     Request-URI that identifies the proxy server. Each proxy server adds 
     its Request-URI to the beginning of the list. 

      The server copies the Record-Route header field unchanged into the 
      response. (Record-Route is only relevant for 2xx responses.) 

      The calling user agent client copies the Record-Route header into a 
      Route header field of subsequent requests within the same call leg, 
      reversing the order of requests, so that the first entry is closest 
      to the user agent client. If the response contained a Contact header 
      field, the calling user agent adds its content as the last Route 
      header. Unless this would cause a loop, any client MUST send any 
      subsequent requests for this call leg to the first Request-URI in the 
      Route request header field and remove that entry. 

 

    The above describes building Route headers from the Record-Route 
headers, 
    and sending subsequent requests to the first Route, removing that entry.


 

  6.33 Route 

      The Route request-header field determines the route taken by a 
      request. Each host removes the first entry and then proxies the 
      request to the host listed in that entry, also using it as the 
      Request-URI. The operation is further described in Section 6.29. 

    The above notes that the Route header used to proxy a request should 
also 
     be used as the Request-URI.  This is the part that is not being done 
     correctly by the 5300.  The 5300 is building it's own request URI based

on 
     the destination of the request, rather than using the URI in the Route 
    header as the Request-URI.  Note that the 5300 is sending the request 
to the 
    correct destination, which in our case does not match that in the Route 
    header (but they don't have to match). 

 

Or 

 

2)  from page 20 of the draft 

     The maddr parameter indicates the server address to be contacted for 
this user, overriding the address supplied in the host field. This 
     address is typically, but not necessarily, a multicast address. The 
maddr field can be used to force requests from traveling users to visit 
     a home proxy even if an outbound proxy is used. 





c5300-3# 
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001 
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2 
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381 
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',

Plan:ISDN, Type:National 
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001', 
Plan:ISDN, Type:National 
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE, 
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE) 
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP 
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup 
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec 

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type 
:g711ulaw bytes: 160 
*Jan 22 08:34:05.652:  Queued event from SIP SPI : 
SIPSPI_EV_CREATE_CONNECTION 
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, 
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING) 
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE, 
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT 
ING) 
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created 
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created: 
Connid(1) created to 192.168.10.114:5060, local_p 
ort 50727 
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP 
*Jan 22 08:34:05.656: sipSPIAddLocalContact 
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE 
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method 
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE, 
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_ 
NONE) 
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001

*Jan 22 08:34:05.660:         Channel ID i = 0xA98381 
*Jan 22 08:34:05.660: Sent: 
INVITE sip:3032011001@192.168.10.114;user=phone SIP/2.0 
Via: SIP/2.0/UDP  192.168.66.184:50727 
From: "2062011001"  
To:  
Date: Sat, 22 Jan 2000 01:34:05 GMT 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Cisco-Guid: 3954197371-3232041567-0-1845248076 
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x 
CSeq: 101 INVITE 
Max-Forwards: 6 
Timestamp: 948530045 
Contact:  
Expires: 180 
Content-Type: application/sdp 
Content-Length: 138 

v=0 
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184 
s=SIP Call 
c=IN IP4 192.168.66.184 
t=0 0 
m=audio 20492 RTP/AVP 0 

*Jan 22 08:34:05.672: Received: 
SIP/2.0 100 Trying 
Via: SIP/2.0/UDP  192.168.66.184:50727 
From: "2062011001"  
To:  
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
CSeq: 101 INVITE 
Content-Length: 0 

 

*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with 
IPaddr: 192.168.1.114:34050 
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message 
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse 
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code 
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE 

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE, 
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS 
TATE_PROCEEDING_PROCEEDING) 
*Jan 22 08:34:05.852: Received: 
SIP/2.0 180 Ringing 
Via: SIP/2.0/UDP 192.168.66.184:50727 
From: "2062011001"  
To:  
Date:Sat, 22 Jan 2000 08:33:50 GMT 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Timestamp:948530045 
Server:Cisco SIP Gateway (UAS)/IOS 12.x 
CSeq: 101 INVITE 
Content-Length: 0 

 

*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with 
IPaddr: 192.168.1.114:34050 
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message 
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse 
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code 
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE 

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would

wait for 200OK to do negotiation. 

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200 
OK 

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,

SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_ 
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) 
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001 
*Jan 22 08:34:06.356: Received: 
SIP/2.0 200 OK 
Via: SIP/2.0/UDP 192.168.66.184:50727 
From: "2062011001"  
To: ;tag=6DFC2C58-820 
Date:Sat, 22 Jan 2000 08:33:50 GMT 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Timestamp:948530045 
Server:Cisco SIP Gateway (UAS)/IOS 12.x 
Contact: 
Record-Route: 
Record-Route: 
CSeq: 101 INVITE 
Content-Type:application/sdp 
Content-Length: 126 
Session-Expires:300 

v=0 
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2 
s=SIP Call 
t=0 0 
m=audio 4036 RTP/AVP 0 
c=IN IP4 209.6.0.2 

 

************************************* Note 
**************************************** 
Note that the record route header: 

Record-Route: 

  is the one that should be used for the subsequent ACK. 





*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with 
IPaddr: 192.168.1.114:34050 
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message 
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse 
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code 
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE 

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description 
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x

messages did not have SDP 
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful


*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information: 
Negotiated Codec      : g711ulaw , bytes :160 
Early Media           : 0 
Delayed Media         : 0 
Bridge Done           : 0 
New Media             : 0 
DSP DNLD Reqd         : 0 
Media Dest addr/Port  : 209.6.0.2:4036 

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges 
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection 
*Jan 22 08:34:06.360:  Queued event from SIP SPI : 
SIPSPI_EV_RECONNECT_CONNECTION 
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite 
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status = 
TRUE Route ,  
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE 
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method 
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,

SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC 
TIVE, SUBSTATE_NONE) 
*Jan 22 08:34:06.360: The Call Setup Information is : 
  Call Control Block (CCB) : 0x6221E11C 
  State of The Call        : STATE_ACTIVE 
  TCP Sockets Used         : NO 
  Calling Number           : 2062011001 
  Called Number            : 3032011001 
  Negotiated Codec         : g711ulaw 
  Negotiated Codec Bytes   : 160 
  Negotiated Dtmf-relay    : 0 
  Source IP Address (Media): 192.168.66.184 
  Source IP Port    (Media): 20492 
  Destn  IP Address (Media): 209.6.0.2 
  Destn  IP Port    (Media): 4036 
  Destn SIP Req Addr:Port  : 192.168.10.141:5060 
  Destn SIP Resp Addr:Port : 0.0.0.0:0 
  Destination Name         : 192.168.10.114 

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1 
with 192.168.10.141:5060 
*Jan 22 08:34:06.364: Sent: 
ACK sip:3032011001@192.168.10.141:5060;user=phone SIP/2.0 
Via: SIP/2.0/UDP  192.168.66.184:50727 
From: "2062011001"  
To: ;tag=6DFC2C58-820 
Date: Sat, 22 Jan 2000 01:34:05 GMT 
Call-ID: EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Route: , 
 
Max-Forwards: 6 
Content-Length: 0 
CSeq: 101 ACK 

 

********************************* Note *********************************** 
Request-URI in above ACK has domain of 192.168.10.141, should have been 
192.168.10.114 when the record-route was turned into a Route header, 
removed, and used as the Request-URI. 





*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a 
new one 

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind 
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES: 
ccCallID=1276, current_seq_num=0x217C 
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES: 
ccCallID=1276, current_seq_num=0x9EC 
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec : 
g711ulaw, Bytes=160 
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay = 
CC_CAP_DTMF_RELAY_INBAND_VOICE 
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw, 
Bytes=160 
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack 
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001 
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address 
is non-ISDN 
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref = 
0x0001 
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id 
0x227, bchan 0, dsl 0 
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001 
c5300-3# 

 

Thanks 

SG 

 

_______________________________________________ 
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_01C0C753.50CA1D90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







RE: [SIP] Request-uri does not match record-route =
header...








That=20
exactly the point - a proxy can't know whether the UA is DNS or =
whatever. It=20
must merely follow a set of rules (including decisions based on =
transaction=20
state information).


 


Before=20
I start, I think that the use of the maddr parameter in Record-Route is =
not a=20
good idea as it causes these sort of problems!! I think it should be =
removed=20
from the call flow. For instance if a proxy Record-Routes with the =
Contact and=20
its own maddr in the Route and the maddr in the Request-Uri gets =
stripped by the=20
previous hop (as often seems to happen), then the request-uri will no =
longer=20
resolve to the proxy's address. Now this creates all sorts of headaches =
for=20
spiral routes and use of outbound proxies.


 


If=20
there is a Route header present and the address of request-uri does not =
evaluate=20
to the proxy's address then (IMO) it should simply forward it to the =
specified=20
destination (and not remove any Route's). This should be done even if =
the proxy=20
has record-routed the call (as it's Record-Route may not have been the =
topmost=20
Route entry).


 


Regards,


 


Robert.


 


 


-----Original=20
Message-----
From: Arunachalam Venkatraman=20
[mailto:arunvenk@cisco.com]
Sent: Tuesday, April 17, 2001 =
4:14=20
PM
To: Fairlie-Cuninghame, Robert; Sherman Gong;=20
sip@lists.bell-labs.com
Cc: 'Jonathan =
Rosenberg'
Subject:=20
RE: [SIP] Request-uri does not match record-route =
header...



    

    
How=20
    does the proxy know if the client is DNS capable? If the proxy know =
it is=20
    the default proxy and should not Record Route, it can then simply =
route the=20
    call based on the maddr in the Route. Again, the name-addr in the =
Req-URI is=20
    irrelevant.

    
 
=

    
I=20
    want to clarify that what I meant to say was that the name-addr =
part of the=20
    REQ-URI seems to be irrelevant when the toptmost Route entry is =
copied. The=20
    maddr and the port in the name-addr is used to route the call to =
the next=20
    hop. The name-addr of the Req-URI can be anything so long as the =
port is=20
    correct. I am not suggesting mangling the name-addr, though. I am =
pointing=20
    out why your request will get correctly routed whether you specify =
the=20
    REQ-URI to be 

    
 
=

    
           =20
    ACK=20
    sip:3032011001@192.168.10.141:5060;user=3Dphone =
SIP/2.0

    
 

    
Or=20
    

    
 

    
ACK=20
    sip:3032011001@192.168.10.114:5060;user=3Dphone =
SIP/2.0

    
 

    
If the=20
    routing is done based on the maddr=3D192.168.10.141 in the route =
entry of the=20
    Route Set built from the Record Route

    
(and=20
    the Contact) Received.

    
 
=

    
Record-Route:<sip:3032011001@east.c53005.com:5070;maddr=3D192.1=
68.10.141;trans 
port=3Dudp> 
Record-Route:<sip:3032011001@192.168.10.114:5060;user=3Dphone;m=
addr=3D192.168.10 
.141;transport=3Dudp> 

    
 
=

    
-----Original=20
    Message-----
From:=20
    Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
Sent: Friday, April 13, 2001 =
6:24=20
    AM
To: =
'Arunachalam=20
    Venkatraman'; Sherman Gong; sip@lists.bell-labs.com
Cc: 'Jonathan =
Rosenberg'
Subject: RE: [SIP] =
Request-uri does not=20
    match record-route header...

    
 

    
Hi, 

    
I =
believe the=20
    Record-Route test has been completely rewritten (message attached). =
I=20
    personally believe however Arunachalam's response should be =
qualified by the=20
    saying that a proxy should only use the next Route header=20
    if

    
a.      =20
    the=20
    proxy knows that it record-routed this call leg

    
b.     =20
    or=20
    the Request-URI resolves to the local proxy's =
address.

    
 

    
I don't =
believe=20
    this is reflected in the new Record-Route text. It touches on an =
unresolved=20
    (or at least that was my feeling) discussion a long time about =
whether a=20
    Record-Routing's interaction with "Outbound=20
    Proxies".

    
For =
instance, when=20
    a UA or Proxy, puts the first Route header in the Request-URI but =
then sends=20
    the message to an outbound proxy because the UA lacks DNS =
capability. The=20
    outbound proxy may not have Record-Route'd but it must not =
remove/process=20
    the next Route header either.

    
At risk =
of=20
    reopening this discussion, did we reach at conclusion on this =
point, that=20
    is, when a proxy should use the next Route header and when should =
it not (if=20
    the Request-URI is does not resolve to the proxy's=20
    address)?

    
Robert. 

    
<<[SIP] new=20
    record-route text!>> 
-----Original=20
    Message----=20
    
From:  =20
    Arunachalam Venkatraman [mailto:arunvenk@cisco.com]=
 =

Sent:   Thursday, April=20
    12, 2001 5:46 PM=20
    
To:     Sherman =
Gong;=20
    sip@lists.bell-labs.com 
Subject:        RE: =
[SIP]=20
    Request-uri does not match record-route =
header... 

    
You are =
correct in=20
    that  the REQ URI in ACK of your example should =
be 
192.168.10.114. 
However, I don't=20
    know what is the value of copying the topmost route to=20
    the=20
    
REQ URI =

    .=20
    
If the =
port of the=20
    UAS is different from that in the Route, it looks =
wrong! 
The =
fact is, the=20
    REQ URI is not used for routing when there is a =
ROUTE 
header =
in the=20
    message.=20
    
I have =
found that=20
    the REQ URI in the ACK to a proxy I have been =
testing 
with, =
can be=20
    anything (so long as it parses ok) when there is a =
ROUTE 
header. =
The proxy=20
    uses the Route header for routing and not the REQ =
URI, 
when a =
ROUTE=20
    header is present. 

    
 

    
 -----Original=20
    Message-----=20
    
From: =
 =20
    sip-admin@lists.bell-labs.com [mailto:sip-admin@lists=
.bell-labs.com] 
On =
Behalf Of=20
    Sherman Gong=20
    
Sent:  =20
    Thursday, April 12, 2001 10:09 AM 
To:    =20
    sip@lists.bell-labs.com 
Subject:       =20
    [SIP] Request-uri does not match record-route =
header... 

    
Having =
a problem=20
    whereby the request-uri used in the ACK does not =
match 
that =
which was in=20
    the record-route header in the 200 OK.  Per the SIP=20
    bis=20
    
draft =
(section=20
    6.39 in the 02 version), the first Route header=20
    (constructed=20
    
from =
the=20
    record-route header) should be removed and used as =
the 
Request-URI. =20
    I included a couple of notes below asterisks =
(******). 

    
I have =
been=20
    getting conflicting arguments on which requirement this=20
    should=20
    
follow.  Need=20
    to determine which spec. is correct. 

    
1)  6.29=20
    Record-Route=20
    

    
    =20
    The Record-Route request and response header field is added to=20
    a=20
    
    =20
    request by any proxy that insists on being in the path of=20
    subsequent=20
    
    =20
    requests for the same call leg. It contains a globally=20
    reachable=20
    
    =20
    Request-URI that identifies the proxy server. Each proxy server=20
    adds =

    
    =20
    its Request-URI to the beginning of the list. 

    
     =20
    The server copies the Record-Route header field unchanged into=20
    the=20
    
     =20
    response. (Record-Route is only relevant for 2xx=20
    responses.)=20
    

    
     =20
    The calling user agent client copies the Record-Route header into=20
    a=20
    
     =20
    Route header field of subsequent requests within the same call=20
    leg, =

    
     =20
    reversing the order of requests, so that the first entry is=20
    closest=20
    
     =20
    to the user agent client. If the response contained a Contact=20
    header=20
    
     =20
    field, the calling user agent adds its content as the last=20
    Route=20
    
     =20
    header. Unless this would cause a loop, any client MUST send=20
    any=20
    
     =20
    subsequent requests for this call leg to the first Request-URI in=20
    the=20
    
     =20
    Route request header field and remove that =
entry. 

    
 

    
   =20
    The above describes building Route headers from the=20
    Record-Route=20
    
headers, 
   =20
    and sending subsequent requests to the first Route, removing that=20
    entry.=20
    

    
 

    
  =
6.33=20
    Route=20
    

    
     =20
    The Route request-header field determines the route taken by=20
    a=20
    
     =20
    request. Each host removes the first entry and then proxies=20
    the=20
    
     =20
    request to the host listed in that entry, also using it as=20
    the=20
    
     =20
    Request-URI. The operation is further described in Section=20
    6.29.=20
    

    
   =20
    The above notes that the Route header used to proxy a request=20
    should=20
    
also 
    =20
    be used as the Request-URI.  This is the part that is not =
being=20
    done =

    
    =20
    correctly by the 5300.  The 5300 is building it's own request =
URI=20
    based=20
    
on 
    =20
    the destination of the request, rather than using the URI in the=20
    Route=20
    
   =20
    header as the Request-URI.  Note that the 5300 is sending the=20
    request=20
    
to=20
    the=20
    
   =20
    correct destination, which in our case does not match that in the=20
    Route=20
    
   =20
    header (but they don't have to match). 

    
 

    
Or 

    
 

    
2)  from page=20
    20 of the draft=20
    

    
    =20
    The maddr parameter indicates the server address to be contacted=20
    for=20
    
this =
user,=20
    overriding the address supplied in the host field. =
This 
    =20
    address is typically, but not necessarily, a multicast address.=20
    The=20
    
maddr =
field can be=20
    used to force requests from traveling users to =
visit 
    =20
    a home proxy even if an outbound proxy is used. 

    

    
c5300-3# 
*Jan 22 =

    08:34:05.632: ISDN Se0:23: RX <-  SETUP pd =3D 8  =
callref =3D=20
    0x0001=20
    
*Jan 22 =

    08:34:05.632:         =
Bearer=20
    Capability i =3D 0x8090A2 
*Jan=20
    22 08:34:05.636:         =
Channel ID=20
    i =3D 0xA98381=20
    
*Jan 22 =

    08:34:05.636:         =
Calling Party=20
    Number i =3D 0x2180, '2062011001', 
Plan:ISDN,=20
    Type:National=20
    
*Jan 22 =

    08:34:05.636:         =
Called Party=20
    Number i =3D 0xA1, '3032011001', 
Plan:ISDN,=20
    Type:National=20
    
*Jan 22 =

    08:34:05.652: 0x6221E11C : State change from =
(STATE_NONE, 
SUBSTATE_NONE) =20
    to (STATE_IDLE, SUBSTATE_NONE) 
*Jan=20
    22 08:34:05.652:  Queued event from SIP SPI :=20
    SIPSPI_EV_CC_CALL_SETUP 
*Jan=20
    22 08:34:05.652: CCSIP-SPI-CONTROL: =20
    act_idle_call_setup 
*Jan=20
    22 08:34:05.652:  act_idle_call_setup:Not using Voice Class=20
    Codec=20
    

    
*Jan 22 =

    08:34:05.652: act_idle_call_setup: preferred_codec set[0]=20
    type =

    
:g711ulaw bytes:=20
    160=20
    
*Jan 22 =

    08:34:05.652:  Queued event from SIP SPI : 
SIPSPI_EV_CREATE_CONNECTION 
*Jan 22 =

    08:34:05.652: 0x6221E11C : State change from =
(STATE_IDLE, 
SUBSTATE_NONE) =20
    to (STATE_IDLE, SUBSTATE_CONNECTING) 
*Jan=20
    22 08:34:05.652: 0x6221E11C : State change from=20
    (STATE_IDLE,=20
    
SUBSTATE_CONNECTING) =20
    to (STATE_IDLE, SUBSTATE_CONNECT 
ING) 
*Jan 22 =

    08:34:05.652: CCSIP-SPI-CONTROL: =20
    act_idle_connection_created 
*Jan=20
    22 08:34:05.652: CCSIP-SPI-CONTROL: =20
    act_idle_connection_created: 
Connid(1) created=20
    to 192.168.10.114:5060, local_p 
ort=20
    50727=20
    
*Jan 22 =

    08:34:05.656: CCSIP-SPI-CONTROL: =20
    sipSPIOutgoingCallSDP 
*Jan=20
    22 08:34:05.656: sipSPIAddLocalContact 
*Jan=20
    22 08:34:05.656:  Queued event from SIP SPI :=20
    SIPSPI_EV_SEND_MESSAGE 
*Jan=20
    22 08:34:05.656: CCSIP-SPI-CONTROL: =20
    sip_stats_method=20
    
*Jan 22 =

    08:34:05.656: 0x6221E11C : State change from =
(STATE_IDLE, 
SUBSTATE_CONNECTING) =20
    to (STATE_SENT_INVITE, SUBSTATE_ 
NONE) 
*Jan 22 =

    08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd =3D 8  =
callref =3D=20
    0x8001=20
    
*Jan 22 =

    08:34:05.660:         =
Channel ID i =3D=20
    0xA98381=20
    
*Jan 22 =

    08:34:05.660: Sent: 
INVITE=20
    sip:3032011001@192.168.10.114;user=3Dphone =
SIP/2.0 
Via:=20
    SIP/2.0/UDP  192.168.66.184:50727 
From:=20
    "2062011001"=20
    <sip:2062011001@192.168.66.184> 
To:=20
    =
<sip:3032011001@192.168.10.114;user=3Dphone> 
Date: =
Sat, 22 Jan=20
    2000 01:34:05 GMT=20
    
Call-ID:=20
    EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Cisco-Guid:=20
    3954197371-3232041567-0-1845248076 
User-Agent: Cisco=20
    SIP Gateway (UAC)/IOS 12.x 
CSeq:=20
    101 INVITE=20
    
Max-Forwards:=20
    6=20
    
Timestamp:=20
    948530045=20
    
Contact:=20
    =
<sip:2062011001@192.168.66.184:5060;user=3Dphone> 
Expires:=20
    180=20
    
Content-Type:=20
    application/sdp=20
    
Content-Length:=20
    138=20
    

    
v=3D0 
o=3DCiscoSystemsSIP-GW-UserAgent=20
    7656 9288 IN IP4 192.168.66.184 
s=3DSIP=20
    Call =

    
c=3DIN =
IP4=20
    192.168.66.184=20
    
t=3D0=20
    0=20
    
m=3Daudio 20492=20
    RTP/AVP 0=20
    

    
*Jan 22 =

    08:34:05.672: Received: 
SIP/2.0 =
100=20
    Trying=20
    
Via:=20
    SIP/2.0/UDP  192.168.66.184:50727 
From:=20
    "2062011001"=20
    <sip:2062011001@192.168.66.184> 
To:=20
    =
<sip:3032011001@192.168.10.114;user=3Dphone> 
Call-ID:=20
    EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
CSeq: =
101=20
    INVITE=20
    
Content-Length:=20
    0=20
    

    
 

    
*Jan 22 =

    08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI=20
    with =

    
IPaddr: =

    192.168.1.114:34050 
*Jan=20
    22 08:34:05.672: CCSIP-SPI-CONTROL: =20
    act_sentinvite_new_message 
*Jan=20
    22 08:34:05.672: CCSIP-SPI-CONTROL: =20
    sipSPICheckResponse 
*Jan=20
    22 08:34:05.672: CCSIP-SPI-CONTROL: =20
    sip_stats_status_code 
*Jan=20
    22 08:34:05.672:  Roundtrip delay 16 milliseconds for method=20
    INVITE=20
    

    
*Jan 22 =

    08:34:05.672: 0x6221E11C : State change from=20
    (STATE_SENT_INVITE, 
SUBSTATE_NONE) =20
    to (STATE_RECD_PROCEEDING, SUBS 
TATE_PROCEEDING_PROCEEDING) 
*Jan 22 =

    08:34:05.852: Received: 
SIP/2.0 =
180=20
    Ringing=20
    
Via: =
SIP/2.0/UDP=20
    192.168.66.184:50727 
From:=20
    "2062011001"=20
    <sip:2062011001@192.168.66.184> 
To:=20
    =
<sip:3032011001@192.168.10.114;user=3Dphone> 
Date:Sat, 22 Jan=20
    2000 08:33:50 GMT=20
    
Call-ID:=20
    EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Timestamp:948530045 
Server:Cisco SIP=20
    Gateway (UAS)/IOS 12.x 
CSeq:=20
    101 INVITE=20
    
Content-Length:=20
    0=20
    

    
&n=
bsp;

    
*Jan 22 =

    08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI=20
    with =

    
IPaddr: =

    192.168.1.114:34050 
*Jan=20
    22 08:34:05.856: CCSIP-SPI-CONTROL: =20
    act_recdproc_new_message 
*Jan=20
    22 08:34:05.856: CCSIP-SPI-CONTROL: =20
    sipSPICheckResponse 
*Jan=20
    22 08:34:05.856: CCSIP-SPI-CONTROL: =20
    sip_stats_status_code 
*Jan=20
    22 08:34:05.856:  Roundtrip delay 200 milliseconds for method=20
    INVITE=20
    

    
*Jan 22 =

    08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING -=20
    would=20
    
wait =
for 200OK to=20
    do negotiation.=20
    

    
*Jan 22 =

    08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in=20
    200=20
    
OK 

    
*Jan 22 =

    08:34:05.856: 0x6221E11C : State change from=20
    (STATE_RECD_PROCEEDING, 
SUBSTATE_PROCEEDING_PROCEEDING) =20
    to (STATE_=20
    
RECD_PROCEEDING,=20
    SUBSTATE_PROCEEDING_ALERTING) 
*Jan=20
    22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd =3D =
8  callref =3D=20
    0x8001=20
    
*Jan 22 =

    08:34:06.356: Received: 
SIP/2.0 =
200=20
    OK=20
    
Via: =
SIP/2.0/UDP=20
    192.168.66.184:50727 
From:=20
    "2062011001"=20
    <sip:2062011001@192.168.66.184> 
To:=20
    =
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820 
Date:Sat, 22 Jan=20
    2000 08:33:50 GMT=20
    
Call-ID:=20
    EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Timestamp:948530045 
Server:Cisco SIP=20
    Gateway (UAS)/IOS 12.x 
Contact:<sip:3032011001@192.168.67.186:5060;user=3Dphone> 
Record-Route:<sip:3032011001@east.c53005.com:5070;maddr=3D192.1=
68.10.141;trans 
port=3Dudp> 
Record-Route:<sip:3032011001@192.168.10.114:5060;user=3Dphone;m=
addr=3D192.168.10 
.141;transport=3Dudp> 
CSeq: =
101=20
    INVITE=20
    
Content-Type:application/sdp 
Content-Length:=20
    126=20
    
Session-Expires:300 

    
v=3D0 
o=3DCiscoSystemsSIP-GW-UserAgent=20
    6565 3960 IN IP4 10.1.1.2 
s=3DSIP=20
    Call =

    
t=3D0=20
    0=20
    
m=3Daudio 4036=20
    RTP/AVP 0=20
    
c=3DIN =
IP4=20
    209.6.0.2=20
    

    
 

    
*************************************=20
    Note =

    
**************************************** 
Note =
that the=20
    record route header: 

    
Record-Route:<sip:3032011001@192.168.10.114:5060;user=3Dphone;m=
addr=3D192.168.10 
.141;transport=3Dudp> 

    
  =
is the one=20
    that should be used for the subsequent ACK. 

    

    
*Jan 22 =

    08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI=20
    with =

    
IPaddr: =

    192.168.1.114:34050 
*Jan=20
    22 08:34:06.356: CCSIP-SPI-CONTROL: =20
    act_recdproc_new_message 
*Jan=20
    22 08:34:06.356: CCSIP-SPI-CONTROL: =20
    sipSPICheckResponse 
*Jan=20
    22 08:34:06.360: CCSIP-SPI-CONTROL: =20
    sip_stats_status_code 
*Jan=20
    22 08:34:06.360:  Roundtrip delay 704 milliseconds for method=20
    INVITE=20
    

    
*Jan 22 =

    08:34:06.360: sipSPIGetSdpBody : Parse incoming session=20
    description=20
    
*Jan 22 =

    08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as=20
    18x=20
    
messages did not=20
    have SDP=20
    
*Jan 22 =

    08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation=20
    Successful=20
    

    
*Jan 22 =

    08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media=20
    Information:=20
    
Negotiated=20
    Codec      : g711ulaw , bytes=20
    :160 =

    
Early=20
    Media           : =

    0=20
    
Delayed =

    Media         : =
0 
Bridge=20
    Done           :=20
    0=20
    
New=20
    =
Media           &=
nbsp;=20
    : 0=20
    
DSP =
DNLD=20
    Reqd         : =
0 
Media =
Dest=20
    addr/Port  : 209.6.0.2:4036 

    
*Jan 22 =

    08:34:06.360: sipSPIProcessMediaChanges 
*Jan=20
    22 08:34:06.360: CCSIP-SPI-CONTROL: =20
    sipSPIReconnectConnection 
*Jan=20
    22 08:34:06.360:  Queued event from SIP SPI =
: 
SIPSPI_EV_RECONNECT_CONNECTION 
*Jan 22 =

    08:34:06.360: CCSIP-SPI-CONTROL: =20
    sipSPIProcess200OKforinvite 
*Jan=20
    22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders =
status=20
    =3D=20
    
TRUE =
Route=20
    <sip:3032011001@east.c53005.com:5070 
;maddr=3D192.168.10.141>,=20
    =
<sip:3032011001@192.168.67.186:5060;user=3Dphone> 
*Jan 22 =

    08:34:06.360:  Queued event from SIP SPI :=20
    SIPSPI_EV_SEND_MESSAGE 
*Jan=20
    22 08:34:06.360: CCSIP-SPI-CONTROL: =20
    sip_stats_method=20
    
*Jan 22 =

    08:34:06.360: 0x6221E11C : State change from=20
    (STATE_RECD_PROCEEDING, 
SUBSTATE_PROCEEDING_ALERTING) =20
    to (STATE_AC=20
    
TIVE,=20
    SUBSTATE_NONE)=20
    
*Jan 22 =

    08:34:06.360: The Call Setup Information is : 
  =
Call=20
    Control Block (CCB) : 0x6221E11C 
  =
State of=20
    The Call        :=20
    STATE_ACTIVE=20
    
  =
TCP Sockets=20
    Used         : =
NO 
  =
Calling=20
    Number           =
:=20
    2062011001=20
    
  =
Called=20
    =
Number           =
 :=20
    3032011001=20
    
  =
Negotiated=20
    Codec         :=20
    g711ulaw=20
    
  =
Negotiated=20
    Codec Bytes   : 160 
  =
Negotiated=20
    Dtmf-relay    : 0 
  =
Source IP=20
    Address (Media): 192.168.66.184 
  =
Source IP=20
    Port    (Media): 20492 
  =
Destn =20
    IP Address (Media): 209.6.0.2 
  =
Destn =20
    IP Port    (Media): 4036 
  =
Destn SIP=20
    Req Addr:Port  : 192.168.10.141:5060 
  =
Destn SIP=20
    Resp Addr:Port : 0.0.0.0:0 
  =
Destination=20
    Name         :=20
    192.168.10.114=20
    

    
*Jan 22 =

    08:34:06.364: HandleUdpReconnection: Udp socket connected for fd:=20
    1=20
    
with=20
    192.168.10.141:5060 
*Jan=20
    22 08:34:06.364: Sent: 
ACK=20
    sip:3032011001@192.168.10.141:5060;user=3Dphone =
SIP/2.0 
Via:=20
    SIP/2.0/UDP  192.168.66.184:50727 
From:=20
    "2062011001"=20
    <sip:2062011001@192.168.66.184> 
To:=20
    =
<sip:3032011001@192.168.10.114;user=3Dphone>;tag=3D6DFC2C58-820 
Date: =
Sat, 22 Jan=20
    2000 01:34:05 GMT=20
    
Call-ID:=20
    EBB0437B-C0A50A61-0-6DFC4058@192.168.66.184 
Route:=20
    =
<sip:3032011001@east.c53005.com:5070;maddr=3D192.168.10.141>, 
<sip:=
3032011001@192.168.67.186:5060;user=3Dphone> 
Max-Forwards:=20
    6=20
    
Content-Length:=20
    0=20
    
CSeq: =
101=20
    ACK=20
    

    
 

    
*********************************=20
    Note *********************************** 
Request-URI in=20
    above ACK has domain of 192.168.10.141, should have =
been 
192.168.10.114=20
    when the record-route was turned into a Route =
header, 
removed, and used=20
    as the Request-URI. 

    

    
*Jan 22 =

    08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, =
create=20
    a=20
    
new=20
    one=20
    

    
*Jan 22 =

    08:34:06.364: CCSIP-SPI-CONTROL:  =
ccsip_caps_ind 
*Jan 22 =

    08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT=20
    VALUES:=20
    
ccCallID=3D1276,=20
    current_seq_num=3D0x217C 
*Jan=20
    22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW=20
    VALUES:=20
    
ccCallID=3D1276,=20
    current_seq_num=3D0x9EC 
*Jan=20
    22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec=20
    :=20
    
g711ulaw,=20
    Bytes=3D160=20
    
*Jan 22 =

    08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay=20
    =3D=20
    
CC_CAP_DTMF_RELAY_INBAND_VOICE 
*Jan 22 =

    08:34:06.368: ccsip_caps_ind: Load DSP with codec :=20
    g711ulaw,=20
    
Bytes=3D160 
*Jan 22 =

    08:34:06.368: CCSIP-SPI-CONTROL:  =
ccsip_caps_ack 
*Jan 22 =

    08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd =3D 8  =
callref =3D=20
    0x8001=20
    
*Jan 22 =

    08:34:06.372:         =
Progress Ind i=20
    =3D 0x8182 - Destination address 
is=20
    non-ISDN=20
    
*Jan 22 =

    08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd =3D =
8  callref=20
    =3D=20
    
0x0001 
*Jan 22 =

    08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call=20
    id=20
    
0x227, =
bchan 0,=20
    dsl 0=20
    
3w0d:=20
    %ISDN-6-CONNECT: Interface Serial0:0 is now connected to=20
    2062011001=20
    
c5300-3# 

    
 

    
Thanks 

    
SG 

    
 

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

    
 

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