From sip-bounces@ietf.org Sat Dec 01 12:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyW5J-0008O2-VD; Sat, 01 Dec 2007 12:24:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyW5I-0008Na-LT for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 12:24:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyW5I-0008NS-Al for sip@ietf.org; Sat, 01 Dec 2007 12:24:56 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyW5H-0002Hi-Fy for sip@ietf.org; Sat, 01 Dec 2007 12:24:55 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1HOZU13996; Sat, 1 Dec 2007 09:24:35 -0800 In-Reply-To: <469FF0A4.8040201@nostrum.com> References: <46928F5F.3080502@softarmor.com> <469FF0A4.8040201@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E5BEAD7-C909-425C-95A4-5126C4AB5479@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 09:24:23 -0800 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: Outbound: TCP and SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Adam, I believe this comment has been adressed in outbound-11 section 4.4.1: > If sending over a SigComp [25] compressed data stream, the CRLF > keepalives are sent inside the compressed stream. thanks, -rohan On Jul 19, 2007, at 4:15 PM, Adam Roach wrote: > With the move to CRLF for keepalive in outbound, the language > discussing STUN handling with SigComp in TCP is also gone. This > makes sense, since TCP no longer uses STUN. > > However, there was no equivalent language added for how to handle > the CRLF keepalives in conjunction with SigComp. > > As with the earlier STUN mechanism, you can't just send the CRLF > stuff down the TCP connection -- it needs to be wrapped in SigComp. > Of course, we could employ the same mechanism originally proposed > for STUN (the well-known shim), which would be the 13-byte SigComp > shim, plus 2 bytes (CRLF) or 4 bytes (double CRLF). > > Alternately, we can shave this down a _little_ bit by using > bytecodes specifically designed to output just the CRLFs we need; > for a double-CRLF, it would look like: > > at (128) > OUTPUT (crlf, 4) > JUMP(end) > > :crlf byte(13,10,13,10) > > :end > END-MESSAGE (0,0,0,0,0,0,0) > > Which translates to the following 14 bytes: f8 00 b1 22 a0 86 04 16 > 06 0d 0a 0d 0a 23 > > > (Yes, I realize this is 14 bytes instead of the 17 bytes you get > with the shim, so it might not be worth using custom code). > > For a single CRLF, such code would end up looking like this: > > at (64) > :crlf pad(2) > > at (128) > LOAD (crlf, 3338) > OUTPUT (crlf, 2) > END-MESSAGE (0,0,0,0,0,0,0) > > Which translates to the following 11 bytes: f8 00 81 0e 86 ad 0a 22 > 86 02 23. > > In practice, we're probably best off just normatively saying that > the CRLF characters are sent inside SigComp, and that the mechanism > for representing them is a matter to be handled by the SigComp > compressor at the sending end. We can point out the shim, and we > can include the foregoing purpose-built SigComp messages, but there > may be architectural complications to using either of them, so the > ultimate requirement is simply to send something that produces > "CRLF" as its output when it is sent. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 12:34:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWDi-0007K5-1B; Sat, 01 Dec 2007 12:33:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyWDg-0007Jw-HT for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 12:33:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWDg-0007Jo-7u for sip@ietf.org; Sat, 01 Dec 2007 12:33:36 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyWDe-0007kl-GF for sip@ietf.org; Sat, 01 Dec 2007 12:33:36 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1HWmU14211; Sat, 1 Dec 2007 09:32:49 -0800 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437115B748E2@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DFF@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437115B748E2@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90454AB8-5589-4E19-A999-F54347B6BB4D@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 09:32:36 -0800 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Francois Audet , Gonzalo Camarillo , cboulton@ubiquitysoftware.com Subject: [Sip] Re: Another comment on the outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brian, I think this is now addressed in outbound-11 with the following comment in section 4.2: > If the registrar did not support outbound, the UA may have > unintentionally registered an unroutable contact. It is the > responsiblity of the UA to remove any inappropriate Contacts. thanks, -rohan On Jul 23, 2007, at 7:18 AM, Brian Stucker wrote: >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: Friday, July 20, 2007 11:31 AM >> To: Stucker, Brian (RICH1:AR00) >> Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet, >> Francois (SC100:3055); cboulton@ubiquitysoftware.com; >> Jonathan Rosenberg; Gonzalo Camarillo >> Subject: Re: Another comment on the outbound draft >> >> >> On Jul 19, 2007, at 10:47 PM, Brian Stucker wrote: >> >>> Rohan/Cullen, >>> >>> One other comment on the outbound draft... I think a >> statement needs >>> to be added to the draft to cover the following situation: >>> >>> Let's say a UAC is registering from behind a NAT. If the outbound >>> proxy does not support outbound (i.e. does not put 'ob' in the Path >>> header) then the resulting registration will contain an >> address that >>> is likely not reachable by the local outbound proxy after the NAT >>> binding has expired. The UAC can detect that this may occur >> by looking >>> for the 'outbound' tag in the supported header of the registration >>> response and act accordingly. However, in section 4.2 the >> text in the >>> third paragraph on page 15 shows that checking the >> supported header to >>> see if outbound processing occurred is only a MAY instead of a MUST. >>> >>> I believe that the UAC must do this checking unless they know for a >>> fact that their contact address is globally routable (or at least >>> reachable by the local outbound proxy at all times), and if not, >>> re-register using their server reflexive address in the contact URI >>> via STUN or derived through some other means (observation of >>> received/rport values in the registration response Via header, etc). >> >> Hi Brian, >> >> Originally I was thinking that the UAC might not care. If >> the UAC already set its Contact prepared for the possibility >> of both outbound and non-outbound cases, it won't need to do >> anything differently in its initial REGISTER request. >> However, the UAC MUST check if the 'outbound' tag was in the >> Require header (see Adam's note on tags) to see if outbound >> was applied, so it can add or not add the 'ob' >> parameter to the UACs Contact URI. >> >> thanks, >> -rohan >> > > Hi Rohan, > > Sorry for the delay in replying. > > There's a blurb in section 4.3 (third paragraph) that seems to throw a > possible wrench into that logic... > > The contact is formed normally in that the UAC uses the IP > address of > the device (even if the device is behind a NAT). > > The section on registrations (4.2) does not state anything in > particular > about the content of the Contact URI other than the parameters that > are > specific to the outbound draft itself. So, if in general, the > expectation (from section 4.3) is that the contact is composed of > the IP > address of the device (wondering why it shouldn't generally be the > contact it registered) and there's nothing stated in 4.2 specifically, > it may follow that the UAC implementation doesn't consider the case > I am > raising and is left without a usable registration. > > Regards, > Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 12:37:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWGs-0004dX-JX; Sat, 01 Dec 2007 12:36:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyWGr-0004aY-Hg for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 12:36:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWGr-0004aP-6t for sip@ietf.org; Sat, 01 Dec 2007 12:36:53 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyWGq-0002kU-Gn for sip@ietf.org; Sat, 01 Dec 2007 12:36:52 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1HaaU14427; Sat, 1 Dec 2007 09:36:36 -0800 In-Reply-To: <46A52ACF.3030402@db.org> References: <46A52ACF.3030402@db.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 09:36:24 -0800 To: "Alfred E. Heggestad" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Cullen Jennings , Rohan Mahy , SIP IETF Subject: [Sip] Re: Comments on draft-ietf-sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, All your comments have been addressed in outbound-11 as noted below. thanks, -rohan On Jul 23, 2007, at 3:25 PM, Alfred E. Heggestad wrote: > Comments on draft-ietf-sip-outbound-10 > > by Alfred E. Heggestad > 23. July 2007 > > > > > > 3.2. Single Registrar and UA > > > > REGISTER sip:example.com;keep-crlf SIP/2.0 > > Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 > > Max-Forwards: 70 > > From: Bob ;tag=d879h76 > > To: Bob > > Call-ID: 8921348ju72je840.204 > > CSeq: 1 REGISTER > > Supported: path > > Contact: ; reg-id=1; > > ;+sip.instance="" > > Content-Length: 0 > > I find this example SIP message a bit strange. If the message is sent > over TCP, shouldn't the URI in the Contact header contain > ";transport=tcp" ? > Also, is the IP address in the Via header supposed to be a private IP > address (192.168.x.y) or a public IP address? yes. fixed. > > 3.5.3. STUN Keepalive Technique > > > > This technique can only be used for transports, such as UDP, > that are > > not connection oriented. > > Suggest rewriting this sentence: > > "This approach MUST only be used with connection-less transports > such as UDP." accepted. > > 4.4.3. Keepalive with STUN > > > > This approach MUST only be used with transports, such as UDP, that > > are not connection oriented. > > same as above likewise > > 12.2. SIP/SIPS URI Parameters > > > > Parameter Name Predefined Values Reference > > ____________________________________________ > > keep-crlf No [RFC AAAA] > > keep-stun No [RFC AAAA] > > suggest to merge these two parameters to "keepalive" ack > > 12.2. SIP/SIPS URI Parameters > > > > Parameter Name Predefined Values Reference > > ____________________________________________ > > timed-keepalive No [RFC AAAA] > > ^^^^^^^^^^^^^^^ > > This URI parameter is referred to as 'timed-keepalives' (with the > trailing 's') > a total of 4 locations in the document. They should be updated to read > "timed-keepalive" ack > apart from these comments, the document is well structured and easy > to read. many thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 12:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWY2-0007yb-OA; Sat, 01 Dec 2007 12:54:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyWY1-0007yQ-5H for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 12:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWY0-0007yI-Rv for sip@ietf.org; Sat, 01 Dec 2007 12:54:36 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyWXy-0008Sn-8j for sip@ietf.org; Sat, 01 Dec 2007 12:54:36 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1HrYU14880; Sat, 1 Dec 2007 09:53:35 -0800 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03EC9853@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F03EC9853@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] WGLC comments on sip-outbound-10: behaviour of the registrar Date: Sat, 1 Dec 2007 09:53:23 -0800 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, I largely used your text for a reworded section 6, except that the text deals with the binding rules for GRUU as well as outbound. I believe all your points are addressed in outbound-11. more inline. On Aug 1, 2007, at 7:34 AM, wrote: > > Hi, > > Here are my comments regarding to the behaviour of the registrar > as specified within SIP Outbound-10. > > As a summary, it seems to me that section 6 would need substantial > changes to become clearer. I am sorry to not find and point all that > out until WGLC. To compensate I tried to rework section 6 and you > can find the result in the end of this email. Please use for version > 11, if you find it useful. > > > 3.1. Summary of Mechanism > > Nit: > > "The registrar can use the reg-id label to > recognize that a UA is registering after a reboot or a network > failure." > > In practice the registrar can not detect from the reg-id > if the UA is just refreshing an existing registration or > registering after a reboot or other failure. Thus my suggestion > is to replace that sentence with this one: "The registrar can > use the reg-id label to recognize whether an UA is creating a > new flow or refreshing an existing flow, possibly after a reboot > or a network failure." incorporated > 6. Registrar Mechanisms > > Nit: > > "When no +sip.instance media feature parameter is present in a > Contact > header field value in a REGISTER request, the corresponding binding > is still between an AOR and the URI from that Contact header field > value." > > I believe this statement should be dropped from the spec as it does > not tell anything new compared to RFC 3261. But if the idea is rather > to tell what the registrar should do if the Contact contains reg-id > but does not contain the +sip.instance, then the statement has to be > clarified to point that out. In my opinion the statement is not needed > even for this latter case as the section 6 covers that case later. this was confusing to others, so I have left it in place. > Nit: > > "When a +sip.instance media feature parameter is present in a > Contact header field value in a REGISTER request, the corresponding > binding is between an AOR and the combination of the instance-id > (from the +sip.instance media feature parameter) and the value of > reg-id parameter if it is present." > > As GRUU specifies what the registrar should do when the Contact > header contains +sip.instance without reg-id, this statement should > more clearly focus to the case when Contact has both of them. I > suggest > rewrite like this: "When both +sip.instance media feature parameter > and reg-id parameter are present in a Contact header field of > a REGISTER request, the corresponding binding is between an AOR and > the combination of the instance-id (from the +sip.instance media > feature parameter) and the value of reg-id parameter." With the > current formulation the statement is a bit open-ended and leaves the > reader to wonder what might happen if reg-id parameter is not present > (which is the case in GRUU). the outbound spec is supposed to define the new binding behavior for both GRUU and outbound-style registrations. > Nit: > > "A Contact header field value with an instance-id but no reg-id is > valid" > > An informative reference to GRUU would be helpful here. done. > Minor technical: > > "For a binding with an > instance-id, the registrar still stores the Contact header field > value URI with the binding, but does not consider the Contact > URI for > comparison purposes." > > Why does the registrar has to store the URI ? To which purpose it > will be used ? If there is no explicit purpose for storing the URI > I suggest dropping that statement and reformulating this one: "The > registrar MUST also store all the Contact header field information" > just to require storage all the Contact header parameters, not URI. The registrar has to store the URI so the authoritative proxy can place the URI in the Request-URI (retarget) when it forwards the request. This URI is not used for next hop routing however. > Major technical: > > "Specifically, if it ignores the 'reg-id' parameter the registrar > MUST > use RFC 3261 Contact binding rules" > > What happens if the UA is requesting both Outbound and GRUU behavior > in its REGISTER request, but the edge proxy does not support > Outbound ? > The statement above in the Outbound seems to suggest that the > registrar > will not deliver even the GRUUs (and store the instance-Id with AOR as > specified for GRUU), which however does not sound correct to me. > Instead > the UA should get its GRUUs and the registrar should use binding rules > specified in GRUU spec. A registrar which supports GRUU MUST also support outbound. If the UA requests outbound, it is highly likely that the GRUU will be unusable anyway. > Nit: > > "If a Path header field is present, RFC 3327 [5] requires the > registrar > to store this information as well." > > Why to repeat this in Outbound ? I suggest dropping it and only > leaving > the statement given earlier in the same section: "Registrars which > implement this specification MUST support the Path header mechanism > [5]." I left this in place as a reminder to implementors. Several implementors contacted me privately asking what information the registrar needs to store. With this text, that information is in one place. > Major technical: > > "and MUST NOT include the 'outbound' option-tag in its Supported > header > field." > > "The Registrar MUST include the 'outbound' option-tag (defined in > Section (Section 12.1)) in a Supported header field value in its > responses to REGISTER requests for which it has performed outbound > processing" > > It was stated already earlier the registrar must add the tag into > the Require header (and may also add it into Supported header). fixed > Nit: > > "and MUST NOT include this option-tag if it did not > perform outbound processing. Furthermore, the Registrar MUST NOR > include this option-tag in its response if the Registrar skipped > outbound processing by ignoring the reg-id parameter as > described in > this specification." > > The text above unnecessarily says the same thing twice. > Statement starting with word "Furthermore" is redundant and > should be deleted. fixed. > Nit: > > "The registrar MUST also store all the Contact header field > information including the reg-id and instance-id parameters and > SHOULD also store the time at which the binding was last updated." > > It is not logical to have this statement in the middle of the text > which discusses what the registrar should do if it has a direct flow > with the UA. moved. thanks, -rohan > ======== > > Here is the reworked text for section 6. It is at least shorter > than the original version without any loss of functionality. I also > believe that the structure has become much clearer during the rewrite > and consists now of the following steps: > > a) Validation of Contact header (with help of Via and Path) > and decision whether to use Outbound or not > > b) Creating bindings for Contacts with reg-id and instance-id > and responding to the UA > > c) Maintenance of flows and registration refreshes > > d) Support for keepalives > > > 6. Registrar Mechanisms: Processing REGISTER Requests > > This specification updates the definition of a binding in RFC 3261 > [1] Section 10 and RFC 3327 [5] Section 5.3. > > Registrars which implement this specification MUST support the Path > header mechanism [5]. > > When receiving a REGISTER request, the registrar first checks from > its Via header field if the registrar is the first hop or not. If > the registrar is not the first hop, it examines Path header of the > request. If the Path header field is missing or it exists but the > first URI does not have an 'ob' URI parameter, the registrar MUST > ignore the reg-id parameter of the Contact header. > > A Contact header field value with an instance-id but no reg-id is > valid (as specified in GRUU [25]), but one with a reg-id but no > instance-id is not. If the registrar processes a Contact header > field value with a reg-id but no instance-id, it simply ignores > the reg-id parameter. > > If the Contact header did not contain 'reg-id' parameter or if that > parameter became ignored (as described above) the registrar MUST > NOT > apply any outbound processing for the request. Specifically, > registrar > MUST NOT include the 'outbound' option-tag in the Require header > field > of its response and it MUST use Contact binding rules of GRUU > [25] or > > RFC 3261 [1], depending whether or not the Contact header contains > +sip.instance media feature parameter. > > The registrar MUST be prepared to receive, simultaneously for the > same AOR, some registrations that use instance-id and reg-id and > some registrations that do not. The Registrar MAY be configured > with local policy to reject any registrations that do not include > the instance-id and reg-id, or with Path header field values that > do not contain the 'ob' parameter. > > When both +sip.instance media feature parameter and reg-id > parameter > are present in a Contact header field of a REGISTER request (after > the Contact header validation as described above), the > corresponding > binding is between an AOR and the combination of the instance-id > (from the +sip.instance media feature parameter) and the value of > reg-id parameter. The registrar MUST store all the Contact > parameters > > in the binding and SHOULD also store the time at which the binding > was last updated. Further on the Registrar MUST include the > 'outbound' > option-tag (defined in Section (Section 12.1)) into a Require > header > field value in its response to the REGISTER request. > > If the UAC has a direct flow with the registrar, the registrar MUST > store enough information to uniquely identify the network flow over > which the request arrived. For common operating systems with TCP, > this would typically just be the handle to the file descriptor > where > the handle would become invalid if the TCP session was closed. For > common operating systems with UDP this would typically be the file > descriptor for the local socket that received the request, the > local > interface, and the IP address and port number of the remote side > that > sent the request. The registrar MAY store this information by > adding > itself to the Path header field with an appropriate flow token. > > If the registrar receives a re-registration for a specific > combination > of AOR, instance-id and reg-id values, the registrar MUST update > any > information that uniquely identifies the network flow over which > the request arrived if that information has changed, and SHOULD > update the time the binding was last updated. > > To be compliant with this specification, registrars which can > receive > SIP requests directly from a UAC without intervening edge proxies > MUST implement STUN NAT Keepalives on its SIP UDP ports as > described > in Section 8 and when it receives a double-CRLF sequence on a > connection oriented transport such as TCP or SCTP, it MUST > immediately respond with a single CRLF over the same connection. > > > Regards, > > Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 13:13:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWpH-0002L0-4J; Sat, 01 Dec 2007 13:12:27 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyWpF-000290-QP for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 13:12:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWpF-00023N-Ej for sip@ietf.org; Sat, 01 Dec 2007 13:12:25 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyWpC-0003ws-Np for sip@ietf.org; Sat, 01 Dec 2007 13:12:23 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1IAlU15498; Sat, 1 Dec 2007 10:10:48 -0800 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] WGLC comments on sip-outbound-10: further concerns for registrar Date: Sat, 1 Dec 2007 10:10:36 -0800 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, I believe I have addressed all your comments below except storing the time (which is an issue for GRUU). See inline for more. thanks, -rohan On Aug 2, 2007, at 12:50 AM, wrote: > > Hi, > > After cleaning up the Section 6 from some apparently > redundant text I finally got my thoughts focused to > some aspects of the registrar behaviour defined in > the remaining pieces of text. Here are the related > comments: > > 6. Registrar Mechanisms > > Minor technical: > > "The registrar MUST be prepared to receive, > simultaneously for the same AOR, some registrations that use > instance-id and reg-id and some registrations that do not." > > Which specific use cases this is expected to cover: > a) for the same AOR but from different devices; or > b) for the same AOR even from one single device so > that one REGISTER contains reg-id while another > does not; or > c) for the same AOR from one single device so that > a single REGISTER would contain multiple Contacts, > some of them having reg-id while others not ? > > To me the cases b) and c) do not make sense so I suggest > scoping this statement for case a) as follows: > "The registrar MUST be prepared to receive, > for the same AOR (from different devices), > some registrations that use instance-id and > reg-id and some registrations that do not." The registrar could receive from the same UA, one registration through a edge proxy that supports outbound, and one that does not. (a and b are allowed, but not c). The case of c) is already prohibited by the text in section 4.2.1 > Minor technical: > > "The Registrar MAY be configured > with local policy to reject any registrations that do not include > the instance-id and reg-id, or with Path header field values that > do not contain the 'ob' parameter. > > If REGISTER request with mixed type of Contacts is allowed > (case c above) some text has to be added how to handle such > REGISTER requests if the proxy has been configured a local > policy to reject registrations without reg-id or instance-id. > Shall the registrar reject the whole request or only > those contacts which are not according to the policy ? the whole request with a 400 Bad Request, since this combination is clearly illegal. > Minor technical: > > "The registrar MUST store all the Contact parameters > in the binding and SHOULD also store the time at which the > binding was last updated." > > "and SHOULD update the time the binding was last updated." > > Maybe this has been explained earlier, but I did not find > from the document any reason why the registrar should store > the time at which the binding was last updated. Why should > it do that ? At least the time should not be needed for > replacing earlier registrations with newer ones, which > is described in section 3.2 like this: "If the instance-id > and reg-id are the same as a previous registration for the > same AOR, the registrar replaces the old Contact URI and > flow information." As I mentioned in another thread, the time is stored for consistency with 3261 and for use with GRUU, but we could change this behavior if we update GRUU accordingly. > Related Nit for Section 3.2: > > As pointed out in my earlier email, in my opinion > the storing the Contact URI is not necessary for Outbound > so that the section 3.2 should say: "If the instance-id > and reg-id are the same as a previous registration for the > same AOR, the registrar replaces the old binding and > flow information." The Contact URI is still necessary (for retargeting), but your sentence is still correct. thanks, -rohan > Regards, > > Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 13:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyX29-00067w-3h; Sat, 01 Dec 2007 13:25:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyX27-00063Q-Ek for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 13:25:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyX27-00062z-41 for sip@ietf.org; Sat, 01 Dec 2007 13:25:43 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyX24-0004S0-1t for sip@ietf.org; Sat, 01 Dec 2007 13:25:41 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1IOpU15812; Sat, 1 Dec 2007 10:24:51 -0800 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03F03422@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F03F03422@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D9F61AC-46A4-401B-810B-0D5EE9C8614D@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] WGLC comments on sip-outbound-10: behaviour of the UA Date: Sat, 1 Dec 2007 10:24:39 -0800 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, I believe your comments have been addressed except for the question of which error response to send a registration Requires outbound, but the ob parameter is missing from the 1st Path header. In addition, the invalidation of temporary GRUU I have raised as an open issue, although the text in -11 will behave nicely with the current GRUU spec. See inline for more. thanks, -rohan On Aug 2, 2007, at 4:03 AM, wrote: > > Hi, > > Here are my comments regarding to the behaviour of the UA > as specified within SIP Outbound-10. I also hope that these > would be my final comments for this WGLC. > > 4.1. Instance ID Creation > > Nit: > > I suggest renaming section 4.1 as "Instance ID Creation and Usage" > as the section also discusses how to convey the ID in requests and > responses. > > Minor technical: > > "To convey its instance-id in both requests and responses, the UA > includes a "sip.instance" media feature tag as a UA characteristic > [7] . As described in [7], this media feature tag will be > encoded in > the Contact header field as the "+sip.instance" Contact header > field > parameter. The value of this parameter MUST be a URN [8]. One > case > where a UA may not want to include the URN in the sip.instance > media > feature tag is when it is making an anonymous request or some other > privacy concern requires that the UA not reveal its identity." > > It sounds odd to state that the value of sip.instance parameter MUST > be URN but tell that there is a case when a UA would not want to > include URN into that parameter. The last statement should instead > tell that the UA is free not to include sip.instance media tag (but > if it includes it, the value must always be URN). I suggest rephrasing > the paragraph like this: > > "To convey its instance-id in both requests and responses, the UA > MAY add a "sip.instance" media feature tag as a UA characteristic > [7]. As described in [7], the media feature tag will be encoded in > the Contact header field as the "+sip.instance" Contact header field > parameter. The value of this parameter MUST be a URN [8]. A UA MAY > decide not to add the sip.instance media feature tag e.g. when it is > making an anonymous request or some other privacy concern requires > that the UA not reveal its identity." This section was updated based on feedback from the apps area and the URI mailing list. Now it MUST be a URN specifically described for use with outbound in an IETF-consensus RFC. The UUID is the only one currently defined. if the IETF defined an IMEI URN for example, that spec could allow its use with outbound. > 4.2. Registrations > > Nit: > > "These ordinary registration requests include a distinct reg-id > parameter in the Contact header field." > > Propose to rewrite the statement like this: "REGISTER requests sent > towards different URIs within the outbound-proxy-set MUST include > the reg-id parameter into the Contact header field, with a distinct > reg-id value for each proxy." I believe the text now in -11 (sect 4.2 para 4) is appropriate. > Major technical: > > "The UAC can situationally decide whether to request outbound > behavior by including or omitting the 'reg-id' parameter. For > example, imagine the outbound-proxy-set contains two proxies in > different domains, EP1 and EP2. If an outbound-style > registration > succeeded for a flow through EP1, the UA might decide to include > 'outbound' in its Require header field when registering with > EP2, > in order to insure consistency. Similarly, if the registration > through EP1 did not support outbound, the UA might decide to > omit > the 'reg-id' parameter when registering with EP2." > > To me this paragraph sounds dangerous and I suggest removing it > for the following reasons: > > - It is not specified anywhere what the registrar should do if > it finds a REGISTER request to contain Require: outbound in a > case where the reg-id will be ignored due to the proxy not > supporting outbound. Intuitively the registrar should reject > the REGISTER with an error response, but which one ? Using > 420 Bad Extension is not according to RFC 3261, since the > registrar supports Outbound but would just like to tell that > it can not apply it since the first hop proxy did not support > Outbound. More text is needed into the spec if a REGISTER > request is allowed to use Require: Outbound. This is currently an open issue. One way to resolve this is to say that UAs must not include Require: outbound in a REGISTER request. A survey of error codes does not give an obvious answer. 420 is clearly wrong however. Precondition failed looked like a dubious possibility. > - If a registration through EP1 did not support outbound, then > I would believe the UA should not try to register via EP2 at > all. Otherwise the authoritative proxy could fork an incoming > request to the a multihomed UA via both EP1 and EP2, which > is not desirable. And if the UA is not multihomed then this > kind of double registration without Outbound does not make sense. This text was fixed so the UA does not register via EP2 at all. > Major technical: > > "The UAC MAY examine successful registrations for the presence > of an > 'outbound' option-tag in a Supported header field value. > Presence of > this option-tag indicates that the registrar is compliant with this > specification, and that any edge proxies which need to participate > are also compliant." > > As stated earlier, registrar will use Require header for this purpose. fixed > 9. Example Message Flow > > Minor technical: > > "The second registration in message 3 and 4 are similar other than > the > Call-ID has changed, the reg-id is 2, and the route is set to the > secondary instead of the primary." > > "The registrations in message 13 and 14 are the same as message > 1 and > 2 other than the Call-ID and tags have changed. Because these > messages will contain the same instance-id and reg-id as those in 1 > and 2, this flow will partially supersede that for messages 1 and 2 > and will be tried first by Primary." > > In the examples the UA is changing the Call-ID for every successive > REGISTER request. What is the reason for the UA to do that ? > The normative text for neither the UA nor the registrar suggest > any that kind of behaviour. If the UA and registrar use GRUU > this would cause the temporary GRUUs to be invalidated and I > do not think the purpose of this example would be to implicate > any such behavior for case when UA is using Outbound. I have changed the behavior so the Call-IDs do not change, however I think this is bad behavior and that the GRUU spec should be changed to keep temporary GRUUs as long as a new registration comes form any previously used Call-ID. thanks, -rohan > Regards, > > Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 13:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXY4-0006I2-HX; Sat, 01 Dec 2007 13:58:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyXY2-0006Hw-Qn for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 13:58:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXY2-0006Ho-HL for sip@ietf.org; Sat, 01 Dec 2007 13:58:42 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXY0-0002IG-O2 for sip@ietf.org; Sat, 01 Dec 2007 13:58:42 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1IvkU16615; Sat, 1 Dec 2007 10:57:47 -0800 In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C63AFE87@srvxchg3.cablelabs.com> References: <9AAEDF491EF7CA48AB587781B8F5D7C63AFE87@srvxchg3.cablelabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5680AE9C-EF6C-46D7-96B3-ADD254844297@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 10:57:34 -0800 To: Kevin Johns X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org Subject: [Sip] Re: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Kevin, I think all your comments have been addressed in outbound-11. more inline. thanks, -rohan On Aug 1, 2007, at 11:11 AM, Kevin Johns wrote: > Hi, > > Here are my comments on outbound. A few technical comments and > several nits... > > Kevin > > Technical (minor) > Detecting Flow Failure - I could not find any text in this section > which provides requirements (nor informative guidance) on when a > flow should be considered failed. For CRLF it can be pretty > straight forward given there are no re-transmission algorithms > going on in the background (missed a response, immediatly send > another CRLF before declaring a failure or immediately declare the > flow failed). However, STUN does have a retransmission algorithm > that the UA would need to implement and presumably this would need > to complete before a flow is considered failed? for UDP, the flow has failed when the STUN request fails (which includes timing out after 7.9 secs). Normal STUN retransmits are sent since these are normal STUN requests. This is covered in sect 8, 9th paragraph. > Edge Proxy Mechanisms - A question on edge proxy behavior when the > registrar does not provide an indication of outbound support in the > REGISTER response. Assuming that the UAC indicated outbound support > and placed a reg-id in the contact header, the Edge Proxy would > create a flow token and add that to the Path header. The registrar > may not support outbound, but may support the Path header and store > that as part of the contact/AOR binding. If this is done, how is > the Edge Proxy to behave if it receives a request which contains a > Path header with a flow token? Is it to ignore the flow token and > follow standard forwarding rules per 3261 or do something else (act > on the flow token and forward per Outbound procedures?) It is the responsibility of the UA to cleanup any registrations that are unwanted. This includes any registration that had a Path header with a flow token that is no longer of interest. I added this sentence: > If the registrar did not support outbound, the UA may have > unintentionally registered an unroutable contact. It is the > responsiblity of the UA to remove any inappropriate Contacts. > STUN Keepalive Processing - I think almost all of the points made > in RFC3489bis around how to define a STUN usage are addressed by > this section with the exception of usage of optional attributes (in > particular FINGERPRINT). I think it can be inferred that Outbound > does not require (nor recommend?) the use of optional attributes, > but it might be good to clarify that to ensure interoperable > implementations. good point. I fixed this in section 8. > Nits: > Abstract - the last sentence states 'specifies the usage of > multiple connections'. I find this statement a bit ambiguous as it > does not provide any context as to what multiple connections are > used for? fixed > Introduction, 1st paragraph, last sentence states 'this > specification allows SIP registrations when the UA is behind such a > firewall or NAT'. I thought this spec was about allowing inbound > requests from the proxy or registrar to the UA in the presence of a > firewall or NAT? fixed > Overview, 1st sentence state 'this technique'. What technique is > being referred to? I assume Outbound procedures? fixed > Summary of mechanism, 2nd paragraph, 2nd sentence states 'A failure > on a particular flow can be tried again on an alternate flow". > Suggest rewording to state A failure to deliver a request on a > particular flow can be re-attempted on an alternate flow. fixed > Edge Proxy Keepalive Handling - This section makes it very clear > that STUN MUST be supported, but only implies that CRLF must be > supported. It would be nice to align the text for the two methods. fixed _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXsk-0004uq-Rf; Sat, 01 Dec 2007 14:20:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyXsi-0004uf-Gc for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:20:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXsi-0004uA-5j for sip@ietf.org; Sat, 01 Dec 2007 14:20:04 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyXsf-0006Qe-8E for sip@ietf.org; Sat, 01 Dec 2007 14:20:02 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1JJWU17225; Sat, 1 Dec 2007 11:19:32 -0800 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D020638F@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D020638F@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F725E19-617B-46CF-948A-384D091F6B64@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 11:19:21 -0800 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John, I think I have addressed all your issues in outbound-11 except as noted below. On Aug 1, 2007, at 1:43 AM, Elwell, John wrote: > 1. "The UA can also include a reg-id parameter which is used to allow > the > registrar to detect and avoid keeping invalid contacts when a UA > reboots or reconnects after its old connection has failed for some > reason." > Surely if outbound behaviour is required it is necessary to include > reg-id. So it should say "The UA also includes...." This "can include" language allows the UA to do non-outbound registrations (for example third-party registrations described in sect 4.2.1) > 2. "When the proxy goes to forward a > request to a given target, it looks and finds the flows over > which it > received the registration." > In the case being described here in 3.2 there is only a single > flow. Add > ", in this case, only a single flow". good point. fixed > 3. "The proxy then forwards the request on > that flow, instead of resolving the Contact URI using the > procedures > in RFC 3263 [4] and trying to form a new flow to that contact. > This > allows the proxy to forward a request to a particular contact over > the same flow that the UA used to register this AOR." > This seems a bit circular. It effectively says that by forwarding > on the > existing flow it enables the proxy to forward on the existing flow! I > think the second of these two sentences can be deleted. done > 4. "To convey its instance-id in both requests and responses, the UA > includes a "sip.instance" media feature tag as a UA characteristic > [7] ." > The sending of instance-id in responses does not seem to be specified > anywhere, so perhaps this sentence should only refer to requests. > On the > other hand, perhaps the intention is to send an instance-id in a > contact > in a response, as described for requests in 4.3. If so, a section on > sending responses is required. I believe the current text clears this up. The registrar includes the instance-id parameter in the response to a register request, but that is just a side effect of normal operation. > 5. "These ordinary registration requests include a distinct reg-id > parameter in the Contact header field." > There is no RFC2119 language here. Shouldn't it say something like: > "If outbound behavior is required, registration requests MUST > include..." we've been asked by the ADs to avoid excessive use of normative language, so I left the text as is. > 6. "4.3. Sending Requests" > I am not sure whether this section is intended to cover all requests > (including REGISTER requests) or requests other than REGISTER. If the > latter, the title should be "Sending Requests other than REGISTER". done > 7. "The contact is formed normally in that the UAC uses the IP address > of > the device (even if the device is behind a NAT)." > This does not allow for the use of a GRUU in non-REGISTER requests. fixed > 8. "Note that the requirements in this section > applies to both REGISTER requests received from an Edge Proxy as > well > as requests received directly from the UAC." > I think this note is intended to refer only to the current paragraph, > not the entire section. fixed > 9. "then the proxy MUST send the request over the same > 'logical flow' saved with the binding that is known to deliver data > to the specific target UA instance." > It is the logical flow that is know to deliver data to the UA, not the > binding. I think it should say: > "then the proxy MUST send the request over the same > 'logical flow' saved with the binding, since that flow is known to > deliver data > to the specific target UA instance." fixed > 10. "8. STUN Keepalive Processing" > This section contains a mixture of requirements on a UA and > requirements > on a server. It would be good practice to separate these. we came to some consensus in Montreal to put these in a single section. The section is short enough that I think the requirements will be clear enough to implementors. > 11. "Note that UACs MUST NOT > use an ambiguous configuration option such as "Work through > NATs?" or > "Do Keepalives?" to imply next hop STUN support." > I am not sure about RFC2119 language here. First, it does not > express a > protocol requirement. Second, the whole statement is a note. Third, > the > requirement is vague and hard to test. I would have thought it > sufficient to say "should not". If RFC2119 language is really > considered > necessary, it should not be stronger than "SHOULD NOT" because of the > vagueness of the requirement. this was added based on consensus in Montreal. kept. > 12. "Later, after > the Primary reboots, The Callee discovers the flow failure and > reestablishes a new flow to the Primary." > Alternatively the proxy might discover the flow failure before the > Primary reboots, although it cannot of course successfully re- > establish > the flow until after reboot. Perhaps it should say: > "Later, after the Primary reboots, the Callee successfully > reestablishes > a new flow to the Primary. Keepalive checks and any failed attempts to > re-establish the flow are not shown." fixed > 13. "The value of the reg-id MUST NOT be 0 and MUST be less than > 2**31." > According to the ABNF, the value can be less than or equal to 2**31. fixed > NITS > - Change "the Registrar MUST NOR" to "the Registrar MUST NOT". > - Change "Note that the requirements in this section > applies" to "Note that the requirements in this section > apply" all fixed thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXwk-0000Bk-Vs; Sat, 01 Dec 2007 14:24:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyXwj-00005J-1X for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXwi-0008Vy-Nt for sip@ietf.org; Sat, 01 Dec 2007 14:24:12 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXwg-00038b-SR for sip@ietf.org; Sat, 01 Dec 2007 14:24:12 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1JN7U17380; Sat, 1 Dec 2007 11:23:07 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound-10 comments Date: Sat, 1 Dec 2007 11:22:54 -0800 To: peter_blatherwick@mitel.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Rohan Mahy , sip@ietf.org, fluffy@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jerry, Peter, Per consenus in Chicago we have ;keep in outbound-11 instead of ;keep- stun and ;keep-crlf. I believe this fix addresses your comments. thanks, -rohan On Sep 20, 2007, at 8:06 AM, peter_blatherwick@mitel.com wrote: > I agree with Jerry here, and believe this has come up before (?). > It is pointless for the originating UA to try to impose, or infer, > the keepalive mechanism before it can know what is applicable. > > An additional comment along these lines. > > a. UA sends REGISTER to the proxy with a "outbound" tag in the > Supported header. > ... > > c. If the "outbound" tag is present in the 200 OK, and if the > transport is UDP, using the STUN keep alive, other connection based > transport using crlf keep alive. > > Step a) would really imply the originating UA MUST support both > keepalive mechanisms, and c) implies it MUST begin using the > appropriate one after 200 OK. The usage is implied, not explicit, > which I believe is sufficient in this case. Alternatively, the > usage could be made more explicit by listing the supported k-a > mechanisms in Supported exchange, or some such. This should be > spelled out either way. > > -- Peter Blatherwick > > > > > Jerry Yin > 19.09.07 16:40 > > > To: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com > cc: > Subject: [Sip] Outbound-10 comments > > > > Hi Cullen and Rohan, > > In the draft, it requires the UA configure the next hop route > header with "keep-stun", "keep-crlf", or "timed-keepalive" tags. > This would cause some problems. > > 1. As an example, the route-set contains this route header as > indicated in section 9 example: > Route: > If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or > TLS, the keep-stun will be useless. Vice versa, if the > pri.example.com is resolved as UDP, and if "keep-crlf" was manually > configured, it is not working either. > > 2. Before sending the REGISTER request, the admin/or user does not > know what keep-alive mechanism the proxy (or edge proxy) supports. > Blindly configure the keep-stun, or keep-crlf would cause the > problem that the draft indicated itself in section 8: "the node > could be blacklisted for UDP traffic". > The better approach is to let the UA and the proxy to negotiate, > not manually configure from UA side. > a. UA sends REGISTER to the proxy with a "outbound" tag in the > Supported header. > b. Proxy insert the "outbound" tag in the 200 OK, if the UA > indicated that it supports the outbound. > c. If the "outbound" tag is present in the 200 OK, and if the > transport is UDP, using the STUN keep alive, other connection based > transport using crlf keep alive. > There would be no way to mass up by configurations with this > approach. Let me know if I missed something. > > Regards, > Jerry Yin > > > Yahoo! oneSearch: Finally, mobile search that gives answers, not > web links. _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:31:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyY3c-0003vl-4S; Sat, 01 Dec 2007 14:31:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyY3a-0003vd-RF for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:31:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyY3a-0003vU-GZ for sip@ietf.org; Sat, 01 Dec 2007 14:31:18 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyY3a-0006pe-74 for sip@ietf.org; Sat, 01 Dec 2007 14:31:18 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2007 14:31:17 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB1JVHxt009443; Sat, 1 Dec 2007 14:31:17 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB1JVH0i002064; Sat, 1 Dec 2007 19:31:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 14:31:17 -0500 Received: from [10.86.241.240] ([10.86.241.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 14:31:16 -0500 Message-ID: <4751B684.7060603@cisco.com> Date: Sat, 01 Dec 2007 14:31:16 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 19:31:16.0710 (UTC) FILETIME=[BDD77060:01C83450] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=746; t=1196537477; x=1197401477; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-kaplan-sip-info-events- 00 |Sender:=20 |To:=20=22DRAGE,=20Keith=20\(Keith\)=22=20; bh=EUmFzSdd6T6sIkbQpTeRLbaIM5YyBpuX0JVu0j5s1Wk=; b=ZO82J6IErNLoPKVT5nth1eNnwbxzqIKChyZlhzEkXEtQLbDGLgZFbHyIkpdFx0TbIfnYrbHt B5edpbWTClBa2WyqutZVsGyP0KzlArGVAPHDxnA3ed8X9EhOjQZrVLcg; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, A comment about one of your points: DRAGE, Keith (Keith) wrote: > In particular, one area which needs to be covered is > how the embedded information tranfer caters for out of sequence > delivery, given that the carriage mechanism does not guarantee order of > delivery in all circumstances of SIP usage. I'm wondering what you have in mind here. It is possible to send request R1 then send R2 before getting a response to R1. And then it is possible for R2 to arrive before R1, and in that case it will be accepted. But then, when R1 arrives there will be a CSeq error so it will be rejected. The end result is that you can get *nondelivery* of a message, but not *out of order delivery*. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYBI-0006qA-Mt; Sat, 01 Dec 2007 14:39:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyYBH-0006q4-0s for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:39:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYBG-0006pw-MJ for sip@ietf.org; Sat, 01 Dec 2007 14:39:14 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyYBF-00076c-Hn for sip@ietf.org; Sat, 01 Dec 2007 14:39:14 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1JcfU18504; Sat, 1 Dec 2007 11:38:41 -0800 In-Reply-To: <20070921012259.39rpqki5cg84c4wg@horde-intra.tml.hut.fi> References: <20070921012259.39rpqki5cg84c4wg@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Outbound-10 comments Date: Sat, 1 Dec 2007 11:38:29 -0800 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: sip@ietf.org, Rohan Mahy , peter_blatherwick@mitel.com, fluffy@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Sergio, I believe all your concerns have been addressed in outbound-11, except that the example in Section 9 needs to be rewritten. The keep- stun and keep-crlf parameters have been merged into a single 'keep' parameter. A few more comments inline. thanks, -rohan On Sep 20, 2007, at 3:22 PM, sergiole@tml.hut.fi wrote: > Hi, > > I composed the email below a month ago related to this thread and > thought that I was missing something so I did not posted it, but it > seems that there are some issues pending with the keepalive label > and processing. > > Sorry to introduce more questions: > > -- > > My comments are about the keep-stun label. > > It is not very clear how the UA discovers that the Edge Proxy > supports STUN. > > > In section 8 (keepalive processing). I read > > " When a URI is created that refers to a SIP node that supports > STUN as > described in this section, the 'keep-stun' URI parameter, as > defined > in Section 12 MUST be added to the URI. This allows a UA to > inspect > the URI to decide if it should attempt to send STUN requests to > this > location. For example, an edge proxy could insert this parameter > into its Path URI so that the registering UA can discover the edge > proxy supports STUN keepalives." > > Q1. Why "an edge proxy COULD insert this parameter into its Path > URI" and not MUST ? (considering that the UA supports STUN) If the next hop from the UA is the registrar, there will be no edge proxy and therefore probably no Path header. > Q2. In what other header can I also add the keep-stun, so that it > will be still present when I get back a response? the Path header or the Service-Route header for example. This could just be learned through configuration. > Note that in the example of section 9 the responses 200-OK haven't > any keep-stun This will get fixed when I overhaul the example. > (Also mentioned in http://www1.ietf.org/mail-archive/web/sip/ > current/msg20295.html) > > > Q3. For the case in this example, How will the Callee know that it > is allowed to send STUN keepalives? (no keep-stun present) > > For the case in the example, and considering: > > "Typically, a SIP node first sends a SIP request and waits to > receive a final response (other than a 408 response) over a flow > to a new target destination, before sending any STUN messages." > > The callee will never send the keepalives... > > -- > Part II > > > In my opinion, the edge proxy MUST add a list of the supported > mechanisms for keepalive in the 200-OK response to REGISTER. The > list MUST include ALL the supported mechanisms (so the UA can for > example know that if some mechanism is not available for the > transport it used to register there are other mechanisms for other > protocols. In this case the UA will form a new flow by registering > using another protocol.) > > Example 1: > > UA sends REGISTER over UDP. > It gets back a 200 OK with only keep-crlf. > UA recognizes that STUN is not available, so a UDP flow can not > succeed. Then it sends a REGISTER over TCP. > > Example 2: > > UA sends REGISTER over UDP. > It gets back a 200 OK with keep-crlf and keep-stun. > UA recognizes that keep-crlf is present so (its logic) can judge > that TCP is a better choice. > Then the UA forgets using UDP and switches to TCP: sends a REGISTER > over TCP. > > Q: Should not be handy to have something like keep-Scrlf so the UA > can knows that TLS is also supported? The same for DTLS. > > > > > Sergio > > > Quoting peter_blatherwick@mitel.com: > >> I agree with Jerry here, and believe this has come up before (?). >> It is >> pointless for the originating UA to try to impose, or infer, the >> keepalive >> mechanism before it can know what is applicable. >> >> An additional comment along these lines. >>> a. UA sends REGISTER to the proxy with a "outbound" tag in the >>> Supported >> header. >> ... >>> c. If the "outbound" tag is present in the 200 OK, and if the >>> transport >> is UDP, using the STUN keep alive, other connection based >> transport using >> crlf keep alive. >> >> Step a) would really imply the originating UA MUST support both >> keepalive >> mechanisms, and c) implies it MUST begin using the appropriate one >> after >> 200 OK. The usage is implied, not explicit, which I believe is >> sufficient >> in this case. Alternatively, the usage could be made more >> explicit by >> listing the supported k-a mechanisms in Supported exchange, or >> some such. >> This should be spelled out either way. >> >> -- Peter Blatherwick >> >> >> >> >> >> >> Jerry Yin >> 19.09.07 16:40 >> >> To: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com >> cc: >> Subject: [Sip] Outbound-10 comments >> >> >> Hi Cullen and Rohan, >> >> In the draft, it requires the UA configure the next hop route >> header with >> "keep-stun", "keep-crlf", or "timed-keepalive" tags. This would >> cause some >> problems. >> >> 1. As an example, the route-set contains this route header as >> indicated in >> section 9 example: >> Route: >> If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or >> TLS, the >> keep-stun will be useless. Vice versa, if the pri.example.com is >> resolved >> as UDP, and if "keep-crlf" was manually configured, it is not working >> either. >> >> 2. Before sending the REGISTER request, the admin/or user does not >> know >> what keep-alive mechanism the proxy (or edge proxy) supports. Blindly >> configure the keep-stun, or keep-crlf would cause the problem that >> the >> draft indicated itself in section 8: "the node could be >> blacklisted for >> UDP traffic". >> The better approach is to let the UA and the proxy to negotiate, not >> manually configure from UA side. >> a. UA sends REGISTER to the proxy with a "outbound" tag in the >> Supported >> header. >> b. Proxy insert the "outbound" tag in the 200 OK, if the UA >> indicated that >> it supports the outbound. >> c. If the "outbound" tag is present in the 200 OK, and if the >> transport is >> UDP, using the STUN keep alive, other connection based transport >> using >> crlf keep alive. >> There would be no way to mass up by configurations with this >> approach. Let >> me know if I missed something. >> >> Regards, >> Jerry Yin >> >> Yahoo! oneSearch: Finally, mobile search that gives answers, not web >> links. _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:41:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYDH-0007wR-52; Sat, 01 Dec 2007 14:41:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyYDG-0007u7-7O for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:41:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYDF-0007ty-Tn for sip@ietf.org; Sat, 01 Dec 2007 14:41:17 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyYDD-0003kn-JW for sip@ietf.org; Sat, 01 Dec 2007 14:41:17 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1Jf5U18580; Sat, 1 Dec 2007 11:41:05 -0800 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F312@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D026F312@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4852B8AC-A0AB-4EFD-930C-AEDB58FD5B80@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 11:40:54 -0800 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: Question on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John, I believe outbound-11 addresses this concern. The UA is now allowed to request flow token handling on a REGISTER or any dialog-forming request. thanks, -rohan On Aug 20, 2007, at 1:28 AM, Elwell, John wrote: > In section 4.3 "Sending requests" it states: > "The UA performs normal DNS resolution on the next hop URI (as > described in RFC 3263 [4]) to find a protocol, IP address, and > port. > For protocols that don't use TLS, if the UA has an existing flow to > this IP address, and port with the correct protocol, then the UA > MUST > use the existing connection. For TLS protocols, there MUST also > be a > match between the host production in the next hop and one of the > URIs > contained in the subjectAltName in the peer certificate. If the UA > cannot use one of the existing flows, then it SHOULD form a new > flow > by sending a datagram or opening a new connection to the next > hop, as > appropriate for the transport protocol." > > This seems to imply that the UA simply sends the request on a new > flow, > yet there are no proxy procedures defined for receiving a non-register > request on a new flow. So perhaps what is intended is that UA should > register again using the new flow, and then send the request on the > new > flow. Whatever the intention, it seems some clarification is required. > > John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 14:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYM4-00062L-OU; Sat, 01 Dec 2007 14:50:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyYM2-0005u8-Kh for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 14:50:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYM2-0005cO-3r for sip@ietf.org; Sat, 01 Dec 2007 14:50:22 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyYLz-0007V5-7q for sip@ietf.org; Sat, 01 Dec 2007 14:50:20 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1JnjU18794; Sat, 1 Dec 2007 11:49:45 -0800 In-Reply-To: <200708051802.55505.lists@ohlmeier.org> References: <200708051802.55505.lists@ohlmeier.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 11:49:34 -0800 To: Nils Ohlmeier X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: sip@ietf.org, Rohan Mahy , fluffy@cisco.com Subject: [Sip] Re: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Nils, The example still needs to be overhauled and will address the concern you raised. On Aug 5, 2007, at 9:02 AM, Nils Ohlmeier wrote: > Hello, > > sorry for being with my comments. Please find one minor technical > issue and > several NITs below. > > > Minor Technical: > > 9. Example Message Flow > > The 200 OK on page 28 contains no Path header, which should carry > the ob and/or the keepalive URI parameters to allow the UA to detect > that Oubound is supported and used. How can the UA detect that > outbound is supported and used for this flow when it receives a > 200 OK like this one? > In the case there is an edge proxy included which supports outbound > the 200 OK should have the Path header with the parameters. If the > edge proxy does not support outbound, the Path header should not > have the parameters. If the edge proxy does not even support the > Path extension, outbound can not be supported either. > But how does the UA detect that the Registrar supports and uses > outbound in case there is no edge proxy involved? > The easiest and simple solution to me would be that the Registrar > has to include a Path header into the reply which points to itself > and carries the required parameters. > > Another alternative would be to rely only on the Suported/Required > header and do not look at the Path URI at all. Then the keepalive > algorithm would be implicitly determined by the used transport, but > that would also mean that there is no way for the Registrar to let > the UA know that it supports the optional TCP Keepalive algorithm. > And the Supported/Required header would have to be included into > the reply by edge proxy (in case), which is, I think, against the > normal > usage of these headers. > > > NITs: > > 1. Introduction > > "This specification allows SIP registration when the > UA is behind such a firewall or NAT." > > Proposed improvement: > This specification ensures that the UA if it is behind > such a firewall or NAT is reachable by the registrar after > the first successful initial registration. The UA is now also allowed to form a flow for dialog-forming requests > 2.1 Definitions > > "outbound-proxy-set A set of SIP URIs...." > > Proposed improvement: > outbound-proxy-set: A set of SIP URIs... fixed > 3.2 Single Registrar and UA > > " > REGISTER sip:example.com;keep-crlf SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.1;branch... > ... > Contact: ;reg-id=1;... > " > > Why have Via and Contact different IPs? I assume > this is a type and should look like this: > > REGISTER sip:example.com;keep-crlf SIP/2.0 > Via: SIP/2.0/TCP 192.168.0.2;branch... > ... > Contact: ;reg-id=1;... fixed > 3.3 Multiple Connections from a User Agent > > "..., so mechanism like SRV can be used..." > > Proposed improvement: > ..., so mechanism like DNS SRV can be used... fixed > 4.1 Instance ID Creation > > "... as the device knows no other UUIDs were generated at this time." > > Proposed improvement: > ... as the device knows no other UUIDs were generated at this > time on this device. fixed > 4.2.1 Registration by Other Instances > > Is the second paragraph about unregister only ment for this > particular case or for all UAs supporting this draft? > > To me it semms at it is ment for all UAs, as the star Contact > should match all bindings anyway. Otherwise it should be explained > somewhere what a star Contact with an instance-id and/or reg-id > means. fixed. star with instance-id is not allowed. > 4.4 Detecting Flow Failure > > The last paragraph talks about tags in the URIs of the > outbound-proxy-set. Are these tags are still used after the Chicago > meeting? If so, then there should be a refence to chapter 12. ok > 5.4 Edge Proxy Keepalive Handling > > Why is TCP Keepalive not mentioned in this section? > I think it should mention that this an optional keepalive mechanism > for the edge proxy. fixed > 6. Registrar Mechanisms: Processing REGISTER Requests > > Last paragraph on page 22: > > "First the registrar examines the first Path header field value, > if any." > > Proposed improvement: > First the registrar examines the first (bottom most) Path header > field value, if any. I think "first" is clear enough. > 4th paragraph on page 23: > > "Furthermore, the Registrar MUST NOR include this option-tag..." > > Fix: > Furthermore, the Registrar MUST NOT include this option-tag... fixed > 8. STUN Keeplalive Processing > > 1st paragraph on page 26: > > "Typically, a SIP node first sends a SIP request and waits to > receive a final response (other than a 408 response) over a flow > to a new target destination, before sending any STUN messages." > > Why should an UA start sending any STUN messages when it received > any non-2xx reply? > I think the sentence above should be limited to 2xx responses only > as indication that the flow is "established" and the UA can send > STUN messages now. good point. fixed > 12.2 SIP/SIPS URI Parameters > > Why is there no Parameter for the optional TCP Keepalive? > Or should the sections talking about TCP Keepalive as an optional > alternative be deleted from the document? TCP keepalive references have been removed from the document. The UA can always use TCP keepalives, but the UA cannot know that the next hop will respond (this is a ping with no pong). thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 15:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYpR-0005wu-JL; Sat, 01 Dec 2007 15:20:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyYpP-0005vw-R5 for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 15:20:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyYpP-0005vo-HX for sip@ietf.org; Sat, 01 Dec 2007 15:20:43 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyYpM-00051B-DH for sip@ietf.org; Sat, 01 Dec 2007 15:20:43 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1KKMU20443; Sat, 1 Dec 2007 12:20:23 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D2EB238-1F8A-4836-A7E3-DC8FD690F4F7@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 1 Dec 2007 12:20:11 -0800 To: Derek MacDonald X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Derek, I think I have addressed all your comments except the CRLF backward compatibility, which I have fixed in my working copy. See below for specifics. On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote: > I've finished my review of outbound-10, mainly thinking about things > from a client implementation & NAT traversal perspective. > > Major issues: > > The following issues are all one part of what I think is the core > issue w/ outbound; the draft does not require normative behavior that > will result in successful NAT traversal, although it does contain the > necessary mechanisms for NAT traversal > In 4.2 and 4.3 it is stated that route-set creation is outside the > scope of outbound. The behavior that is would work for NAT traversal > in a simple deployment is described as an example in 4.2. I think this is greatly improved in -11 by the following changes: outbound-11 now states that the edge proxy is expected to record- route with a flow-token if the client includes an 'ob' parameter in its Contact. If the client is using gruu, it uses the gruu instead in its contact. The UA now also uses rport in all requests. I think this should be sufficient to insure responses (rport), incoming requests (from Path flow token in REGISTER), and in-dialog requests (from Record-Route flow token, or from a GRUU) all get back to the UA. >> From 4.2: > > "Forming the route set for the request is outside the scope of > this document, but typically results in sending the REGISTER such > that the topmost Route header field contains a loose route to the > outbound proxy URI." > > Are we really anticipating that an element will be inserted between > the UA and the outbound proxy(s). Do we want to allow this? no and no. The "typically results in sending the REGISTER..." text is there to allow the traditional usage of an outbound proxy, which is to resolve the IP address, port, and transport and send it there without including a Route header at all. > If there > is such an element in the route set, it will either have to: > > Support outbound, which causes a single point of failure if there > isn't a 1-1 correspondence with the edge proxies. If there is a 1-1 > correspondence with the edge proxies, it is an edge proxy, so is > should have just been configured as the outbound proxy. > > OR > > Transparently relay outbound, which seems like a very bad idea. > > I think we should change the text to something like: > > "While forming the route set for the request is outside the scope of > this specification, the first element in the route set for a > registration MUST be from the outbound-proxy-set in order to use this > specification." I think the current text already require that the first element visited (whether in the route set or not) is in the outbound-proxy-set. > Section 4.3 Discusses how a UA would send a request, but does not > describe the basic behavior that would establish a dialog through a > NAT. > > " When a UA is about to send a request, it first performs normal > processing to select the next hop URI. The UA can use a variety of > techniques to compute the route set and accordingly the next hop > URI. > Discussion of these techniques is outside the scope of this > document > but could include mechanisms specified in RFC 3608 [22] (Service > Route) and [21]." > > If the next hop does not support outbound, and isn't an existing flow, > a dialog establishing request will likely result in a route set which > does not work through a NAT. The rport mechanism only provides NAT > traversal for a single SIP response. correct. there is now text setting the responsibility clearly: > If the registrar did not support outbound, the UA may have > unintentionally registered an unroutable contact. It is the > responsiblity of the UA to remove any inappropriate Contacts. > "The UA performs normal DNS resolution on the next hop URI (as > described in RFC 3263 [4]) to find a protocol, IP address, and > port." > > As there is no mechanism to determine outbound support in other > administrative domains, this lookup is only relevant to outbound if > the UA knows next hop supports outbound. yes. > Later in the same paragraph: > > "If the UA cannot use one of the existing flows,then it SHOULD > form a new flow > by sending a datagram or opening a new connection to the next > hop, as > appropriate for the transport protocol." > > I was under the impression that flows are only created with REGISTER > requests...is this incorrect? this has been changed in -11 to allow flows to be formed for dialog- creating requests. > The crux of the issue is that to accomplish NAT traversal using > outbound w/out extensions, the UA MUST send dialog creating requests > using an existing flow(selected by round-robin for appropriate > transport/etc). Furthermore, in 5.3, edge proxies MUST record route > dialog creating requests. We need to change the base-level behaviour > of outbound so NAT traversal just works, is this is a core requirement > of outbound. > > Also: > > Note that if the UA wants its flow to work through NATs or > firewalls it still needs to put the 'rport' parameter [10] in > its > Via header field value, and send from the port it is prepared to > receive on. More general information about NAT traversal in SIP > is described in [23]. > > should be removed. [23] is very out of date, and references > outbound-01, and I believe some of the text is out of date. Rport is > not relevant when flows are used, although it doesn't cause any harm. rport is still relevant when flows are used, because outbound does not change the rules in 3261 for forwarding responses. > Questions/minor issues: > > 4.1: > > "The value of this parameter MUST be a URN [8]. One case > where a UA may not want to include the URN in the sip.instance > media feature tag..." > > Does this mean that a sip.instance feature tag is still included? If > so, what does it contain? no, the whole parameter should be omitted. i think i reworded this to make it more clear. > "As a result, the UA instance SHOULD provide lexically equivalent URNs > in each registration it > generates. " > > Why not MUST instead of SHOULD? fixed > Nits > > Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't > break existing SIP implementations. I spent a lot of time looking > through the grammar before I gave up and asked Rohan and pointed me to > section 7.5 of 3261. I would reference this section in 3.5.1 and/or > 4.4.2. bummer. I forgot to include this in -11. I have added this in my working copy to section 3.5.1 as follows: > Sending a CRLF over a connection-oriented transport is > backwards safe (because of requirements in Section 7.5 of > RFC 3261), > but only implementations which support the 'keep' > parameter will > respond to a "ping" with a "pong". > 2.1 > > "reg-id: This refers to the value of a new header field parameter > value for the Contact header field. When a UA registers > multiple > times, each simultaneous registration gets a unique reg-id > value." > > change simultaneous to concurrent: > > "reg-id: This refers to the value of a new header field parameter > value for the Contact header field. When a UA registers > multiple > times, each concurrent registration gets a unique reg-id value." fixed > 3.3 > > "If a UA has multiple flows, and one of the servers fails, the UA > delays the specified time before trying to form a new connection to > replace the flow to the server that failed." > > This implies that if the UA only has one flow, it retries immediately > which doesn't match the behaviour described in 4.5. Maybe: > > "When a server fails the UA will delay before attempting to > re-establish a flow, using the delays specified in section 4.5." fixed > 3.5 > > Change(awkward): > > "In this case, the server provides an indicator (the > 'timed-keepalives' parameter) that the server requires the > client to > use the suggested timer values." > > to > > "In this case, the server indicates that the client must use the > suggested timer values by including the timed-keepalives parameter." i think the original text (while uglier) is more clear. > 4.1 > > "This means the value of the time component of the UUID can be > arbitrarily selected to be any time less than the time when the > device was manufactured. A time of 0 (as shown in the > example in > Section 3.2) is perfectly legal as long as the device knows no > other UUIDs were generated at this time." > > I found this extremely confusing; I think it is saying that the time > component isn't necessary(but can't be in the future) if the device > already has a unique mac address it includes in the UUID. Why not just > say that a time of 0 can be used if the device is guaranteed to have a > unique MAC address at construction time? The UA can't use time zero, if the UA generates multiple instance-ids and uses time zero for all of them. In the absence of better text, I left it as is. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 16:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyZRN-00079k-T4; Sat, 01 Dec 2007 15:59:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyZRM-00079d-D6 for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 15:59:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyZRM-00079U-3Q for sip@ietf.org; Sat, 01 Dec 2007 15:59:56 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyZRJ-00065l-Ke for sip@ietf.org; Sat, 01 Dec 2007 15:59:56 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB1KxHU22316; Sat, 1 Dec 2007 12:59:18 -0800 In-Reply-To: <46B7ABEB.50207@nokia.com> References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> <46B7ABEB.50207@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C12AF7F-AB54-4B2D-A028-4C394761024A@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Date: Sat, 1 Dec 2007 12:59:06 -0800 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: sip@ietf.org, Rohan Mahy , "ext DRAGE, Keith \(Keith\)" , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Aki, My comments inline... On Aug 6, 2007, at 4:16 PM, Aki Niemi wrote: > Here are my WGLC comments to sip-outbound-10. There may be > duplicates as > I've only been following others' comments on the surface. > > --- > > #1 First, the title says: > > Managing Client Initiated Connections in the Session Initiation > Protocol > (SIP) > > yet, the draft is really about managing registrations, with > failover and > reliability. For example, it is not at all clear how one would go > about > implementing these techniques in, say, subscriptions (this is the > issue > Markus brought up recently with the config-framework) In outbound-11 I think I have addressed this issue. The UAC can include an 'ob' parameter in a dialog-forming request and expect the first hop proxy to record route appropriately. This should allow the sip config package subscription to work. > #2 URI parameters are confusing. > > o First, I don't understand why the keepalive params are needed at > all. > It's simple, really: if the UAC opens a TCP flow, it needs to use > CRLF. > If it opens a UDP flow, it needs to use STUN. Or am I missing > something? we merged the keep-stun and keep-crlf into a simple 'keep' parameter. this 'keep' parameter just allows the UAC to know if it will get a pong in response to its pings. > (In fact, I would like to see TCP-keepalives removed completely, as > that > just hurts interop.) removed > o Justification for 'timed-keepalives' > > Why does the UA need to know beforehand that it needs to use the > default > interval keepalive? Could this not be returned in the 200 OK instead? it probably could, but it is not clear where it would go in the 200 OK. > All in all, I don't see the reason that these parameters need to be > pre-configured to the UA as the draft suggests. Seems they are either > self-evident (based on transport), or something the registrar/edge- > proxy > could return in a header field or parameter at register-time. Much > cleaner IMHO. what we have may be ugly, but it will work and we appear to have consensus on it. > o In 3.2. example message: > > REGISTER sip:example.com;keep-crlf SIP/2.0 > > Why does this parameter need to be in the R-URI? the parameter does not need to be there. It could instead be in the topmost Route header for example. > o In 4.3. says: > > The UAC MUST also include an "ob" parameter in the > Contact URI if, and only if, the UAC is sending the request over a > flow for which the Registrar applied outbound processing. > > Isn't 'ob' only inserted by edge-proxies, and to Path? Furthermore, > how > can the UA know that "the Registrar applied outbound processing" to a > flow that is just about to be formed? ob is used for two things: - inserted in Path by the first edge proxy - added to Contact by UA to request record-routing > o In 5.3 says: > > The Edge Proxy can use > the presence of the "ob" parameter in the UAC's Contact URI to > determine if it should add a flow token. > > Hmm. I thought it was the reg-id. The edge proxy uses the presence of the reg-id in a Contact in a REGISTER request to add a Path header with a flow token, and the presence of the ob parameter in a Contact in a non-REGISTER request to add a Record-Route header with a flow token. > #3 Implementation strategy > > How is it intended that outbound support be added to a typical single > registrar/proxy deployment today? The spec intentionally leaves > configuration of a proxy-set open, but somehow assumes that one exists > in order to use outbound. Couldn't the UA just attempt a REGISTER via > the default NAPTR/SRV and just include reg-id and instance-ID? This > option should be made the default in the absence of a specific a > priori > configuration in Section 4.2/4.3. This should just work, but the single UA/proxy would need to return a Path header, otherwise the UA would have no way of discovering support for keepalive responses. > #4 Keepalive timer values > > Like I've said in the past that 2 mins for TCP is way too low. > Sure, the > UA can extend it, unless of course the proxy mandates it with > timed-keepalive param. And of course the proxy wants high reliability, > which means the UA is hosed probably more often than it would like > to ;) > My question is: where did this 2 minutes come from? Is it based on > some > hard data, like empirical evidence or user experience studies? No. It was pulled out of thin air. > If not, > how about 14 minutes instead? Much better on the battery and should > still play nice with the NATs. There was some expectation that the UA would be willing to lose 2 minutes of phone calls, but 14 minutes would be a lot of time to be off the air. Certainly, the UA can use something short (like 2 minutes) for one flow, and 14 minutes for any additional flows without many ill effects. > #5 Retry timer calculation formula > > In 4.5: > > wait-time = min( max-time, (base-time * (2 ^ consecutive- > failures))) > > These times MAY be configurable in the UA. The three times are: > o max-time with a default of 1800 seconds > o base-time-all-fail with a default of 30 seconds > o base-time-not-failed with a default of 90 seconds > > But there are only two unknowns pertaining to time in the equation > (there is no base-time-all-fail, or base-time-not-failed -- just > base-time that apparently is 30 sec...). I made this more clear in -11. The base time is either 30 secs or 90 secs. > #6 Definition of a ping or a pong > > It should be explained in the spec that a ping is double CRLF, or any > other traffic. And same goes for a pong. I.e., the UA should only > consider a flow dead if it receives no CRLF nor any other traffic > within > 10 seconds of sending the ping. this does not work. receiving some other traffic does not count as a pong since it could be very stale data. > #7 Very minor things: > > o The justification for choosing STUN as the UDP keepalive > mechanism is > a little misleading. It was *claimed* that STUN would be less of a > load > to proxies than a SIP OPTIONS (or similar). However, this was never > proven in practice. There were also people saying that parsing SIP is > not the bottleneck -- network or memory I/O is, and on that front, > STUN > and SIP are equal. If anything, a SIP+STUN parser might actually have > worse performance. Just for the record -- I've no interest to revisit > the decision -- just getting the facts right ;) Hear, hear! I toned this rhetoric down a bit. > o In 3.3 > > The UA is configured with multiple outbound proxy registration URIs. > These URIs are configured into the UA through whatever the normal > mechanism is to configure the proxy or registrar address in the UA. > > The registrar address is not supposed to be configured. It is learned > from the AoR, the name behind the '@' sign. ;) yeah. thanks, -rohan > That's all > > Cheers, > Aki > > ext DRAGE, Keith (Keith) wrote: >> A reminder of the ongoing WGLC on the above document >> >> This WGLC period runs through IETF and hopefully close August 6, >> 2007. >> >> That gives you about a week after the end of IETF - please >> schedule some time for doing this. >> >> Regards >> >> Keith >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Thursday, July 12, 2007 7:14 PM >>> To: Dean Willis >>> Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) >>> Subject: Correction: WGLC for draft-ietf-sip-outbound >>> >>> Dean Willis wrote: >>>> I'd like to start a long working group last call for: >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt >>>> >>> My error. This should have referred to >>> draft-ietf-sip-outbound-10, not -09. It was busy working its >>> way through the posting system and I grabbed a pointer to the >>> wrong one. >>> >>> Sorry about that, folks. >>> >>> -- >>> Dean >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 01 18:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IybJZ-0000y6-Tt; Sat, 01 Dec 2007 18:00:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IybJY-0000xh-7V for sip-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 18:00:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IybJX-0000xX-R9 for sip@ietf.org; Sat, 01 Dec 2007 17:59:59 -0500 Received: from bay0-omc2-s29.bay0.hotmail.com ([65.54.246.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IybJV-00023o-Ku for sip@ietf.org; Sat, 01 Dec 2007 17:59:59 -0500 Received: from BAY102-W19 ([64.4.61.119]) by bay0-omc2-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 Dec 2007 14:59:57 -0800 Message-ID: X-Originating-IP: [24.188.138.59] From: mohammed Ali To: Rohan Mahy , Derek MacDonald Date: Sun, 2 Dec 2007 01:59:56 +0300 Importance: Normal In-Reply-To: <0D2EB238-1F8A-4836-A7E3-DC8FD690F4F7@ekabal.com> References: <0D2EB238-1F8A-4836-A7E3-DC8FD690F4F7@ekabal.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2007 22:59:57.0176 (UTC) FILETIME=[E49EEF80:01C8346D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Cullen Jennings Subject: [Sip] unsubscrib X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084673149==" Errors-To: sip-bounces@ietf.org --===============1084673149== Content-Type: multipart/alternative; boundary="_2d91f701-728e-48f9-bc34-b65dd939af01_" --_2d91f701-728e-48f9-bc34-b65dd939af01_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 8bit unsubscrib > From: rohan@ekabal.com> Date: Sat, 1 Dec 2007 12:20:11 -0800> To: derek@counterpath.com> CC: sip@ietf.org; rohan@ekabal.com; fluffy@cisco.com> Subject: [Sip] Re: WGLC comments on sip-outbound-10> > Hi Derek,> > I think I have addressed all your comments except the CRLF backward > compatibility, which I have fixed in my working copy. See below for > specifics.> > > On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote:> > > I've finished my review of outbound-10, mainly thinking about things> > from a client implementation & NAT traversal perspective.> >> > Major issues:> >> > The following issues are all one part of what I think is the core> > issue w/ outbound; the draft does not require normative behavior that> > will result in successful NAT traversal, although it does contain the> > necessary mechanisms for NAT traversal> > In 4.2 and 4.3 it is stated that route-set creation is outside the> > scope of outbound. The behavior that is would work for NAT traversal> > in a simple deployment is described as an example in 4.2.> > I think this is greatly improved in -11 by the following changes:> > outbound-11 now states that the edge proxy is expected to record- > route with a flow-token if the client includes an 'ob' parameter in > its Contact. If the client is using gruu, it uses the gruu instead > in its contact. The UA now also uses rport in all requests.> > I think this should be sufficient to insure responses (rport), > incoming requests (from Path flow token in REGISTER), and in-dialog > requests (from Record-Route flow token, or from a GRUU) all get back > to the UA.> > >> From 4.2:> >> > "Forming the route set for the request is outside the scope of> > this document, but typically results in sending the REGISTER such> > that the topmost Route header field contains a loose route to the> > outbound proxy URI."> >> > Are we really anticipating that an element will be inserted between> > the UA and the outbound proxy(s). Do we want to allow this?> > no and no. The "typically results in sending the REGISTER..." text > is there to allow the traditional usage of an outbound proxy, which > is to resolve the IP address, port, and transport and send it there > without including a Route header at all.> > > If there> > is such an element in the route set, it will either have to:> >> > Support outbound, which causes a single point of failure if there> > isn't a 1-1 correspondence with the edge proxies. If there is a 1-1> > correspondence with the edge proxies, it is an edge proxy, so is> > should have just been configured as the outbound proxy.> >> > OR> >> > Transparently relay outbound, which seems like a very bad idea.> >> > I think we should change the text to something like:> >> > "While forming the route set for the request is outside the scope of> > this specification, the first element in the route set for a> > registration MUST be from the outbound-proxy-set in order to use this> > specification."> > I think the current text already require that the first element > visited (whether in the route set or not) is in the outbound-proxy-set.> > > Section 4.3 Discusses how a UA would send a request, but does not> > describe the basic behavior that would establish a dialog through a> > NAT.> >> > " When a UA is about to send a request, it first performs normal> > processing to select the next hop URI. The UA can use a variety of> > techniques to compute the route set and accordingly the next hop > > URI.> > Discussion of these techniques is outside the scope of this > > document> > but could include mechanisms specified in RFC 3608 [22] (Service> > Route) and [21]."> >> > If the next hop does not support outbound, and isn't an existing flow,> > a dialog establishing request will likely result in a route set which> > does not work through a NAT. The rport mechanism only provides NAT> > traversal for a single SIP response.> > correct. there is now text setting the responsibility clearly:> > If the registrar did not support outbound, the UA may have > > unintentionally registered an unroutable contact. It is the > > responsiblity of the UA to remove any inappropriate Contacts.> > > > "The UA performs normal DNS resolution on the next hop URI (as> > described in RFC 3263 [4]) to find a protocol, IP address, and > > port."> >> > As there is no mechanism to determine outbound support in other> > administrative domains, this lookup is only relevant to outbound if> > the UA knows next hop supports outbound.> > yes.> > > Later in the same paragraph:> >> > "If the UA cannot use one of the existing flows,then it SHOULD > > form a new flow> > by sending a datagram or opening a new connection to the next > > hop, as> > appropriate for the transport protocol."> >> > I was under the impression that flows are only created with REGISTER> > requests...is this incorrect?> > this has been changed in -11 to allow flows to be formed for dialog- > creating requests.> > > The crux of the issue is that to accomplish NAT traversal using> > outbound w/out extensions, the UA MUST send dialog creating requests> > using an existing flow(selected by round-robin for appropriate> > transport/etc). Furthermore, in 5.3, edge proxies MUST record route> > dialog creating requests. We need to change the base-level behaviour> > of outbound so NAT traversal just works, is this is a core requirement> > of outbound.> >> > Also:> >> > Note that if the UA wants its flow to work through NATs or> > firewalls it still needs to put the 'rport' parameter [10] in > > its> > Via header field value, and send from the port it is prepared to> > receive on. More general information about NAT traversal in SIP> > is described in [23].> >> > should be removed. [23] is very out of date, and references> > outbound-01, and I believe some of the text is out of date. Rport is> > not relevant when flows are used, although it doesn't cause any harm.> > rport is still relevant when flows are used, because outbound does > not change the rules in 3261 for forwarding responses.> > > Questions/minor issues:> >> > 4.1:> >> > "The value of this parameter MUST be a URN [8]. One case> > where a UA may not want to include the URN in the sip.instance> > media feature tag..."> >> > Does this mean that a sip.instance feature tag is still included? If> > so, what does it contain?> > no, the whole parameter should be omitted. i think i reworded this > to make it more clear.> > > "As a result, the UA instance SHOULD provide lexically equivalent URNs> > in each registration it> > generates. "> >> > Why not MUST instead of SHOULD?> fixed> > > Nits> >> > Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't> > break existing SIP implementations. I spent a lot of time looking> > through the grammar before I gave up and asked Rohan and pointed me to> > section 7.5 of 3261. I would reference this section in 3.5.1 and/or> > 4.4.2.> > bummer. I forgot to include this in -11. I have added this in my > working copy to section 3.5.1 as follows:> > Sending a CRLF over a connection-oriented transport is> > backwards safe (because of requirements in Section 7.5 of > > RFC 3261),> > but only implementations which support the 'keep' > > parameter will> > respond to a "ping" with a "pong".> > > > 2.1> >> > "reg-id: This refers to the value of a new header field parameter> > value for the Contact header field. When a UA registers > > multiple> > times, each simultaneous registration gets a unique reg-id > > value."> >> > change simultaneous to concurrent:> >> > "reg-id: This refers to the value of a new header field parameter> > value for the Contact header field. When a UA registers > > multiple> > times, each concurrent registration gets a unique reg-id value."> fixed> > > 3.3> >> > "If a UA has multiple flows, and one of the servers fails, the UA> > delays the specified time before trying to form a new connection to> > replace the flow to the server that failed."> >> > This implies that if the UA only has one flow, it retries immediately> > which doesn't match the behaviour described in 4.5. Maybe:> >> > "When a server fails the UA will delay before attempting to> > re-establish a flow, using the delays specified in section 4.5."> > fixed> > > 3.5> >> > Change(awkward):> >> > "In this case, the server provides an indicator (the> > 'timed-keepalives' parameter) that the server requires the > > client to> > use the suggested timer values."> >> > to> >> > "In this case, the server indicates that the client must use the> > suggested timer values by including the timed-keepalives parameter."> > i think the original text (while uglier) is more clear.> > > 4.1> >> > "This means the value of the time component of the UUID can be> > arbitrarily selected to be any time less than the time when the> > device was manufactured. A time of 0 (as shown in the > > example in> > Section 3.2) is perfectly legal as long as the device knows no> > other UUIDs were generated at this time."> >> > I found this extremely confusing; I think it is saying that the time> > component isn't necessary(but can't be in the future) if the device> > already has a unique mac address it includes in the UUID. Why not just> > say that a time of 0 can be used if the device is guaranteed to have a> > unique MAC address at construction time?> > The UA can't use time zero, if the UA generates multiple instance-ids > and uses time zero for all of them.> In the absence of better text, I left it as is.> > thanks,> -rohan> > > > > > _______________________________________________> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip> This list is for NEW development of the core SIP Protocol> Use sip-implementors@cs.columbia.edu for questions on current sip> Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Connect to the next generation of MSN Messenger  http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline --_2d91f701-728e-48f9-bc34-b65dd939af01_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: 8bit unsubscrib

> From: rohan@ekabal.com
> Date: Sat, 1 Dec 2007 12:20:11 -0800
> To: derek@counterpath.com
> CC: sip@ietf.org; rohan@ekabal.com; fluffy@cisco.com
> Subject: [Sip] Re: WGLC comments on sip-outbound-10
>
> Hi Derek,
>
> I think I have addressed all your comments except the CRLF backward
> compatibility, which I have fixed in my working copy. See below for
> specifics.
>
>
> On Aug 6, 2007, at 3:46 PM, Derek MacDonald wrote:
>
> > I've finished my review of outbound-10, mainly thinking about things
> > from a client implementation & NAT traversal perspective.
> >
> > Major issues:
> >
> > The following issues are all one part of what I think is the core
> > issue w/ outbound; the draft does not require normative behavior that
> > will result in successful NAT traversal, although it does contain the
> > necessary mechanisms for NAT traversal
> > In 4.2 and 4.3 it is stated that route-set creation is outside the
> > scope of outbound. The behavior that is would work for NAT traversal
> > in a simple deployment is described as an example in 4.2.
>
> I think this is greatly improved in -11 by the following changes:
>
> outbound-11 now states that the edge proxy is expected to record-
> route with a flow-token if the client includes an 'ob' parameter in
> its Contact. If the client is using gruu, it uses the gruu instead
> in its contact. The UA now also uses rport in all requests.
>
> I think this should be sufficient to insure responses (rport),
> incoming requests (from Path flow token in REGISTER), and in-dialog
> requests (from Record-Route flow token, or from a GRUU) all get back
> to the UA.
>
> >> From 4.2:
> >
> > "Forming the route set for the request is outside the scope of
> > this document, but typically results in sending the REGISTER such
> > that the topmost Route header field contains a loose route to the
> > outbound proxy URI."
> >
> > Are we really anticipating that an element will be inserted between
> > the UA and the outbound proxy(s). Do we want to allow this?
>
> no and no. The "typically results in sending the REGISTER..." text
> is there to allow the traditional usage of an outbound proxy, which
> is to resolve the IP address, port, and transport and send it there
> without including a Route header at all.
>
> > If there
> > is such an element in the route set, it will either have to:
> >
> > Support outbound, which causes a single point of failure if there
> > isn't a 1-1 correspondence with the edge proxies. If there is a 1-1
> > correspondence with the edge proxies, it is an edge proxy, so is
> > should have just been configured as the outbound proxy.
> >
> > OR
> >
> > Transparently relay outbound, which seems like a very bad idea.
> >
> > I think we should change the text to something like:
> >
> > "While forming the route set for the request is outside the scope of
> > this specification, the first element in the route set for a
> > registration MUST be from the outbound-proxy-set in order to use this
> > specification."
>
> I think the current text already require that the first element
> visited (whether in the route set or not) is in the outbound-proxy-set.
>
> > Section 4.3 Discusses how a UA would send a request, but does not
> > describe the basic behavior that would establish a dialog through a
> > NAT.
> >
> > " When a UA is about to send a request, it first performs normal
> > processing to select the next hop URI. The UA can use a variety of
> > techniques to compute the route set and accordingly the next hop
> > URI.
> > Discussion of these techniques is outside the scope of this
> > document
> > but could include mechanisms specified in RFC 3608 [22] (Service
> > Route) and [21]."
> >
> > If the next hop does not support outbound, and isn't an existing flow,
> > a dialog establishing request will likely result in a route set which
> > does not work through a NAT. The rport mechanism only provides NAT
> > traversal for a single SIP response.
>
> correct. there is now text setting the responsibility clearly:
> > If the registrar did not support outbound, the UA may have
> > unintentionally registered an unroutable contact. It is the
> > responsiblity of the UA to remove any inappropriate Contacts.
>
>
> > "The UA performs normal DNS resolution on the next hop URI (as
> > described in RFC 3263 [4]) to find a protocol, IP address, and
> > port."
> >
> > As there is no mechanism to determine outbound support in other
> > administrative domains, this lookup is only relevant to outbound if
> > the UA knows next hop supports outbound.
>
> yes.
>
> > Later in the same paragraph:
> >
> > "If the UA cannot use one of the existing flows,then it SHOULD
> > form a new flow
> > by sending a datagram or opening a new connection to the next
> > hop, as
> > appropriate for the transport protocol."
> >
> > I was under the impression that flows are only created with REGISTER
> > requests...is this incorrect?
>
> this has been changed in -11 to allow flows to be formed for dialog-
> creating requests.
>
> > The crux of the issue is that to accomplish NAT traversal using
> > outbound w/out extensions, the UA MUST send dialog creating requests
> > using an existing flow(selected by round-robin for appropriate
> > transport/etc). Furthermore, in 5.3, edge proxies MUST record route
> > dialog creating requests. We need to change the base-level behaviour
> > of outbound so NAT traversal just works, is this is a core requirement
> > of outbound.
> >
> > Also:
> >
> > Note that if the UA wants its flow to work through NATs or
> > firewalls it still needs to put the 'rport' parameter [10] in
> > its
> > Via header field value, and send from the port it is prepared to
> > receive on. More general information about NAT traversal in SIP
> > is described in [23].
> >
> > should be removed. [23] is very out of date, and references
> > outbound-01, and I believe some of the text is out of date. Rport is
> > not relevant when flows are used, although it doesn't cause any harm.
>
> rport is still relevant when flows are used, because outbound does
> not change the rules in 3261 for forwarding responses.
>
> > Questions/minor issues:
> >
> > 4.1:
> >
> > "The value of this parameter MUST be a URN [8]. One case
> > where a UA may not want to include the URN in the sip.instance
> > media feature tag..."
> >
> > Does this mean that a sip.instance feature tag is still included? If
> > so, what does it contain?
>
> no, the whole parameter should be omitted. i think i reworded this
> to make it more clear.
>
> > "As a result, the UA instance SHOULD provide lexically equivalent URNs
> > in each registration it
> > generates. "
> >
> > Why not MUST instead of SHOULD?
> fixed
>
> > Nits
> >
> > Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't
> > break existing SIP implementations. I spent a lot of time looking
> > through the grammar before I gave up and asked Rohan and pointed me to
> > section 7.5 of 3261. I would reference this section in 3.5.1 and/or
> > 4.4.2.
>
> bummer. I forgot to include this in -11. I have added this in my
> working copy to section 3.5.1 as follows:
> > Sending a CRLF over a connection-oriented transport is
> > backwards safe (because of requirements in Section 7.5 of
> > RFC 3261),
> > but only implementations which support the 'keep'
> > parameter will
> > respond to a "ping" with a "pong".
>
>
> > 2.1
> >
> > "reg-id: This refers to the value of a new header field parameter
> > value for the Contact header field. When a UA registers
> > multiple
> > times, each simultaneous registration gets a unique reg-id
> > value."
> >
> > change simultaneous to concurrent:
> >
> > "reg-id: This refers to the value of a new header field parameter
> > value for the Contact header field. When a UA registers
> > multiple
> > times, each concurrent registration gets a unique reg-id value."
> fixed
>
> > 3.3
> >
> > "If a UA has multiple flows, and one of the servers fails, the UA
> > delays the specified time before trying to form a new connection to
> > replace the flow to the server that failed."
> >
> > This implies that if the UA only has one flow, it retries immediately
> > which doesn't match the behaviour described in 4.5. Maybe:
> >
> > "When a server fails the UA will delay before attempting to
> > re-establish a flow, using the delays specified in section 4.5."
>
> fixed
>
> > 3.5
> >
> > Change(awkward):
> >
> > "In this case, the server provides an indicator (the
> > 'timed-keepalives' parameter) that the server requires the
> > client to
> > use the suggested timer values."
> >
> > to
> >
> > "In this case, the server indicates that the client must use the
> > suggested timer values by including the timed-keepalives parameter."
>
> i think the original text (while uglier) is more clear.
>
> > 4.1
> >
> > "This means the value of the time component of the UUID can be
> > arbitrarily selected to be any time less than the time when the
> > device was manufactured. A time of 0 (as shown in the
> > example in
> > Section 3.2) is perfectly legal as long as the device knows no
> > other UUIDs were generated at this time."
> >
> > I found this extremely confusing; I think it is saying that the time
> > component isn't necessary(but can't be in the future) if the device
> > already has a unique mac address it includes in the UUID. Why not just
> > say that a time of 0 can be used if the device is guaranteed to have a
> > unique MAC address at construction time?
>
> The UA can't use time zero, if the UA generates multiple instance-ids
> and uses time zero for all of them.
> In the absence of better text, I left it as is.
>
> thanks,
> -rohan
>
>
>
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

Connect to the next generation of MSN Messenger  Get it now! --_2d91f701-728e-48f9-bc34-b65dd939af01_-- --===============1084673149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1084673149==-- From sip-bounces@ietf.org Sun Dec 02 05:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq7-0004V5-Lp; Sun, 02 Dec 2007 05:14:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq6-0004Ru-PM for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq6-0004P4-8k for sip@ietf.org; Sun, 02 Dec 2007 05:14:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq4-0005Qr-DE for sip@ietf.org; Sun, 02 Dec 2007 05:14:18 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:16 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AEGfN021562; Sun, 2 Dec 2007 02:14:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEB7B026991; Sun, 2 Dec 2007 10:14:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:12 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 03:32:00 -0600 To: Hannes Tschofenig , daniel grotti From: "James M. Polk" Subject: Re: R: R: [Sip] a question about IETF draft location conveyance 09 In-Reply-To: <4745D839.4000902@gmx.net> References: <4742BDF5.9040302@unibo.it> <4745BDC7.30003@gmx.net> <4745D839.4000902@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:12.0400 (UTC) FILETIME=[15D03B00:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5712; t=1196590456; x=1197454456; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20R=3A=20R=3A=20[Sip]=20a=20question=20about=20IETF=20d raft=20location=0A=20=20conveyance=2009 |Sender:=20; bh=xe/oYa7Gueo3V/ePC8dSO2AX+LjOOIZ2LvFRZe0n1VE=; b=tjceNT59/3HOzjC/PzysFkzU3ovXl/dlt+3HK1ZsN2AmEv2i2JlvNu3N6Y5EQctCUcODSNcK 4Yuib1Izzewmo6vHO9JkV9J/3tPVK8nYMT7Pi/2YJA64emo+uxnnFyUZ; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:27 PM 11/22/2007, Hannes Tschofenig wrote: >RFC 2119 language aims to accomplish interoperability. >The MUST NOT in that sentence does not accomplish interoperability. which is one of my main points >It does not do harm for the proxy to still read it. I'm sure not everyone agrees with this >I would be fine with a sentence that indicates that it is not useful >for the proxy to read the location information if the recipient >parameter is set to "endpoint". I have no problems writing this into the doc, if this is agreeable. Should something like, "and a LbyR URI (MUST NOT/SHOULD NOT) to be dereferenced" >Ciao >Hannes > > >daniel grotti wrote: >>Hi all, >>so why don't emphasize this point in the next draft, saying : >>"Proxy server MUST not read messages with "recipient=endpoint" >>paramenter setted". >>This is my point of you. >> >>What do you think? James? >> >>Regards, >>Daniel >> >>---------------------------------- >> Daniel Grotti >>D.E.I.S. - University of Bologna >>---------------------------------- >> Via Venezia, 52 >> 47023 Cesena (FC) - ITALY >>---------------------------------- >>e-mail: daniel.grotti@unibo.it >>---------------------------------- >> >> >>-----Messaggio originale----- >>Da: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Inviato: gio 22/11/2007 18.35 >>A: daniel grotti >>Cc: Ted Hardie; James M. Polk; IETF SIP List >>Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09 >> >>Hi Daniel, >> >>daniel grotti wrote: >> >>>I believe that if a UA puts "recipient=routing-entity" paramenter >>>into locationValue, the location information should be read only >>>by Proxy Server for location-based routing. But if a UA wants its >>>own location information to be known and seen by endusers, then UA >>>have to insert the "recipient=endpoints" paramenter. In this case >>>Proxy server, from my view, should only forward the message to the >>>destination. UA would just like to bring its own location to an >>>endpoint, and could not interested in location-based routing. >>> >>>Does this make sense? >>> >>> >>> >> >>Correct and makes sense. >> >>The recipient parameter is just a hint for processing. It does not >>have security properties. >> >>Ciao >>Hannes >> >> >> >> >>>Regards, >>>Daniel >>> >>> >>> >>> >>>----------------------------- >>> Daniel Grotti >>>DEIS - Universita' di Bologna >>>----------------------------- >>> Via Venezia, 52 >>> 47023 Cesena (FC) - ITALY >>>----------------------------- >>>email:daniel.grotti@unibo.it >>>----------------------------- >>> >>> >>>-----Messaggio originale----- >>>Da: Ted Hardie [mailto:hardie@qualcomm.com] >>>Inviato: gio 11/22/2007 12:36 >>>A: James M. Polk; daniel grotti; IETF SIP List >>>Oggetto: Re: [Sip] a question about IETF draft location conveyance 09 >>> >>>At 4:18 PM -0600 11/21/07, James M. Polk wrote: >>> >>> >>>>\ >>>>Ted -- This header parameter is for a PIDF-LO, yes -- but it >>>>pertains to the SIP WG's expertise in knowing and agreeing with >>>>SIP's ability to foresee the type of topology from UAC to UAS, >>>>and each server (whether there even is one) in between. I'm not >>>>so sure the SIP WG agrees that a UAC can make this determination, >>>>and am soliciting their input here in a broad way. >>>> >>>>Can a UAC understand enough about the topology of the Internet to >>>>understand where it is sending a request, including how SIP >>>>servers may or may not act upon that request? >>>> >>>>I believe, if the answer is no, the the "recipient=" parameter is >>>>a flawed SIP header parameter. >>>> >>>>If the answer is yes, then it stays with no further arguments from me. >>>> >>>> >>>I think we have fundamentally different ideas of how much >>>understanding of the >>>topology this implies. My view is that the header as currently >>>specified says >>>either "This is meant for the person answering the call/taking the >>>session" or >>>"This is meant to help get the call through/get the session to the >>>right responder". >>>Within the latter case, it requires no knowledge at all of topology; it does >>>not distinguish among the many different routing elements which might be >>>trying to make that happen. >>>A UA that does not care whether it is used for routing can enter "both" >>>and all is well. A UA that *wants* it to be used this way can >>>enter "routing-entity". >>>The availability of "endpoint" as a separate possibility makes sure that >>>an endpoint can indicate that use by the routing system is not >>>intended. If the SIP community believes "routing-entity" is too vague >>>and needs to be broken out, I do not see how the GeoPRIV could object or >>>why it would want to; certainly this working group should have the >>>final word >>>on that. But collapsing things so that entering "endpoint" is >>>not an indicator to the routing entities that they should just >>>pass things along >>>would find opposition (at the very least from me). That would >>>break a pretty >>>fundamental assumption that users are in control of the pidf-lo >>>distributions. >>> >>>Hope you have a great Thanksgiving, >>> Ted >>> >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 05:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq5-0004LH-Nz; Sun, 02 Dec 2007 05:14:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq4-0004D0-44 for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq3-0004As-PB for sip@ietf.org; Sun, 02 Dec 2007 05:14:15 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq1-0005Qe-Sk for sip@ietf.org; Sun, 02 Dec 2007 05:14:15 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:13 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AEDEj021544; Sun, 2 Dec 2007 02:14:13 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEC1f025112; Sun, 2 Dec 2007 10:14:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:12 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 02:58:40 -0600 To: Hannes Tschofenig , daniel grotti From: "James M. Polk" Subject: Re: R: [Sip] a question about IETF draft location conveyance 09 In-Reply-To: <4745BDC7.30003@gmx.net> References: <4742BDF5.9040302@unibo.it> <4745BDC7.30003@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:11.0993 (UTC) FILETIME=[15922090:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5445; t=1196590453; x=1197454453; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20R=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20 location=20conveyance=2009 |Sender:=20; bh=L6rzI77qwrlU6kkuBqECQhWPT1/GFDfTIRO3BAbmd/8=; b=uvmqnbuF49t3EsygIFUvMwGMpJteqFIJl8tlXTCDtTvz5r7BVrCer0DUkWhIKK7FoUzH2bV9 UfwgX7rUS1wxwaZEg9CBjuSPPRs+rxcYiK8tAP+RvThpgf+XVpRKPazh; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:35 AM 11/22/2007, Hannes Tschofenig wrote: >Hi Daniel, > >daniel grotti wrote: >>I believe that if a UA puts "recipient=routing-entity" paramenter >>into locationValue, the location information should be read only by >>Proxy Server for location-based routing. But if a UA wants its own >>location information to be known and seen by endusers, then UA have >>to insert the "recipient=endpoints" paramenter. In this case Proxy >>server, from my view, should only forward the message to the >>destination. UA would just like to bring its own location to an >>endpoint, and could not interested in location-based routing. >> >>Does this make sense? >> >> > >Correct and makes sense. > >The recipient parameter is just a hint for processing. Ted's tone doesn't indicate this is "just a hint", he's making this seem like a mandatory prevention mechanism. That I think is a fool's errand, and it is not enforceable in cleartext. That said, "hinting" that proxies SHOULD NOT view location when "recipient=endpoint" is not a problem. What I am resisting, is that UA's don't know if a message might need location to route the message to the endpoint. Contacting a UAS, like Pizza Hut, might need location to route the message to the nearest store, the user might know this, but the UA might not. This would result in a rejection of the initial message (because location isn't readable by a proxy that needs the location-info). Would the UA understand that the rejection means sent "recipient=both" in a subsequent request? Or does the implementation of that UAC need to prompt the user to acknowledge this is necessary to complete the call set-up? This seems to me to be complicated and against normal user behavior, and I'm thinking about whether or not this is being expected to become normal user behavior? I think this might be preventing calls to any store/service that implements a network routing plan based on the UAC knowing where it is to route the call to the right destination. I cannot understand how this would be differentiated by users. >It does not have security properties. I agree >Ciao >Hannes > > > >>Regards, >>Daniel >> >> >> >> >>----------------------------- >> Daniel Grotti >>DEIS - Universita' di Bologna >>----------------------------- >> Via Venezia, 52 >> 47023 Cesena (FC) - ITALY >>----------------------------- >>email:daniel.grotti@unibo.it >>----------------------------- >> >> >>-----Messaggio originale----- >>Da: Ted Hardie [mailto:hardie@qualcomm.com] >>Inviato: gio 11/22/2007 12:36 >>A: James M. Polk; daniel grotti; IETF SIP List >>Oggetto: Re: [Sip] a question about IETF draft location conveyance 09 >> >>At 4:18 PM -0600 11/21/07, James M. Polk wrote: >> >>>\ >>>Ted -- This header parameter is for a PIDF-LO, yes -- but it >>>pertains to the SIP WG's expertise in knowing and agreeing with >>>SIP's ability to foresee the type of topology from UAC to UAS, and >>>each server (whether there even is one) in between. I'm not so >>>sure the SIP WG agrees that a UAC can make this determination, and >>>am soliciting their input here in a broad way. >>> >>>Can a UAC understand enough about the topology of the Internet to >>>understand where it is sending a request, including how SIP >>>servers may or may not act upon that request? >>> >>>I believe, if the answer is no, the the "recipient=" parameter is >>>a flawed SIP header parameter. >>> >>>If the answer is yes, then it stays with no further arguments from me. >>> >> >> >>I think we have fundamentally different ideas of how much >>understanding of the >>topology this implies. My view is that the header as currently >>specified says >>either "This is meant for the person answering the call/taking the >>session" or >>"This is meant to help get the call through/get the session to the >>right responder". >>Within the latter case, it requires no knowledge at all of topology; it does >>not distinguish among the many different routing elements which might be >>trying to make that happen. >>A UA that does not care whether it is used for routing can enter "both" >>and all is well. A UA that *wants* it to be used this way can >>enter "routing-entity". >>The availability of "endpoint" as a separate possibility makes sure that >>an endpoint can indicate that use by the routing system is not >>intended. If the SIP community believes "routing-entity" is too vague >>and needs to be broken out, I do not see how the GeoPRIV could object or >>why it would want to; certainly this working group should have the final word >>on that. But collapsing things so that entering "endpoint" is >>not an indicator to the routing entities that they should just pass >>things along >>would find opposition (at the very least from me). That would break a pretty >>fundamental assumption that users are in control of the pidf-lo >>distributions. >> >>Hope you have a great Thanksgiving, >> Ted >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 05:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq2-00049Q-OQ; Sun, 02 Dec 2007 05:14:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq2-000496-0I for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq1-00048u-Mq for sip@ietf.org; Sun, 02 Dec 2007 05:14:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq1-0005Qe-2Z for sip@ietf.org; Sun, 02 Dec 2007 05:14:13 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AECnp024595; Sun, 2 Dec 2007 02:14:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEC1f025103; Sun, 2 Dec 2007 10:14:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:11 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 02:41:35 -0600 To: Ted Hardie , Daniel Grotti , IETF SIP List From: "James M. Polk" Subject: Re: [Sip] a question about IETF draft location conveyance 09 In-Reply-To: References: <4742BDF5.9040302@unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:11.0650 (UTC) FILETIME=[155DCA20:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2926; t=1196590452; x=1197454452; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20locatio n=20conveyance=2009 |Sender:=20; bh=H32NiiWvkapV2pM2RoQijGRdWwPZ70FVhkO/N5k2Dwc=; b=Ad3K/CbV9jClJEr4/QwxxX8mBqpJgwnb0VzoskeuBfiWsNLw6aaHgP3b2ZEEEBhG2zPgejuk LBSLuCCT6Z/fnMpoK8SaHrvnOfH46nC1iVNG9QQXs7DuNiBQ/1luD/Xh; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:36 PM 11/21/2007, Ted Hardie wrote: >At 4:18 PM -0600 11/21/07, James M. Polk wrote: > >\ > >Ted -- This header parameter is for a PIDF-LO, yes -- but it > pertains to the SIP WG's expertise in knowing and agreeing with > SIP's ability to foresee the type of topology from UAC to UAS, and > each server (whether there even is one) in between. I'm not so > sure the SIP WG agrees that a UAC can make this determination, and > am soliciting their input here in a broad way. > > > >Can a UAC understand enough about the topology of the Internet to > understand where it is sending a request, including how SIP servers > may or may not act upon that request? > > > >I believe, if the answer is no, the the "recipient=" parameter is > a flawed SIP header parameter. > > > >If the answer is yes, then it stays with no further arguments from me. > > >I think we have fundamentally different ideas of how much understanding of the >topology this implies. My view is that the header as currently specified says >either "This is meant for the person answering the call/taking the session" or >"This is meant to help get the call through/get the session to the >right responder". >Within the latter case, it requires no knowledge at all of topology; it does >not distinguish among the many different routing elements which might be >trying to make that happen. > >A UA that does not care whether it is used for routing can enter "both" >and all is well. A UA that *wants* it to be used this way can enter >"routing-entity". >The availability of "endpoint" as a separate possibility makes sure that >an endpoint can indicate that use by the routing system is not intended. I think this is what we disagree about. Aside the emergency scenario, it is there types of requests that I find it a little hard to believe a UA will know that a "routing-entity" will not be needed to get the message to the ultimate UAS. How can the UA logic know that when calling Pizza Hut or a specific verses nearest garage needs to have location used or not? This almost makes a practical use of this parameter (and this RFC(to-be) to RECOMMENDED that "recipient=both" is the default unless the UAC _knows_ it doesn't want a server ("routing-entity") to view the location. >If the SIP community believes "routing-entity" is too vague >and needs to be broken out, I do not see how the GeoPRIV could object or >why it would want to; certainly this working group should have the final word >on that. But collapsing things so that entering "endpoint" is >not an indicator to the routing entities that they should just pass >things along >would find opposition (at the very least from me). That would break a pretty >fundamental assumption that users are in control of the pidf-lo distributions. > >Hope you have a great Thanksgiving, > Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 05:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq6-0004QH-Kf; Sun, 02 Dec 2007 05:14:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq4-0004Gz-NQ for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq4-0004Eq-Cu for sip@ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq3-0005Qe-Vq for sip@ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AEFuN014166; Sun, 2 Dec 2007 02:14:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEB77026991; Sun, 2 Dec 2007 10:14:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:13 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 03:37:48 -0600 To: Adam Roach , sip@ietf.org From: "James M. Polk" In-Reply-To: <474C84F0.7000309@nostrum.com> References: <474C84F0.7000309@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:12.0743 (UTC) FILETIME=[16049170:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1594; t=1196590455; x=1197454455; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20NITS=3A=20draft-ietf-sip-location-conveyance-09.txt |Sender:=20; bh=Xj6cIBy5t3wuyyhS8N1FykZ6iVrf/HO4E0QpUxUdumU=; b=GuqnBi9usgYcwhEDkm9lrp/F7DB1chLp9umUPcnxFR0k+5w89CrtabCQRRVtX92VHmGv1eB/ C+8hgjxX08w0rGpTKVrdFOG4x5+6TEv9LH6czzevVB6e3SrQCuTMz9kV; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Sip] Re: NITS: draft-ietf-sip-location-conveyance-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Thanks for the comments. see in-line below At 02:58 PM 11/27/2007, Adam Roach wrote: >"A 424 (Bad Location Information) response is a final response >within a transaction, and does not terminate a dialog." > >This does a good job in being specific on the effect of the newly >defined error responses -- however, to be as precise as possible, I >propose that this sentence should read "...and does not terminate a >_usage_." (Alternately: "...a usage or a dialog.") went with the alternate above >Also -- and I could just be missing something here -- but this >document appears to have removed a couple of important header field >parameters from the IANA section. Section 5.2 explains: > > There are 3 Geolocation header parameters, > > o "inserted-by=" > o "used-for-routing" the two above were taken out, as they do not have parameter-values (which I thought one night was the barrier to be included on this list). I can add them in easily. > o "recipient=" > >However, the IANA registration contains only "recipient:" > > Geolocation Header parameters > > Header Parameters Parameter-values Reference > ---------------- ---------------- -------------- > recipient endpoint RFC XXXX (this document) > recipient routing-entity RFC XXXX (this document) > recipient both RFC XXXX (this document) > > >It appears that draft-...-08 _did_ contain the other two parameters. >Why were they removed? see above >/a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 05:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq2-00049Q-OQ; Sun, 02 Dec 2007 05:14:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq2-000496-0I for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq1-00048u-Mq for sip@ietf.org; Sun, 02 Dec 2007 05:14:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq1-0005Qe-2Z for sip@ietf.org; Sun, 02 Dec 2007 05:14:13 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AECnp024595; Sun, 2 Dec 2007 02:14:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEC1f025103; Sun, 2 Dec 2007 10:14:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:11 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 02:41:35 -0600 To: Ted Hardie , Daniel Grotti , IETF SIP List From: "James M. Polk" Subject: Re: [Sip] a question about IETF draft location conveyance 09 In-Reply-To: References: <4742BDF5.9040302@unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:11.0650 (UTC) FILETIME=[155DCA20:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2926; t=1196590452; x=1197454452; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20locatio n=20conveyance=2009 |Sender:=20; bh=H32NiiWvkapV2pM2RoQijGRdWwPZ70FVhkO/N5k2Dwc=; b=Ad3K/CbV9jClJEr4/QwxxX8mBqpJgwnb0VzoskeuBfiWsNLw6aaHgP3b2ZEEEBhG2zPgejuk LBSLuCCT6Z/fnMpoK8SaHrvnOfH46nC1iVNG9QQXs7DuNiBQ/1luD/Xh; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:36 PM 11/21/2007, Ted Hardie wrote: >At 4:18 PM -0600 11/21/07, James M. Polk wrote: > >\ > >Ted -- This header parameter is for a PIDF-LO, yes -- but it > pertains to the SIP WG's expertise in knowing and agreeing with > SIP's ability to foresee the type of topology from UAC to UAS, and > each server (whether there even is one) in between. I'm not so > sure the SIP WG agrees that a UAC can make this determination, and > am soliciting their input here in a broad way. > > > >Can a UAC understand enough about the topology of the Internet to > understand where it is sending a request, including how SIP servers > may or may not act upon that request? > > > >I believe, if the answer is no, the the "recipient=" parameter is > a flawed SIP header parameter. > > > >If the answer is yes, then it stays with no further arguments from me. > > >I think we have fundamentally different ideas of how much understanding of the >topology this implies. My view is that the header as currently specified says >either "This is meant for the person answering the call/taking the session" or >"This is meant to help get the call through/get the session to the >right responder". >Within the latter case, it requires no knowledge at all of topology; it does >not distinguish among the many different routing elements which might be >trying to make that happen. > >A UA that does not care whether it is used for routing can enter "both" >and all is well. A UA that *wants* it to be used this way can enter >"routing-entity". >The availability of "endpoint" as a separate possibility makes sure that >an endpoint can indicate that use by the routing system is not intended. I think this is what we disagree about. Aside the emergency scenario, it is there types of requests that I find it a little hard to believe a UA will know that a "routing-entity" will not be needed to get the message to the ultimate UAS. How can the UA logic know that when calling Pizza Hut or a specific verses nearest garage needs to have location used or not? This almost makes a practical use of this parameter (and this RFC(to-be) to RECOMMENDED that "recipient=both" is the default unless the UAC _knows_ it doesn't want a server ("routing-entity") to view the location. >If the SIP community believes "routing-entity" is too vague >and needs to be broken out, I do not see how the GeoPRIV could object or >why it would want to; certainly this working group should have the final word >on that. But collapsing things so that entering "endpoint" is >not an indicator to the routing entities that they should just pass >things along >would find opposition (at the very least from me). That would break a pretty >fundamental assumption that users are in control of the pidf-lo distributions. > >Hope you have a great Thanksgiving, > Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 05:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq6-0004QH-Kf; Sun, 02 Dec 2007 05:14:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iylq4-0004Gz-NQ for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iylq4-0004Eq-Cu for sip@ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iylq3-0005Qe-Vq for sip@ietf.org; Sun, 02 Dec 2007 05:14:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 02:14:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB2AEFuN014166; Sun, 2 Dec 2007 02:14:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2AEB77026991; Sun, 2 Dec 2007 10:14:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:13 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.68.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 02:14:12 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 02 Dec 2007 03:37:48 -0600 To: Adam Roach , sip@ietf.org From: "James M. Polk" In-Reply-To: <474C84F0.7000309@nostrum.com> References: <474C84F0.7000309@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2007 10:14:12.0743 (UTC) FILETIME=[16049170:01C834CC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1594; t=1196590455; x=1197454455; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20NITS=3A=20draft-ietf-sip-location-conveyance-09.txt |Sender:=20; bh=Xj6cIBy5t3wuyyhS8N1FykZ6iVrf/HO4E0QpUxUdumU=; b=GuqnBi9usgYcwhEDkm9lrp/F7DB1chLp9umUPcnxFR0k+5w89CrtabCQRRVtX92VHmGv1eB/ C+8hgjxX08w0rGpTKVrdFOG4x5+6TEv9LH6czzevVB6e3SrQCuTMz9kV; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Sip] Re: NITS: draft-ietf-sip-location-conveyance-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Thanks for the comments. see in-line below At 02:58 PM 11/27/2007, Adam Roach wrote: >"A 424 (Bad Location Information) response is a final response >within a transaction, and does not terminate a dialog." > >This does a good job in being specific on the effect of the newly >defined error responses -- however, to be as precise as possible, I >propose that this sentence should read "...and does not terminate a >_usage_." (Alternately: "...a usage or a dialog.") went with the alternate above >Also -- and I could just be missing something here -- but this >document appears to have removed a couple of important header field >parameters from the IANA section. Section 5.2 explains: > > There are 3 Geolocation header parameters, > > o "inserted-by=" > o "used-for-routing" the two above were taken out, as they do not have parameter-values (which I thought one night was the barrier to be included on this list). I can add them in easily. > o "recipient=" > >However, the IANA registration contains only "recipient:" > > Geolocation Header parameters > > Header Parameters Parameter-values Reference > ---------------- ---------------- -------------- > recipient endpoint RFC XXXX (this document) > recipient routing-entity RFC XXXX (this document) > recipient both RFC XXXX (this document) > > >It appears that draft-...-08 _did_ contain the other two parameters. >Why were they removed? see above >/a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 06:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IynPy-00079z-Bk; Sun, 02 Dec 2007 06:55:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IynPx-00079q-2l for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 06:55:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IynPw-00079i-PS for sip@ietf.org; Sun, 02 Dec 2007 06:55:24 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IynPv-0004Eg-18 for sip@ietf.org; Sun, 02 Dec 2007 06:55:24 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0016820EBF; Sun, 2 Dec 2007 12:55:21 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-e7-47529d29f8c0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E389020811; Sun, 2 Dec 2007 12:55:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:55:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 12:55:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acgzuk+a2GmMeISUSMaNHxawZYGAPQBHqDYf References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 02 Dec 2007 11:55:21.0845 (UTC) FILETIME=[377C0A50:01C834DA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with you that there are still things missing. I have listed a = number of issues in my slides, based on the comments I've got. =20 Some comments inline. >If we go with this approach, then I would note that there are a number >of additional issues we need to address, for which material is not yet >on the table: > >1) We should provide guidance as to when it is appropriate to >define an INFO package and when some other mechanism should be used. >draft-burger-sip-info-02.txt is one extreme of this which says NEVER. >This guidance will need to be taken account of by any review process >(whatever it is) for IANA registration. I agree it would be good to have some words about this. >2) The registry of packages has to exist. Need to define the = review >requirements for adding to the registry. Yes. This is one of the things I'd thought we handle once we have agreed = whether we are going to go forward with the draft in the first place, = though :) >3) There should be a template associated with such packages. This >should prompt the definer of a new package to specify all issues that >should be covered. Yes. This is listed as an issue in my slides. >In particular, one area which needs to be covered is >how the embedded information tranfer caters for out of sequence >delivery, given that the carriage mechanism does not guarantee order of >delivery in all circumstances of SIP usage. Good point. I will add that to the issues. I guess we have two = possibilities: either we define some kind of sequence number, or we = mandate to only have one outstanding INFO transaction at a time - which = I think could be too restrictive. >4) RFC 2976 still references the obsolete SIP RFC, and therefore >presumably operates to the state machine defined in that RFC, rather >than the one in RFC 3261. If we are going to resurrect INFO, then >presumably we need to replace RFC 2976 with either this draft, or a >companion draft, rather than just update it. Yes. The possible replacement of 2976 by the draft is covered in my = slides. >5) Do we define packages for ISUP and QSIG? It is an issue also covered in my slides, and the question is really = whether we need to do something. First, we already have standardized, and deployed, mechanisms for ISUP = and QSIG transport. Second, ISUP and QSIG may also be sent in the initial INVITE, before you = have done the Info Package negotiation, and also in other non-INFO = messages. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 07:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IynU3-0001IB-Ra; Sun, 02 Dec 2007 06:59:39 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IynU2-0001I1-No for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 06:59:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IynU2-0001Hq-Ds for sip@ietf.org; Sun, 02 Dec 2007 06:59:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IynU0-0004Wl-Tj for sip@ietf.org; Sun, 02 Dec 2007 06:59:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D13A32068E; Sun, 2 Dec 2007 12:59:14 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-6b-47529e127ac4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC76720052; Sun, 2 Dec 2007 12:59:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:59:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 12:56:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg0Uk7oiol0sty8TA29Ln45S9R2PQAiAgFs References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 02 Dec 2007 11:59:14.0703 (UTC) FILETIME=[C24759F0:01C834DA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> In particular, one area which needs to be covered is >> how the embedded information tranfer caters for out of sequence >> delivery, given that the carriage mechanism does not guarantee order = of >> delivery in all circumstances of SIP usage. > >I'm wondering what you have in mind here. > >It is possible to send request R1 then send R2 before getting a = response >to R1. And then it is possible for R2 to arrive before R1, and in that >case it will be accepted. But then, when R1 arrives there will be a = CSeq >error so it will be rejected. > >The end result is that you can get *nondelivery* of a message, but not >*out of order delivery*. =20 The problem is that if the receiver receives a message with Cseq=3DX, it = doesn't matter whether it will receive Cseq=3DX-1 later, because CSeq = doesn't have to be incremented by one. =20 I guess the question is: =20 Shall it be possible to send a new INFO with the SAME Info Package type = as in an ongoing INFO transaction? =20 If you have negotiated multiple Info Package types, being forced to only = have one outstanding INFO transaction is too restrictive, I think. =20 Regards, =20 Christer =20 =20 Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 09:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IypfA-0000Mw-1M; Sun, 02 Dec 2007 09:19:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iypf8-0000FB-6F for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 09:19:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iypf7-0000F1-SK for sip@ietf.org; Sun, 02 Dec 2007 09:19:13 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iypf7-0007cA-E0 for sip@ietf.org; Sun, 02 Dec 2007 09:19:13 -0500 Received: from localhost.localdomain (ppp-70-242-127-246.dsl.rcsntx.swbell.net [70.242.127.246]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id lB2EJBtw095654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Dec 2007 08:19:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4752BED8.7050404@nostrum.com> Date: Sun, 02 Dec 2007 08:19:04 -0600 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "James M. Polk" References: <474C84F0.7000309@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.127.246 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4971/Sat Dec 1 19:03:39 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org Subject: [Sip] Re: NITS: draft-ietf-sip-location-conveyance-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James M. Polk wrote: > >> [T]his document appears to have removed a couple of important header >> field parameters from the IANA section. Section 5.2 explains: >> >> There are 3 Geolocation header parameters, >> >> o "inserted-by=" >> o "used-for-routing" > > the two above were taken out, as they do not have parameter-values > (which I thought one night was the barrier to be included on this > list). I can add them in easily. I've become more confused just now. The headers on the table in the IANA section of this document don't appear to match any of the tables in the sip-parameters registry . If you could point to the table in question, I could probably find you a specific example of parameters being registered without predefined parameter values in the specific table in question. (The specific registry that I think you're aiming for is "Header Field Parameters and Parameter Values", which has a column to indicate whether the parameter has predefined values -- and most of them don't). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 10:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqdx-0006iv-D7; Sun, 02 Dec 2007 10:22:05 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyqdv-0006h6-0Y for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 10:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqdu-0006gw-Mk for sip@ietf.org; Sun, 02 Dec 2007 10:22:02 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyqdu-0006Gp-BB for sip@ietf.org; Sun, 02 Dec 2007 10:22:02 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2007 10:22:02 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB2FM1nL025815; Sun, 2 Dec 2007 10:22:01 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2FM1Ba018379; Sun, 2 Dec 2007 15:22:01 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 10:22:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 10:22:00 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> In-Reply-To: <4751B684.7060603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg0UMwH3jysaVr4TOeHyJ1CGv7D3wApeq7A From: "Sanjay Sinha (sanjsinh)" To: "Paul Kyzivat (pkyzivat)" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 02 Dec 2007 15:22:01.0626 (UTC) FILETIME=[165477A0:01C834F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1583; t=1196608922; x=1197472922; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Comments=20on=20draft-kaplan-sip-info-events- 00 |Sender:=20 |To:=20=22Paul=20Kyzivat=20(pkyzivat)=22=20, =0A=20=20 =20=20=20=20=20=20=22DRAGE, =20Keith=20(Keith)=22=20; bh=JZ0RnHsek9AA1fnKi7EqgOK+5ajNTHBmS0lrga6dB/U=; b=O4/uLcaq2U2FCeXg8d/eATk4o1YlVIpq6z7Iay6v9C76y8VZ5a8zGQXuPNTDSwysqj+EXHsU QKZAX0LL9SmDQavQCI73djJPPRiRuic7IgulRx2w/ttArMZJfNJpepng; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline ... >-----Original Message----- >From: Paul Kyzivat (pkyzivat)=20 >Sent: Saturday, December 01, 2007 2:31 PM >To: DRAGE, Keith (Keith) >Cc: sip@ietf.org >Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > >Keith, > >A comment about one of your points: > >DRAGE, Keith (Keith) wrote: > >> In particular, one area which needs to be covered is how the=20 >embedded=20 >> information tranfer caters for out of sequence delivery, given that=20 >> the carriage mechanism does not guarantee order of delivery in all=20 >> circumstances of SIP usage. > >I'm wondering what you have in mind here. > >It is possible to send request R1 then send R2 before getting=20 >a response to R1. And then it is possible for R2 to arrive=20 >before R1, and in that case it will be accepted. But then,=20 >when R1 arrives there will be a CSeq error so it will be rejected. But if the INFO is used for dtmf, the rejected request will be a problem as it will result in loss of digit information. So I think package type should define whether it is ok to send overlapping requests or not. Sanjay > >The end result is that you can get *nondelivery* of a message,=20 >but not *out of order delivery*. > > Thanks, > Paul > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 10:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqwo-0007Yv-W0; Sun, 02 Dec 2007 10:41:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyqwn-0007VN-D2 for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 10:41:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyqwn-0007Su-1P for sip@ietf.org; Sun, 02 Dec 2007 10:41:33 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyqwm-00089d-Jj for sip@ietf.org; Sun, 02 Dec 2007 10:41:32 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1196610091!25553962!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 15350 invoked from network); 2 Dec 2007 15:41:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 2 Dec 2007 15:41:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lB2FfVJc023667 for ; Sun, 2 Dec 2007 10:41:31 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lB2FfOmr023650 for ; Sun, 2 Dec 2007 10:41:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 10:41:24 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246E728@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 thread-index: Acg0UMwH3jysaVr4TOeHyJ1CGv7D3wApeq7AAAC00rA= References: <4751B684.7060603@cisco.com> <8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" , "DRAGE, Keith (Keith)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Wait a minute. Simply put the issue here is whether the complexity is at the edge element or device versus in the application server. Either one needs to correlate and put the digits in order.=20 -----Original Message----- From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com]=20 Sent: Sunday, December 02, 2007 10:22 AM To: Paul Kyzivat (pkyzivat); DRAGE, Keith (Keith) Cc: sip@ietf.org Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Inline ... >-----Original Message----- >From: Paul Kyzivat (pkyzivat)=20 >Sent: Saturday, December 01, 2007 2:31 PM >To: DRAGE, Keith (Keith) >Cc: sip@ietf.org >Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > >Keith, > >A comment about one of your points: > >DRAGE, Keith (Keith) wrote: > >> In particular, one area which needs to be covered is how the=20 >embedded=20 >> information tranfer caters for out of sequence delivery, given that=20 >> the carriage mechanism does not guarantee order of delivery in all=20 >> circumstances of SIP usage. > >I'm wondering what you have in mind here. > >It is possible to send request R1 then send R2 before getting=20 >a response to R1. And then it is possible for R2 to arrive=20 >before R1, and in that case it will be accepted. But then,=20 >when R1 arrives there will be a CSeq error so it will be rejected. But if the INFO is used for dtmf, the rejected request will be a problem as it will result in loss of digit information. So I think package type should define whether it is ok to send overlapping requests or not. Sanjay > >The end result is that you can get *nondelivery* of a message,=20 >but not *out of order delivery*. > > Thanks, > Paul > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 11:31:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyri9-0002fp-HT; Sun, 02 Dec 2007 11:30:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyri7-0002fZ-Sc for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 11:30:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyri6-0002dr-Md for sip@ietf.org; Sun, 02 Dec 2007 11:30:27 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyri5-0005aG-OQ for sip@ietf.org; Sun, 02 Dec 2007 11:30:26 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2007 11:30:21 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB2GULde007177; Sun, 2 Dec 2007 11:30:21 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB2GUL0i014798; Sun, 2 Dec 2007 16:30:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 11:30:20 -0500 Received: from [10.86.241.240] ([10.86.241.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 11:30:20 -0500 Message-ID: <4752DD9B.3040202@cisco.com> Date: Sun, 02 Dec 2007 11:30:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: R: [Sip] a question about IETF draft location conveyance 09 References: <4742BDF5.9040302@unibo.it> <4745BDC7.30003@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 16:30:20.0262 (UTC) FILETIME=[A14EB060:01C83500] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8454; t=1196613021; x=1197477021; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20R=3A=20[Sip]=20a=20question=20about=20IETF=20draft=20 location=20conveyance=2009 |Sender:=20 |To:=20=22James=20M.=20Polk=22=20; bh=qAbw7c37VYYC3YwduU6HrBoCownsRIeZmEbiqDMTDO0=; b=SSzpsu8J5ErAJ7vRySu5CpHDjYlsRKsqd3jmMmwq9+ge1sXApSl2atIQTCZZDgKqiUPxEGMi AHHhrWMRnnn1oEBYfJHcgCTDHxB4ub8J4ddo0cxqqnRhWeufVbAJM6o/; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, I have not been following this discussion closely, so apologies if this comment doesn't make sense... It seems like a key issue is understanding *who* will need location information for routing purposes, and how it is that they would know that they should do so. I don't think a UAC will be inserting location information in every call, so it must have some way of knowing that it will be needed for some purpose. Has there been any discussion of that? (If I just dial the number for Pizza Hut, my phone won't know. Either I must press some special button that says to include location, or else there must a response from downstream to the first request indicating that location is needed. If the specification of "recipient" must be included, then that error response will need to indicate the desired purpose. And then the UAC will still have to decide if it is ok to include this. Next, lets take the Pizza Hut case. If I am calling sip:orders@pizzahut.com, then to me pizzahut.com *is* target destination. It is probably not difficult for me to decide if I want to give pizzahut my location or not. And it is probably irrelevant to me whether it is so that the closest branch can be selected for routing, or if it is so the pizza can be delivered to me. *If* Pizza Hut wants to do routing based on location of caller then it will be done at or downstream from pizzahut.com. The significance of recipient=routing-entity only seems to make sense if it is used for routing *before* reaching pizzahut.com. But I don't see that as a very valid or plausible use case - at best it is meddling by SPs that IMO they ought not be doing. Perhaps that is more significant and valid if the destination is a service URN - e.g. urn:service:pizza. The translation from from a service urn to a URI might be a valid reason to use location information, and might be done by any routing entity. Its also predictable by the UAC that location might be needed for this. But maybe that isn't a real distinction. With the URN, in effect any node on the route can decide to take on the role of translating the URN. If it does, then it is in effect the intended recipient of the request. I don't have a clear suggestion here, but IMO the distinction among categories of users of location information seems not quite right. Thanks, Paul James M. Polk wrote: > At 11:35 AM 11/22/2007, Hannes Tschofenig wrote: >> Hi Daniel, >> >> daniel grotti wrote: >>> I believe that if a UA puts "recipient=routing-entity" paramenter >>> into locationValue, the location information should be read only by >>> Proxy Server for location-based routing. But if a UA wants its own >>> location information to be known and seen by endusers, then UA have >>> to insert the "recipient=endpoints" paramenter. In this case Proxy >>> server, from my view, should only forward the message to the >>> destination. UA would just like to bring its own location to an >>> endpoint, and could not interested in location-based routing. >>> >>> Does this make sense? >>> >>> >> >> Correct and makes sense. >> >> The recipient parameter is just a hint for processing. > > Ted's tone doesn't indicate this is "just a hint", he's making this seem > like a mandatory prevention mechanism. That I think is a fool's errand, > and it is not enforceable in cleartext. > > That said, "hinting" that proxies SHOULD NOT view location when > "recipient=endpoint" is not a problem. What I am resisting, is that > UA's don't know if a message might need location to route the message to > the endpoint. Contacting a UAS, like Pizza Hut, might need location to > route the message to the nearest store, the user might know this, but > the UA might not. This would result in a rejection of the initial > message (because location isn't readable by a proxy that needs the > location-info). Would the UA understand that the rejection means sent > "recipient=both" in a subsequent request? Or does the implementation of > that UAC need to prompt the user to acknowledge this is necessary to > complete the call set-up? This seems to me to be complicated and > against normal user behavior, and I'm thinking about whether or not this > is being expected to become normal user behavior? I think this might be > preventing calls to any store/service that implements a network routing > plan based on the UAC knowing where it is to route the call to the right > destination. I cannot understand how this would be differentiated by users. > >> It does not have security properties. > > I agree > > >> Ciao >> Hannes >> >> >> >>> Regards, >>> Daniel >>> >>> >>> >>> >>> ----------------------------- >>> Daniel Grotti >>> DEIS - Universita' di Bologna >>> ----------------------------- >>> Via Venezia, 52 >>> 47023 Cesena (FC) - ITALY >>> ----------------------------- >>> email:daniel.grotti@unibo.it >>> ----------------------------- >>> >>> >>> -----Messaggio originale----- >>> Da: Ted Hardie [mailto:hardie@qualcomm.com] >>> Inviato: gio 11/22/2007 12:36 >>> A: James M. Polk; daniel grotti; IETF SIP List >>> Oggetto: Re: [Sip] a question about IETF draft location conveyance 09 >>> >>> At 4:18 PM -0600 11/21/07, James M. Polk wrote: >>> >>>> \ >>>> Ted -- This header parameter is for a PIDF-LO, yes -- but it >>>> pertains to the SIP WG's expertise in knowing and agreeing with >>>> SIP's ability to foresee the type of topology from UAC to UAS, and >>>> each server (whether there even is one) in between. I'm not so sure >>>> the SIP WG agrees that a UAC can make this determination, and am >>>> soliciting their input here in a broad way. >>>> >>>> Can a UAC understand enough about the topology of the Internet to >>>> understand where it is sending a request, including how SIP servers >>>> may or may not act upon that request? >>>> >>>> I believe, if the answer is no, the the "recipient=" parameter is a >>>> flawed SIP header parameter. >>>> >>>> If the answer is yes, then it stays with no further arguments from me. >>>> >>> >>> >>> I think we have fundamentally different ideas of how much >>> understanding of the >>> topology this implies. My view is that the header as currently >>> specified says >>> either "This is meant for the person answering the call/taking the >>> session" or >>> "This is meant to help get the call through/get the session to the >>> right responder". >>> Within the latter case, it requires no knowledge at all of topology; >>> it does >>> not distinguish among the many different routing elements which might be >>> trying to make that happen. >>> A UA that does not care whether it is used for routing can enter "both" >>> and all is well. A UA that *wants* it to be used this way can enter >>> "routing-entity". >>> The availability of "endpoint" as a separate possibility makes sure that >>> an endpoint can indicate that use by the routing system is not >>> intended. If the SIP community believes "routing-entity" is too vague >>> and needs to be broken out, I do not see how the GeoPRIV could object or >>> why it would want to; certainly this working group should have the >>> final word >>> on that. But collapsing things so that entering "endpoint" is >>> not an indicator to the routing entities that they should just pass >>> things along >>> would find opposition (at the very least from me). That would break >>> a pretty >>> fundamental assumption that users are in control of the pidf-lo >>> distributions. >>> >>> Hope you have a great Thanksgiving, >>> Ted >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 12:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysRY-0008UO-4y; Sun, 02 Dec 2007 12:17:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IysRW-0008SV-9G for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 12:17:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysRV-0008SJ-Vn for sip@ietf.org; Sun, 02 Dec 2007 12:17:21 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IysRV-00038d-DK for sip@ietf.org; Sun, 02 Dec 2007 12:17:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2007 12:17:21 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB2HHL0Z015529; Sun, 2 Dec 2007 12:17:21 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2HHGBa013240; Sun, 2 Dec 2007 17:17:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:17:16 -0500 Received: from [10.86.241.240] ([10.86.241.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:17:16 -0500 Message-ID: <4752E89B.1040800@cisco.com> Date: Sun, 02 Dec 2007 12:17:15 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] Comments on draft-kaplan-sip-info-events-00 References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 17:17:16.0272 (UTC) FILETIME=[2FC7B700:01C83507] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2464; t=1196615841; x=1197479841; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20Comments=20on=20draft-kaplan-sip-info -events-00 |Sender:=20 |To:=20Christer=20Holmberg=20; bh=FA8dtEEJI+7m3IARKkfHa/SeysOnHocGa60bgGNx4WM=; b=mIV0NIxaflNvFOt1f1E7V62LVZMC+U7dJzPQiKe8QfD6uZievvFHSIW5hzye7B+Ek/IDDrM4 lQxjyCNOBQfiklm+9n/ntHEj0bNzphdTij9+x3D9dU4O9Z0vS/7qapq2; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >>> In particular, one area which needs to be covered is >>> how the embedded information tranfer caters for out of sequence >>> delivery, given that the carriage mechanism does not guarantee order of >>> delivery in all circumstances of SIP usage. >> I'm wondering what you have in mind here. >> >> It is possible to send request R1 then send R2 before getting a response >> to R1. And then it is possible for R2 to arrive before R1, and in that >> case it will be accepted. But then, when R1 arrives there will be a CSeq >> error so it will be rejected. >> >> The end result is that you can get *nondelivery* of a message, but not >> *out of order delivery*. > > The problem is that if the receiver receives a message with Cseq=X, it doesn't matter whether it will receive Cseq=X-1 later, because CSeq doesn't have to be incremented by one. I'm not sure if we are agreeing or talking past one another. If R1 is sent with Cseq=X and R2 is sent with Cseq=X+1, and R2 is received first, it will be considered a valid request even though there was a gap in the Cseq numbering. Then, when R1 finally arrives, its Cseq will be too small, so the request will be rejected. > I guess the question is: > > Shall it be possible to send a new INFO with the SAME Info Package type as in an ongoing INFO transaction? > If you have negotiated multiple Info Package types, being forced to only have one outstanding INFO transaction is too restrictive, I think. It doesn't matter if it is the same info package type or not. This is a fundamental problem with sending multiple requests concurrently in a dialog. There is nothing you can do in the specification of INFO that will improve on this. Fixing that would require changing the basic nature Cseq processing in 3261. I don't know about you, but I am not going to recommend that. Rather, I think the restriction to one outstanding transaction must be accepted as a limitation of using the INFO technique. Paul > Regards, > > Christer > > > > > Thanks, > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 12:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iysic-0007S5-A2; Sun, 02 Dec 2007 12:35:02 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iysib-0007Px-4Z for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 12:35:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iysia-0007OF-QS for sip@ietf.org; Sun, 02 Dec 2007 12:35:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IysiZ-0005Jy-Dp for sip@ietf.org; Sun, 02 Dec 2007 12:35:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Dec 2007 12:34:59 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB2HYxMp019179; Sun, 2 Dec 2007 12:34:59 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2HYxBa017392; Sun, 2 Dec 2007 17:34:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:34:58 -0500 Received: from [10.86.241.240] ([10.86.241.240]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 12:34:58 -0500 Message-ID: <4752ECC1.5020004@cisco.com> Date: Sun, 02 Dec 2007 12:34:57 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 References: <8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 17:34:58.0321 (UTC) FILETIME=[A8CF8810:01C83509] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1800; t=1196616899; x=1197480899; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-kaplan-sip-info-events- 00 |Sender:=20 |To:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20; bh=5Do090fsiTnHCZ+LXu45nmGX6IP8XiAyPgqo1Eergos=; b=jR3Cjq3AOP/5pWM+wCXKyCQJgINrwCN0q/uMJp+Y1YWuFTqnHRVTF/g7CYd+/cJ11t2iEnPL F/Hi/kssQuQB65jhCUWF2o/SNTbPna5WAe4fWt/NKfDrc4bOx1em7L9a; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think iw will have to be a responsibility of the sending UA to serialize all things that need to travel via INFO. Paul Sanjay Sinha (sanjsinh) wrote: > Inline ... > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Saturday, December 01, 2007 2:31 PM >> To: DRAGE, Keith (Keith) >> Cc: sip@ietf.org >> Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 >> >> Keith, >> >> A comment about one of your points: >> >> DRAGE, Keith (Keith) wrote: >> >>> In particular, one area which needs to be covered is how the >> embedded >>> information tranfer caters for out of sequence delivery, given that >>> the carriage mechanism does not guarantee order of delivery in all >>> circumstances of SIP usage. >> I'm wondering what you have in mind here. >> >> It is possible to send request R1 then send R2 before getting >> a response to R1. And then it is possible for R2 to arrive >> before R1, and in that case it will be accepted. But then, >> when R1 arrives there will be a CSeq error so it will be rejected. > > But if the INFO is used for dtmf, the rejected request will be a problem > as it will result in loss of digit information. So I think package type > should define whether it is ok to send overlapping requests or not. > > Sanjay > >> The end result is that you can get *nondelivery* of a message, >> but not *out of order delivery*. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 14:18:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuJM-0000Pb-GZ; Sun, 02 Dec 2007 14:17:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IyuJL-0000P4-4v for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuJK-0000OR-R2 for sip@ietf.org; Sun, 02 Dec 2007 14:17:02 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyuJK-0001M0-AF for sip@ietf.org; Sun, 02 Dec 2007 14:17:02 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Sun, 2 Dec 2007 14:17:02 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sun, 2 Dec 2007 14:17:01 -0500 From: Hadriel Kaplan To: Paul Kyzivat , Christer Holmberg Date: Sun, 2 Dec 2007 14:16:58 -0500 Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg1B1WRC/zr5GFgSA+QxSJOhIe7uQADsx8Q Message-ID: References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <4752E89B.1040800@cisco.com> In-Reply-To: <4752E89B.1040800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "sip@ietf.org" , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we're getting wrapped around an issue that just doesn't matter. Th= e probability of this case is very small, and even if it happens so what? = It's like a DTMF tone got lost. The user has to re-enter their digits. Th= at happens regularly in the real world with cell phones, with 2833, and cou= ld happen with KPML (I think). As long as it's a rare occurrence per user,= it doesn't really matter. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, December 02, 2007 12:17 PM > To: Christer Holmberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > > Christer Holmberg wrote: > > Hi, > > > >>> In particular, one area which needs to be covered is > >>> how the embedded information tranfer caters for out of sequence > >>> delivery, given that the carriage mechanism does not guarantee order > of > >>> delivery in all circumstances of SIP usage. > >> I'm wondering what you have in mind here. > >> > >> It is possible to send request R1 then send R2 before getting a > response > >> to R1. And then it is possible for R2 to arrive before R1, and in that > >> case it will be accepted. But then, when R1 arrives there will be a > CSeq > >> error so it will be rejected. > >> > >> The end result is that you can get *nondelivery* of a message, but not > >> *out of order delivery*. > > > > The problem is that if the receiver receives a message with Cseq=3DX, i= t > doesn't matter whether it will receive Cseq=3DX-1 later, because CSeq > doesn't have to be incremented by one. > > I'm not sure if we are agreeing or talking past one another. > > If R1 is sent with Cseq=3DX and R2 is sent with Cseq=3DX+1, and R2 is > received first, it will be considered a valid request even though there > was a gap in the Cseq numbering. Then, when R1 finally arrives, its Cseq > will be too small, so the request will be rejected. > > > I guess the question is: > > > > Shall it be possible to send a new INFO with the SAME Info Package type > as in an ongoing INFO transaction? > > > If you have negotiated multiple Info Package types, being forced to onl= y > have one outstanding INFO transaction is too restrictive, I think. > > It doesn't matter if it is the same info package type or not. This is a > fundamental problem with sending multiple requests concurrently in a > dialog. There is nothing you can do in the specification of INFO that > will improve on this. > > Fixing that would require changing the basic nature Cseq processing in > 3261. I don't know about you, but I am not going to recommend that. > > Rather, I think the restriction to one outstanding transaction must be > accepted as a limitation of using the INFO technique. > > Paul > > > Regards, > > > > Christer > > > > > > > > > > Thanks, > > Paul > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 16:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyvuu-00034X-Du; Sun, 02 Dec 2007 15:59:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyvus-00034J-QZ for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:59:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyvus-000344-FZ for sip@ietf.org; Sun, 02 Dec 2007 15:59:54 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyvur-00067P-Mq for sip@ietf.org; Sun, 02 Dec 2007 15:59:54 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4908321CB1; Sun, 2 Dec 2007 21:59:14 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-54-47531ca29a62 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BE24214C9; Sun, 2 Dec 2007 21:59:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:59:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: VS: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 21:59:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg1BzP6zRw1r0vBSki8QhiEFHfAUgAHhlVk References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <4752E89B.1040800@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Dec 2007 20:59:13.0902 (UTC) FILETIME=[31B4C8E0:01C83526] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, >>>> In particular, one area which needs to be covered is >>>> how the embedded information tranfer caters for out of sequence >>>> delivery, given that the carriage mechanism does not guarantee = order of >>>> delivery in all circumstances of SIP usage. >>> I'm wondering what you have in mind here. >>> >>> It is possible to send request R1 then send R2 before getting a = response >>> to R1. And then it is possible for R2 to arrive before R1, and in = that >>> case it will be accepted. But then, when R1 arrives there will be a = CSeq >>> error so it will be rejected. >>> >>> The end result is that you can get *nondelivery* of a message, but = not >>> *out of order delivery*. >>=20 >>The problem is that if the receiver receives a message with Cseq=3DX, = it doesn't matter whether it will receive Cseq=3DX-1=20 >>later, because CSeq doesn't have to be incremented by one. > >I'm not sure if we are agreeing or talking past one another. I think we agree. I shouldn't have sent my e-mail after 35 hours without = sleep :) >If R1 is sent with Cseq=3DX and R2 is sent with Cseq=3DX+1, and R2 is >received first, it will be considered a valid request even though there >was a gap in the Cseq numbering. Then, when R1 finally arrives, its = Cseq >will be too small, so the request will be rejected. > > I guess the question is: >=20 > Shall it be possible to send a new INFO with the SAME Info Package = type as in an ongoing INFO transaction? >If you have negotiated multiple Info Package types, being forced to = only have one outstanding INFO transaction is too >restrictive, I think. > >It doesn't matter if it is the same info package type or not. This is a >fundamental problem with sending multiple requests concurrently in a >dialog. There is nothing you can do in the specification of INFO that >will improve on this. > >Fixing that would require changing the basic nature Cseq processing in >3261. I don't know about you, but I am not going to recommend that. > >Rather, I think the restriction to one outstanding transaction must be >accepted as a limitation of using the INFO technique. Yes. What I had in mind is whether we would need some additional sequence = number, which is always incremented by one -similar to what we have for = PRACK. In that case the receiver would know that there is supposed to = come something before R2, so it would not accept R2 unti it has received = R1. But, before we start looking into such things I think we need to = consider whether it is really needed. It could also be defined as an = extension in future (it doesn't even have to be INFO specific, so). Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 16:11:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyw5w-0000e2-TM; Sun, 02 Dec 2007 16:11:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyw5w-0000dr-2s for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:11:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyw5v-0000dj-OH for sip@ietf.org; Sun, 02 Dec 2007 16:11:19 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyw5u-0007dK-ST for sip@ietf.org; Sun, 02 Dec 2007 16:11:19 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB2LB8f0022828; Sun, 2 Dec 2007 15:11:08 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 15:11:08 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 22:10:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 22:10:47 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019B77BA@DEEXC1U01.de.lucent.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246E728@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg0UMwH3jysaVr4TOeHyJ1CGv7D3wApeq7AAAC00rAABRvMwA== References: <4751B684.7060603@cisco.com><8983EC086A9D954BA74D9763E853CF3E04468C35@xmb-rtp-215.amer.cisco.com> <28F05913385EAC43AF019413F674A0171246E728@OCCLUST04EVS1.ugd.att.com> From: "DRAGE, Keith \(Keith\)" To: "DOLLY, MARTIN C, ATTLABS" , "Sanjay Sinha \(sanjsinh\)" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 02 Dec 2007 21:10:48.0368 (UTC) FILETIME=[CFA3E300:01C83527] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All I am saying here is that a package needs to define what mechanism it uses to ensure that it has received things in order, assuming that it matters. My assumption was that this would be package specific, and dependent on the application. I was then calling for the template for a package definition to provide a space for the package definer to specify this. There is nothing in the INFO RFC as far as I recall that prevents multiple INFO messages being in flight at the same time. Additionally items can be delivered out of order. One mechanism that may work in some applications, may be to ensure that a new INFO is not sent until a final response has been received to the previous one sent. Alternatively, as Christer has said, pay attention to the Cseq, however straight increments will not work as some other message could have been sent in between. It probably therefore cannot be used as a mechanism to determine that an INFO payload has been lost. By the way, does the proposal cover usage of multiple packages simultaneously within the same dialog, each with their own sequencing requirements. If so, that probably adds a further round of complexity. Keith > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Sent: Sunday, December 02, 2007 3:41 PM > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); DRAGE,=20 > Keith (Keith) > Cc: sip@ietf.org > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 >=20 > Wait a minute. Simply put the issue here is whether the=20 > complexity is at the edge element or device versus in the=20 > application server. Either one needs to correlate and put the=20 > digits in order.=20 >=20 > -----Original Message----- > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Sunday, December 02, 2007 10:22 AM > To: Paul Kyzivat (pkyzivat); DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 >=20 > Inline ... >=20 > >-----Original Message----- > >From: Paul Kyzivat (pkyzivat) > >Sent: Saturday, December 01, 2007 2:31 PM > >To: DRAGE, Keith (Keith) > >Cc: sip@ietf.org > >Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > >Keith, > > > >A comment about one of your points: > > > >DRAGE, Keith (Keith) wrote: > > > >> In particular, one area which needs to be covered is how the > >embedded > >> information tranfer caters for out of sequence delivery,=20 > given that=20 > >> the carriage mechanism does not guarantee order of delivery in all=20 > >> circumstances of SIP usage. > > > >I'm wondering what you have in mind here. > > > >It is possible to send request R1 then send R2 before getting a=20 > >response to R1. And then it is possible for R2 to arrive=20 > before R1, and=20 > >in that case it will be accepted. But then, when R1 arrives=20 > there will=20 > >be a CSeq error so it will be rejected. >=20 > But if the INFO is used for dtmf, the rejected request will=20 > be a problem as it will result in loss of digit information.=20 > So I think package type should define whether it is ok to=20 > send overlapping requests or not. >=20 > Sanjay >=20 > > > >The end result is that you can get *nondelivery* of a=20 > message, but not=20 > >*out of order delivery*. > > > > Thanks, > > Paul > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 16:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywML-0006KV-KC; Sun, 02 Dec 2007 16:28:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IywMK-0006Jp-F2 for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:28:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywMK-0006IR-41 for sip@ietf.org; Sun, 02 Dec 2007 16:28:16 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IywMH-0001U7-Ec for sip@ietf.org; Sun, 02 Dec 2007 16:28:13 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lB2LS62F004691; Sun, 2 Dec 2007 15:28:10 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 15:28:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 22:28:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 22:28:04 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> In-Reply-To: <4751B684.7060603@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg0UMMcw5pBr7DHT1SOwTH56E2kzQA2TgTw References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Dec 2007 21:28:05.0655 (UTC) FILETIME=[39E95270:01C8352A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Working backwards through my mailbox, and I guess I should have read = this first. Yes, what I had in mind was the non-delivery of packets, e.g. for the = reason of non-sequential delivery. SIP will not tell you you have missed any packets in this case. Regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Saturday, December 01, 2007 7:31 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 >=20 > Keith, >=20 > A comment about one of your points: >=20 > DRAGE, Keith (Keith) wrote: >=20 > > In particular, one area which needs to be covered is how=20 > the embedded=20 > > information tranfer caters for out of sequence delivery, given that=20 > > the carriage mechanism does not guarantee order of delivery in all=20 > > circumstances of SIP usage. >=20 > I'm wondering what you have in mind here. >=20 > It is possible to send request R1 then send R2 before getting=20 > a response to R1. And then it is possible for R2 to arrive=20 > before R1, and in that case it will be accepted. But then,=20 > when R1 arrives there will be a CSeq error so it will be rejected. >=20 > The end result is that you can get *nondelivery* of a=20 > message, but not *out of order delivery*. >=20 > Thanks, > Paul >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 17:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywqd-00073v-L4; Sun, 02 Dec 2007 16:59:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iywqc-000733-JI for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iywqc-00072o-9K for sip@ietf.org; Sun, 02 Dec 2007 16:59:34 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iywqb-0005eS-HT for sip@ietf.org; Sun, 02 Dec 2007 16:59:34 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lB2LwWdq018366; Sun, 2 Dec 2007 15:58:32 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 15:58:32 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 22:58:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Sun, 2 Dec 2007 22:58:28 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg1B1WRC/zr5GFgSA+QxSJOhIe7uQADsx8QAAX5nMA= References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com><4751B684.7060603@cisco.com> <4752E89B.1040800@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Hadriel Kaplan" , "Paul Kyzivat" , "Christer Holmberg" X-OriginalArrivalTime: 02 Dec 2007 21:58:30.0565 (UTC) FILETIME=[79A47D50:01C8352E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think we can be as categorical as that, due to the fact that we don't know what will exist in the future. That was why I went for suggesting it should be defined by the application using the package. We can identify the problems that exist - if it matters, it is up to the package designer to specify the fix it (probably within the transported data itself unless the solution of not sending another INFO until a final response to the previous is received works). Regards Keith > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Sunday, December 02, 2007 7:17 PM > To: Paul Kyzivat; Christer Holmberg > Cc: sip@ietf.org; DRAGE, Keith (Keith) > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 >=20 > I think we're getting wrapped around an issue that just=20 > doesn't matter. The probability of this case is very small,=20 > and even if it happens so what? It's like a DTMF tone got=20 > lost. The user has to re-enter their digits. That happens=20 > regularly in the real world with cell phones, with 2833, and=20 > could happen with KPML (I think). As long as it's a rare=20 > occurrence per user, it doesn't really matter. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Sunday, December 02, 2007 12:17 PM > > To: Christer Holmberg > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > > > > > > Christer Holmberg wrote: > > > Hi, > > > > > >>> In particular, one area which needs to be covered is how the=20 > > >>> embedded information tranfer caters for out of sequence=20 > delivery,=20 > > >>> given that the carriage mechanism does not guarantee order > > of > > >>> delivery in all circumstances of SIP usage. > > >> I'm wondering what you have in mind here. > > >> > > >> It is possible to send request R1 then send R2 before getting a > > response > > >> to R1. And then it is possible for R2 to arrive before=20 > R1, and in=20 > > >> that case it will be accepted. But then, when R1 arrives=20 > there will=20 > > >> be a > > CSeq > > >> error so it will be rejected. > > >> > > >> The end result is that you can get *nondelivery* of a=20 > message, but=20 > > >> not *out of order delivery*. > > > > > > The problem is that if the receiver receives a message=20 > with Cseq=3DX,=20 > > > it > > doesn't matter whether it will receive Cseq=3DX-1 later, because = CSeq=20 > > doesn't have to be incremented by one. > > > > I'm not sure if we are agreeing or talking past one another. > > > > If R1 is sent with Cseq=3DX and R2 is sent with Cseq=3DX+1, and R2 = is=20 > > received first, it will be considered a valid request even though=20 > > there was a gap in the Cseq numbering. Then, when R1=20 > finally arrives,=20 > > its Cseq will be too small, so the request will be rejected. > > > > > I guess the question is: > > > > > > Shall it be possible to send a new INFO with the SAME=20 > Info Package=20 > > > type > > as in an ongoing INFO transaction? > > > > > If you have negotiated multiple Info Package types, being=20 > forced to=20 > > > only > > have one outstanding INFO transaction is too restrictive, I think. > > > > It doesn't matter if it is the same info package type or=20 > not. This is=20 > > a fundamental problem with sending multiple requests=20 > concurrently in a=20 > > dialog. There is nothing you can do in the specification of=20 > INFO that=20 > > will improve on this. > > > > Fixing that would require changing the basic nature Cseq=20 > processing in=20 > > 3261. I don't know about you, but I am not going to recommend that. > > > > Rather, I think the restriction to one outstanding=20 > transaction must be=20 > > accepted as a limitation of using the INFO technique. > > > > Paul > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > Thanks, > > > Paul > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 18:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyxtm-00077t-3U; Sun, 02 Dec 2007 18:06:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iyxtk-00076i-Gy for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 18:06:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyxtk-0006yC-61 for sip@ietf.org; Sun, 02 Dec 2007 18:06:52 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyxth-00067i-GL for sip@ietf.org; Sun, 02 Dec 2007 18:06:50 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB2N6fU02842; Sun, 2 Dec 2007 15:06:42 -0800 In-Reply-To: <469FFC30.2090309@nostrum.com> References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sun, 2 Dec 2007 15:06:42 -0800 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: Outbound: Feature Tag (Ab)Use X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Adam, I believe outbound-11 now correctly uses option-tags. thanks, -rohan On Jul 19, 2007, at 5:05 PM, Adam Roach wrote: > At the risk of further bloodying the corpse of this poor horse, I > still think the usage of feature tags in outbound is way, way off > in terms of the semantics described in 3261. > > Reviewing the way this is defined to work in SIP: > > 3261:8.1.1.9: >> If the UAC supports extensions to SIP that can be applied by the >> server to the response, the UAC SHOULD include a Supported header >> field in the request listing the option tags (Section 19.2) for >> those >> extensions. > > 3261:8.2.4: > >> A UAS that wishes to apply some extension when generating the >> response MUST NOT do so unless support for that extension is >> indicated in the Supported header field in the request. If the >> desired extension is not supported, the server SHOULD rely only on >> baseline SIP and any other extensions supported by the client. >> ... >> Any extensions applied to a non-421 response MUST be listed in a >> Require header field included in the response. Of course, the >> server >> MUST NOT apply extensions not listed in the Supported header >> field in >> the request. As a result of this, the Require header field in a >> response will only ever contain option tags defined in standards- >> track RFCs. > > There are five normative statements in the text I quote above. The > mechanism described in the outbound draft actually manages to > violate _all_ _five_ of them. > > The registrar infers *both* support for outbound *and* a request to > apply the outbound extension by the presence of the "reg-id" > Contact header field parameter. In particular, the client is > apparently NOT supposed to send a "Supported: outbound" header > field. This appears to contravene the normative statement in > 8.1.1.9 cited above. > > The registrar indicates that outbound procedures are being applied > by including a "Supported" header field in the REGISTER response. > (In 3261, "Supported" in a _response_ indicates that an extension > _can_ _be_ supported in a future request, NOT that it is being > applied to the current one -- sections 11 and 13.3.1.4 both talk > about Supported usage in responses.) > > In other words, the registrar (acting as a UAS) is applying an > extension when generating a response without that extension being > indicated in the "Supported" header field in the request. Again, > this directly contravenes two normative statements from section > 8.2.4 (cited above). > > The registrar is further applying an extension to a non-421 > response that is not listed in a "Require" header field, in > violation of the remaining normative statement in the portion of > section 8.2.4 cited above. > > Why are we doing this so very, very wrong? It's almost as if we've > gone out of our way to violate both the spirit AND the law of > feature tag handling in as many ways as possible. Most annoyingly, > we get exactly the desired behavior if we just do things the way > they're described in 3261. To wit: > > * If a client supports outbound, it includes "Supported: outbound" > in all REGISTER requests, regardless of whether the specific > request makes use of that extension. > > * The client adds a "reg-id" header field parameter to any Contacts > to which outbound processing is to apply. > > * The registrar includes "Require: outbound" in any REGISTER > requests to which outbound behavior is being applied. > > * The registrar is free to include "Supported: outbound" in any > responses it generates -- and it means exactly what 3261 intends > it to mean: that outbound is *supported*, but is not being > applied > to the response in question. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 21:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Td-0007RL-Ks; Sun, 02 Dec 2007 21:56:09 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz1Tc-0007R6-LP for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 21:56:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Tc-0007Qm-B6 for sip@ietf.org; Sun, 02 Dec 2007 21:56:08 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz1Tb-00072u-NL for sip@ietf.org; Sun, 02 Dec 2007 21:56:08 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB32tvU20280; Sun, 2 Dec 2007 18:55:58 -0800 In-Reply-To: <00b801c7cafe$2e5ae040$0601a8c0@BEMBUSTER> References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> <8AA4964D-1BA4-4E5E-8189-02A1032AD389@ekabal.com> <00b801c7cafe$2e5ae040$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A55E294-D74E-497F-A325-9B299AD6855B@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: Outbound: Feature Tag (Ab)Use Date: Sun, 2 Dec 2007 18:55:59 -0800 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Rohan Mahy , Adam Roach , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, In outbound-11, the UAC includes the 'ob' parameter in its Contact in dialog-forming requests if it wants the first-hop to Record-Route with a flow token. This language is flexible enough that it allows an implementation to use a GRUU in its contact instead (once it has one), to implement outbound without GRUU, and to send an initial SUBSCRIBE for the SIP config event package before registration. I believe this addresses your comment. thanks, -rohan On Jul 20, 2007, at 11:45 AM, Jeroen van Bemmel wrote: > Rohan, > > The flag is needed, but you could make it a header parameter rather > than a URI parameter (both for Contact and for Path). > > There is no need for it to appear in the request URI of mid-dialog > requests. The EP can use its own convention to encode the flag, due > to things like GRUU it cannot rely on the 'ob' parameter being in > the request URI anyway. > > Regards, > Jeroen > > Rohan Mahy wrote: >> On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote: >> >>> Hi Adam, >>> >>> What can I say but "You're right". Unless there is some >>> fundamental objection, I will make this change pronto to my working >>> copy. >>> >>> I believe this also means I can remove the 'ob' parameter from the >>> UAC's Contact header. >> >> On further thought, I realized that the 'ob' parameter is still >> needed, since it reflects whether the UAC is sending over a flow for >> which out bound processing is being applied, as opposed to merely >> indicating the UAC is capable of requesting outbound. >> >> thanks, >> -rohan >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 02 21:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Tf-0007S6-EZ; Sun, 02 Dec 2007 21:56:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz1Td-0007RO-Nm for sip-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 21:56:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Td-0007RD-Ck for sip@ietf.org; Sun, 02 Dec 2007 21:56:09 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz1Tc-000736-QY for sip@ietf.org; Sun, 02 Dec 2007 21:56:09 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB32tqU20274; Sun, 2 Dec 2007 18:55:52 -0800 In-Reply-To: <00b801c7cafe$2e5ae040$0601a8c0@BEMBUSTER> References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> <8AA4964D-1BA4-4E5E-8189-02A1032AD389@ekabal.com> <00b801c7cafe$2e5ae040$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] Re: Outbound: Feature Tag (Ab)Use Date: Sun, 2 Dec 2007 18:55:54 -0800 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Rohan Mahy , Adam Roach , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, In outbound-11, the UAC includes the 'ob' parameter in its Contact in dialog-forming requests if it wants the first-hop to Record-Route with a flow token. This language is flexible enough that it allows an implementation to use a GRUU in its contact instead (once it has one), to implement outbound without GRUU, and to send an initial SUBSCRIBE for the SIP config event package before registration. I believe this addresses your comment. thanks, -rohan On Jul 20, 2007, at 11:45 AM, Jeroen van Bemmel wrote: > Rohan, > > The flag is needed, but you could make it a header parameter rather > than a URI parameter (both for Contact and for Path). > > There is no need for it to appear in the request URI of mid-dialog > requests. The EP can use its own convention to encode the flag, due > to things like GRUU it cannot rely on the 'ob' parameter being in > the request URI anyway. > > Regards, > Jeroen > > Rohan Mahy wrote: >> On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote: >> >>> Hi Adam, >>> >>> What can I say but "You're right". Unless there is some >>> fundamental objection, I will make this change pronto to my working >>> copy. >>> >>> I believe this also means I can remove the 'ob' parameter from the >>> UAC's Contact header. >> >> On further thought, I realized that the 'ob' parameter is still >> needed, since it reflects whether the UAC is sending over a flow for >> which out bound processing is being applied, as opposed to merely >> indicating the UAC is capable of requesting outbound. >> >> thanks, >> -rohan >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 00:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3eK-0003YI-Ui; Mon, 03 Dec 2007 00:15:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz3eJ-0003Y4-Ms for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 00:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3eJ-0003Xp-D8 for sip@ietf.org; Mon, 03 Dec 2007 00:15:19 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz3eI-000202-Ol for sip@ietf.org; Mon, 03 Dec 2007 00:15:19 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Mon, 3 Dec 2007 00:15:18 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 3 Dec 2007 00:15:15 -0500 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , Paul Kyzivat , Christer Holmberg Date: Mon, 3 Dec 2007 00:15:11 -0500 Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Topic: [Sip] Comments on draft-kaplan-sip-info-events-00 Thread-Index: Acg1B1WRC/zr5GFgSA+QxSJOhIe7uQADsx8QAAX5nMAADua0MA== Message-ID: References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com><4751B684.7060603@cisco.com> <4752E89B.1040800@cisco.com> <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180019B77C0@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yup, fair enough. -hadriel > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Sunday, December 02, 2007 4:58 PM > To: Hadriel Kaplan; Paul Kyzivat; Christer Holmberg > Cc: sip@ietf.org > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 > > I don't think we can be as categorical as that, due to the fact that we > don't know what will exist in the future. > > That was why I went for suggesting it should be defined by the > application using the package. We can identify the problems that exist > - if it matters, it is up to the package designer to specify the fix it > (probably within the transported data itself unless the solution of not > sending another INFO until a final response to the previous is received > works). > > Regards > > Keith > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Sunday, December 02, 2007 7:17 PM > > To: Paul Kyzivat; Christer Holmberg > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > Subject: RE: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > > I think we're getting wrapped around an issue that just > > doesn't matter. The probability of this case is very small, > > and even if it happens so what? It's like a DTMF tone got > > lost. The user has to re-enter their digits. That happens > > regularly in the real world with cell phones, with 2833, and > > could happen with KPML (I think). As long as it's a rare > > occurrence per user, it doesn't really matter. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Sunday, December 02, 2007 12:17 PM > > > To: Christer Holmberg > > > Cc: sip@ietf.org; DRAGE, Keith (Keith) > > > Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 > > > > > > > > > > > > Christer Holmberg wrote: > > > > Hi, > > > > > > > >>> In particular, one area which needs to be covered is how the > > > >>> embedded information tranfer caters for out of sequence > > delivery, > > > >>> given that the carriage mechanism does not guarantee order > > > of > > > >>> delivery in all circumstances of SIP usage. > > > >> I'm wondering what you have in mind here. > > > >> > > > >> It is possible to send request R1 then send R2 before getting a > > > response > > > >> to R1. And then it is possible for R2 to arrive before > > R1, and in > > > >> that case it will be accepted. But then, when R1 arrives > > there will > > > >> be a > > > CSeq > > > >> error so it will be rejected. > > > >> > > > >> The end result is that you can get *nondelivery* of a > > message, but > > > >> not *out of order delivery*. > > > > > > > > The problem is that if the receiver receives a message > > with Cseq=3DX, > > > > it > > > doesn't matter whether it will receive Cseq=3DX-1 later, because CSeq > > > doesn't have to be incremented by one. > > > > > > I'm not sure if we are agreeing or talking past one another. > > > > > > If R1 is sent with Cseq=3DX and R2 is sent with Cseq=3DX+1, and R2 is > > > received first, it will be considered a valid request even though > > > there was a gap in the Cseq numbering. Then, when R1 > > finally arrives, > > > its Cseq will be too small, so the request will be rejected. > > > > > > > I guess the question is: > > > > > > > > Shall it be possible to send a new INFO with the SAME > > Info Package > > > > type > > > as in an ongoing INFO transaction? > > > > > > > If you have negotiated multiple Info Package types, being > > forced to > > > > only > > > have one outstanding INFO transaction is too restrictive, I think. > > > > > > It doesn't matter if it is the same info package type or > > not. This is > > > a fundamental problem with sending multiple requests > > concurrently in a > > > dialog. There is nothing you can do in the specification of > > INFO that > > > will improve on this. > > > > > > Fixing that would require changing the basic nature Cseq > > processing in > > > 3261. I don't know about you, but I am not going to recommend that. > > > > > > Rather, I think the restriction to one outstanding > > transaction must be > > > accepted as a limitation of using the INFO technique. > > > > > > Paul > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > Thanks, > > > > Paul > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 01:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4M9-0001pV-PO; Mon, 03 Dec 2007 01:00:37 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz4M7-0001pA-N6 for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 01:00:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4M7-0001p1-C9 for sip@ietf.org; Mon, 03 Dec 2007 01:00:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz4M6-0005eJ-RV for sip@ietf.org; Mon, 03 Dec 2007 01:00:35 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 22:00:34 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB360Y98023248; Sun, 2 Dec 2007 22:00:34 -0800 Received: from [130.129.86.243] (sjc-vpn3-316.cisco.com [10.21.65.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB360X76014188; Mon, 3 Dec 2007 06:00:34 GMT In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0441C01@GBNTHT12009MSX.gb002.siemens.net> References: <4741BB94.80202@cisco.com> <4F6C1429-EABB-452A-A542-94078E8AA151@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0441A85@GBNTHT12009MSX.gb002.siemens.net> <474AC204.9080606@cisco.com> <474B62C7.6050604@cisco.com> A<0D5F89FAC29E2C41B98A6A762007F5D0441C01@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73B36FE5-9E94-40C9-AF30-123AC8667FB4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework Date: Sun, 2 Dec 2007 21:58:45 -0800 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3149; t=1196661634; x=1197525634; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-dtls-framework |Sender:=20; bh=GoMKtjenEJWSuJrqtVNmBLtLezVM2XC8CwexALnQoSE=; b=iSoNT/d2P4WyRv8fCsiJ1n7Hi40eRaoymlvfw23d8aTjNfkRLAbvRZA2VNTP/9qqHsqArile VvwVgNU4B2gvgCab20TogtVX11kRyZsP3GgORKEUZrpiUqJpAIziLNiEKlaFLEM5GLns716onp tstAZl7ArzkxcSRV8QoOrgCZE=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree that if a device is going to have much usefulness in indicating that media is encrypted, it also needs to say who it is from so one can determine that it is not from the MiTM. Cullen On Nov 26, 2007, at 11:28 PM, Elwell, John wrote: > The point is, when showing the padlock icon to say that a call's media > are secured, it needs to accompanied by a display of the domain to > which > it has been verified to be secure. The same way that when I go to a > secure web site I can see the URL and, if I desire, view the > certificate. For SIP, this should be true whether the user-ID within > that domain is a phone number or not. > > So if I make a call to somebody in example1.com, I would expect > that to > be shown and not something like MitM.net. > > John > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: 27 November 2007 00:20 > > To: Paul Kyzivat > > Cc: Cullen Jennings; IETF SIP List; Elwell, John > > Subject: Re: [Sip] comments on draft-ietf-sip-dtls-framework > > > > inline: > > > > Paul Kyzivat wrote: > > > John, > > > > > > I agree with your analysis. And yet in many contexts there > > is a strong > > > desire to display "phone numbers", because of custom and > > limitations of > > > protocols and devices. So there is a tendency to coerce a > > sip URI into a > > > phone number whenever it looks like that can be done. > > > > Its more than a rendering problem. The identifier is meaningful for > > security because the person on the receiving end of the call > > can tie it > > to user - the one that they know has been assigned this > > identifier. And > > thus, they can be assured that, when they answer the phone, they > know > > the user that is calling (let us put aside issues when > > someone else uses > > my phone to make calls). > > > > The root issue is that FUNDAMENTALLY, phone numbers are not scoped > > within a domain. For this reason, the mapping that exists in peoples > > heads from identifiers to users is of one of two forms: > > > > "user@domain" --> some person > > "1 (408) 902-5000" ---> some person > > > > so, even if you user interface could render the fact that, > > the call was > > from sip:14089025000@somedomain.com, I believe that users > > would anyway > > ignore the domain part since there is no domain part for > > phone numbers. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > > Cisco Fellow Edison, NJ 08837 > > Cisco, Voice Technology Group > > jdrosen@cisco.com > > http://www.jdrosen.net PHONE: (408) 902-3084 > > http://www.cisco.com > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 01:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4pq-0005CE-R3; Mon, 03 Dec 2007 01:31:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz4po-00054q-ME for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 01:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4pn-0004z6-KB for sip@ietf.org; Mon, 03 Dec 2007 01:31:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz4pn-0007M9-4s for sip@ietf.org; Mon, 03 Dec 2007 01:31:15 -0500 Received: from [172.17.119.251] ([24.85.64.125]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB36V7R3010067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Dec 2007 00:31:09 -0600 In-Reply-To: <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B132E65-667C-4C0E-B21C-E3CEC3FBC748@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Mon, 3 Dec 2007 00:30:56 -0600 To: "DRAGE, Keith ((Keith))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 2, 2007, at 3:28 PM, DRAGE, Keith ((Keith)) wrote: > Working backwards through my mailbox, and I guess I should have > read this first. > > Yes, what I had in mind was the non-delivery of packets, e.g. for > the reason of non-sequential delivery. > > SIP will not tell you you have missed any packets in this case. > But if the sender follows basic NIT rules and doesn't overlap transactions within the dialog, then you'll never have out-of-order delivery. If you're sending ordered delivery, don't send packet 2 until packet 1 gets ACKed. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 03:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GM-0003jS-MG; Mon, 03 Dec 2007 03:02:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GL-0003j7-3X for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GE-0003dL-8l for sip@ietf.org; Mon, 03 Dec 2007 03:02:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6GD-00052f-RX for sip@ietf.org; Mon, 03 Dec 2007 03:02:38 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382aC3013023 for ; Mon, 3 Dec 2007 00:02:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382M1n023244 for ; Mon, 3 Dec 2007 08:02:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:30 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:30 -0800 Message-ID: <47538A57.4010907@cisco.com> Date: Sun, 02 Dec 2007 23:47:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:30.0251 (UTC) FILETIME=[DA2DBBB0:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1588; t=1196668956; x=1197532956; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-hilt-sip-correction-503-01 |Sender:=20; bh=8NznC2x3VaYPnL61grd02xpHB/hycNltbb20dcGL1HQ=; b=fCj8f/8lil7KXzi/J2IJaVyhUuiXgo4ivD+Jr8KdDeuHrzKdKO8In5cYhoL6r0Fc9dzughjN OZ7oNW1N0WQlvgXNFPgsZU+fQ0CbeFOnfRaAemPPZBnv8PtLLkehW0Xz; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] comments on draft-hilt-sip-correction-503-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Something that needs to be looked into; I think one of the interworking specs to ISUP uses the 503 response code as well to map to certain PSTN failure cases. Those need to be looked at to make sure they still fit with the proposed new definition. The draft implies that the Retry-After mechanism provides too coarse-grained solution for overload control, and finer-grained controls are needed. As you know, some of the solutions being investigated for overload algorithms still use on/off behavior but just tune the Retry-After more algorithmically. So your statements about this need to be tempered a bit. I'm really unsure about whether this is an essential correction or not. Its not a functional bug, but a performance bug. So a system based on rfc3261 works, but just not that well under load. I'm a bit worried that, in an attempt tFrom sip-bounces@ietf.org Mon Dec 03 03:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GM-0003jS-MG; Mon, 03 Dec 2007 03:02:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GL-0003j7-3X for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GE-0003dL-8l for sip@ietf.org; Mon, 03 Dec 2007 03:02:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6GD-00052f-RX for sip@ietf.org; Mon, 03 Dec 2007 03:02:38 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382aC3013023 for ; Mon, 3 Dec 2007 00:02:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382M1n023244 for ; Mon, 3 Dec 2007 08:02:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:30 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:30 -0800 Message-ID: <47538A57.4010907@cisco.com> Date: Sun, 02 Dec 2007 23:47:19 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:30.0251 (UTC) FILETIME=[DA2DBBB0:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1588; t=1196668956; x=1197532956; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-hilt-sip-correction-503-01 |Sender:=20; bh=8NznC2x3VaYPnL61grd02xpHB/hycNltbb20dcGL1HQ=; b=fCj8f/8lil7KXzi/J2IJaVyhUuiXgo4ivD+Jr8KdDeuHrzKdKO8In5cYhoL6r0Fc9dzughjN OZ7oNW1N0WQlvgXNFPgsZU+fQ0CbeFOnfRaAemPPZBnv8PtLLkehW0Xz; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] comments on draft-hilt-sip-correction-503-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Something that needs to be looked into; I think one of the interworking specs to ISUP uses the 503 response code as well to map to certain PSTN failure cases. Those need to be looked at to make sure they still fit with the proposed new definition. The draft implies that the Retry-After mechanism provides too coarse-grained solution for overload control, and finer-grained controls are needed. As you know, some of the solutions being investigated for overload algorithms still use on/off behavior but just tune the Retry-After more algorithmically. So your statements about this need to be tempered a bit. I'm really unsure about whether this is an essential correction or not. Its not a functional bug, but a performance bug. So a system based on rfc3261 works, but just not that well under load. I'm a bit worried that, in an attempt to squeeze this in as an essential correction, we may define the wrong thing so as to minimize change. In particular I don't like alternative 2 and think we probably need a new response code. The other big question is, is it worth defining a new response code now, and then later on basically updating it with the right overload handling behavior, or do it all at once. I think that requires some discussion. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 03:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GK-0003iJ-Q4; Mon, 03 Dec 2007 03:02:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GI-0003dp-03 for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GA-0003aZ-6F for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz6G9-0004Ob-Pj for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:33 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382Xnw012975 for ; Mon, 3 Dec 2007 00:02:33 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382N1j023266 for ; Mon, 3 Dec 2007 08:02:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:29 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:29 -0800 Message-ID: <47538639.6080709@cisco.com> Date: Sun, 02 Dec 2007 23:29:45 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:29.0251 (UTC) FILETIME=[D9952530:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=623; t=1196668953; x=1197532953; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-gurbani-sip-ipv6-abnf-fix-00 |Sender:=20; bh=XGoQEvpb4lranU0l6uP/cZnpBMF3GkeEpWfg/NFKO3M=; b=C4DFYRSENBD0Pqr96hkjY5QysmHN45DigB1tukhY6OGjOudOIT+ZPEp+/ZlneTY9ddrKReHG jHP5KipBP5J1k1lzzDRfFg2ilCub4lWckqvPxUb6tobfdoCW75QTuyOn; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GK-0003iJ-Q4; Mon, 03 Dec 2007 03:02:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GI-0003dp-03 for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GA-0003aZ-6F for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz6G9-0004Ob-Pj for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:33 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382Xnw012975 for ; Mon, 3 Dec 2007 00:02:33 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382N1j023266 for ; Mon, 3 Dec 2007 08:02:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:29 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:29 -0800 Message-ID: <47538639.6080709@cisco.com> Date: Sun, 02 Dec 2007 23:29:45 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:29.0251 (UTC) FILETIME=[D9952530:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=623; t=1196668953; x=1197532953; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-gurbani-sip-ipv6-abnf-fix-00 |Sender:=20; bh=XGoQEvpb4lranU0l6uP/cZnpBMF3GkeEpWfg/NFKO3M=; b=C4DFYRSENBD0Pqr96hkjY5QysmHN45DigB1tukhY6OGjOudOIT+ZPEp+/ZlneTY9ddrKReHG jHP5KipBP5J1k1lzzDRfFg2ilCub4lWckqvPxUb6tobfdoCW75QTuyOn; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks like a good document and definitely something that is in the category of an essential correction. My only comment is that I think there is also an issue with v6 URI equality that we need to fix, and may as well wrap that into a single v6 essential correction. Nits: Missing period at end of abstract -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip help> List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks like a good document and definitely something that is in the category of an essential correction. My only comment is that I think there is also an issue with v6 URI equality that we need to fix, and may as well wrap that into a single v6 essential correction. Nits: Missing period at end of abstract -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 03:03:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GJ-0003gb-OI; Mon, 03 Dec 2007 03:02:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GH-0003dq-W2 for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GA-0003b0-GK for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6G9-000522-Ub for sip@ietf.org; Mon, 03 Dec 2007 03:02:34 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:33 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB382X4I006885 for ; Mon, 3 Dec 2007 00:02:33 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382N1h023266 for ; Mon, 3 Dec 2007 08:02:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:27 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:27 -0800 Message-ID: <47537F44.8080700@cisco.com> Date: Sun, 02 Dec 2007 23:00:04 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:27.0173 (UTC) FILETIME=[D8581150:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2729; t=1196668953; x=1197532953; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20My=20two=20cents=20on=20the=20INFO=20question |Sender:=20; bh=gQBJm7B/oMMl3mmzYPXNCpvJNjUb2trHBeeEreW3q6U=; b=sMGKY30SlNcvTvIO0wbFwlunltLW7d+1PnHCWqLZEvzjWh9ToJipobf+xdJSZ22NljBdDI++ sOcUoNyzknvCAUWyHWHXoPMPZUnJEOjxpxJqRe1NDy4pxTXsM+YPdpuZR+pttfS4g0mMDBdEJf pusJwYQ4oXfjZXrHfsKWm1o3c=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] My two cents on the INFO question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, I finally had a chance to catch up on this topic - reading both Eric's and Hadriel's drafts and most (though not all) of the enormous number of messages on this topic. I personally do not think there is a good definition yet of what the problem is that we are trying to solve. There has been lots of general discussion about INFO usages but for the most part, DTMF is the only real concrete one that has come to the table. My big worry is that the DTMF "problem" is in fact much bigger than just adding negotiation to INFO. Indeed, in a very real sense, defining a new INFO package and INFO framework will just add yet ANOTHER mechanism to the list of things standardized for DTMF (2833, KPML, existing non-standard INFO, unsolicited NOTIFY, and now INFO package). The real problem IMHO is that we lack clear guidance on when each of these applies and when it doesn't. We have no baseline standard that everyone has to implement, and we have no framework for negotiating amongst these very different things. I simply do not see how defining an INFO framework solves that problem. What are the actual use cases where DTMF-over-INFO is the 'right' thing? The only one I've seen mentioned was the 323 gateway case. Are there others? Is that the only use case that this whole mess would actually address? Another big worry is that, if we did have this INFO framework, we would be adding another mechanism to an already-long list of ways to handle UA to UA signaling. Is it clear what the different areas of applicability are for rfc3265 vs. setting up a separate control session vs. new methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think is clear at all. To give an example, Hadriel raised a potential new usage of the INFO framework for exchanging pictures or vcard in the middle of the call. However, we already have a mechanism for doing that via Call-Info. Indeed, Call-Info has the benefit of having a "purpose" attribute, which defines the context for the URL being exchange. So, would the right way to exchange vcards to send an UPDATE with Call-Info? Or send INFO with Info-Event: vcard along with the vcard content in the body? I'm not opposed to a new info framework in principle, but I think its not at all clear that, if we defined such a framework, we'd be solving any real interoperability problems. My 2 cents, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 03:03:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GL-0003jK-Uw; Mon, 03 Dec 2007 03:02:45 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz6GI-0003eC-8I for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GD-0003d5-N8 for sip@ietf.org; Mon, 03 Dec 2007 03:02:37 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6GD-00052f-4S for sip@ietf.org; Mon, 03 Dec 2007 03:02:37 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB382aSj016245 for ; Mon, 3 Dec 2007 00:02:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382M1j023244 for ; Mon, 3 Dec 2007 08:02:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:28 -0800 Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:28 -0800 Message-ID: <47538524.1010205@cisco.com> Date: Sun, 02 Dec 2007 23:25:08 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 08:02:28.0188 (UTC) FILETIME=[D8F2F1C0:01C83582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3805; t=1196668956; x=1197532956; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-ietf-sip-record-route-fix-01 |Sender:=20; bh=GGFMp0SO2KQ+8i4k2nccYl+dOUe+EiCdGbl8fKQfKsw=; b=c8V6rYVUbyOJ4fpTS7LpX59QkcHiNGLYKD7vX+zP1fFcFCftUFDpx0MHU5CrjEY06+/uu5md Ve5ECPG3ejkFuu1YBsqVIzm+tiEFFwUcFreLC0NmJKWc4cbsdzlu5L/t; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Sip] comments on draft-ietf-sip-record-route-fix-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Firstly, I am still of the opinion that this is NOT an essential correction to SIP, but rather a BCP. Clearly the record-route mechanism in RFC3261 itself still works and works fine for the cases where it is applicable. Documenting double-record routing makes sense, but I do not believe it should replace what is in RFC3261 or obsolete it. There is no reason to do it, and its unrealistic to think that everyone who is doing rr-rewriting will go an change their implementation because IETF decided to deprecate something that works. Section 3.1: this is an unrealistic use case. If this were the actual network, no media would be able to flow in the resulting session. Section 3.2: the indented text seems to include both the original rfc3261 text and commentary on it; I think only the orginal text should be indented. > often been noticed that letting [RFC3261] with the Record-Route > rewriting as the only technique described in core specification is > dangerous, due to the fact that rewriting has some heavy drawbacks. this is hyperbole, and not supported by the two points which follow: > 1) Callee cannot sign the route set, because it gets edited by the > proxy in the response. Consequently, end-to-end protection of the > route set can not be supported by the protocol. The openness and > the end-to-end principles are broken (!)... sign the route set?? This has never been possible. Even S/MIME doesn't support that: Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security I don't know what real attack or real problem you are talking about here. > 2) Proxy must implement special "multi-homed" stateful logic. On > the request phase, it goes through output interface calculation > and writes the output interface into the route. It must then > inspect all responses, grep for an input interface, and > selectively edit them to reference the correct output interface: > this is a CPU drag. it is true that there is additional CPU cost. However, that is hardly "dangerous". And, I suspect, in most cases, not a very big CPU burden. I'm not opposed to double record-routing; I am taking objection to the vilification of what is in RFC 3261. > Thus, on the request processing side: item 4 of section 16.6 of > [RFC3261], it SHOULD be noticed that the URI MAY contain the I don't know what it means to SHOULD notice something. Why is this text indented? > This technique has many benefits, and is completely backwards > compatible with [RFC3261]. It consists in putting as the first > value, the Route of receiving interface, including schemes and/or URI > parameters, and, as second value, the Route of the sending interface. > When processing the response, no modification of the recorded route > is required. s/Route/URI Section 5 has odd indenting. The document is hard to follow; it intermixes restatements of RFC3261 sections along with other normative text which is not defined as a restateemnt of rfc3261. I think it would be a clearer document, in fact, if it were not an essential correction and instead a clear description of how to double record-route and when to do it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 04:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7ni-00038V-Bq; Mon, 03 Dec 2007 04:41:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iz7ng-00038B-RV for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 04:41:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7ng-000383-Gf for sip@ietf.org; Mon, 03 Dec 2007 04:41:16 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz7nf-0003Cj-RS for sip@ietf.org; Mon, 03 Dec 2007 04:41:16 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB39eMZ2011216; Mon, 3 Dec 2007 11:40:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:40:54 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:40:53 +0200 Received: from [10.162.252.51] (essapo-nirac25251.europe.nokia.com [10.162.252.51]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB39ek6v029257; Mon, 3 Dec 2007 11:40:49 +0200 Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound From: Aki Niemi To: ext Rohan Mahy In-Reply-To: <0C12AF7F-AB54-4B2D-A028-4C394761024A@ekabal.com> References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> <46B7ABEB.50207@nokia.com> <0C12AF7F-AB54-4B2D-A028-4C394761024A@ekabal.com> Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Mon, 03 Dec 2007 01:41:22 -0800 Message-Id: <1196674882.13248.28.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 09:40:53.0164 (UTC) FILETIME=[9896C6C0:01C83590] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, Cullen Jennings , "ext DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. la, 2007-12-01 kello 12:59 -0800, ext Rohan Mahy kirjoitti: > > o First, I don't understand why the keepalive params are needed at > > all. > > It's simple, really: if the UAC opens a TCP flow, it needs to use > > CRLF. > > If it opens a UDP flow, it needs to use STUN. Or am I missing > > something? > > we merged the keep-stun and keep-crlf into a simple 'keep' parameter. > this 'keep' parameter just allows the UAC to know if it will get a > pong in response to its pings. Huh? Sending the pong is mandatory. > > Why does the UA need to know beforehand that it needs to use the > > default > > interval keepalive? Could this not be returned in the 200 OK instead? > it probably could, but it is not clear where it would go in the 200 OK. How about Flow-Expires: 120 > > All in all, I don't see the reason that these parameters need to be > > pre-configured to the UA as the draft suggests. Seems they are either > > self-evident (based on transport), or something the registrar/edge- > > proxy > > could return in a header field or parameter at register-time. Much > > cleaner IMHO. > what we have may be ugly, but it will work and we appear to have > consensus on it. I remember some very wise advice on these sorts of things: a spec is ready only when there are no non-critical features left to remove. I think this is definitely one such feature. More below. > > o In 3.2. example message: > > > > REGISTER sip:example.com;keep-crlf SIP/2.0 > > > > Why does this parameter need to be in the R-URI? > > the parameter does not need to be there. It could instead be in the > topmost Route header for example. You mean could, SHOULD, or MUST? > This should just work, but the single UA/proxy would need to return a > Path header, otherwise the UA would have no way of discovering > support for keepalive responses. Again, what purpose does the keep parameter then server? > > My question is: where did this 2 minutes come from? Is it based on > > some > > hard data, like empirical evidence or user experience studies? > > No. It was pulled out of thin air. > > > If not, > > how about 14 minutes instead? Much better on the battery and should > > still play nice with the NATs. > > There was some expectation that the UA would be willing to lose 2 > minutes of phone calls, but 14 minutes would be a lot of time to be > off the air. We don't have that today. In fact, today we have a one hour re-registration interval, and I don't see a lot of people complaining. > Certainly, the UA can use something short (like 2 > minutes) for one flow, and 14 minutes for any additional flows > without many ill effects. 2 minutes is too short. It drains the battery. Do you think having an additional flow in addition to the 2-minute flow will improve the situation? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 08:04:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzAxr-0007DZ-OD; Mon, 03 Dec 2007 08:03:59 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzAxp-0007DH-CA for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 08:03:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzAxp-0007D9-2S for sip@ietf.org; Mon, 03 Dec 2007 08:03:57 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzAxn-0001b3-3x for sip@ietf.org; Mon, 03 Dec 2007 08:03:57 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FC122104D; Mon, 3 Dec 2007 14:03:54 +0100 (CET) X-AuditID: c1b4fb3e-b16a4bb00000459d-aa-4753febab45a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62A9121579; Mon, 3 Dec 2007 14:03:54 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:03:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] My two cents on the INFO question Date: Mon, 3 Dec 2007 14:03:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] My two cents on the INFO question Thread-Index: Acg1gy5CgpohnWzoREuLh5dzS45P+gAJQUtu References: <47537F44.8080700@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 03 Dec 2007 13:03:54.0317 (UTC) FILETIME=[F51F37D0:01C835AC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, =20 If we do NOT this, it is not going to help interoperability either. = People will continue using INFO in their own way (even if we go ahead = with Eric's proposal), and the same discussion will come up at some = point again (it's similar to the discussion on early media :). Yes, then = we can say "it's not an IETF problem", but what good will that make for = interoperability? =20 If we go ahead with this there will of course still be non-standard = implementations out there, but at least it will allow for people to use = a standardized mechanism. =20 Now, regarding the issue when it's more appropriate to use mechanism X = rather than mechanism Y, I think that is something we SHALL work on - = no matter what we do with the Info Event draft - and I think it would be = very useful to document. I do NOT think it's part of the Info-Event = draft, however, but rather something more generic, where we collect and = describe the difference mechanisms of doing things, the cons and prefs, = etc. Then people won't have to try to look for different mechanism = separately, and then try to compare them on their own. =20 But, as we have discussed, two of the main reasons why people use INFO = instead of NOTIFY is because they can use the existing invite dialog = (you CAN do that with NOTIFY also, but as we know there are lots of = issues with that - which is the reason we recommend not to do it), and = you don't have to assume the remote entity will know everything you may = want to send to him (he will have to subscribe before you can send = anything). INFO often also works better with B2BUAs, uses standard SIP = mid-dialog routing etc.=20 =20 Regarding DTMF, I agree that it has been the most obvious example, but = there are also other usages people are looking into. I won't speculate = about the most obvious DTMF-over-INFO (or DTMF-out-of-band in general) = use-cases. Interworking with H.323 is certainly one use-case, another = one is interworking with H.324m (in which case there MAY also be other = type of information that you want to send), but people also use it for = "pure" SIP-to-SIP communciations. =20 Thank You very much for your comments! =20 Regards, =20 Christer =20 ________________________________ L=E4hett=E4j=E4: Jonathan Rosenberg [mailto:jdrosen@cisco.com] L=E4hetetty: ma 3.12.2007 5:00 Vastaanottaja: IETF SIP List Aihe: [Sip] My two cents on the INFO question Well, I finally had a chance to catch up on this topic - reading both Eric's and Hadriel's drafts and most (though not all) of the enormous number of messages on this topic. I personally do not think there is a good definition yet of what the problem is that we are trying to solve. There has been lots of general discussion about INFO usages but for the most part, DTMF is the only real concrete one that has come to the table. My big worry is that the DTMF "problem" is in fact much bigger than just adding negotiation to INFO. Indeed, in a very real sense, defining a new INFO package and INFO framework will just add yet ANOTHER mechanism to the list of things standardized for DTMF (2833, KPML, existing non-standard INFO, unsolicited NOTIFY, and now INFO package). The real problem IMHO is that we lack clear guidance on when each of these applies and when it doesn't. We have no baseline standard that everyone has to implement, and we have no framework for negotiating amongst these very different things. I simply do not see how defining an INFO framework solves that problem. What are the actual use cases where DTMF-over-INFO is the 'right' thing? The only one I've seen mentioned was the 323 gateway case. Are there others? Is that the only use case that this whole mess would actually address? Another big worry is that, if we did have this INFO framework, we would be adding another mechanism to an already-long list of ways to handle UA to UA signaling. Is it clear what the different areas of applicability are for rfc3265 vs. setting up a separate control session vs. new methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think is clear at all. To give an example, Hadriel raised a potential new usage of the INFO framework for exchanging pictures or vcard in the middle of the call. However, we already have a mechanism for doing that via Call-Info. Indeed, Call-Info has the benefit of having a "purpose" attribute, which defines the context for the URL being exchange. So, would the right way to exchange vcards to send an UPDATE with Call-Info? Or send INFO with Info-Event: vcard along with the vcard content in the body? I'm not opposed to a new info framework in principle, but I think its not at all clear that, if we defined such a framework, we'd be solving any real interoperability problems. My 2 cents, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net = PHONE: (408) 902-3084 http://www.cisco.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 08:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBMO-0003wH-Tq; Mon, 03 Dec 2007 08:29:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzBMN-0003kO-2f for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 08:29:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzBMM-0003fI-01 for sip@ietf.org; Mon, 03 Dec 2007 08:29:18 -0500 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzBML-0003jo-2h for sip@ietf.org; Mon, 03 Dec 2007 08:29:17 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lB3DRcR0000543; Mon, 3 Dec 2007 14:27:38 +0100 Received: from [127.0.0.1] ([155.132.188.76]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 3 Dec 2007 14:29:11 +0100 Message-ID: <475404A1.4020205@alcatel-lucent.fr> Date: Mon, 03 Dec 2007 14:29:06 +0100 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-record-route-fix-01 References: <47538524.1010205@cisco.com> In-Reply-To: <47538524.1010205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 03 Dec 2007 13:29:12.0195 (UTC) FILETIME=[7DD90530:01C835B0] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id lB3DRcR0000543 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, answers inlines... Jonathan Rosenberg a =E9crit : > Firstly, I am still of the opinion that this is NOT an essential=20 > correction to SIP, but rather a BCP. Clearly the record-route=20 > mechanism in RFC3261 itself still works and works fine for the cases=20 > where it is applicable. Documenting double-record routing makes sense,=20 > but I do not believe it should replace what is in RFC3261 or obsolete=20 > it. There is no reason to do it, and its unrealistic to think that=20 > everyone who is doing rr-rewriting will go an change their=20 > implementation because IETF decided to deprecate something that works. > > Section 3.1: this is an unrealistic use case. If this were the actual=20 > network, no media would be able to flow in the resulting session. So, I assume the following sentence should be removed "In other words,=20 there is no IP level route between U1 and U2;". The multi-home proxy still exist, do you agree? > > Section 3.2: the indented text seems to include both the original=20 > rfc3261 text and commentary on it; I think only the orginal text=20 > should be indented. Ok, I will try to clarify this.. Indeed, it was mixed from the first=20 version of the document because it is inspired by the sipit.net=20 descriptions: http://bugs.sipit.net/show_bug.cgi?id=3D664 http://bugs.sipit.net/show_bug.cgi?id=3D734 http://bugs.sipit.net/show_bug.cgi?id=3D735 >> 1) Callee cannot sign the route set, because it gets edited by the >> proxy in the response. Consequently, end-to-end protection of t= he >> route set can not be supported by the protocol. The openness an= d >> the end-to-end principles are broken (!)... > > sign the route set?? This has never been possible. Even S/MIME doesn't=20 > support that: > > Header fields that can be legitimately modified by proxy servers are= : > Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- > Authorization. If these header fields are not intact end-to-end, > implementations SHOULD NOT consider this a breach of security > > I don't know what real attack or real problem you are talking about her= e. These two points were raised by Dean in a mailing list discussion, Oct.=20 4th 2002: http://www1.ietf.org/mail-archive/web/sip/current/msg06589.html It is just wrong? >> 2) Proxy must implement special "multi-homed" stateful logic. On >> the request phase, it goes through output interface calculation >> and writes the output interface into the route. It must then >> inspect all responses, grep for an input interface, and >> selectively edit them to reference the correct output interface: >> this is a CPU drag. > > it is true that there is additional CPU cost. However, that is hardly=20 > "dangerous". And, I suspect, in most cases, not a very big CPU burden. > > I'm not opposed to double record-routing; I am taking objection to the=20 > vilification of what is in RFC 3261. In fact, my initial version was not so oriented *against* the rewriting,=20 but some people encouraged me to be more "radical"... (I can give the=20 names ;-)....) >> Thus, on the request processing side: item 4 of section 16.6 of >> [RFC3261], it SHOULD be noticed that the URI MAY contain the > > I don't know what it means to SHOULD notice something. Why is this=20 > text indented? fixing it.. This part aims at summarizing parts of the RFC being impacted by the=20 draft, I will probably make a dedicated section for that, and remove the=20 "SHOULD notice" ;-).. >> This technique has many benefits, and is completely backwards >> compatible with [RFC3261]. It consists in putting as the first >> value, the Route of receiving interface, including schemes and/or U= RI >> parameters, and, as second value, the Route of the sending interfac= e. >> When processing the response, no modification of the recorded route >> is required. > > s/Route/URI > > > Section 5 has odd indenting. > > The document is hard to follow; it intermixes restatements of RFC3261=20 > sections along with other normative text which is not defined as a=20 > restateemnt of rfc3261. I agree with this main objection, and that it should be re-organized=20 now, will taken into account these recommendations in version -02, Still need to decide now if it should be a BCP or an RFC 3261 essential=20 correction process document... Thansk a lot, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 10:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCyS-0005FY-AF; Mon, 03 Dec 2007 10:12:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzCyR-0005EV-AG for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 10:12:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCyR-0005EK-03 for sip@ietf.org; Mon, 03 Dec 2007 10:12:43 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzCyQ-0004e7-EY for sip@ietf.org; Mon, 03 Dec 2007 10:12:42 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lB3FCc4o022396; Mon, 3 Dec 2007 09:12:38 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lB3FCcj07751; Mon, 3 Dec 2007 09:12:38 -0600 (CST) Message-ID: <47541CE5.2030709@alcatel-lucent.com> Date: Mon, 03 Dec 2007 09:12:37 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: <47538639.6080709@cisco.com> In-Reply-To: <47538639.6080709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > This looks like a good document and definitely something that is in the > category of an essential correction. My only comment is that I think > there is also an issue with v6 URI equality that we need to fix, and may > as well wrap that into a single v6 essential correction. Jonathan: Can you elaborate on the v6 URI equality fix? Are you referring to the one Brett raised about the equivalence of sip:[::ffff:192.0.2.128] and sip:[::ffff:c000:280]? If so, we have decided to include it in this v6 essential correction. > Nits: > > Missing period at end of abstract Will add in. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 11:04:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDlW-0002vV-GO; Mon, 03 Dec 2007 11:03:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzDlT-0002uv-RQ for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 11:03:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDlT-0002sZ-DK for sip@ietf.org; Mon, 03 Dec 2007 11:03:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzDlS-00021f-Ud for sip@ietf.org; Mon, 03 Dec 2007 11:03:23 -0500 Received: from [172.17.119.251] ([24.85.64.125]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB3G2fHg014637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Dec 2007 10:02:51 -0600 In-Reply-To: <47538524.1010205@cisco.com> References: <47538524.1010205@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] comments on draft-ietf-sip-record-route-fix-01 Date: Mon, 3 Dec 2007 10:02:27 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 2, 2007, at 10:25 PM, Jonathan Rosenberg wrote: > > Section 3.1: this is an unrealistic use case. If this were the > actual network, no media would be able to flow in the resulting > session. > well, MESSAGE methods and presence and probably MSRP would flow. Do you mean to say SIP isn't useful for that sort of application? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 12:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFLC-0005X1-Ex; Mon, 03 Dec 2007 12:44:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzFLA-0005Un-Qm for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:44:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFLA-0005Uc-8t for sip@ietf.org; Mon, 03 Dec 2007 12:44:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFL9-0005d9-Ty for sip@ietf.org; Mon, 03 Dec 2007 12:44:20 -0500 X-IronPort-AV: E=Sophos;i="4.23,244,1194217200"; d="scan'208";a="159435923" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2007 18:44:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB3Hi1lA011054; Mon, 3 Dec 2007 18:44:01 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB3Hen3x020033; Mon, 3 Dec 2007 17:44:01 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 18:42:49 +0100 Received: from [10.21.145.214] ([10.21.145.214]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 18:42:49 +0100 Message-ID: <4754403C.6030804@cisco.com> Date: Mon, 03 Dec 2007 12:43:24 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: <47538639.6080709@cisco.com> <47541CE5.2030709@alcatel-lucent.com> In-Reply-To: <47541CE5.2030709@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 17:42:49.0524 (UTC) FILETIME=[EC152740:01C835D3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1057; t=1196703841; x=1197567841; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-gurbani-sip-ipv6-abnf-f ix-00 |Sender:=20; bh=PuD88dh/EXMjEQL1HHLxbvGzllFobaNn9YyqCW+1USg=; b=qpeeIFQPVEQ/pr2jwWcX81PD/C9x3BccItpcWJR6u5ARbfNH1X5tnLffSyHa5jHCDIU5KAVK zASzgACvtJ8nN8hQ1ZCYC0H07hfl216yDCuSox3zddhAP5Gy355XzvWV; Authentication-Results: ams-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that was the one I was talking about. -Jonathan R. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: >> This looks like a good document and definitely something that is in >> the category of an essential correction. My only comment is that I >> think there is also an issue with v6 URI equality that we need to fix, >> and may as well wrap that into a single v6 essential correction. > > Jonathan: Can you elaborate on the v6 URI equality fix? Are you > referring to the one Brett raised about the equivalence of > sip:[::ffff:192.0.2.128] and sip:[::ffff:c000:280]? > > If so, we have decided to include it in this v6 essential correction. > >> Nits: >> >> Missing period at end of abstract > > Will add in. > > Thanks, > > - vijay -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 12:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFWL-0006GG-0B; Mon, 03 Dec 2007 12:55:53 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzFWK-0006G8-B5 for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:55:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFWK-0006Fv-1R for sip@ietf.org; Mon, 03 Dec 2007 12:55:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFWH-0004xz-PP for sip@ietf.org; Mon, 03 Dec 2007 12:55:52 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB3HtHuW022676; Mon, 3 Dec 2007 11:55:17 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lB3HtHj15191; Mon, 3 Dec 2007 11:55:17 -0600 (CST) Message-ID: <47544304.8030009@alcatel-lucent.com> Date: Mon, 03 Dec 2007 11:55:16 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: <47538639.6080709@cisco.com> <47541CE5.2030709@alcatel-lucent.com> <4754403C.6030804@cisco.com> In-Reply-To: <4754403C.6030804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List , Brian E Carpenter X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Yes, that was the one I was talking about. OK -- then we have it covered. I have had a conversation with Brett and Gonzalo and we decided to include v6 URI equality clarification in the next release of the draft, post Vancouver. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 13:44:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGH5-0000Jd-0f; Mon, 03 Dec 2007 13:44:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzGH3-0000JC-4N for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:44:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGH2-0000J1-QS for sip@ietf.org; Mon, 03 Dec 2007 13:44:08 -0500 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGH2-000177-CY for sip@ietf.org; Mon, 03 Dec 2007 13:44:08 -0500 Received: from dhcp-11b9.ietf70.org (dhcp-11b9.ietf70.org [130.129.17.185]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id lB3IhoUu084909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 12:43:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <47544E62.2030808@nostrum.com> Date: Mon, 03 Dec 2007 10:43:46 -0800 From: Adam Roach User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> <2B132E65-667C-4C0E-B21C-E3CEC3FBC748@softarmor.com> In-Reply-To: <2B132E65-667C-4C0E-B21C-E3CEC3FBC748@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.17.185 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4984/Mon Dec 3 11:37:48 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(\(Keith\)\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 12/2/07 10:30 PM, Dean Willis wrote: > > But if the sender follows basic NIT rules and doesn't overlap > transactions within the dialog, then you'll never have out-of-order > delivery. If you're sending ordered delivery, don't send packet 2 > until packet 1 gets ACKed. I had it in my head many years ago that overlapping NITs were illegal also, but I couldn't ever find any supporting text in RFCs. I think it was in some pre-publication versions of 2543-bis, but got pulled out before finalization. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 13:48:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGKn-0006xv-Ti; Mon, 03 Dec 2007 13:48:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzGKl-0006TL-Gb for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:47:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGKk-00068Q-KI for sip@ietf.org; Mon, 03 Dec 2007 13:47:58 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzGKi-0003UC-2n for sip@ietf.org; Mon, 03 Dec 2007 13:47:56 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Mon, 3 Dec 2007 13:47:55 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 3 Dec 2007 13:47:55 -0500 From: Hadriel Kaplan To: Jonathan Rosenberg , IETF SIP List Date: Mon, 3 Dec 2007 13:47:54 -0500 Subject: RE: [Sip] My two cents on the INFO question Thread-Topic: [Sip] My two cents on the INFO question Thread-Index: Acg1gxWivFISFB7ARVupS5WUNZ+IeQATex7A Message-ID: References: <47537F44.8080700@cisco.com> In-Reply-To: <47537F44.8080700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thanks for the feedback - comment inline... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Sunday, December 02, 2007 11:00 PM > To: IETF SIP List > Subject: [Sip] My two cents on the INFO question > > I personally do not think there is a good definition yet of what the > problem is that we are trying to solve. Huh. I thought that was clear. Sorry if the draft wasn't clear on that. = We currently have an in-invite-dialog method defined (INFO) that many peopl= e use, but it's "broken" because it's missing a standardized way to negotia= te or discover supported uses for INFO, a standardization process for defin= ing packages for it, and signaling what package the specific INFO request i= s carrying/notifying. That's the problem draft-kaplan-sip-info-events is t= rying to address. Whether INFO actually needs to be fixed or instead needs to be abandoned is= almost a separate issue. Is that what you're asking? At the last IETF you said "we should work on things that are broken in the = real world". DTMF is broken in the real world (sometimes), except right no= w SBCs "fix" this issue to make it interop. I don't mind them doing that f= orever, but even fixing it is fraught with problems. > There has been lots of general discussion about INFO usages but for the > most part, DTMF is the only real concrete one that has come to the > table. My big worry is that the DTMF "problem" is in fact much bigger > than just adding negotiation to INFO. Indeed, in a very real sense, > defining a new INFO package and INFO framework will just add yet ANOTHER > mechanism to the list of things standardized for DTMF (2833, KPML, > existing non-standard INFO, unsolicited NOTIFY, and now INFO package). My short answer to your question is "I don't know". I don't know if standa= rdizing INFO will succeed in attracting implementation by vendors which cur= rently do non-standard in-dialog INFO/NOTIFY for DTMF. I don't know if thi= s will reduce the interop issues. I don't know if given enough time, those= vendors would go implement KPML anyway. I *do* believe that there is a price to be paid for KPML above that of INFO= , and that price will keep people doing INFO/NOTIFY. I *do* know there is = a need for signaling-plane DTMF. I *do* know that there is no current stan= dard for INFO-based DTMF. I do believe that if we do not offer a standardi= zed way of doing DMTF in INFO, then the set of {2833, KPML, application/dtm= f-relay INFO, application/dtmf INFO, application/dtmf-event Notify, etc.} w= ill not get smaller. The hope is it gets down to {2833, KPML, INFO}. We can piss up a rope and outlaw the most popular way to do signaling-plane= DTMF. Or we can account for gravity. > What are the actual use cases where DTMF-over-INFO is the 'right' thing? > The only one I've seen mentioned was the 323 gateway case. Are there > others? Is that the only use case that this whole mess would actually > address? DTMF-over-INFO is the 'right' thing to do when the other side asks to recei= ve it. You'd ask to receive it if you're a UA in the call path that wants = to get DTMF in an Invite dialog in the signaling plane. It's not just h323= . It's MGCP too. And apparently a bunch of app-servers and PSTN gateways = that continue to use INFO/NOTIFY today. > Another big worry is that, if we did have this INFO framework, we would > be adding another mechanism to an already-long list of ways to handle UA > to UA signaling. Is it clear what the different areas of applicability > are for rfc3265 vs. setting up a separate control session vs. new > methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think > is clear at all. I think that could be worked on, with one extreme result being to limit INF= O to only DTMF. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 14:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGzH-0001dp-2N; Mon, 03 Dec 2007 14:29:51 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzGzG-0001dB-2j for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 14:29:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGzF-0001ct-O9 for sip@ietf.org; Mon, 03 Dec 2007 14:29:49 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzGzF-0000JF-Ev for sip@ietf.org; Mon, 03 Dec 2007 14:29:49 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB3JTdOR022472; Mon, 3 Dec 2007 13:29:39 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lB3JTcj04481; Mon, 3 Dec 2007 13:29:38 -0600 (CST) Message-ID: <47545921.1060002@alcatel-lucent.com> Date: Mon, 03 Dec 2007 13:29:37 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: <47538639.6080709@cisco.com> <47541CE5.2030709@alcatel-lucent.com> <4754403C.6030804@cisco.com> <47544304.8030009@alcatel-lucent.com> <47545434.6080907@gmail.com> In-Reply-To: <47545434.6080907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian E Carpenter wrote: > Ack. What about the generic equivalence between :: and the zeros that > it elides? We should also include that as a point in the discussion. After Vancouver, Brett and I will sent out some text to the WG for further comments on v6 equality clarifications. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 15:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHqZ-0002Ps-9A; Mon, 03 Dec 2007 15:24:55 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzGez-0005hE-6a for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 14:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGey-0005gS-St for sip@ietf.org; Mon, 03 Dec 2007 14:08:52 -0500 Received: from ro-out-1112.google.com ([72.14.202.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGew-0003lg-OJ for sip@ietf.org; Mon, 03 Dec 2007 14:08:52 -0500 Received: by ro-out-1112.google.com with SMTP id k4so5190339rog for ; Mon, 03 Dec 2007 11:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=y90nlAdovzmiOdt6GMxUye4Ag8OeWTAmAQZZNUEA0KU=; b=BBsv34EuPxfp7+hnPbAYKQcu0oDccd//8V306uRZboDFI3Yv5ck0NtXKWRG3q9OOY2dztOjmvPpCY6Tcq+rjUyKXxAXb8RDqojO1qLJSG4mqwkATY+c34/unO3u5OsZZmdD4EA3dq5sgkK1GYhWOOhiqgxWFNmRLutc53off+3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dfw5QwmxleMNaHAKsIcpp6gM9MiblhviplH1/RbAE9CX8FxZ2DcI3A+a4kQTZ+qYHLxooVqSK/+YCvl5UR0f+L5tP1lk3AlOP4MbkoP0CwAYpVFrwfK5D24Jc0SftKPJE7MIkfXZJflRxa7ANw+YNRD6DB21EKvW1V4wUvNVKz4= Received: by 10.114.88.1 with SMTP id l1mr598953wab.1196708929972; Mon, 03 Dec 2007 11:08:49 -0800 (PST) Received: from ?10.1.130.54? ( [203.98.10.198]) by mx.google.com with ESMTPS id m27sm1618733wag.2007.12.03.11.08.46 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Dec 2007 11:08:49 -0800 (PST) Message-ID: <47545434.6080907@gmail.com> Date: Tue, 04 Dec 2007 08:08:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: <47538639.6080709@cisco.com> <47541CE5.2030709@alcatel-lucent.com> <4754403C.6030804@cisco.com> <47544304.8030009@alcatel-lucent.com> In-Reply-To: <47544304.8030009@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 03 Dec 2007 15:24:53 -0500 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ack. What about the generic equivalence between :: and the zeros that it elides? Regards Brian Carpenter University of Auckland On 2007-12-04 06:55, Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: >> Yes, that was the one I was talking about. > > OK -- then we have it covered. I have had a conversation > with Brett and Gonzalo and we decided to include v6 URI > equality clarification in the next release of the draft, > post Vancouver. > > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 15:31:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHwg-0003L0-I8; Mon, 03 Dec 2007 15:31:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iv4rs-0001zs-5F for sip-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 00:44:52 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iv4rr-0001zj-S5 for sip@ietf.org; Thu, 22 Nov 2007 00:44:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4qg-0006c6-7k for sip@ietf.org; Thu, 22 Nov 2007 00:43:38 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iv4qf-0006An-0X for sip@ietf.org; Thu, 22 Nov 2007 00:43:38 -0500 X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1195710215!10029587!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 31631 invoked from network); 22 Nov 2007 05:43:35 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-5.tower-153.messagelabs.com with SMTP; 22 Nov 2007 05:43:35 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lAM5hZuU001944 for ; Wed, 21 Nov 2007 22:43:35 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lAM5hYqd006674 for ; Wed, 21 Nov 2007 23:43:34 -0600 (CST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lAM5hW9Q006660 for ; Wed, 21 Nov 2007 23:43:33 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIPit21: BNF future-proofing problem? Date: Thu, 22 Nov 2007 13:43:21 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E6029AC62C@ZMY16EXM67.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63wAAashzgAGJzNMA== References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com><66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com><6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com> From: "T Satyanarayana-A12694" To: "Christer Holmberg" , "Robert Sparks" X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 X-TMDA-Confirmed: Thu, 22 Nov 2007 00:44:51 -0500 X-Mailman-Approved-At: Mon, 03 Dec 2007 15:31:13 -0500 Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This would mean a large change to existing parsers and formatters. And also, the "escaping" and "unescaping" overheads. Changing the header-value BNF may be more acceptable? Regards Satya T -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, November 21, 2007 11:13 PM To: Christer Holmberg; Robert Sparks Cc: sip List Subject: RE: [Sip] SIPit21: BNF future-proofing problem? Hi, =20 Another alternative would be to define an escaping mechanism for quoted-strings in SIP messages, and require all characters not allowed by the header-value ABNF to be escaped. =20 Regards, =20 Christer=20 ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 21/11/2007 15:33 To: Robert Sparks Cc: sip List Subject: RE: [Sip] SIPit21: BNF future-proofing problem? Hi, >So to restate the problem that was reported: > >Right now, extension-header does not allow a new header that contains a >quoted-string. > >We have defined extensions (and are likely to define new >ones) that use quoted-string (anything that uses name-addr for=20 >instance). > >This inconsistency has caused interoperability problems in real=20 >implementations. > >My original note was to suggest that we change extension-header to=20 >actually allow the headers we're going to define. > >Christer's response could be read as a proposal to change >quoted- string to achieve the same goal. Yes. Unless someone can show a use-case where the x00-x20 characters would be needed, for backward compability reasons I think it's better to restrict quoted-string than to extend extension-header. Regards, Christer > > Hi, > > > > I am still a little unclear what Robert is proposing, but is there=20 > > really a need to be able to use characters between x00 and > x20 in SIP > > messages? Characters between x21 and x7F, and between x80 > and xBF, are > > ok since they are covered by TEXT-UTF8char and UTF8-CONT. > > > > Regards, > > > > Christer > > > > > > ________________________________ > > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: 21. marraskuuta 2007 7:30 > > To: Robert Sparks > > Cc: sip List > > Subject: Re: [Sip] SIPit21: BNF future-proofing problem? > > =20 > > =20 > > I think I did misread Robert's original email. I thought header=20 > > values having quoted strings are currently not allowed and Robert=20 > > wanted to change RFC2822. Now I realise that you can have > header field > > values with quoted string. Therefore I support the correction that=20 > > Robert is proposing. > > =20 > > Hisham > > =20 > > =20 > > On 21/11/2007, Hisham Khartabil > > wrote: > > > > This is a big change if we do adopt it. It will > cause a lot of > > problem to parsers that handle extenion headers today and is not=20 > > backwards compatible. Why isn't the extension header as is defined=20 > > today not sufficient? > > =20 > > Hisham > > =20 > > =20 > > On 20/11/2007, Robert=20 > > Sparks wrote: > > > > The BNF in 3261 says the following: > > =20 > > extension-header =3D header-name HCOLON > header-value > > header-value =3D *(TEXT-UTF8char / = UTF8-CONT > > / LWS) > > =20 > > This is intended to be the catch-all > field for all future > > extensions > > - older parsers working against this > BNF shouldn't barf > > when we introduce a new header field. > > =20 > > Now, we may have new fields in the > future that look like: > > =20 > > NewHeader =3D new-header-name HCOLON = quoted-string > > =20 > > And down inside quoted-string, we get: > > =20 > > quoted-string =3D SWS DQUOTE > *(qdtext / quoted-pair ) DQUOTE > > qdtext =3D LWS / %x21 / %x23-5B / > > %x5D-7E > > / UTF8-NONASCII > > quoted-pair =3D "\" (%x00-09 / %x0B-0C > > / %x0E-7F) > > =20 > > So, for instance, we could have inside > a quoted string the 2 byte > > sequence \ NULL > > =20 > > This does not parse against > header-value above... > > =20 > > Is this a problem? Some of the SIPit21 > participants argued that it > > is. > > =20 > > The projects I've been involved in > don't parse unknown headers and > > the stacks will just hand up an > unparsed bucket of bits (the only > > rules > > used are those necessary to identify > the next header-field > > starting). > > =20 > > Would it be worth the effort to make > the BNF reflect that rather > > than > > continuing with the incongruity that we > currently specify? > > =20 > > RjS > > =20 > > =20 > > _______________________________________________ > > Sip mailing list=20 > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the > core SIP Protocol > > Use sip-implementors@cs.columbia.edu > for questions on current sip > > Use sipping@ietf.org for new > developments on the application of sip > > =20 > > > > > > =20 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 15:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzI1f-0006GX-S3; Mon, 03 Dec 2007 15:36:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzI1d-0006AU-KR for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 15:36:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzI1d-00064j-6r for sip@ietf.org; Mon, 03 Dec 2007 15:36:21 -0500 Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzI1c-0005tW-Lv for sip@ietf.org; Mon, 03 Dec 2007 15:36:20 -0500 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA10.westchester.pa.mail.comcast.net with comcast id LLLg1Y00H0EZKEL0501a00; Mon, 03 Dec 2007 20:36:20 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA01.westchester.pa.mail.comcast.net with comcast id LLcK1Y00E0umElk0300000; Mon, 03 Dec 2007 20:36:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=ebA3azEne4CeaAg7KFIA:9 a=VDwZJIVAKXa1OI-c68xGi9MuPxcA:4 a=0MAqpqVwYqEA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lB3KaJTc006342 for ; Mon, 3 Dec 2007 15:36:19 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lB3KaJB6006338; Mon, 3 Dec 2007 15:36:19 -0500 Date: Mon, 3 Dec 2007 15:36:19 -0500 Message-Id: <200712032036.lB3KaJB6006338@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <47544E62.2030808@nostrum.com> (adam@nostrum.com) Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> <2B132E65-667C-4C0E-B21C-E3CEC3FBC748@softarmor.com> <47544E62.2030808@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Adam Roach I had it in my head many years ago that overlapping NITs were illegal also, but I couldn't ever find any supporting text in RFCs. I think it was in some pre-publication versions of 2543-bis, but got pulled out before finalization. I think that overlapped transactions is a basic feature of SIP. (The UAC has to be able to deal with the occasional 500 Out Of Order situation, of course.) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 16:05:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzITF-0003W7-GO; Mon, 03 Dec 2007 16:04:53 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzITD-0003Vr-Pp for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 16:04:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzITD-0003Vd-FU for sip@ietf.org; Mon, 03 Dec 2007 16:04:51 -0500 Received: from out003.iad.hostedmail.net ([209.225.56.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzITD-00073b-7I for sip@ietf.org; Mon, 03 Dec 2007 16:04:51 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out003.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Dec 2007 16:04:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-hilt-sip-correction-503-01 Date: Mon, 3 Dec 2007 16:04:50 -0500 Message-ID: In-Reply-To: <47538A57.4010907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-hilt-sip-correction-503-01 Thread-Index: Acg1gv35/y3WJve3RQGkivbZ4mJsDgAY+HGA From: "Brett Tate" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 03 Dec 2007 21:04:50.0311 (UTC) FILETIME=[24A27970:01C835F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I'm really unsure about whether this is an=20 > essential correction or not. Its not a=20 > functional bug, but a performance bug. I'm also uncertain if this should be an essential correction. The only 503 essential corrections that I see needed are clarification of "server" within the rfc3261 section 21.5.4 and security implications of honoring a 503's Retry-After. Draft-hilt-sip-correction-503-01 attempts to provide some clarification concerning "server". However I did not notice what should occur if immediate destination IP address of request was different than source address of 503 response. Leaving it vague is ok with me; however the topic (and 503 with Retry-After in general) should be likely be discussed from a security perspective. The rest of the draft appears to mainly be an rfc3261 extension and related justification. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 17:14:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJXi-0002xc-GA; Mon, 03 Dec 2007 17:13:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzJXg-0002qi-SF for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:13:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJXg-0002nA-C5 for sip@ietf.org; Mon, 03 Dec 2007 17:13:32 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJXf-0001Gw-W2 for sip@ietf.org; Mon, 03 Dec 2007 17:13:32 -0500 Received: from [130.129.87.72] ([130.129.87.72]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB3MDQUk018001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Dec 2007 16:13:28 -0600 In-Reply-To: <200712032036.lB3KaJB6006338@dragon.ariadne.com> References: <5D1A7985295922448D5550C94DE29180019B7775@DEEXC1U01.de.lucent.com> <4751B684.7060603@cisco.com> <5D1A7985295922448D5550C94DE29180019B77BE@DEEXC1U01.de.lucent.com> <2B132E65-667C-4C0E-B21C-E3CEC3FBC748@softarmor.com> <47544E62.2030808@nostrum.com> <200712032036.lB3KaJB6006338@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments on draft-kaplan-sip-info-events-00 Date: Mon, 3 Dec 2007 16:13:15 -0600 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 3, 2007, at 2:36 PM, Dale.Worley@comcast.net wrote: > From: Adam Roach > > I had it in my head many years ago that overlapping NITs were > illegal > also, but I couldn't ever find any supporting text in RFCs. I > think it > was in some pre-publication versions of 2543-bis, but got pulled > out > before finalization. > > I think that overlapped transactions is a basic feature of SIP. (The > UAC has to be able to deal with the occasional 500 Out Of Order > situation, of course.) Yes, but just because the protocol can handle overlapped NITs doesn't mean the application should send them that way. If you have sequential data that needs to be delivered in order (for example, MESSAGE requests) you have to sequence the requests at the application level. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 17:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK2R-0007eX-5C; Mon, 03 Dec 2007 17:45:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzK2O-0007A8-QN for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzK2O-00074K-9g for sip@ietf.org; Mon, 03 Dec 2007 17:45:16 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzK2M-0002Ak-Do for sip@ietf.org; Mon, 03 Dec 2007 17:45:16 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB3MieU21025; Mon, 3 Dec 2007 14:44:40 -0800 In-Reply-To: <1196674882.13248.28.camel@scotty> References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> <46B7ABEB.50207@nokia.com> <0C12AF7F-AB54-4B2D-A028-4C394761024A@ekabal.com> <1196674882.13248.28.camel@scotty> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8739474A-FC28-4626-BB7E-A705A4C2262A@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Date: Mon, 3 Dec 2007 14:44:40 -0800 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: sip@ietf.org, Rohan Mahy , "ext DRAGE, Keith \(Keith\)" , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Aki, Don't shoot the messenger ;-) I think most of our disconnect here is based on the ability to do keepalives outside of outbound. We had consensus to make the document so someone could implement STUN keepalives over UDP that does not implement outbound. This motivated the keep-stun URI parameter, later merged into the keep URI parameter. Since the correct keepalive responses are required by the first hop when doing outbound, the UAC *could* infer the ability to send keepalive pings and receive pongs based on the a successful outbound registration working over the same flow. We could get rid of the keep parameter for outbound registration and only use it in non-outbound keepalive uses (and move the definition to section 8), but we would need to get the consensus of the WG to do that. More brief comments inline... On Dec 3, 2007, at 1:41 AM, Aki Niemi wrote: > Inline. > > la, 2007-12-01 kello 12:59 -0800, ext Rohan Mahy kirjoitti: >>> o First, I don't understand why the keepalive params are needed at >>> all. >>> It's simple, really: if the UAC opens a TCP flow, it needs to use >>> CRLF. >>> If it opens a UDP flow, it needs to use STUN. Or am I missing >>> something? >> >> we merged the keep-stun and keep-crlf into a simple 'keep' parameter. >> this 'keep' parameter just allows the UAC to know if it will get a >> pong in response to its pings. > > Huh? Sending the pong is mandatory. if the implementation supports outbound. (see above) >>> Why does the UA need to know beforehand that it needs to use the >>> default >>> interval keepalive? Could this not be returned in the 200 OK >>> instead? >> it probably could, but it is not clear where it would go in the >> 200 OK. > > How about Flow-Expires: 120 I like it, but we need consensus to switch to that. >>> All in all, I don't see the reason that these parameters need to be >>> pre-configured to the UA as the draft suggests. Seems they are >>> either >>> self-evident (based on transport), or something the registrar/edge- >>> proxy >>> could return in a header field or parameter at register-time. Much >>> cleaner IMHO. >> what we have may be ugly, but it will work and we appear to have >> consensus on it. > > I remember some very wise advice on these sorts of things: a spec is > ready only when there are no non-critical features left to remove. > > I think this is definitely one such feature. More below. > >>> o In 3.2. example message: >>> >>> REGISTER sip:example.com;keep-crlf SIP/2.0 >>> >>> Why does this parameter need to be in the R-URI? >> >> the parameter does not need to be there. It could instead be in the >> topmost Route header for example. > > You mean could, SHOULD, or MUST? whether the parameter is there or not is a by product of where it appears (in which URIs). depending on where the URI came from , it gets copied to various places. outbound does not change those rules. > > >> This should just work, but the single UA/proxy would need to return a >> Path header, otherwise the UA would have no way of discovering >> support for keepalive responses. > > Again, what purpose does the keep parameter then server? again, we would need to agree to assume that an outbound registration is "good-enough". This is certainly safe for any server that correctly implements the spec. >>> My question is: where did this 2 minutes come from? Is it based on >>> some >>> hard data, like empirical evidence or user experience studies? >> >> No. It was pulled out of thin air. >> >>> If not, >>> how about 14 minutes instead? Much better on the battery and should >>> still play nice with the NATs. >> >> There was some expectation that the UA would be willing to lose 2 >> minutes of phone calls, but 14 minutes would be a lot of time to be >> off the air. > > We don't have that today. In fact, today we have a one hour > re-registration interval, and I don't see a lot of people complaining. > >> Certainly, the UA can use something short (like 2 >> minutes) for one flow, and 14 minutes for any additional flows >> without many ill effects. > > 2 minutes is too short. It drains the battery. Do you think having an > additional flow in addition to the 2-minute flow will improve the > situation? I'm not the one you need to convince here. ;-) thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 18:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKwB-0007r7-FA; Mon, 03 Dec 2007 18:42:55 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzKwA-0007qt-GF for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:42:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKwA-0007q1-5R for sip@ietf.org; Mon, 03 Dec 2007 18:42:54 -0500 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzKw9-0008DW-Lt for sip@ietf.org; Mon, 03 Dec 2007 18:42:54 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Dec 2007 18:42:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Mon, 3 Dec 2007 18:42:53 -0500 Message-ID: In-Reply-To: <47545434.6080907@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg16tCByd1k/yc4TLWOqSix1UsoyQAC7ukg From: "Brett Tate" To: "Brian E Carpenter" X-OriginalArrivalTime: 03 Dec 2007 23:42:53.0097 (UTC) FILETIME=[38D0C990:01C83606] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > What about the generic equivalence between :: and=20 > the zeros that it elides? As Vijay mentioned, enhancements concerning IPv6 (and IPv4) address equivalency will be added within the next version of the draft. The initial focus will likely be on the impacts of the variations presented within rfc4291 sections 2.2 and 2.5.5. The variations presented within section 2.2 (such as your question) should be considered equivalent from a SIP perspective. However concerning things like To/From sip-uri's host, I assume that there will currently be poor interoperability if devices adjust things per section 2.2's flexibility (beyond hex case) within a transaction or dialog. I haven't received any feedback concerning impacts of section 2.5.5. However I assume that they should not be considered equivalent to their IPv4 addresses from a SIP perspective. And other IPv6 addresses are also not equivalent to their IPv4 counterpart; for instance "::1" does not equal "127.0.0.1". For prior threads... the following were my initial questions posted to sip-implementors. The first reflects questions related to rfc4291 section 2.2. The second reflects questions related to section 2.5.5. https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/01 7678.html https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/01 7692.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 19:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLJV-00041x-P7; Mon, 03 Dec 2007 19:07:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzLJU-0003wz-Cb for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 19:07:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLJT-0003tx-Tn for sip@ietf.org; Mon, 03 Dec 2007 19:06:59 -0500 Received: from ag-out-0708.google.com ([72.14.246.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLJT-0002Dt-Ji for sip@ietf.org; Mon, 03 Dec 2007 19:06:59 -0500 Received: by ag-out-0708.google.com with SMTP id 8so4171849agc for ; Mon, 03 Dec 2007 16:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=oBhRFUmUjxCbt3aWhmsFtJho/LFEXUpDuaSKxFb8vUg=; b=GQjz3MIkzvSph/xk0kzXJSMXwa4xh5gkkPbflXcB5/P1S1EGYX8jFwFcY1hKsgT/YQL8bJfTdPdzA1StW8PV63SJjDWtHJ6+hdJSvKtXd2lrQd1tZ2sZ3UwHfDST7XqoBTUiMNCo1VUB/RuQFWmVUL+5CNZNBZ3HnunqTg+EAEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lJxRjLn7x9dPPLXLbdAQQnR6QvaWDxIIGmNA3U/JvImSPuc9cmksStUNqoGVl9PN5Iwn1i5zmlpdXMBtUpjEHaS8u6UtYSay13uzfPhXzMkacpG/Lv+cv8s7F91U0MibEAttnOcJh1ZeZqgZdQxTsDG/52ohY1H3eC3yZWXzDzo= Received: by 10.100.34.16 with SMTP id h16mr21354088anh.1196726819295; Mon, 03 Dec 2007 16:06:59 -0800 (PST) Received: by 10.100.228.11 with HTTP; Mon, 3 Dec 2007 16:06:59 -0800 (PST) Message-ID: Date: Mon, 3 Dec 2007 16:06:59 -0800 From: "Jason Fischl" To: "Francois Audet" Subject: Re: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13290B22@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1ECE0EB50388174790F9694F77522CCF13290B22@zrc2hxm0.corp.nortel.com> X-Google-Sender-Auth: 0fa5c5d8c1eaff26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, Flemming Andreasen , Hannes.Tschofenig@nsn.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Nov 13, 2007 11:50 AM, Francois Audet wrote: > (copying Flemming) > > Good draft. Very helpful. > > On the SDP side of things. > > I didn't seen anything in the SDP format that specifically indicated in the offer that > you are trying to setup DTLS-SRTP. > This is signaled in the SDP with the token "UDP/TLS/RTP/SAVP". See http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dtls-04.txt for more details. > Is the assumption that if there is no indication besides the RTP/SAVP in the tcap, that > DTLS-SRTP may be negotiated, and that therefore we do not need an explicit indication > that DTLS-SRTP is supported? > More specifically, UDP/TLS/RTP/SAVP. to signal we're sending SRTP over DTLS. > Do we think it's good enough? In other words, is RTP/SAVP without a=crypto or a=key-mgmt > good enough to indicate DTLS-SRTP? Or should we have another attribute? > I think this is good enough. > A side comment is that the example shows usage with Best-Effort SRTP. My take is > that it could also be used in "DTLS-SRTP-always" mode by having the m-line > use UDP/TLS/RTP/AVP instead of RTP/AVP and not using a a=tcap/a=pcfg line. It > would probably be worthwile to describe it in the draft. > I can add an example fragment to cover this case. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 03 19:17:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLSi-0006Nq-OX; Mon, 03 Dec 2007 19:16:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzLSh-0006Mi-Ia for sip-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 19:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLSh-0006Lc-8F for sip@ietf.org; Mon, 03 Dec 2007 19:16:31 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLSg-0003CG-Ry for sip@ietf.org; Mon, 03 Dec 2007 19:16:31 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB40GPC26436; Tue, 4 Dec 2007 00:16:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt Date: Mon, 3 Dec 2007 18:16:24 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1389A83F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt Thread-Index: Acg2CZp505T/tMuMTHWnN+n48TlYbQAANMNA References: <1ECE0EB50388174790F9694F77522CCF13290B22@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Jason Fischl" X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, Flemming Andreasen , Hannes.Tschofenig@nsn.com, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org See below.=20 > -----Original Message----- > From: jason.fischl@gmail.com [mailto:jason.fischl@gmail.com]=20 > On Behalf Of Jason Fischl > Sent: Monday, December 03, 2007 16:07 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Hannes.Tschofenig@nsn.com;=20 > ekr@networkresonance.com; Flemming Andreasen > Subject: Re: [Sip] I-D=20 > Action:draft-ietf-sip-dtls-srtp-framework-00.txt >=20 > On Nov 13, 2007 11:50 AM, Francois Audet wrote: > > (copying Flemming) > > > > Good draft. Very helpful. > > > > On the SDP side of things. > > > > I didn't seen anything in the SDP format that specifically=20 > indicated=20 > > in the offer that you are trying to setup DTLS-SRTP. > > > This is signaled in the SDP with the token=20 > "UDP/TLS/RTP/SAVP". See=20 > http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dt > ls-04.txt > for more details. Ah.... Can you explicitly say that in the document? I see there is a reference to this draft, but the document doesn't say=20 that it is used for that purpose. >=20 > > Is the assumption that if there is no indication besides=20 > the RTP/SAVP=20 > > in the tcap, that DTLS-SRTP may be negotiated, and that=20 > therefore we=20 > > do not need an explicit indication that DTLS-SRTP is supported? > > > More specifically, UDP/TLS/RTP/SAVP. to signal we're sending=20 > SRTP over DTLS. >=20 > > Do we think it's good enough? In other words, is RTP/SAVP without=20 > > a=3Dcrypto or a=3Dkey-mgmt good enough to indicate DTLS-SRTP?=20 > Or should we have another attribute? > > > I think this is good enough. Agreed. > > A side comment is that the example shows usage with=20 > Best-Effort SRTP.=20 > > My take is that it could also be used in "DTLS-SRTP-always" mode by=20 > > having the m-line use UDP/TLS/RTP/AVP instead of RTP/AVP=20 > and not using=20 > > a a=3Dtcap/a=3Dpcfg line. It would probably be worthwile to=20 > describe it in the draft. > > > I can add an example fragment to cover this case. That would be very useful. Thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 04 04:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzTi6-0004bN-Ui; Tue, 04 Dec 2007 04:04:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzTi4-0004ZR-Vx for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 04:04:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzTi4-0004ZI-Jn for sip@ietf.org; Tue, 04 Dec 2007 04:04:56 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzTi3-0003Ce-KT for sip@ietf.org; Tue, 04 Dec 2007 04:04:56 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 3289F2C01A; Tue, 4 Dec 2007 04:04:55 -0500 (EST) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5QLbuWtOWnu; Tue, 4 Dec 2007 04:04:53 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 3E7CA2C01D; Tue, 4 Dec 2007 04:04:53 -0500 (EST) In-Reply-To: To: Rohan Mahy Subject: Re: [Sip] Outbound-10 comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 4 Dec 2007 04:04:50 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 12/04/2007 04:04:51 AM, Serialize complete at 12/04/2007 04:04:51 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: fluffy@cisco.com, sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0507705657==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0507705657== Content-Type: multipart/alternative; boundary="=_alternative 0031E48A852573A7_=" This is a multipart message in MIME format. --=_alternative 0031E48A852573A7_= Content-Type: text/plain; charset="US-ASCII" Yes, it does. I checked the related changes and they look fine. Thanks., -- Peter Rohan Mahy 01.12.07 14:22 To: peter_blatherwick@mitel.com cc: Rohan Mahy , Jerry Yin , fluffy@cisco.com, sip@ietf.org Subject: Re: [Sip] Outbound-10 comments Jerry, Peter, Per consenus in Chicago we have ;keep in outbound-11 instead of ;keep- stun and ;keep-crlf. I believe this fix addresses your comments. thanks, -rohan On Sep 20, 2007, at 8:06 AM, peter_blatherwick@mitel.com wrote: > I agree with Jerry here, and believe this has come up before (?). > It is pointless for the originating UA to try to impose, or infer, > the keepalive mechanism before it can know what is applicable. > > An additional comment along these lines. > > a. UA sends REGISTER to the proxy with a "outbound" tag in the > Supported header. > ... > > c. If the "outbound" tag is present in the 200 OK, and if the > transport is UDP, using the STUN keep alive, other connection based > transport using crlf keep alive. > > Step a) would really imply the originating UA MUST support both > keepalive mechanisms, and c) implies it MUST begin using the > appropriate one after 200 OK. The usage is implied, not explicit, > which I believe is sufficient in this case. Alternatively, the > usage could be made more explicit by listing the supported k-a > mechanisms in Supported exchange, or some such. This should be > spelled out either way. > > -- Peter Blatherwick > > > > > Jerry Yin > 19.09.07 16:40 > > > To: sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com > cc: > Subject: [Sip] Outbound-10 comments > > > > Hi Cullen and Rohan, > > In the draft, it requires the UA configure the next hop route > header with "keep-stun", "keep-crlf", or "timed-keepalive" tags. > This would cause some problems. > > 1. As an example, the route-set contains this route header as > indicated in section 9 example: > Route: > If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or > TLS, the keep-stun will be useless. Vice versa, if the > pri.example.com is resolved as UDP, and if "keep-crlf" was manually > configured, it is not working either. > > 2. Before sending the REGISTER request, the admin/or user does not > know what keep-alive mechanism the proxy (or edge proxy) supports. > Blindly configure the keep-stun, or keep-crlf would cause the > problem that the draft indicated itself in section 8: "the node > could be blacklisted for UDP traffic". > The better approach is to let the UA and the proxy to negotiate, > not manually configure from UA side. > a. UA sends REGISTER to the proxy with a "outbound" tag in the > Supported header. > b. Proxy insert the "outbound" tag in the 200 OK, if the UA > indicated that it supports the outbound. > c. If the "outbound" tag is present in the 200 OK, and if the > transport is UDP, using the STUN keep alive, other connection based > transport using crlf keep alive. > There would be no way to mass up by configurations with this > approach. Let me know if I missed something. > > Regards, > Jerry Yin > > > Yahoo! oneSearch: Finally, mobile search that gives answers, not > web links. _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --=_alternative 0031E48A852573A7_= Content-Type: text/html; charset="US-ASCII"
Yes, it does.  I checked the related changes and they look fine.  Thanks.,
-- Peter



Rohan Mahy <rohan@ekabal.com>

01.12.07 14:22

       
        To:        peter_blatherwick@mitel.com
        cc:        Rohan Mahy <rohan@ekabal.com>, Jerry Yin <jerry.yin@yahoo.com>, fluffy@cisco.com, sip@ietf.org
        Subject:        Re: [Sip] Outbound-10 comments



Jerry, Peter,

Per consenus in Chicago we have ;keep in outbound-11 instead of ;keep-
stun and ;keep-crlf.  I believe this fix addresses your comments.

thanks,
-rohan


On Sep 20, 2007, at 8:06 AM, peter_blatherwick@mitel.com wrote:
> I agree with Jerry here, and believe this has come up before (?).  
> It is pointless for the originating UA to try to impose, or infer,  
> the keepalive mechanism before it can know what is applicable.
>
> An additional comment along these lines.
> > a. UA sends REGISTER to the proxy with a "outbound" tag in the  
> Supported header.
> ...
> > c. If the "outbound" tag is present in the 200 OK, and if the  
> transport is UDP, using the STUN keep alive, other connection based  
> transport using crlf keep alive.
>
> Step a) would really imply the originating UA MUST support both  
> keepalive mechanisms, and c) implies it MUST begin using the  
> appropriate one after 200 OK.  The usage is implied, not explicit,  
> which I believe is sufficient in this case.  Alternatively, the  
> usage could be made more explicit by listing the supported k-a  
> mechanisms in Supported exchange, or some such.  This should be  
> spelled out either way.
>
> -- Peter Blatherwick
>
>
>
>
> Jerry Yin <jerry.yin@yahoo.com>
> 19.09.07 16:40
>
>
>         To:        sip@ietf.org, fluffy@cisco.com, rohan@ekabal.com
>         cc:
>         Subject:        [Sip] Outbound-10 comments
>
>
>
> Hi Cullen and Rohan,
>
> In the draft, it requires the UA configure the next hop route  
> header with "keep-stun", "keep-crlf", or "timed-keepalive" tags.  
> This would cause some problems.
>
> 1. As an example, the route-set contains this route header as  
> indicated in section 9 example:
> Route: <sip:pri.example.com;lr;keep-stun>
> If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or  
> TLS, the keep-stun will be useless. Vice versa, if the  
> pri.example.com is resolved as UDP, and if "keep-crlf" was manually  
> configured, it is not working either.
>
> 2. Before sending the REGISTER request, the admin/or user does not  
> know what keep-alive mechanism the proxy (or edge proxy) supports.  
> Blindly configure the keep-stun, or keep-crlf would cause the  
> problem that the draft indicated itself in section 8: "the node  
> could be blacklisted for UDP traffic".
> The better approach is to let the UA and the proxy to negotiate,  
> not manually configure from UA side.
> a. UA sends REGISTER to the proxy with a "outbound" tag in the  
> Supported header.
> b. Proxy insert the "outbound" tag in the 200 OK, if the UA  
> indicated that it supports the outbound.
> c. If the "outbound" tag is present in the 200 OK, and if the  
> transport is UDP, using the STUN keep alive, other connection based  
> transport using crlf keep alive.
> There would be no way to mass up by configurations with this  
> approach. Let me know if I missed something.
>
> Regards,
> Jerry Yin
>
>
> Yahoo! oneSearch: Finally, mobile search that gives answers, not  
> web links. _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
--=_alternative 0031E48A852573A7_=-- --===============0507705657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0507705657==-- From sip-bounces@ietf.org Tue Dec 04 06:32:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzVzi-0007Ov-6z; Tue, 04 Dec 2007 06:31:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzVzg-0007Ol-FP for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 06:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzVzg-0007Od-61 for sip@ietf.org; Tue, 04 Dec 2007 06:31:16 -0500 Received: from submit01.sysedata.no ([195.159.29.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzVzd-0007Je-VY for sip@ietf.org; Tue, 04 Dec 2007 06:31:16 -0500 Received: from [82.196.214.14] (helo=[192.168.1.66]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1IzVzW-00073o-BD; Tue, 04 Dec 2007 12:31:06 +0100 Message-ID: <47553A7D.7010202@db.org> Date: Tue, 04 Dec 2007 12:31:09 +0100 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Rohan Mahy References: <46A52ACF.3030402@db.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Cullen Jennings , SIP IETF Subject: [Sip] Re: Comments on draft-ietf-sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline Rohan Mahy wrote: > Hi, > > All your comments have been addressed in outbound-11 as noted below. > thanks! > thanks, > -rohan > > On Jul 23, 2007, at 3:25 PM, Alfred E. Heggestad wrote: >> Comments on draft-ietf-sip-outbound-10 >> >> by Alfred E. Heggestad >> 23. July 2007 >> > >> > 12.2. SIP/SIPS URI Parameters >> > >> > Parameter Name Predefined Values Reference >> > ____________________________________________ >> > keep-crlf No [RFC AAAA] >> > keep-stun No [RFC AAAA] >> >> suggest to merge these two parameters to "keepalive" > > ack > outbound-11 says: 12.2. SIP/SIPS URI Parameters Parameter Name Predefined Values Reference ____________________________________________ keep No [RFC AAAA] however, since you have already published the draft with the "keep" parameter, I dont see any reason to change it now. /alfred _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 04 08:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzXdI-0001XU-0A; Tue, 04 Dec 2007 08:16:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzXdG-0001XH-LJ for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 08:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzXdG-0001X9-Be for sip@ietf.org; Tue, 04 Dec 2007 08:16:14 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzXdE-0005hk-8k for sip@ietf.org; Tue, 04 Dec 2007 08:16:14 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 44DF221F0D; Tue, 4 Dec 2007 14:13:44 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-db-475552881e2b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29AB521F09; Tue, 4 Dec 2007 14:13:44 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 14:13:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Tue, 4 Dec 2007 14:13:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: AcgsSaCFMdxh9wfFTeKGF2CITLPJSAAAZ63wAAashzgAGJzNMAJrlt8J References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><66cd252f0711202053x70902fe7nabea5bd31a6cfa74@mail.gmail.com><66cd252f0711202129x7967a4f3p7d29ffb3697e6cd6@mail.gmail.com><6C813C91-7A57-42F8-A22D-774F5A716EBF@nostrum.com> <3100473D52017B48B9068E079BE2A6E6029AC62C@ZMY16EXM67.ds.mot.com> From: "Christer Holmberg" To: "T Satyanarayana-A12694" , "Robert Sparks" X-OriginalArrivalTime: 04 Dec 2007 13:13:44.0031 (UTC) FILETIME=[7F082EF0:01C83677] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >This would mean a large change to existing parsers and formatters. And >also, the "escaping" and "unescaping" overheads. Existing parsers would work, in the sense that they would not report = error due to unallowed characters.=20 But, if you are interested in the actual escapted value you would of = course have to add the "unescaping" functionality. >Changing the header-value BNF may be more acceptable? Any solution which EXTENDS what we have today may cause problems with = existing parsers. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 21, 2007 11:13 PM To: Christer Holmberg; Robert Sparks Cc: sip List Subject: RE: [Sip] SIPit21: BNF future-proofing problem? Hi, Another alternative would be to define an escaping mechanism for quoted-strings in SIP messages, and require all characters not allowed by the header-value ABNF to be escaped. Regards, Christer ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wed 21/11/2007 15:33 To: Robert Sparks Cc: sip List Subject: RE: [Sip] SIPit21: BNF future-proofing problem? Hi, >So to restate the problem that was reported: > >Right now, extension-header does not allow a new header that contains a >quoted-string. > >We have defined extensions (and are likely to define new >ones) that use quoted-string (anything that uses name-addr for >instance). > >This inconsistency has caused interoperability problems in real >implementations. > >My original note was to suggest that we change extension-header to >actually allow the headers we're going to define. > >Christer's response could be read as a proposal to change >quoted- string to achieve the same goal. Yes. Unless someone can show a use-case where the x00-x20 characters would be needed, for backward compability reasons I think it's better to restrict quoted-string than to extend extension-header. Regards, Christer > > Hi, > > > > I am still a little unclear what Robert is proposing, but is there > > really a need to be able to use characters between x00 and > x20 in SIP > > messages? Characters between x21 and x7F, and between x80 > and xBF, are > > ok since they are covered by TEXT-UTF8char and UTF8-CONT. > > > > Regards, > > > > Christer > > > > > > ________________________________ > > > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: 21. marraskuuta 2007 7:30 > > To: Robert Sparks > > Cc: sip List > > Subject: Re: [Sip] SIPit21: BNF future-proofing problem? > > =20 > > =20 > > I think I did misread Robert's original email. I thought header > > values having quoted strings are currently not allowed and Robert > > wanted to change RFC2822. Now I realise that you can have > header field > > values with quoted string. Therefore I support the correction that > > Robert is proposing. > > =20 > > Hisham > > =20 > > =20 > > On 21/11/2007, Hisham Khartabil > > wrote: > > > > This is a big change if we do adopt it. It will > cause a lot of > > problem to parsers that handle extenion headers today and is not > > backwards compatible. Why isn't the extension header as is defined > > today not sufficient? > > =20 > > Hisham > > =20 > > =20 > > On 20/11/2007, Robert > > Sparks wrote: > > > > The BNF in 3261 says the following: > > =20 > > extension-header =3D header-name HCOLON > header-value > > header-value =3D *(TEXT-UTF8char / = UTF8-CONT > > / LWS) > > =20 > > This is intended to be the catch-all > field for all future > > extensions > > - older parsers working against this > BNF shouldn't barf > > when we introduce a new header field. > > =20 > > Now, we may have new fields in the > future that look like: > > =20 > > NewHeader =3D new-header-name HCOLON = quoted-string > > =20 > > And down inside quoted-string, we get: > > =20 > > quoted-string =3D SWS DQUOTE > *(qdtext / quoted-pair ) DQUOTE > > qdtext =3D LWS / %x21 / %x23-5B / > > %x5D-7E > > / UTF8-NONASCII > > quoted-pair =3D "\" (%x00-09 / %x0B-0C > > / %x0E-7F) > > =20 > > So, for instance, we could have inside > a quoted string the 2 byte > > sequence \ NULL > > =20 > > This does not parse against > header-value above... > > =20 > > Is this a problem? Some of the SIPit21 > participants argued that it > > is. > > =20 > > The projects I've been involved in > don't parse unknown headers and > > the stacks will just hand up an > unparsed bucket of bits (the only > > rules > > used are those necessary to identify > the next header-field > > starting). > > =20 > > Would it be worth the effort to make > the BNF reflect that rather > > than > > continuing with the incongruity that we > currently specify? > > =20 > > RjS > > =20 > > =20 > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the > core SIP Protocol > > Use sip-implementors@cs.columbia.edu > for questions on current sip > > Use sipping@ietf.org for new > developments on the application of sip > > =20 > > > > > > =20 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 04 10:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZg9-0004r9-It; Tue, 04 Dec 2007 10:27:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzZg8-0004qi-FE for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 10:27:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzZg8-0004qZ-5a for sip@ietf.org; Tue, 04 Dec 2007 10:27:20 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzZg5-0006SU-SG for sip@ietf.org; Tue, 04 Dec 2007 10:27:20 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB4FRFUs016308 for ; Tue, 4 Dec 2007 09:27:17 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 09:27:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 16:27:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 16:27:02 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019B7E52@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy Thread-Index: Acg2ih6i4UTKPgVSQf2WFbiy3Qsq9w== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 04 Dec 2007 15:27:04.0971 (UTC) FILETIME=[1FF6BDB0:01C8368A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Delivering request-URI and parameters to UAS via proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We have a couple of milestones that we generated as a result of discussion of=20 http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-0 1.txt Dec 2007 Delivering request-URI and parameters to UAS via proxy to WGLC =20 Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) =20 This work is currently stalled and the editor needs input. The document contains various example scenarios where a solution is required, for which there appears to be no dispute that a solution is needed. The document proposes one solution to resolve these example scenarios, but this solution is not gaining consensus. At least one other solution has been talked about, but there is no documentation on the table. This mail is to identify a deadline for other solutions to the example scenarios to be documented as internet drafts, showing how the solution works for those scenarios. This deadline is: January 11th 2008 It is appropriate fo these documents to identify any other scenarios where such a solution is appropriate. Any other input is also welcome in identifying other scenarios. If we have no such internet-drafts by this deadline, we will proceed with completing the solution we have. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 04 13:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc59-0001Ur-TI; Tue, 04 Dec 2007 13:01:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Izc58-0001Uf-8V for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:01:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc57-0001UT-T9 for sip@ietf.org; Tue, 04 Dec 2007 13:01:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izc57-0008JN-6H for sip@ietf.org; Tue, 04 Dec 2007 13:01:17 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5C59621CD0; Tue, 4 Dec 2007 18:58:26 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-83-47559542296e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3DCDB21CBD; Tue, 4 Dec 2007 18:58:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 18:58:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Tue, 4 Dec 2007 18:58:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delivering request-URI and parameters to UAS via proxy Thread-Index: Acg2ih6i4UTKPgVSQf2WFbiy3Qsq9wAAR3+U References: <5D1A7985295922448D5550C94DE29180019B7E52@DEEXC1U01.de.lucent.com> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 04 Dec 2007 17:58:26.0114 (UTC) FILETIME=[44BF3220:01C8369F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 In order to think about documenting "alternative solutions", I have a = question for clarifications regarding the scope of the problem we are = trying to solve. =20 The MECHANISM part of the draft says that a UA supporting the mechanism = would indicate it to the registrar, and the registrar would only use the = mechanism in case the UA has indicated support for it (that is also = shown in the example in the draft). It has also been claimed that this = would be backward compatible with an MGC which uses the R-URI to map to = ISUP Called Party number, because the MGC does not register so the = mechanism would not be used towards it.=20 =20 My question is: does this mean that the only entity allowed to use this = mechanism is the registrar, since the mechanism is used based on whether = the UA supports it or not?=20 =20 When reading the USE-CASE part of the draft, I would say that the answer = is "no". Because, as I understand the text, there could be non-registrar = entities in the path, which today normally would re-write the R-URI, but = would now instead use this mechanism. Is my understanding correct? =20 If so, my next question is: these non-registrar entities have no clue = about whether the terminating UA supports the mechanism or not, or = whether the call will be routed towards an MGC. So, what happens if the = request is routed towards an UA that has not indicated support, or = towards an MGC? The MGC may not be able to map the R-URI. =20 Regards, =20 Christer =20 =20 ________________________________ L=E4hett=E4j=E4: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] L=E4hetetty: ti 4.12.2007 16:27 Vastaanottaja: sip@ietf.org Aihe: [Sip] Delivering request-URI and parameters to UAS via proxy (As WG chair) We have a couple of milestones that we generated as a result of discussion of http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-0 1.txt Dec 2007 Delivering request-URI and parameters to UAS via proxy to WGLC=20 Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS)=20 This work is currently stalled and the editor needs input. The document contains various example scenarios where a solution is required, for which there appears to be no dispute that a solution is needed. The document proposes one solution to resolve these example scenarios, but this solution is not gaining consensus. At least one other solution has been talked about, but there is no documentation on the table. This mail is to identify a deadline for other solutions to the example scenarios to be documented as internet drafts, showing how the solution works for those scenarios. This deadline is: January 11th 2008 It is appropriate fo these documents to identify any other scenarios where such a solution is appropriate. Any other input is also welcome in identifying other scenarios. If we have no such internet-drafts by this deadline, we will proceed with completing the solution we have. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 04 23:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izloa-0002to-O3; Tue, 04 Dec 2007 23:24:52 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzloZ-0002tj-Rj for sip-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 23:24:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzloZ-0002tY-HR for sip@ietf.org; Tue, 04 Dec 2007 23:24:51 -0500 Received: from qmta01.emeryville.ca.mail.comcast.net ([76.96.30.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzloZ-0000x8-2f for sip@ietf.org; Tue, 04 Dec 2007 23:24:51 -0500 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id LkDX1Y00416AWCU0A0rz00; Wed, 05 Dec 2007 04:24:55 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id LsQt1Y0050umElk0800000; Wed, 05 Dec 2007 04:24:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=A1HwzCXZ3jIae6VPkOIA:9 a=tUX-LGfTrX8AbnLfDNEA:7 a=g848E745CBLMJAkbmATfL7f6viIA:4 a=TZm1MNU2oDwA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lB54OmTc016488 for ; Tue, 4 Dec 2007 23:24:48 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lB54OmtH016484; Tue, 4 Dec 2007 23:24:48 -0500 Date: Tue, 4 Dec 2007 23:24:48 -0500 Message-Id: <200712050424.lB54OmtH016484@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (brett@broadsoft.com) Subject: Re: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Brett Tate" However concerning things like To/From sip-uri's host, I assume that there will currently be poor interoperability if devices adjust things per section 2.2's flexibility (beyond hex case) within a transaction or dialog. To and From headers shouldn't be a problem because applications really shouldn't be comparing them; they should be treated as comments. IIRC, there is some circumstance during registration where URI equivalence is important, though. I haven't received any feedback concerning impacts of section 2.5.5. However I assume that they should not be considered equivalent to their IPv4 addresses from a SIP perspective. And other IPv6 addresses are also not equivalent to their IPv4 counterpart; for instance "::1" does not equal "127.0.0.1". That makes sense to me. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 12:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyNQ-0005J3-C8; Wed, 05 Dec 2007 12:49:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzyNP-0005Iu-Ic for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:49:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyNP-0005Im-96 for sip@ietf.org; Wed, 05 Dec 2007 12:49:39 -0500 Received: from out002.iad.hostedmail.net ([209.225.56.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzyNO-0001XJ-PY for sip@ietf.org; Wed, 05 Dec 2007 12:49:39 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out002.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 12:49:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Wed, 5 Dec 2007 12:49:41 -0500 Message-ID: In-Reply-To: <200712050424.lB54OmtH016484@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg29s54K2uSMgVsQq+p+ys7MgzBFwAbRvRQ From: "Brett Tate" To: , X-OriginalArrivalTime: 05 Dec 2007 17:49:43.0631 (UTC) FILETIME=[37BC5DF0:01C83767] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > However concerning things like To/From sip-uri's host,=20 > > I assume that there will currently be poor=20 > > interoperability if devices adjust things per=20 > > section 2.2's flexibility (beyond hex case)=20 > > within a transaction or dialog. >=20 > To and From headers shouldn't be a problem because=20 > applications really shouldn't be comparing them; they=20 > should be treated as comments. > IIRC, there is some circumstance during registration=20 > where URI equivalence is important, though. RFC 3261 still requires the To/From uri's to not change. However I agree that it won't be a problem if vendors have adjusted/deployed their implementations based upon rfc3261's comment that such a requirement is expected to be deprecated in the future or have accommodated the IPv6 address representation flexibility. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 13:18:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izyoz-0002xF-SD; Wed, 05 Dec 2007 13:18:09 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Izyoy-0002x2-Bj for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izyox-0002wt-VT for sip@ietf.org; Wed, 05 Dec 2007 13:18:07 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izyow-0003yr-3f for sip@ietf.org; Wed, 05 Dec 2007 13:18:07 -0500 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id lB5IGbU30986; Wed, 5 Dec 2007 10:16:38 -0800 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1187017D@zrc2hxm0.corp.nortel.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> <1ECE0EB50388174790F9694F77522CCF1187017D@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EC8E130-A3D9-426E-B22F-23F45568218C@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 5 Dec 2007 10:16:34 -0800 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: fluffy@cisco.com, Rohan Mahy , sip@ietf.org Subject: [Sip] Re: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My comments and a question or two inline. thanks, -rohan On Aug 3, 2007, at 4:20 PM, Francois Audet wrote: > Some more WGLC on sip-outbound-10 > --------------------------------- > > Section 4.4: change "timed-keepalives" to "time-keepalive" (there > are at > least 2 instances of > this mistake). fixed in -11 > ------- > > The example in section 9 should use TCP instead of of UDP, since > TCP is > preferred (as > discussed in section 14). Furthermore, if the UDP example is used, it > should show > the rport parameter in the Via header. I plan to completely revamp the example and will incorporate these comments. > It should be clarified that the last paragraph of 4.3 only applies to > UDP. ok, I added, then accidentally deleted this in -11. This is now fixed in my local copy. > ------ > > I would like to see more details in section 9 about how the "ob", > "rport" and Route and > Record-Route headers (i.e., including the keep-XXX parameter) are used > by a UA that > supports outbound procedures, when sending requests using Outbound > (like > INVITE for example). > > Also, it would be helpful to see an example where the outbound > proxy is > not co-located with the Registrar, so we could see how the Path header > is used, > including the "ob" parameter (as per the procedures of 5.1). This > stuff > is non-trivial > and would benefit greatly from an example flow (with the messages > content). > Distinguishing between 'ob' in Contact and in Path/Route seems > important. > > In other words, a flow (with messages) illustrating what an edge proxy > does for both > registration and for further requests such as INVITE I am going to completely rewrite the example based on your advice here. > ------ > > Finally, the procedures in 5.3 on "incoming" requests is not that > clear > on what it actually > mean "on the wire". It says the following: > > For an incoming request, the proxy removes > the Route header field value and forwards the request over the > 'logical flow' identified by the flow token, that is known to > deliver > data to the specific target UA instance. > > Does it just mean that the request will be forward on the same TCP or > UDP flow, and > that there is no additional requirements? correct > Nothing on the wire that will > show that outbound > is being used (Is the flow token supposed to be inserted by the > Proxy)? nothing on the wire > On that front, > message 8 in the example of section 9 has a flow token, where does it > come from? > This is very confusing since the Caller might not use Outbound, so > where > does this > token come from, and what it is used for in this example? How is the > token of the > Callee given to the Caller??? The existing example is wrong in many ways and will be completely replaced. > It is also no clear from the > example how the Caller knows to reattempt the INVITE to the secondary > proxy (wouldn't > this be handled in the terminating side's domain?). > > There is no description of UAS requirements in the draft. Does it mean > that there are none > whatsoever? (I'm talking about a UAS that is using outbound receiving > incoming requests). If > so, there should be a UAS section stating so. do you think Section 4 should have a separate subsection? All you need to do is leave your flow open and be prepared to receive messages over it. > Is it possible for example that incoming requests might be received by > the UAS on different > flows (because of reboot for example)? In the same session?? Yes. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 13:31:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izz14-0004xI-Pc; Wed, 05 Dec 2007 13:30:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Izz13-0004x3-79 for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:30:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izz12-0004wu-S6 for sip@ietf.org; Wed, 05 Dec 2007 13:30:36 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izz12-0000a2-9m for sip@ietf.org; Wed, 05 Dec 2007 13:30:36 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D272120D9F; Wed, 5 Dec 2007 19:28:52 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-e9-4756ede4ea3b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C0715207E8; Wed, 5 Dec 2007 19:28:52 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 19:28:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Dec 2007 19:28:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow-timer in requests Thread-Index: Acg3bK62Et1wzVycQYu9TRi3baxcJQ== From: "Christer Holmberg" To: , , "Niemi Aki (Nokia-NRC/Helsinki)" X-OriginalArrivalTime: 05 Dec 2007 18:28:52.0347 (UTC) FILETIME=[AFADFCB0:01C8376C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Subject: [Sip] Flow-timer in requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1262358338==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1262358338== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8376C.AF8FC8DF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8376C.AF8FC8DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As indicated in the meeting, I wonder what people think about allowing the Flow-timer parameter also in request messages. It would provide the following: 1) The UA can indicate the minimum keep-alive timer, which can be based on battery life, CPU power, or whatever... We also need some wording and guidance about what to do if the value in the response is too small for the UA. 2) The UA can indicate that it is able to perform keep-alives (similar to the "keepalive" option-tag), even if the UA does not support outbound, and/or if the registrar does not support outbound, or outbound is disabled for whatever other reason. Regards, Christer ------_=_NextPart_001_01C8376C.AF8FC8DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Flow-timer in requests

Hi,

As indicated in the meeting, I wonder = what people think about allowing the Flow-timer parameter also in = request messages. It would provide the following:

1) The UA can indicate the minimum = keep-alive timer, which can be based on battery life, CPU power, or = whatever... We also need some wording and guidance about what to do if = the value in the response is too small for the UA.

2) The UA can indicate that it is able = to perform keep-alives (similar to the "keepalive" = option-tag), even if the UA does not support outbound, and/or if the = registrar does not support outbound, or outbound is disabled for = whatever other reason.

Regards,

Christer

------_=_NextPart_001_01C8376C.AF8FC8DF-- --===============1262358338== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1262358338==-- From sip-bounces@ietf.org Wed Dec 05 13:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzAS-0004mU-P4; Wed, 05 Dec 2007 13:40:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzzAQ-0004lk-Qi for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:40:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzAQ-0004lV-Gf for sip@ietf.org; Wed, 05 Dec 2007 13:40:18 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzzAQ-0005uR-8M for sip@ietf.org; Wed, 05 Dec 2007 13:40:18 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB5Ido720556; Wed, 5 Dec 2007 18:39:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Dec 2007 12:39:27 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF139348DB@zrc2hxm0.corp.nortel.com> In-Reply-To: <3EC8E130-A3D9-426E-B22F-23F45568218C@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on sip-outbound-10 Thread-Index: Acg3azK734hDlCvNQHKUdqa05W7YJQAAfkmQ References: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> <1ECE0EB50388174790F9694F77522CCF1187017D@zrc2hxm0.corp.nortel.com> <3EC8E130-A3D9-426E-B22F-23F45568218C@ekabal.com> From: "Francois Audet" To: "Rohan Mahy" , "DRAGE, Keith (Keith)" X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: fluffy@cisco.com, sip@ietf.org Subject: [Sip] RE: WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Trimming all the resolved issues from the email.=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Wednesday, December 05, 2007 10:17 > To: Audet, Francois (SC100:3055) > Cc: Rohan Mahy; fluffy@cisco.com; sip@ietf.org > Subject: Re: WGLC comments on sip-outbound-10 > > > > Francois: > > > > There is no description of UAS requirements in the draft.=20 > Does it mean=20 > > that there are none whatsoever? (I'm talking about a UAS=20 > that is using=20 > > outbound receiving incoming requests). If so, there should be a UAS=20 > > section stating so. >=20 > do you think Section 4 should have a separate subsection? =20 > All you need to do is leave your flow open and be prepared to=20 > receive messages over it. I think the procedures for a standards track document makes it clear that we have to separate the UAS from the UAC from the Proxy = requirements. Yes. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 14:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izzf2-0005Ov-6s; Wed, 05 Dec 2007 14:11:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Izzf0-0005OX-3j for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 14:11:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izzez-0005Nh-NH for sip@ietf.org; Wed, 05 Dec 2007 14:11:53 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izzey-0004Ia-Pn for sip@ietf.org; Wed, 05 Dec 2007 14:11:53 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2007 11:11:51 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB5JBqst021005; Wed, 5 Dec 2007 11:11:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB5JBb7Z029450; Wed, 5 Dec 2007 19:11:52 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 11:11:50 -0800 Received: from [10.21.125.119] ([10.21.125.119]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 11:11:50 -0800 Message-ID: <4756F7F5.9040609@cisco.com> Date: Wed, 05 Dec 2007 14:11:49 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] I-D Action:draft-ietf-sip-dtls-srtp-framework-00.txt References: <1ECE0EB50388174790F9694F77522CCF13290B22@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1389A83F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1389A83F@zrc2hxm0.corp.nortel.com> X-OriginalArrivalTime: 05 Dec 2007 19:11:50.0586 (UTC) FILETIME=[B06E09A0:01C83772] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7228; t=1196881912; x=1197745912; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[Sip]=20I-D=20Action=3Adraft-ietf-sip-dtls-srtp-frame work-00.txt |Sender:=20; bh=u4Y7KI0SJnYdt0Jj5jJbAQLZ0lalq97Yk9XYMK4t+Ms=; b=qCRFYmnee1qd5fvpgouU3/i3oPXfRu7LhbiR015/beZjWRY9t6dJjO1VL6IvD2JHC/yOpxMx 19Nryj3+UzlD9yFiu24SK+hXLho3poxafUJnvkj/6YKapHsRNDyojoiY; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: sip@ietf.org, Hannes.Tschofenig@nsn.com, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616237653==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1616237653== Content-Type: multipart/alternative; boundary="------------080203030404070008010808" This is a multi-part message in MIME format. --------------080203030404070008010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The SDP Capability Negotiation part is fine albeit you could argue it would be cleaner to have the DTLS-SRTP related attributes encoded as attribute capabilities rather than as first-level attributes. -- Flemming Francois Audet wrote: > See below. > > >> -----Original Message----- >> From: jason.fischl@gmail.com [mailto:jason.fischl@gmail.com] >> On Behalf Of Jason Fischl >> Sent: Monday, December 03, 2007 16:07 >> To: Audet, Francois (SC100:3055) >> Cc: sip@ietf.org; Hannes.Tschofenig@nsn.com; >> ekr@networkresonance.com; Flemming Andreasen >> Subject: Re: [Sip] I-D >> Action:draft-ietf-sip-dtls-srtp-framework-00.txt >> >> On Nov 13, 2007 11:50 AM, Francois Audet wrote: >> >>> (copying Flemming) >>> >>> Good draft. Very helpful. >>> >>> On the SDP side of things. >>> >>> I didn't seen anything in the SDP format that specifically >>> >> indicated >> >>> in the offer that you are trying to setup DTLS-SRTP. >>> >>> >> This is signaled in the SDP with the token >> "UDP/TLS/RTP/SAVP". See >> http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dt >> ls-04.txt >> for more details. >> > > Ah.... Can you explicitly say that in the document? > I see there is a reference to this draft, but the document doesn't say > that it is used for that purpose. > > >>> Is the assumption that if there is no indication besides >>> >> the RTP/SAVP >> >>> in the tcap, that DTLS-SRTP may be negotiated, and that >>> >> therefore we >> >>> do not need an explicit indication that DTLS-SRTP is supported? >>> >>> >> More specifically, UDP/TLS/RTP/SAVP. to signal we're sending >> SRTP over DTLS. >> >> >>> Do we think it's good enough? In other words, is RTP/SAVP without >>> a=crypto or a=key-mgmt good enough to indicate DTLS-SRTP? >>> >> Or should we have another attribute? >> >> I think this is good enough. >> > > Agreed. > > >>> A side comment is that the example shows usage with >>> >> Best-Effort SRTP. >> >>> My take is that it could also be used in "DTLS-SRTP-always" mode by >>> having the m-line use UDP/TLS/RTP/AVP instead of RTP/AVP >>> >> and not using >> >>> a a=tcap/a=pcfg line. It would probably be worthwile to >>> >> describe it in the draft. >> >> I can add an example fragment to cover this case. >> > > That would be very useful. > > Thanks. > > --------------080203030404070008010808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The SDP Capability Negotiation part is fine albeit you could argue it would be cleaner to have the DTLS-SRTP related attributes encoded as attribute capabilities rather than as first-level attributes.

-- Flemming

Francois Audet wrote: 
See below. 

  
-----Original Message-----
From: jason.fischl@gmail.com [mailto:jason.fischl@gmail.com] 
On Behalf Of Jason Fischl
Sent: Monday, December 03, 2007 16:07
To: Audet, Francois (SC100:3055)
Cc: sip@ietf.org; Hannes.Tschofenig@nsn.com; 
ekr@networkresonance.com; Flemming Andreasen
Subject: Re: [Sip] I-D 
Action:draft-ietf-sip-dtls-srtp-framework-00.txt

On Nov 13, 2007 11:50 AM, Francois Audet <audet@nortel.com> wrote:
    
(copying Flemming)

Good draft. Very helpful.

On the SDP side of things.

I didn't seen anything in the SDP format that specifically 
      
indicated 
    
in the offer that you are trying to setup DTLS-SRTP.

      
This is signaled in the SDP with the token 
"UDP/TLS/RTP/SAVP". See 
http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dt
ls-04.txt
for more details.
    

Ah.... Can you explicitly say that in the document?
I see there is a reference to this draft, but the document doesn't say 
that it is used for that purpose.

  
Is the assumption that if there is no indication besides 
      
the RTP/SAVP 
    
in the tcap, that DTLS-SRTP may be negotiated, and that 
      
therefore we 
    
do not need an explicit indication that DTLS-SRTP is supported?

      
More specifically, UDP/TLS/RTP/SAVP. to signal we're sending 
SRTP over DTLS.

    
Do we think it's good enough? In other words, is RTP/SAVP without 
a=crypto or a=key-mgmt good enough to indicate DTLS-SRTP? 
      
Or should we have another attribute?
    
I think this is good enough.
    

Agreed.

  
A side comment is that the example shows usage with 
      
Best-Effort SRTP. 
    
My take is that it could also be used in "DTLS-SRTP-always" mode by 
having the m-line use UDP/TLS/RTP/AVP instead of RTP/AVP 
      
and not using 
    
a a=tcap/a=pcfg line. It would probably be worthwile to 
      
describe it in the draft.
    
I can add an example fragment to cover this case.
    

That would be very useful.

Thanks.
--------------080203030404070008010808-- --===============1616237653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1616237653==-- From sip-bounces@ietf.org Wed Dec 05 14:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izzga-0006La-8n; Wed, 05 Dec 2007 14:13:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IzzgY-0006L6-5o for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 14:13:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzgX-0006Km-PV for sip@ietf.org; Wed, 05 Dec 2007 14:13:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzzgX-0004R5-Ba for sip@ietf.org; Wed, 05 Dec 2007 14:13:29 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 05 Dec 2007 11:13:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB5JDSRw024260; Wed, 5 Dec 2007 11:13:28 -0800 Received: from dwingwxp01 (sjc-vpn4-897.cisco.com [10.21.83.128]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB5JDN1f011734; Wed, 5 Dec 2007 19:13:23 GMT From: "Dan Wing" To: , Date: Wed, 5 Dec 2007 11:13:23 -0800 Message-ID: <069501c83772$eac35b50$6e7a150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acg3cubjZCbtBfqaQoubFoytikhjbw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1349; t=1196882008; x=1197746008; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RFC4474=20and=20E.164=20 |Sender:=20; bh=DBV6nsNt4d2ZOzC1csBppFvG1aJhsek4fhcCXmECbeY=; b=ZcjjIcmltCXKussE+Q4CvhgWFn1yLwnDA309S/TYYnBhvljX/cZYJ92tX7GeL5RYHVCaB7/4 S/Mhq9/6Nx7QEe2p/E9kv2T1ptyels64xRGNWB8uravD7Bntn7Quo5yK; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Cullen Jennings' Subject: [Sip] RFC4474 and E.164 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jon, At the microphone I believe you were referring to section 11 of RFC4474. The first paragraph is relevant to today's discussion in SIP and I highlighted a specific sentence. The highlighted sentence does not consider session border controllers which, on today's deployments, _are_ the majority of cases (majority of call minutes and the majority of phone calls): 11. Identity and the TEL URI Scheme Since many SIP applications provide a Voice over IP (VoIP) service, telephone numbers are commonly used as identities in SIP deployments. In the majority of cases, this is not problematic for the identity ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mechanism described in this document. Telephone numbers commonly ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ appear in the username portion of a SIP URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). That username conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For this sort of SIP address-of-record, chicago.example.com is the appropriate signatory. The rest of the section is available at: http://tools.ietf.org/html/rfc4474#section-11 but discusses only the TEL URI (which has no domain name). We will need more text in Jason's document to discuss this in more detail. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 15:36:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00xo-0000NC-QE; Wed, 05 Dec 2007 15:35:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J00xn-0000IH-Bj for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 15:35:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00xn-0000G9-0Y for sip@ietf.org; Wed, 05 Dec 2007 15:35:23 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J00xm-00005M-Kd for sip@ietf.org; Wed, 05 Dec 2007 15:35:22 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB5KZ7sf024902; Wed, 5 Dec 2007 14:35:07 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:35:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 21:35:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Dec 2007 21:35:03 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019F6EBA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP location conveyance discussion Thread-index: Acg3flC5SxajYCwwSS611EwEPI9QEA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Dec 2007 20:35:05.0362 (UTC) FILETIME=[518C5F20:01C8377E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "James M. Polk" , Dean Willis Subject: [Sip] SIP location conveyance discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We failed to achieve agreement in the SIP WG on one of the issues for location conveyance. The chairs and AD considered we were unlikely to get rapid agreement on list and a further face-to-face discussion in Vancounver would be appropriate. Therefore we have:=20 Place: Salon 2=20 Time: 16:15=20 Date: Thursday 6th December Duration: 1 hour for those who are interested in resolving this problem. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 17:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02KI-00087V-7R; Wed, 05 Dec 2007 17:02:42 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J02KG-00087G-JN for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02KG-000875-9F for sip@ietf.org; Wed, 05 Dec 2007 17:02:40 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02KF-00009f-MG for sip@ietf.org; Wed, 05 Dec 2007 17:02:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2007 14:02:39 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB5M2dq6002256; Wed, 5 Dec 2007 14:02:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB5M2c1f024572; Wed, 5 Dec 2007 22:02:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:02:38 -0800 Received: from [10.21.94.113] ([10.21.94.113]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:02:38 -0800 Message-ID: <47572024.9000901@cisco.com> Date: Wed, 05 Dec 2007 17:03:16 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] Delivering request-URI and parameters to UAS via proxy References: <5D1A7985295922448D5550C94DE29180019B7E52@DEEXC1U01.de.lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 22:02:38.0605 (UTC) FILETIME=[8CB9A3D0:01C8378A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2643; t=1196892159; x=1197756159; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20Delivering=20request-URI=20and=20para meters=20to=20UAS=20via=20proxy |Sender:=20; bh=AvzhtGuB1/BL+qg8mK3710nRrktpxPbGX5+Z0a7p6ao=; b=pYsxqRlftTXr3cQgPfiu3pR4JRzAqEpelBdmf4x97Ir5Rrw9Uz8t68ppi32amKSqiWozbr82 bB5sKvOqldT9E0NxovOkDUDDJj4jNKZQoqY5/ge5Vu0ACy3RhdfvJUO2; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > > In order to think about documenting "alternative solutions", I have a > question for clarifications regarding the scope of the problem we are > trying to solve. > > The MECHANISM part of the draft says that a UA supporting the > mechanism would indicate it to the registrar, and the registrar would > only use the mechanism in case the UA has indicated support for it > (that is also shown in the example in the draft). For when a proxy is talking to a registered UA, yes. > It has also been > claimed that this would be backward compatible with an MGC which uses > the R-URI to map to ISUP Called Party number, because the MGC does > not register so the mechanism would not be used towards it. That is not the intent. The idea is, any proxy that is translating a request-URI, is doing so based on some kind of mapping table. There are many ways that this mapping table can get into the proxy: 1. dynamically through register 2. provisioned 3. through an enum query etc. If we take provisioning as an example (i.e., someone enters phone number routing rules via prefix matching rules), when those rules are provisioned, they would include a flag which says whether the destination is loose-route compliant. If they are loose route compliant, the proxy uses a Route header, else it uses r-uri translation as is currently done. > > My question is: does this mean that the only entity allowed to use > this mechanism is the registrar, since the mechanism is used based on > whether the UA supports it or not? As above, no. > > When reading the USE-CASE part of the draft, I would say that the > answer is "no". Because, as I understand the text, there could be > non-registrar entities in the path, which today normally would > re-write the R-URI, but would now instead use this mechanism. Is my > understanding correct? Yes. > > If so, my next question is: these non-registrar entities have no clue > about whether the terminating UA supports the mechanism or not, or > whether the call will be routed towards an MGC. So, what happens if > the request is routed towards an UA that has not indicated support, > or towards an MGC? The MGC may not be able to map the R-URI. Hopefully the above paragraph answers your question. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 17:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Vp-0000zC-SL; Wed, 05 Dec 2007 17:14:37 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J02Vo-0000yo-2E for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:14:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Vn-0000ye-Mv for sip@ietf.org; Wed, 05 Dec 2007 17:14:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J02Vn-0005xX-1Y for sip@ietf.org; Wed, 05 Dec 2007 17:14:35 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 05 Dec 2007 14:14:35 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB5MEYap019297; Wed, 5 Dec 2007 14:14:34 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB5MET77001380; Wed, 5 Dec 2007 22:14:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:14:31 -0800 Received: from [10.21.94.113] ([10.21.94.113]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:14:30 -0800 Message-ID: <475722EB.4030203@cisco.com> Date: Wed, 05 Dec 2007 17:15:07 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com> In-Reply-To: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 22:14:31.0000 (UTC) FILETIME=[35587D80:01C8378C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4691; t=1196892874; x=1197756874; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20SIPit21=3A=20BNF=20future-proofing=20problem? |Sender:=20; bh=XeF7tdqbvgy/ALDyiYSNsQDRExhq7qJG+6SpyYNIK8M=; b=Xu9VFU+KVFyPBys/aqwGt3qMnaPmFXKXBXxmsec3p4eisz0vAiOohCF2n9fhqYHobTGTszzv nzXckwzVasS3mcTkFtg20KBia+y3xcha5jgGl9HoCZLwxDYksmbhSLQzMKsFMkf/lfuOgw6gfW IRqx7sjASGIsXlt+9VKkWH3mk=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This strikes me as a problem in theory and not in practice. AFAICT, the only characters you can't use are ascii 0x00-0x19 (0x20 is space and is possible through the LWS construct as Christer pointed out). Is there a practical use case for any of these? They are: Decimal Octal Hex Binary Value ------- ----- --- ------ ----- 000 000 000 00000000 NUL (Null char.) 001 001 001 00000001 SOH (Start of Header) 002 002 002 00000010 STX (Start of Text) 003 003 003 00000011 ETX (End of Text) 004 004 004 00000100 EOT (End of Transmission) 005 005 005 00000101 ENQ (Enquiry) 006 006 006 00000110 ACK (Acknowledgment) 007 007 007 00000111 BEL (Bell) 008 010 008 00001000 BS (Backspace) 009 011 009 00001001 HT (Horizontal Tab) 010 012 00A 00001010 LF (Line Feed) 011 013 00B 00001011 VT (Vertical Tab) 012 014 00C 00001100 FF (Form Feed) 013 015 00D 00001101 CR (Carriage Return) 014 016 00E 00001110 SO (Shift Out) 015 017 00F 00001111 SI (Shift In) 016 020 010 00010000 DLE (Data Link Escape) 017 021 011 00010001 DC1 (XON) (Device Control 1) 018 022 012 00010010 DC2 (Device Control 2) 019 023 013 00010011 DC3 (XOFF)(Device Control 3) 020 024 014 00010100 DC4 (Device Control 4) 021 025 015 00010101 NAK (Negative Acknowledgement) 022 026 016 00010110 SYN (Synchronous Idle) 023 027 017 00010111 ETB (End of Trans. Block) 024 030 018 00011000 CAN (Cancel) 025 031 019 00011001 EM (End of Medium) 026 032 01A 00011010 SUB (Substitute) 027 033 01B 00011011 ESC (Escape) 028 034 01C 00011100 FS (File Separator) 029 035 01D 00011101 GS (Group Separator) 030 036 01E 00011110 RS (Request to Send)(Record Separator) 031 037 01F 00011111 US (Unit Separator) I don't think this is a real problem. -Jonathan R. Robert Sparks wrote: > The BNF in 3261 says the following: > > extension-header = header-name HCOLON header-value > header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) > > This is intended to be the catch-all field for all future extensions - > older parsers working against this BNF shouldn't barf > when we introduce a new header field. > > Now, we may have new fields in the future that look like: > > NewHeader = new-header-name HCOLON quoted-string > > And down inside quoted-string, we get: > > quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE > qdtext = LWS / %x21 / %x23-5B / %x5D-7E > / UTF8-NONASCII > quoted-pair = "\" (%x00-09 / %x0B-0C > / %x0E-7F) > > So, for instance, we could have inside a quoted string the 2 byte > sequence \ NULL > > This does not parse against header-value above... > > Is this a problem? Some of the SIPit21 participants argued that it is. > > The projects I've been involved in don't parse unknown headers and the > stacks will just hand up an unparsed bucket of bits (the only rules > used are those necessary to identify the next header-field starting). > > Would it be worth the effort to make the BNF reflect that rather than > continuing with the incongruity that we currently specify? > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 17:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02du-00006M-VN; Wed, 05 Dec 2007 17:22:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J02dt-0008Qd-5r for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:22:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02ds-0008P0-P5 for sip@ietf.org; Wed, 05 Dec 2007 17:22:56 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02ds-0002F6-Ei for sip@ietf.org; Wed, 05 Dec 2007 17:22:56 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Dec 2007 14:22:56 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB5MMs5u031529; Wed, 5 Dec 2007 14:22:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB5MMr1f013625; Wed, 5 Dec 2007 22:22:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:22:32 -0800 Received: from [10.21.94.113] ([10.21.94.113]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 14:22:31 -0800 Message-ID: <475724CE.9060905@cisco.com> Date: Wed, 05 Dec 2007 17:23:10 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] comments on draft-ietf-sip-record-route-fix-01 References: <47538524.1010205@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 22:22:31.0816 (UTC) FILETIME=[53EF3080:01C8378D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=834; t=1196893374; x=1197757374; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-record-route-f ix-01 |Sender:=20; bh=/lh4eCDYza33SIqQDb3R3L10++FeXICgYyAC1XJ5Ztg=; b=SzJJtMcsPA6aZdk82ftg/vL1eA8NALDSURfkIos7ehiXSm2OJzFQjakaqxbgW7pXachMs4HW FRhW25ndxWIiAYweNqOWQm346T7tZOXwPHjyR/ZzoEL1tYm+k/G0Nug4; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, according to the picture, there is NO IP CONNECTIVITY between endpoints. Only a SIP proxy connects them. Nothing will work. -Jonathan R. Dean Willis wrote: > > On Dec 2, 2007, at 10:25 PM, Jonathan Rosenberg wrote: > >> >> Section 3.1: this is an unrealistic use case. If this were the actual >> network, no media would be able to flow in the resulting session. >> > > well, MESSAGE methods and presence and probably MSRP would flow. Do you > mean to say SIP isn't useful for that sort of application? > > -- > Dean > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 19:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J049U-0000cp-4D; Wed, 05 Dec 2007 18:59:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J049S-0000cQ-Hb for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 18:59:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J049S-0000cE-7I for sip@ietf.org; Wed, 05 Dec 2007 18:59:38 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J049R-0000Pq-Rz for sip@ietf.org; Wed, 05 Dec 2007 18:59:38 -0500 Received: from [130.129.87.72] ([130.129.87.72]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB5NxYVi009039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Dec 2007 17:59:36 -0600 In-Reply-To: <475724CE.9060905@cisco.com> References: <47538524.1010205@cisco.com> <475724CE.9060905@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] comments on draft-ietf-sip-record-route-fix-01 Date: Wed, 5 Dec 2007 17:59:19 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org MESSAGE requires only a SIP proxy to span this. MSRP could easily have a parallel set of relays. This was actually a fairly typical enterprise network (at least through the mid 1990s), where there is no IP connectivity between the corp net and the Internet. All cross- net connectivity is provided by per-protocol proxies. I built up 50 or more enterprise networks with exactly this property. SIP is useful without media. You ever use Micosoft's IM client? -- dean On Dec 5, 2007, at 4:23 PM, Jonathan Rosenberg wrote: > Dean, according to the picture, there is NO IP CONNECTIVITY between > endpoints. Only a SIP proxy connects them. Nothing will work. > > Dean Willis wrote: >> On Dec 2, 2007, at 10:25 PM, Jonathan Rosenberg wrote: >>> >>> Section 3.1: this is an unrealistic use case. If this were the >>> actual network, no media would be able to flow in the resulting >>> session. >>> >> well, MESSAGE methods and presence and probably MSRP would flow. >> Do you mean to say SIP isn't useful for that sort of application? >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 21:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Ij-0004XN-0a; Wed, 05 Dec 2007 21:17:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J06Ih-0004SI-1b for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:17:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Ig-0004S9-O0 for sip@ietf.org; Wed, 05 Dec 2007 21:17:18 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J06Ig-0006oX-98 for sip@ietf.org; Wed, 05 Dec 2007 21:17:18 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2007 18:17:17 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB62HHTV012200; Wed, 5 Dec 2007 18:17:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB62H877026857; Thu, 6 Dec 2007 02:17:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 18:17:09 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.120.196]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 18:17:09 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Dec 2007 20:17:10 -0600 To: "DRAGE, Keith \(Keith\)" , From: "James M. Polk" In-Reply-To: <5D1A7985295922448D5550C94DE29180019F6EBA@DEEXC1U01.de.luce nt.com> References: <5D1A7985295922448D5550C94DE29180019F6EBA@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Dec 2007 02:17:09.0366 (UTC) FILETIME=[1ACED960:01C837AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1295; t=1196907437; x=1197771437; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20SIP=20location=20conveyance=20discussion |Sender:=20; bh=WjJUiEkffqVnBFtRFOfsKdHb1PNoNtiOH+ly/3XHvu0=; b=VPOgnjZc8sYHCY3RBiEtPf/+v5homjSS72IFm8NURCJj2VgOaJVWGEcJIQIYYL7x5YOMtAuK EVrcMQIZOHW67/qmIr7HHp3K/bAJ3kxaqUbl9sfVwQQkAkKbQPzHTSKp; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Dean Willis Subject: [Sip] Re: SIP location conveyance discussion X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe there were two points of contention at Monday's SIP meeting wrt Location Conveyance: -- the "recipient=" providing an expected result, given no security properties, and -- the granularity of error codes I'm not sure we're planning on talking about the first topic tomorrow, and I definitely consider it secondary to solving the error code issue. Now, folks admitted that they hadn't read the recent version of the ID, and the error section has changed a great deal. Thus, I ask that everyone attending tomorrow's face-to-face read section 3.4 , and all of section 5 to bring yourself up to speed on the current text. The ID is here http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-09.txt James At 02:35 PM 12/5/2007, DRAGE, Keith \(Keith\) wrote: >We failed to achieve agreement in the SIP WG on one of the issues for >location conveyance. > >The chairs and AD considered we were unlikely to get rapid agreement on >list and a further face-to-face discussion in Vancounver would be >appropriate. > >Therefore we have: > >Place: Salon 2 >Time: 16:15 >Date: Thursday 6th December >Duration: 1 hour > >for those who are interested in resolving this problem. > >Regards > >Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 21:36:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06aV-0001q4-JG; Wed, 05 Dec 2007 21:35:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J06aU-0001ps-9R for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 21:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06aT-0001pi-Vo for sip@ietf.org; Wed, 05 Dec 2007 21:35:41 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J06aS-0008H7-Er for sip@ietf.org; Wed, 05 Dec 2007 21:35:41 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA0C5216AC for ; Thu, 6 Dec 2007 03:35:39 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-3d-47575ffba575 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5945211B3 for ; Thu, 6 Dec 2007 03:35:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 03:35:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Dec 2007 03:35:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP gives Vancouver a new upscale yet casual room with a sexy New York feel Thread-Index: Acg3sK/iiJL/T7ncRYKt6RQLLFK3cw== From: "Christer Holmberg" To: X-OriginalArrivalTime: 06 Dec 2007 02:35:39.0604 (UTC) FILETIME=[B08FB940:01C837B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] SIP gives Vancouver a new upscale yet casual room with a sexy New York feel X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536902234==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0536902234== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C837B0.B04C21B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C837B0.B04C21B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of you who are in Vancouver, this is what SIP is all about: www.siplounge.com ------_=_NextPart_001_01C837B0.B04C21B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIP gives Vancouver a new upscale yet casual room with a sexy New = York feel

For those of you who are in Vancouver, = this is what SIP is all about:

www.siplounge.com

------_=_NextPart_001_01C837B0.B04C21B7-- --===============0536902234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0536902234==-- From sip-bounces@ietf.org Wed Dec 05 22:58:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07s4-00005g-7q; Wed, 05 Dec 2007 22:57:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J07s2-00005U-DD for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 22:57:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07s2-00005L-2L for sip@ietf.org; Wed, 05 Dec 2007 22:57:54 -0500 Received: from itclus2.sea5.speakeasy.net ([72.1.141.56] helo=EXCHANGE-BE2.speakeasy.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J07s1-0002bP-LB for sip@ietf.org; Wed, 05 Dec 2007 22:57:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Wed, 5 Dec 2007 19:57:52 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg29s54K2uSMgVsQq+p+ys7MgzBFwAbRvRQABXJFjA= References: <200712050424.lB54OmtH016484@dragon.ariadne.com> From: "Jane Jiang" To: "Brett Tate" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, I guess the purpose of this discussion is about this particular draft, which intends to correct some mistakes existing in some RFCs. I am wondering if you will want to discuss about the impacts of mapping between IPv6 address and IPv4 address? I feel like if we simply try to match the two from each other, we will not be able to maintain the original design beauties behind each address structure. Correct me if I am wrong. Best regards, Jane D. Jiang -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: Wednesday, December 05, 2007 9:50 AM To: Dale.Worley@comcast.net; sip@ietf.org Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 > > However concerning things like To/From sip-uri's host, I assume that > > there will currently be poor interoperability if devices adjust=20 > > things per section 2.2's flexibility (beyond hex case) within a=20 > > transaction or dialog. >=20 > To and From headers shouldn't be a problem because applications really > shouldn't be comparing them; they should be treated as comments. > IIRC, there is some circumstance during registration where URI=20 > equivalence is important, though. RFC 3261 still requires the To/From uri's to not change. However I agree that it won't be a problem if vendors have adjusted/deployed their implementations based upon rfc3261's comment that such a requirement is expected to be deprecated in the future or have accommodated the IPv6 address representation flexibility. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 05 23:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J08P3-0004pD-2L; Wed, 05 Dec 2007 23:32:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J08P1-0004oy-9F for sip-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 23:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J08P0-0004om-VS for sip@ietf.org; Wed, 05 Dec 2007 23:31:58 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J08Oz-0007I0-Ed for sip@ietf.org; Wed, 05 Dec 2007 23:31:58 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 5 Dec 2007 23:31:57 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 5 Dec 2007 23:31:57 -0500 From: Hadriel Kaplan To: "sip@ietf.org" Date: Wed, 5 Dec 2007 23:33:01 -0500 Subject: RE: [Sip] SIP gives Vancouver a new upscale yet casual room with a sexy New York feel Thread-Topic: [Sip] SIP gives Vancouver a new upscale yet casual room with a sexy New York feel Thread-Index: Acg3sK/iiJL/T7ncRYKt6RQLLFK3cwAD+t9g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2000957858==" Errors-To: sip-bounces@ietf.org --===============2000957858== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC302738BBB8Dmailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC302738BBB8Dmailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oh sure they talk "open" kitchen concept, but I note they have walls and a = door and you need to make reservations, not to mention they bill for it. A= nd I'm sure despite their claim of "direct" interaction with the chef, I'm = sure there are servers in the middle handling the real meal. At least they= realize that "[m]music is a large part of the SIP culture". -hadriel ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, December 05, 2007 9:36 PM To: sip@ietf.org Subject: [Sip] SIP gives Vancouver a new upscale yet casual room with a sex= y New York feel For those of you who are in Vancouver, this is what SIP is all about: www.siplounge.com --_000_E6C2E8958BA59A4FB960963D475F7AC302738BBB8Dmailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIP gives Vancouver a new upscale yet casual room with a sexy New Yo= rk feel

Oh sure they talk “open” kitchen concept, but I note they have walls and a door and you need to make reservations, not to mention they bill for it.  And I’m sure des= pite their claim of “direct” interaction with the chef, I’m su= re there are servers in the middle handling the real meal.  At least they realize that “[m]music is a large part of the SIP culture”.

-hadriel

 

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Wednesday, December 05= , 2007 9:36 PM
To: sip@ietf.org
Subject: [Sip] SIP gives Vancouver a new upscale yet casual room with a sexy = New York feel

 

 

For those of you who are in Vancou= ver, this is what SIP is all about:

www.siplounge.com

--_000_E6C2E8958BA59A4FB960963D475F7AC302738BBB8Dmailacmepacke_-- --===============2000957858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2000957858==-- From sip-bounces@ietf.org Thu Dec 06 02:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0BVQ-0004PC-7i; Thu, 06 Dec 2007 02:50:48 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0BVM-00047T-UG for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 02:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0BVE-0003ET-Bv; Thu, 06 Dec 2007 02:50:36 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0BV9-0008Pv-U8; Thu, 06 Dec 2007 02:50:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CFF0332896; Thu, 6 Dec 2007 07:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J0BUf-0000xG-KD; Thu, 06 Dec 2007 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Dec 2007 02:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-fork-loop-fix-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-06.txt Pages : 22 Date : 2007-11-03 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-fork-loop-fix-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-06024339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-06024339.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Dec 06 13:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LQE-0006IT-NF; Thu, 06 Dec 2007 13:26:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0LQD-0006IN-Og for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 13:26:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LQD-0006IF-E6 for sip@ietf.org; Thu, 06 Dec 2007 13:26:05 -0500 Received: from out003.iad.hostedmail.net ([209.225.56.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LQD-0003eY-4f for sip@ietf.org; Thu, 06 Dec 2007 13:26:05 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out003.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 13:26:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Thu, 6 Dec 2007 13:26:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg29s54K2uSMgVsQq+p+ys7MgzBFwAbRvRQABXJFjAAGp63IA== From: "Brett Tate" To: "Jane Jiang" , X-OriginalArrivalTime: 06 Dec 2007 18:26:10.0218 (UTC) FILETIME=[7974D0A0:01C83835] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I guess the purpose of this discussion is about this=20 > particular draft, which intends to correct some mistakes=20 > existing in some RFCs. Yes; the draft is expanding beyond the current ABNF fix to also correct or more clearly document other IPv6 areas of rfc3261. > I am wondering if you will want to discuss about the impacts=20 > of mapping between IPv6 address and IPv4 address? I'm not sure which aspect of mapping you are mentioning. Draft-ietf-sipping-v6-transition and draft-ietf-sipping-ipv6-torture-tests discuss some of the potential issues. > I feel like if we simply try to match the two from each=20 > other, we will not be able to maintain the original design=20 > beauties behind each address structure. Correct me if I am wrong. I'm not sure that I understand the matching comment. The current understanding is that an IPv6 address does not equal an IPv4 address from a SIP equality perspective. However there are obviously situations/services on a device where they might be treated the same: identity, access control, etcetera. There are situations where an IPv6 address contains an IPv4 address. However I currently doubt that we need to discuss the matter beyond highlighting such an address concerning equality and maybe additionally 503, looping, downgrading to IPv4, etcetera. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 15:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Muv-000265-Vo; Thu, 06 Dec 2007 15:01:53 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Muu-0001x0-Il for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 15:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Muu-0001sD-3h for sip@ietf.org; Thu, 06 Dec 2007 15:01:52 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Mut-0003xO-Qj for sip@ietf.org; Thu, 06 Dec 2007 15:01:52 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB6K1ph5002191 for ; Thu, 6 Dec 2007 14:01:51 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 14:01:51 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 21:01:48 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Dec 2007 21:01:47 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019F7218@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-rph-new-namespaces-01 Thread-index: Acg4QtU3MT60QKGIQMqWl2Dmr6/oCw== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 06 Dec 2007 20:01:49.0140 (UTC) FILETIME=[D61ED140:01C83842] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] draft-ietf-sip-rph-new-namespaces-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We working group last called this a few weeks back. I have been checking the revised version, and it seems to me that all the comments have been addressed. Does anyone else have any issues to raise on this document. I am starting to prepare the IESG publication request, and it would be helpful to know if more discussion is needed way before I finish this. In the absence of response I will be declaring this document done, bar the normal checks I do before the publish request in order to get this document into a format for IESG. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 15:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0N2C-00088J-Nj; Thu, 06 Dec 2007 15:09:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0N2B-00085a-1b for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 15:09:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0N2A-00083D-Mb for sip@ietf.org; Thu, 06 Dec 2007 15:09:22 -0500 Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0N2A-0002fs-Cf for sip@ietf.org; Thu, 06 Dec 2007 15:09:22 -0500 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id MY8y1Y00M0xGWP80500B00; Thu, 06 Dec 2007 20:09:21 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA12.westchester.pa.mail.comcast.net with comcast id MY9M1Y00J0umElk0300000; Thu, 06 Dec 2007 20:09:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=sI1JDbO7msgA:10 a=f1qmhUhjCzO5guzP31gA:9 a=UCEvVeopH8eQdhtYLt0A:7 a=87OmJYHsmr0yb2RvVnUdP0voWzsA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lB6K9LTc029181 for ; Thu, 6 Dec 2007 15:09:21 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lB6K9LUw029177; Thu, 6 Dec 2007 15:09:21 -0500 Date: Thu, 6 Dec 2007 15:09:21 -0500 Message-Id: <200712062009.lB6K9LUw029177@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <475722EB.4030203@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com> <475722EB.4030203@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg This strikes me as a problem in theory and not in practice. AFAICT, the only characters you can't use are ascii 0x00-0x19 (0x20 is space and is possible through the LWS construct as Christer pointed out). Is there a practical use case for any of these? They are: HT (horizontal tab) should be included, but that's also in LWS. As for the remaining characters, I don't think that anyone has ever *intended* that they be used in SIP headers, and their inclusion in quoted-pair was a typographical error. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 16:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OVJ-0002UU-0G; Thu, 06 Dec 2007 16:43:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0OVH-0002Qm-Ff for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 16:43:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OVH-0002QG-4Z for sip@ietf.org; Thu, 06 Dec 2007 16:43:31 -0500 Received: from mail87.messagelabs.com ([216.82.250.19]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0OVF-0002Ri-Gw for sip@ietf.org; Thu, 06 Dec 2007 16:43:31 -0500 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-87.messagelabs.com!1196977403!41594045!2 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 27105 invoked from network); 6 Dec 2007 21:43:25 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 6 Dec 2007 21:43:25 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.0/Switch-3.3.0) with ESMTP id lB6LhpCB005610 for ; Thu, 6 Dec 2007 16:43:53 -0500 In-Reply-To: <5D1A7985295922448D5550C94DE29180019F7218@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces-01 MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 6 Dec 2007 16:43:18 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 12/06/2007 04:43:37 PM, Serialize complete at 12/06/2007 04:43:37 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591117288==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0591117288== Content-Type: multipart/alternative; boundary="=_alternative 00775159852573A9_=" This is a multipart message in MIME format. --=_alternative 00775159852573A9_= Content-Type: text/plain; charset="US-ASCII" I read it and it looked fine to me. Janet "DRAGE, Keith \(Keith\)" wrote on 12/06/2007 03:01:47 PM: > (As WG chair) > > We working group last called this a few weeks back. > > I have been checking the revised version, and it seems to me that all > the comments have been addressed. > > Does anyone else have any issues to raise on this document. I am > starting to prepare the IESG publication request, and it would be > helpful to know if more discussion is needed way before I finish this. > > In the absence of response I will be declaring this document done, bar > the normal checks I do before the publish request in order to get this > document into a format for IESG. > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 00775159852573A9_= Content-Type: text/html; charset="US-ASCII"

I read it and it looked fine to me.

Janet

"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> wrote on 12/06/2007 03:01:47 PM:

> (As WG chair)
>
> We working group last called this a few weeks back.
>
> I have been checking the revised version, and it seems to me that all
> the comments have been addressed.
>
> Does anyone else have any issues to raise on this document. I am
> starting to prepare the IESG publication request, and it would be
> helpful to know if more discussion is needed way before I finish this.
>
> In the absence of response I will be declaring this document done, bar
> the normal checks I do before the publish request in order to get this
> document into a format for IESG.
>
> Regards
>
> Keith
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
 --=_alternative 00775159852573A9_=-- --===============0591117288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0591117288==-- From sip-bounces@ietf.org Thu Dec 06 18:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QHh-00082J-DO; Thu, 06 Dec 2007 18:37:37 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0QHf-0007zk-RT for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 18:37:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QHf-0007zc-Hw for sip@ietf.org; Thu, 06 Dec 2007 18:37:35 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QHd-0004wl-Bj for sip@ietf.org; Thu, 06 Dec 2007 18:37:35 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Thu, 6 Dec 2007 18:37:33 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 6 Dec 2007 18:37:32 -0500 From: Hadriel Kaplan To: "sip@ietf.org" Date: Thu, 6 Dec 2007 18:38:36 -0500 Thread-Topic: INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Sip] INFO use-cases X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Howdy, Jonathan asked for use-cases for what types of things would need an in-dial= og SIP message for user-user communication, vs. should be done either out o= f dialog or in the media plane. If the only use-case is DTMF, then we coul= d just document the DTMF negotiation/use only and not have to create a gene= ral info-events framework. That seems a very reasonable argument to me. I= also don't want to do work for no use. There is a counter-argument that there are proprietary uses of INFO in the = wild, and that a framework for negotiation at least removes the manual conf= iguration of vendor-specific profiles, which is a problem of interop today = - even if the IETF should not bless/document the specific use cases themsel= ves. But that would make the draft a very different one than it currently = is as well, and I will ask that in a separate email thread. The chairs have asked for 3 use cases, and I assume they mean 3 NEW use cas= es (we already have 3 RFCs which use INFO, as well as DTMF). I am not sure= if they mean potential future use-cases, or current use-cases (i.e., alrea= dy implemented). Can I get a clarification on that? So anyway, taking the shot-gun approach, here's a first go at some use-case= s, and my personal take on whether they should be in INFO vs. SUB/NOT vs. m= edia-plane, FWIW. [apologize for formatting ugliness] /*************** * Already standardized use-cases: ***************/ 1) SIP-T/ISUP/QSIG/PSTN -Documented in RFC 3372 and RFC 4497. 2) ECMA TR/87 uaCSTA -Uses INFO to send ECMA-323 XML for monitoring and controlling phon= es from a PC. 3) Sending media server control commands. -Documented in RFC4722 MSCML. /**************** * Use-cases that I think are potentially/possibly valid for INFO: ****************/ 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you se= nd me John's vcard?", Bob clicks something and voila it's sent. -Alternatives: send a re-Invite or Update with a Call-Info, with ei= ther a URL reference, data URI, or MIME and CID URL. -Counter-argument: IMO this type of data really belongs in MIME for= a number of reasons, including length is less restricted for mime attachme= nts; one AD has said the Data URL may be deprecated. And sending a re-Invi= te for this purpose seems odd. -Also, the Call-Info header is really about the caller or callee, a= nd thus Bob shouldn't be sending me John's vcard info in it technically. T= hat may sound like a nit, but UA's may well store the call-info vcards into= their address-books automatically and so tie it to the wrong user/call. -Pros of using INFO: it's explicit what you're doing when you send = the vcard, and you can send it knowing the other end can accept it, and you= can send it based on user input. 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an icon t= hat represents himself, sends it when he picks up the phone. -Alternatives: send a 200ok, re-Invite, or Update with call-info, w= hich explicitly has a type for icon. -Counter-argument: same as for vcard, plus with call-info there is = no way to know which picture format the far-end supports a priori. With a = supported-package negotiation one could know. 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey let= 's have a con call at time X", clicks and voila his phone sends a vcalendar= . -Whether the vcalendar is related to the session or not and thus wh= ether it should be sent in an in-dialog request or not is certainly debatab= le. Message method can already be used for this anyway. 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for more = info or a datasheet and Bob sends a URL for Alice to open with her web-brow= ser. -One could also argue this is just making SIP the new SMTP, or this= should be sent using MESSAGE (which really is the new SMTP). 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice does = a sip-traceroute to figure out the path to Bob, by sending Info with an inc= rementing max-forwards type header starting at 0 (but not really max-forwar= ds), with a sip-frag type response body or some such. -It's debatable if certain types of B2BUA's (ie, SBCs) would ever a= llow this type of thing to happen, due to security concerns, but I think th= ey may do it at domain boundary hops. I think this is a reasonable use for= INFO though, maybe. 6) Sending geo-location information after call establishment. Alice calls = Bob, a hotel receptionist. Alice asks for directions to hotel, clicks butt= on and sends him location info of her phone (or Bob clicks button and sends= her his location). -The location conveyance draft specifically calls out INFO as accep= table for geo-loc info. Whether this is a real use-case is debatable, and = obviously it could be done with a sub/not. 7) Sending softkey-labels (not digit-match maps, but rather softkey button = labels). Alice calls her vmail server. Vmail server sends softkey-labels = for the menu items available in the response, Alice presses softkeys and se= nds them in INFO. -This could (and maybe should) be done with sub/not, a la KPML, whe= re the vmail server sends the softkey labels in the Subscribe, UA sends but= tons pressed in Notifies. But this is similar to the DTMF use case so may = well have the same benefit of lower overhead since buttons are rarely press= ed. 8) Sending a screen-pop-up message, e.g., "Do you want to continue with thi= s session?" -There is a patent for doing screen pop-ups using INFO. I guess Al= ert-Info could be used for this, but it's not clear it should? /***************** * Use-cases which have been proposed by others or even implemented, * which are dubious for INFO (IMHO): *****************/ 1) Sending RTP/RTCP statistics during call. -There is an implementation of this, and the rationale is the signa= ling plane box that wants this info is not actually the media plane box tha= t gets RTCP. Again this could (and IMO should) be done with sub/not, so it= can get stats after the call is over, and since it will probably want peri= odic reports the overhead of the Subscribe should be dwarfed by the number = of Notifies. 2) Sending access-location information after call establishment. -There is a P-Access-Network-Info header, and some have proposed to= send an update for it as a phone roams access points or cells. But I thin= k this is an odd thing to do inside an Invite session, vs. in a sub/not or = Register (and besides half the time the network inserts this header, not th= e UA). 3) Sending media-control indications (ie, remote-control "play/pause/etc.") -This is done today by at least one vendor, but is debatable if it'= s the right model. The argument is it's like SDP re-Invite for hold, excep= t at a media content layer above RTP, so not done in RTCP nor SDP. 4) Sending video fast update command -This is an informational draft, which documents what has been impl= emented, but states it should really be done in the media plane. 5) Sending peripheral control commands (ie, USB commands) -There is actually a patent on this, amazingly. Someone thinks it = makes sense to create a SIP session to your laptop, or vice-versa, and then= send USB commands inside MIME in INFO messages. Methinks this should be m= edia-plane, if anything. 6) Sending charging information for a call (i.e., minutes remaining or cost= so far). -There was a proposal to use this for Advice of Charge information = in TISPAN. IMO it should be a sub/not though, as they want this to survive= the Invite session. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 18:45:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QOx-0007xi-Hz; Thu, 06 Dec 2007 18:45:07 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0QOw-0007xb-K4 for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 18:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QOw-0007xS-AN for sip@ietf.org; Thu, 06 Dec 2007 18:45:06 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QOv-0005gE-PV for sip@ietf.org; Thu, 06 Dec 2007 18:45:06 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lB6NiJHj028074; Thu, 6 Dec 2007 17:44:19 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 17:44:19 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 00:44:16 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-rph-new-namespaces-01 Date: Fri, 7 Dec 2007 00:44:13 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019F722E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180019F7218@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-rph-new-namespaces-01 Thread-index: Acg4QtU3MT60QKGIQMqWl2Dmr6/oCwAGL9sg References: <5D1A7985295922448D5550C94DE29180019F7218@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 06 Dec 2007 23:44:16.0847 (UTC) FILETIME=[E9F945F0:01C83861] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In my initial review of the document prior to submission, I have identified the following points that are slightly more than editorial. 1) I don't believe we need the abbreviation "RPH" at all. One of the major usages is in conjunction with the word "namespace" and the correct name of the namespace is the "Resource-Priority namespace" not the "Resource-Priority header namespace". I would prefer to do what RFC 4412 does which is in the IANA section and at the first instance in the document refer to the full name, and just use "namespace" elsewhere. 2) Change abstract to: This document creates additional Session Initiation Protocol=20 Resource-Priority namespaces, and places these namespaces in the IANA register. =20 3) Section 2: Change: This MAY change in future efforts. To: Other namespace definitions in the future could change this. Reason: Inappropriate usage of RFC 2119 language. 4) RFC 4412 states: o A namespace may either reference an existing list of priority values or define a new finite list of priority values in relative priority order for IANA registration within the sip-parameters Resource-Priority priority-values registry. New priority-values SHOULD NOT be added to a previously IANA-registered list associated with a particular namespace, as this may cause interoperability problems. Unless otherwise specified, it is assumed that all priority values confer higher priority than requests without a priority value. The multiple namespaces defined in this document all use the same finite list of priority values. Why do we need multiple new entries within the Resource-Priority Priority-values registry, rather than just reuse the same one. NITS: 1) Change section 1 from Each will be RFC 4412 defined as preemption=20 based in nature, and will have the same 9 priority-values.=20 To=20 Each will be preemption=20 in nature, as defined in RFC 4412, and will have the same 9 priority-values.=20 2) Change section 1 From DISA has a requirement to be able to assign different RPH namespaces to different units of differing sizes throughout their networks.=20 Examples of this may be To=20 DISA has a requirement to be able to assign different Resource-Priority namespaces to different units of differing sizes throughout their networks.=20 Examples of this can be Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Thursday, December 06, 2007 8:02 PM > To: sip@ietf.org > Subject: [Sip] draft-ietf-sip-rph-new-namespaces-01 >=20 > (As WG chair) >=20 > We working group last called this a few weeks back. >=20 > I have been checking the revised version, and it seems to me=20 > that all the comments have been addressed. >=20 > Does anyone else have any issues to raise on this document. I=20 > am starting to prepare the IESG publication request, and it=20 > would be helpful to know if more discussion is needed way=20 > before I finish this. >=20 > In the absence of response I will be declaring this document=20 > done, bar the normal checks I do before the publish request=20 > in order to get this document into a format for IESG. >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 19:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RNm-0002JZ-1q; Thu, 06 Dec 2007 19:47:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0RNj-00023C-Ug for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 19:47:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RNj-000234-Kk for sip@ietf.org; Thu, 06 Dec 2007 19:47:55 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0RNh-0001cX-Sm for sip@ietf.org; Thu, 06 Dec 2007 19:47:55 -0500 X-VirusChecked: Checked X-Env-Sender: sam.ganesan@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1196988472!20974450!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 30417 invoked from network); 7 Dec 2007 00:47:52 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-119.messagelabs.com with SMTP; 7 Dec 2007 00:47:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lB70lqRD015548 for ; Thu, 6 Dec 2007 17:47:52 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB70lpHn017437 for ; Thu, 6 Dec 2007 18:47:51 -0600 (CST) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB70lnif017420 for ; Thu, 6 Dec 2007 18:47:50 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] INFO use-cases Date: Thu, 6 Dec 2007 19:46:00 -0500 Message-ID: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO use-cases thread-index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/ References: From: "Ganesan Sam-W00184" To: "Hadriel Kaplan" , X-CFilter-Loop: Reflected X-Spam-Score: -2.2 (--) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688191055==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0688191055== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8386A.CA2EC6BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8386A.CA2EC6BB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also know of a use case where video npt bookmarks are sent over INFO = across the SIP path while using SIP for video stream set up. Tispan 3 = is actually writing specs on this and so is ATIS... =20 =20 =20 Sam ________________________________ From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thu 12/6/2007 6:38 PM To: sip@ietf.org Subject: [Sip] INFO use-cases Howdy, Jonathan asked for use-cases for what types of things would need an = in-dialog SIP message for user-user communication, vs. should be done = either out of dialog or in the media plane. If the only use-case is = DTMF, then we could just document the DTMF negotiation/use only and not = have to create a general info-events framework. That seems a very = reasonable argument to me. I also don't want to do work for no use. There is a counter-argument that there are proprietary uses of INFO in = the wild, and that a framework for negotiation at least removes the = manual configuration of vendor-specific profiles, which is a problem of = interop today - even if the IETF should not bless/document the specific = use cases themselves. But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread. The chairs have asked for 3 use cases, and I assume they mean 3 NEW use = cases (we already have 3 RFCs which use INFO, as well as DTMF). I am = not sure if they mean potential future use-cases, or current use-cases = (i.e., already implemented). Can I get a clarification on that? So anyway, taking the shot-gun approach, here's a first go at some = use-cases, and my personal take on whether they should be in INFO vs. = SUB/NOT vs. media-plane, FWIW. [apologize for formatting ugliness] /*************** * Already standardized use-cases: ***************/ 1) SIP-T/ISUP/QSIG/PSTN -Documented in RFC 3372 and RFC 4497. 2) ECMA TR/87 uaCSTA -Uses INFO to send ECMA-323 XML for monitoring and controlling = phones from a PC. 3) Sending media server control commands. -Documented in RFC4722 MSCML. /**************** * Use-cases that I think are potentially/possibly valid for INFO: ****************/ 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you = send me John's vcard?", Bob clicks something and voila it's sent. -Alternatives: send a re-Invite or Update with a Call-Info, with = either a URL reference, data URI, or MIME and CID URL. -Counter-argument: IMO this type of data really belongs in MIME = for a number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd. -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call. -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input. 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone. -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon. -Counter-argument: same as for vcard, plus with call-info there = is no way to know which picture format the far-end supports a priori. = With a supported-package negotiation one could know. 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey = let's have a con call at time X", clicks and voila his phone sends a = vcalendar. -Whether the vcalendar is related to the session or not and thus = whether it should be sent in an in-dialog request or not is certainly = debatable. Message method can already be used for this anyway. 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser. -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP). 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such. -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe. 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location). -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not. 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO. -This could (and maybe should) be done with sub/not, a la KPML, = where the vmail server sends the softkey labels in the Subscribe, UA = sends buttons pressed in Notifies. But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed. 8) Sending a screen-pop-up message, e.g., "Do you want to continue with = this session?" -There is a patent for doing screen pop-ups using INFO. I guess = Alert-Info could be used for this, but it's not clear it should? /***************** * Use-cases which have been proposed by others or even implemented, * which are dubious for INFO (IMHO): *****************/ 1) Sending RTP/RTCP statistics during call. -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies. 2) Sending access-location information after call establishment. -There is a P-Access-Network-Info header, and some have proposed = to send an update for it as a phone roams access points or cells. But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA). 3) Sending media-control indications (ie, remote-control = "play/pause/etc.") -This is done today by at least one vendor, but is debatable if = it's the right model. The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor SDP. 4) Sending video fast update command -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane. 5) Sending peripheral control commands (ie, USB commands) -There is actually a patent on this, amazingly. Someone thinks = it makes sense to create a SIP session to your laptop, or vice-versa, = and then send USB commands inside MIME in INFO messages. Methinks this = should be media-plane, if anything. 6) Sending charging information for a call (i.e., minutes remaining or = cost so far). -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C8386A.CA2EC6BB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Sip] INFO use-cases=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I also know = of a use case where video npt bookmarks are sent over INFO across the = SIP path while using SIP for video stream set up.  Tispan 3 is = actually writing specs on this and so is ATIS... 
=0A=
 
=0A=
 
=0A=
Sam
=0A=

=0A=
=0A= From: Hadriel Kaplan = [mailto:HKaplan@acmepacket.com]
Sent: Thu 12/6/2007 6:38 = PM
To: sip@ietf.org
Subject: [Sip] INFO = use-cases

=0A=
=0A=

Howdy,
Jonathan asked for use-cases for what types = of things would need an in-dialog SIP message for user-user = communication, vs. should be done either out of dialog or in the media = plane.  If the only use-case is DTMF, then we could just document = the DTMF negotiation/use only and not have to create a general = info-events framework.  That seems a very reasonable argument to = me.  I also don't want to do work for no use.

There is a = counter-argument that there are proprietary uses of INFO in the wild, = and that a framework for negotiation at least removes the manual = configuration of vendor-specific profiles, which is a problem of interop = today - even if the IETF should not bless/document the specific use = cases themselves.  But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread.

The chairs have asked for 3 use cases, and I assume = they mean 3 NEW use cases (we already have 3 RFCs which use INFO, as = well as DTMF).  I am not sure if they mean potential future = use-cases, or current use-cases (i.e., already implemented).  Can I = get a clarification on that?

So anyway, taking the shot-gun = approach, here's a first go at some use-cases, and my personal take on = whether they should be in INFO vs. SUB/NOT vs. media-plane, = FWIW.
[apologize for formatting = ugliness]

/***************
*  Already standardized = use-cases:
***************/
1) = SIP-T/ISUP/QSIG/PSTN
        = -Documented in RFC 3372 and RFC 4497.

2) ECMA TR/87 = uaCSTA
        -Uses INFO to send = ECMA-323 XML for monitoring and controlling phones from a PC.

3) = Sending media server control = commands.
        -Documented in = RFC4722 MSCML.


/****************
*  Use-cases that I = think are potentially/possibly valid for = INFO:
****************/
1) Sending a vcard asynchronously.  = Alice calls Bob, Alice says "can you send me John's vcard?", Bob clicks = something and voila it's = sent.
        -Alternatives: send = a re-Invite or Update with a Call-Info, with either a URL reference, = data URI, or MIME and CID = URL.
        -Counter-argument: = IMO this type of data really belongs in MIME for a number of reasons, = including length is less restricted for mime attachments; one AD has = said the Data URL may be deprecated.  And sending a re-Invite for = this purpose seems odd.
        = -Also, the Call-Info header is really about the caller or callee, and = thus Bob shouldn't be sending me John's vcard info in it = technically.  That may sound like a nit, but UA's may well store = the call-info vcards into their address-books automatically and so tie = it to the wrong user/call.
        = -Pros of using INFO: it's explicit what you're doing when you send the = vcard, and you can send it knowing the other end can accept it, and you = can send it based on user input.

2) Sending a user-icon = jpeg/bitmap/gif.  Alice calls Bob, Bob has an icon that represents = himself, sends it when he picks up the = phone.
        -Alternatives: send = a 200ok, re-Invite, or Update with call-info, which explicitly has a = type for icon.
        = -Counter-argument: same as for vcard, plus with call-info there is no = way to know which picture format the far-end supports a priori.  = With a supported-package negotiation one could know.

3) Sending a = vcalendar-type invitation.  Alice calls Bob, Bob says "hey let's = have a con call at time X", clicks and voila his phone sends a = vcalendar.
        -Whether the = vcalendar is related to the session or not and thus whether it should be = sent in an in-dialog request or not is certainly debatable.  = Message method can already be used for this anyway.

4) Sending an = HTTP URL.  Alice calls Bob, a sales guy; Alice asks for more info = or a datasheet and Bob sends a URL for Alice to open with her = web-browser.
        -One could = also argue this is just making SIP the new SMTP, or this should be sent = using MESSAGE (which really is the new SMTP).

5) Sending a = session traceroute.  Alice calls Bob, Bob answers, Alice does a = sip-traceroute to figure out the path to Bob, by sending Info with an = incrementing max-forwards type header starting at 0 (but not really = max-forwards), with a sip-frag type response body or some = such.
        -It's debatable if = certain types of B2BUA's (ie, SBCs) would ever allow this type of thing = to happen, due to security concerns, but I think they may do it at = domain boundary hops.  I think this is a reasonable use for INFO = though, maybe.

6) Sending geo-location information after call = establishment.  Alice calls Bob, a hotel receptionist.  Alice = asks for directions to hotel, clicks button and sends him location info = of her phone (or Bob clicks button and sends her his = location).
        -The location = conveyance draft specifically calls out INFO as acceptable for geo-loc = info.  Whether this is a real use-case is debatable, and obviously = it could be done with a sub/not.

7) Sending softkey-labels (not = digit-match maps, but rather softkey button labels).  Alice calls = her vmail server.  Vmail server sends softkey-labels for the menu = items available in the response, Alice presses softkeys and sends them = in INFO.
        -This could (and = maybe should) be done with sub/not, a la KPML, where the vmail server = sends the softkey labels in the Subscribe, UA sends buttons pressed in = Notifies.  But this is similar to the DTMF use case so may well = have the same benefit of lower overhead since buttons are rarely = pressed.

8) Sending a screen-pop-up message, e.g., "Do you want = to continue with this = session?"
        -There is a = patent for doing screen pop-ups using INFO.  I guess Alert-Info = could be used for this, but it's not clear it = should?


/*****************
*  Use-cases which have = been proposed by others or even implemented,
*  which are = dubious for INFO (IMHO):
*****************/
1) Sending RTP/RTCP = statistics during call.
        = -There is an implementation of this, and the rationale is the signaling = plane box that wants this info is not actually the media plane box that = gets RTCP.  Again this could (and IMO should) be done with sub/not, = so it can get stats after the call is over, and since it will probably = want periodic reports the overhead of the Subscribe should be dwarfed by = the number of Notifies.

2) Sending access-location information = after call establishment.
        = -There is a P-Access-Network-Info header, and some have proposed to send = an update for it as a phone roams access points or cells.  But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA).

3) Sending media-control indications (ie, = remote-control = "play/pause/etc.")
        -This = is done today by at least one vendor, but is debatable if it's the right = model.  The argument is it's like SDP re-Invite for hold, except at = a media content layer above RTP, so not done in RTCP nor SDP.

4) = Sending video fast update = command
        -This is an = informational draft, which documents what has been implemented, but = states it should really be done in the media plane.

5) Sending = peripheral control commands (ie, USB = commands)
        -There is = actually a patent on this, amazingly.  Someone thinks it makes = sense to create a SIP session to your laptop, or vice-versa, and then = send USB commands inside MIME in INFO messages.  Methinks this = should be media-plane, if anything.

6) Sending charging = information for a call (i.e., minutes remaining or cost so = far).
        -There was a = proposal to use this for Advice of Charge information in TISPAN.  = IMO it should be a sub/not though, as they want this to survive the = Invite = session.

-hadriel


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

=0A= =0A=
------_=_NextPart_001_01C8386A.CA2EC6BB-- --===============0688191055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0688191055==-- From sip-bounces@ietf.org Thu Dec 06 20:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ra7-0004nY-R1; Thu, 06 Dec 2007 20:00:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Ra6-0004kI-II for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 20:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ra6-0004im-78 for sip@ietf.org; Thu, 06 Dec 2007 20:00:42 -0500 Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Ra5-0002TH-VL for sip@ietf.org; Thu, 06 Dec 2007 20:00:42 -0500 Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id McZx1Y0070bG4ec0502P00; Fri, 07 Dec 2007 01:00:41 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA03.westchester.pa.mail.comcast.net with comcast id Md0h1Y00F0umElk0300000; Fri, 07 Dec 2007 01:00:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=neQNX00HrZFAcgf9YpgA:9 a=jjfpie0SBLWCoUwaKRXZg8s9oeoA:4 a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lB710fTc018108 for ; Thu, 6 Dec 2007 20:00:41 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lB710flB018104; Thu, 6 Dec 2007 20:00:41 -0500 Date: Thu, 6 Dec 2007 20:00:41 -0500 Message-Id: <200712070100.lB710flB018104@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5D1A7985295922448D5550C94DE29180019F722E@DEEXC1U01.de.lucent.com> (drage@alcatel-lucent.com) Subject: Re: [Sip] draft-ietf-sip-rph-new-namespaces-01 References: <5D1A7985295922448D5550C94DE29180019F7218@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180019F722E@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "DRAGE, Keith \(Keith\)" 1) Change section 1 from Each will be RFC 4412 defined as preemption based in nature, and will have the same 9 priority-values. To Each will be preemption in nature, as defined in RFC 4412, and will have the same 9 priority-values. I think the way you want to phrase that is "Each will use a preemption policy, as defined in RFC 4412, ...". It would read even more easily if you said "Each will be preemptive [in nature], ...", but "preemptive" does not appear in RFC 4412. But "preemption policy" is used in section 4.5.1. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 20:49:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SKx-0001Lv-DA; Thu, 06 Dec 2007 20:49:07 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0SKv-0001Lp-J9 for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 20:49:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SKv-0001Lg-4l for sip@ietf.org; Thu, 06 Dec 2007 20:49:05 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0SKu-0003Ol-3t for sip@ietf.org; Thu, 06 Dec 2007 20:49:04 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Thu, 6 Dec 2007 20:49:03 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 6 Dec 2007 20:49:00 -0500 From: Hadriel Kaplan To: =?utf-8?B?7Zmp7KeE6rK9W+yXsOq1rOyghOusuOq3uOujuV0=?= Date: Thu, 6 Dec 2007 20:48:19 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAqGCew Message-ID: References: <0ae701c83871$0f108560$df2a0693@oasys.kt.co.kr> In-Reply-To: <0ae701c83871$0f108560$df2a0693@oasys.kt.co.kr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0870440348==" Errors-To: sip-bounces@ietf.org --===============0870440348== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSkssDQpJIGFjdHVhbGx5IHNhdyB0aGF0IGRyYWZ0IGJ1dCBkaWQgbm90IGluY2x1ZGUgaXQg YmVjYXVzZSBJIHRob3VnaHQgaXQgd2FzIGVzc2VudGlhbGx5IGFub3RoZXIgRFRNRi1zdHlsZSBl dmVudCB0eXBlLCBhbmQgd291bGQgYmUgc3Vic3VtZWQgaW50byBpdCwgYnV0IHlvdSdyZSByaWdo dCBJIHNob3VsZCBoYXZlIGluY2x1ZGVkIHRoYXQgdXNlLWNhc2UuICBTb3JyeSENCg0KLWhhZHJp ZWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiDt mansp4Tqsr1b7Jew6rWs7KCE66y46re466O5XSBbbWFpbHRvOmpraHdhbmdAa3QuY28ua3JdDQpT ZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDYsIDIwMDcgODozMyBQTQ0KVG86IEhhZHJpZWwgS2Fw bGFuOyBzaXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlcw0KRGVh ciBmb2xrcywNCiBIb3cgYWJvdXQgdGhlIE1pZGNhbGwgSU5GTyA/DQogV2hlbiAnSG9vay1GbGFz aCcgZnJvbSB0aGUgU0lQIG9yIFBPVFMgcGhvbmUgZHVyaW5nIGEgZGlhbG9ndWUsIHdlIChLVCkg dXNlIElORk8gbWV0aG9kIGZyb20gdGhlIENTQ0YvTUdDRiB0byBBUy4NCiBJIHN1Ym1pdHRlZCBh IGRyYWZ0IEktRCB0d28geWVhcnMgYWdvIGJ1dCBpdCB3YXMgbm90IGFjY2VwdGVkLA0KQnV0IHdl IHN0aWxsIHVzZSB0aGUgY2FzZS4NCiBDYW4gaXQgYmUgYW5vdGhlciBVc2UtQ2FzZSA/DQogSksg SHdhbmcNCktUDQoNCi0tLS0t7JuQ67O4IOuplOyLnOyngC0tLS0tDQrrs7Trgrgg7IKs656MOiAi SGFkcmllbCBLYXBsYW4iIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPg0K67O064K4IOuCoOynnDog MjAwNy0xMi0wNyDsmKTsoIQgODozODozNg0K67Cb64qUIOyCrOuejDogInNpcEBpZXRmLm9yZyIg PHNpcEBpZXRmLm9yZz4NCuywuOyhsDoNCuygnOuqqTogW1NpcF0gSU5GTyB1c2UtY2FzZXMNCg0K DQpIb3dkeSwNCkpvbmF0aGFuIGFza2VkIGZvciB1c2UtY2FzZXMgZm9yIHdoYXQgdHlwZXMgb2Yg dGhpbmdzIHdvdWxkIG5lZWQgYW4gaW4tZGlhbG9nIFNJUCBtZXNzYWdlIGZvciB1c2VyLXVzZXIg Y29tbXVuaWNhdGlvbiwgdnMuIHNob3VsZCBiZSBkb25lIGVpdGhlciBvdXQgb2YgZGlhbG9nIG9y IGluIHRoZSBtZWRpYSBwbGFuZS4gIElmIHRoZSBvbmx5IHVzZS1jYXNlIGlzIERUTUYsIHRoZW4g d2UgY291bGQganVzdCBkb2N1bWVudCB0aGUgRFRNRiBuZWdvdGlhdGlvbi91c2Ugb25seSBhbmQg bm90IGhhdmUgdG8gY3JlYXRlIGEgZ2VuZXJhbCBpbmZvLWV2ZW50cyBmcmFtZXdvcmsuICBUaGF0 IHNlZW1zIGEgdmVyeSByZWFzb25hYmxlIGFyZ3VtZW50IHRvIG1lLiAgSSBhbHNvIGRvbid0IHdh bnQgdG8gZG8gd29yayBmb3Igbm8gdXNlLg0KDQpUaGVyZSBpcyBhIGNvdW50ZXItYXJndW1lbnQg dGhhdCB0aGVyZSBhcmUgcHJvcHJpZXRhcnkgdXNlcyBvZiBJTkZPIGluIHRoZSB3aWxkLCBhbmQg dGhhdCBhIGZyYW1ld29yayBmb3IgbmVnb3RpYXRpb24gYXQgbGVhc3QgcmVtb3ZlcyB0aGUgbWFu dWFsIGNvbmZpZ3VyYXRpb24gb2YgdmVuZG9yLXNwZWNpZmljIHByb2ZpbGVzLCB3aGljaCBpcyBh IHByb2JsZW0gb2YgaW50ZXJvcCB0b2RheSAtIGV2ZW4gaWYgdGhlIElFVEYgc2hvdWxkIG5vdCBi bGVzcy9kb2N1bWVudCB0aGUgc3BlY2lmaWMgdXNlIGNhc2VzIHRoZW1zZWx2ZXMuICBCdXQgdGhh dCB3b3VsZCBtYWtlIHRoZSBkcmFmdCBhIHZlcnkgZGlmZmVyZW50IG9uZSB0aGFuIGl0IGN1cnJl bnRseSBpcyBhcyB3ZWxsLCBhbmQgSSB3aWxsIGFzayB0aGF0IGluIGEgc2VwYXJhdGUgZW1haWwg dGhyZWFkLg0KDQpUaGUgY2hhaXJzIGhhdmUgYXNrZWQgZm9yIDMgdXNlIGNhc2VzLCBhbmQgSSBh c3N1bWUgdGhleSBtZWFuIDMgTkVXIHVzZSBjYXNlcyAod2UgYWxyZWFkeSBoYXZlIDMgUkZDcyB3 aGljaCB1c2UgSU5GTywgYXMgd2VsbCBhcyBEVE1GKS4gIEkgYW0gbm90IHN1cmUgaWYgdGhleSBt ZWFuIHBvdGVudGlhbCBmdXR1cmUgdXNlLWNhc2VzLCBvciBjdXJyZW50IHVzZS1jYXNlcyAoaS5l LiwgYWxyZWFkeSBpbXBsZW1lbnRlZCkuICBDYW4gSSBnZXQgYSBjbGFyaWZpY2F0aW9uIG9uIHRo YXQ/DQoNClNvIGFueXdheSwgdGFraW5nIHRoZSBzaG90LWd1biBhcHByb2FjaCwgaGVyZSdzIGEg Zmlyc3QgZ28gYXQgc29tZSB1c2UtY2FzZXMsIGFuZCBteSBwZXJzb25hbCB0YWtlIG9uIHdoZXRo ZXIgdGhleSBzaG91bGQgYmUgaW4gSU5GTyB2cy4gU1VCL05PVCB2cy4gbWVkaWEtcGxhbmUsIEZX SVcuDQpbYXBvbG9naXplIGZvciBmb3JtYXR0aW5nIHVnbGluZXNzXQ0KDQovKioqKioqKioqKioq KioqDQoqICBBbHJlYWR5IHN0YW5kYXJkaXplZCB1c2UtY2FzZXM6DQoqKioqKioqKioqKioqKiov DQoxKSBTSVAtVC9JU1VQL1FTSUcvUFNUTg0KICAgICAgICAtRG9jdW1lbnRlZCBpbiBSRkMgMzM3 MiBhbmQgUkZDIDQ0OTcuDQoNCjIpIEVDTUEgVFIvODcgdWFDU1RBDQogICAgICAgIC1Vc2VzIElO Rk8gdG8gc2VuZCBFQ01BLTMyMyBYTUwgZm9yIG1vbml0b3JpbmcgYW5kIGNvbnRyb2xsaW5nIHBo b25lcyBmcm9tIGEgUEMuDQoNCjMpIFNlbmRpbmcgbWVkaWEgc2VydmVyIGNvbnRyb2wgY29tbWFu ZHMuDQogICAgICAgIC1Eb2N1bWVudGVkIGluIFJGQzQ3MjIgTVNDTUwuDQoNCg0KLyoqKioqKioq KioqKioqKioNCiogIFVzZS1jYXNlcyB0aGF0IEkgdGhpbmsgYXJlIHBvdGVudGlhbGx5L3Bvc3Np Ymx5IHZhbGlkIGZvciBJTkZPOg0KKioqKioqKioqKioqKioqKi8NCjEpIFNlbmRpbmcgYSB2Y2Fy ZCBhc3luY2hyb25vdXNseS4gIEFsaWNlIGNhbGxzIEJvYiwgQWxpY2Ugc2F5cyAiY2FuIHlvdSBz ZW5kIG1lIEpvaG4ncyB2Y2FyZD8iLCBCb2IgY2xpY2tzIHNvbWV0aGluZyBhbmQgdm9pbGEgaXQn cyBzZW50Lg0KICAgICAgICAtQWx0ZXJuYXRpdmVzOiBzZW5kIGEgcmUtSW52aXRlIG9yIFVwZGF0 ZSB3aXRoIGEgQ2FsbC1JbmZvLCB3aXRoIGVpdGhlciBhIFVSTCByZWZlcmVuY2UsIGRhdGEgVVJJ LCBvciBNSU1FIGFuZCBDSUQgVVJMLg0KICAgICAgICAtQ291bnRlci1hcmd1bWVudDogSU1PIHRo aXMgdHlwZSBvZiBkYXRhIHJlYWxseSBiZWxvbmdzIGluIE1JTUUgZm9yIGEgbnVtYmVyIG9mIHJl YXNvbnMsIGluY2x1ZGluZyBsZW5ndGggaXMgbGVzcyByZXN0cmljdGVkIGZvciBtaW1lIGF0dGFj aG1lbnRzOyBvbmUgQUQgaGFzIHNhaWQgdGhlIERhdGEgVVJMIG1heSBiZSBkZXByZWNhdGVkLiAg QW5kIHNlbmRpbmcgYSByZS1JbnZpdGUgZm9yIHRoaXMgcHVycG9zZSBzZWVtcyBvZGQuDQoNCiAg ICAgICAgLUFsc28sIHRoZSBDYWxsLUluZm8gaGVhZGVyIGlzIHJlYWxseSBhYm91dCB0aGUgY2Fs bGVyIG9yIGNhbGxlZSwgYW5kIHRodXMgQm9iIHNob3VsZG4ndCBiZSBzZW5kaW5nIG1lIEpvaG4n cyB2Y2FyZCBpbmZvIGluIGl0IHRlY2huaWNhbGx5LiAgVGhhdCBtYXkgc291bmQgbGlrZSBhIG5p dCwgYnV0IFVBJ3MgbWF5IHdlbGwgc3RvcmUgdGhlIGNhbGwtaW5mbyB2Y2FyZHMgaW50byB0aGVp ciBhZGRyZXNzLWJvb2tzIGF1dG9tYXRpY2FsbHkgYW5kIHNvIHRpZSBpdCB0byB0aGUgd3Jvbmcg dXNlci9jYWxsLg0KICAgICAgICAtUHJvcyBvZiB1c2luZyBJTkZPOiBpdCdzIGV4cGxpY2l0IHdo YXQgeW91J3JlIGRvaW5nIHdoZW4geW91IHNlbmQgdGhlIHZjYXJkLCBhbmQgeW91IGNhbiBzZW5k IGl0IGtub3dpbmcgdGhlIG90aGVyIGVuZCBjYW4gYWNjZXB0IGl0LCBhbmQgeW91IGNhbiBzZW5k IGl0IGJhc2VkIG9uIHVzZXIgaW5wdXQuDQoNCjIpIFNlbmRpbmcgYSB1c2VyLWljb24ganBlZy9i aXRtYXAvZ2lmLiAgQWxpY2UgY2FsbHMgQm9iLCBCb2IgaGFzIGFuIGljb24gdGhhdCByZXByZXNl bnRzIGhpbXNlbGYsIHNlbmRzIGl0IHdoZW4gaGUgcGlja3MgdXAgdGhlIHBob25lLg0KICAgICAg ICAtQWx0ZXJuYXRpdmVzOiBzZW5kIGEgMjAwb2ssIHJlLUludml0ZSwgb3IgVXBkYXRlIHdpdGgg Y2FsbC1pbmZvLCB3aGljaCBleHBsaWNpdGx5IGhhcyBhIHR5cGUgZm9yIGljb24uDQogICAgICAg IC1Db3VudGVyLWFyZ3VtZW50OiBzYW1lIGFzIGZvciB2Y2FyZCwgcGx1cyB3aXRoIGNhbGwtaW5m byB0aGVyZSBpcyBubyB3YXkgdG8ga25vdyB3aGljaCBwaWN0dXJlIGZvcm1hdCB0aGUgZmFyLWVu ZCBzdXBwb3J0cyBhIHByaW9yaS4gIFdpdGggYSBzdXBwb3J0ZWQtcGFja2FnZSBuZWdvdGlhdGlv biBvbmUgY291bGQga25vdy4NCg0KMykgU2VuZGluZyBhIHZjYWxlbmRhci10eXBlIGludml0YXRp b24uICBBbGljZSBjYWxscyBCb2IsIEJvYiBzYXlzICJoZXkgbGV0J3MgaGF2ZSBhIGNvbiBjYWxs IGF0IHRpbWUgWCIsIGNsaWNrcyBhbmQgdm9pbGEgaGlzIHBob25lIHNlbmRzIGEgdmNhbGVuZGFy Li4NCiAgICAgICAgLVdoZXRoZXIgdGhlIHZjYWxlbmRhciBpcyByZWxhdGVkIHRvIHRoZSBzZXNz aW9uIG9yIG5vdCBhbmQgdGh1cyB3aGV0aGVyIGl0IHNob3VsZCBiZSBzZW50IGluIGFuIGluLWRp YWxvZyByZXF1ZXN0IG9yIG5vdCBpcyBjZXJ0YWlubHkgZGViYXRhYmxlLiAgTWVzc2FnZSBtZXRo b2QgY2FuIGFscmVhZHkgYmUgdXNlZCBmb3IgdGhpcyBhbnl3YXkuDQoNCjQpIFNlbmRpbmcgYW4g SFRUUCBVUkwuICBBbGljZSBjYWxscyBCb2IsIGEgc2FsZXMgZ3V5OyBBbGljZSBhc2tzIGZvciBt b3JlIGluZm8gb3IgYSBkYXRhc2hlZXQgYW5kIEJvYiBzZW5kcyBhIFVSTCBmb3IgQWxpY2UgdG8g b3BlbiB3aXRoIGhlciB3ZWItYnJvd3Nlci4NCiAgICAgICAgLU9uZSBjb3VsZCBhbHNvIGFyZ3Vl IHRoaXMgaXMganVzdCBtYWtpbmcgU0lQIHRoZSBuZXcgU01UUCwgb3IgdGhpcyBzaG91bGQgYmUg c2VudCB1c2luZyBNRVNTQUdFICh3aGljaCByZWFsbHkgaXMgdGhlIG5ldyBTTVRQKS4NCg0KNSkg U2VuZGluZyBhIHNlc3Npb24gdHJhY2Vyb3V0ZS4gIEFsaWNlIGNhbGxzIEJvYiwgQm9iIGFuc3dl cnMsIEFsaWNlIGRvZXMgYSBzaXAtdHJhY2Vyb3V0ZSB0byBmaWd1cmUgb3V0IHRoZSBwYXRoIHRv IEJvYiwgYnkgc2VuZGluZyBJbmZvIHdpdGggYW4gaW5jcmVtZW50aW5nIG1heC1mb3J3YXJkcyB0 eXBlIGhlYWRlciBzdGFydGluZyBhdCAwIChidXQgbm90IHJlYWxseSBtYXgtZm9yd2FyZHMpLCB3 aXRoIGEgc2lwLWZyYWcgdHlwZSByZXNwb25zZSBib2R5IG9yIHNvbWUgc3VjaC4NCiAgICAgICAg LUl0J3MgZGViYXRhYmxlIGlmIGNlcnRhaW4gdHlwZXMgb2YgQjJCVUEncyAoaWUsIFNCQ3MpIHdv dWxkIGV2ZXIgYWxsb3cgdGhpcyB0eXBlIG9mIHRoaW5nIHRvIGhhcHBlbiwgZHVlIHRvIHNlY3Vy aXR5IGNvbmNlcm5zLCBidXQgSSB0aGluayB0aGV5IG1heSBkbyBpdCBhdCBkb21haW4gYm91bmRh cnkgaG9wcy4gIEkgdGhpbmsgdGhpcyBpcyBhIHJlYXNvbmFibGUgdXNlIGZvciBJTkZPIHRob3Vn aCwgbWF5YmUuDQoNCjYpIFNlbmRpbmcgZ2VvLWxvY2F0aW9uIGluZm9ybWF0aW9uIGFmdGVyIGNh bGwgZXN0YWJsaXNobWVudC4gIEFsaWNlIGNhbGxzIEJvYiwgYSBob3RlbCByZWNlcHRpb25pc3Qu ICBBbGljZSBhc2tzIGZvciBkaXJlY3Rpb25zIHRvIGhvdGVsLCBjbGlja3MgYnV0dG9uIGFuZCBz ZW5kcyBoaW0gbG9jYXRpb24gaW5mbyBvZiBoZXIgcGhvbmUgKG9yIEJvYiBjbGlja3MgYnV0dG9u IGFuZCBzZW5kcyBoZXIgaGlzIGxvY2F0aW9uKS4NCiAgICAgICAgLVRoZSBsb2NhdGlvbiBjb252 ZXlhbmNlIGRyYWZ0IHNwZWNpZmljYWxseSBjYWxscyBvdXQgSU5GTyBhcyBhY2NlcHRhYmxlIGZv ciBnZW8tbG9jIGluZm8uICBXaGV0aGVyIHRoaXMgaXMgYSByZWFsIHVzZS1jYXNlIGlzIGRlYmF0 YWJsZSwgYW5kIG9idmlvdXNseSBpdCBjb3VsZCBiZSBkb25lIHdpdGggYSBzdWIvbm90Lg0KDQo3 KSBTZW5kaW5nIHNvZnRrZXktbGFiZWxzIChub3QgZGlnaXQtbWF0Y2ggbWFwcywgYnV0IHJhdGhl ciBzb2Z0a2V5IGJ1dHRvbiBsYWJlbHMpLiAgQWxpY2UgY2FsbHMgaGVyIHZtYWlsIHNlcnZlci4g IFZtYWlsIHNlcnZlciBzZW5kcyBzb2Z0a2V5LWxhYmVscyBmb3IgdGhlIG1lbnUgaXRlbXMgYXZh aWxhYmxlIGluIHRoZSByZXNwb25zZSwgQWxpY2UgcHJlc3NlcyBzb2Z0a2V5cyBhbmQgc2VuZHMg dGhlbSBpbiBJTkZPLg0KICAgICAgICAtVGhpcyBjb3VsZCAoYW5kIG1heWJlIHNob3VsZCkgYmUg ZG9uZSB3aXRoIHN1Yi9ub3QsIGEgbGEgS1BNTCwgd2hlcmUgdGhlIHZtYWlsIHNlcnZlciBzZW5k cyB0aGUgc29mdGtleSBsYWJlbHMgaW4gdGhlIFN1YnNjcmliZSwgVUEgc2VuZHMgYnV0dG9ucyBw cmVzc2VkIGluIE5vdGlmaWVzLiAgQnV0IHRoaXMgaXMgc2ltaWxhciB0byB0aGUgRFRNRiB1c2Ug Y2FzZSBzbyBtYXkgd2VsbCBoYXZlIHRoZSBzYW1lIGJlbmVmaXQgb2YgbG93ZXIgb3ZlcmhlYWQg c2luY2UgYnV0dG9ucyBhcmUgcmFyZWx5IHByZXNzZWQuDQoNCjgpIFNlbmRpbmcgYSBzY3JlZW4t cG9wLXVwIG1lc3NhZ2UsIGUuZy4sICJEbyB5b3Ugd2FudCB0byBjb250aW51ZSB3aXRoIHRoaXMg c2Vzc2lvbj8iDQogICAgICAgIC1UaGVyZSBpcyBhIHBhdGVudCBmb3IgZG9pbmcgc2NyZWVuIHBv cC11cHMgdXNpbmcgSU5GTy4gIEkgZ3Vlc3MgQWxlcnQtSW5mbyBjb3VsZCBiZSB1c2VkIGZvciB0 aGlzLCBidXQgaXQncyBub3QgY2xlYXIgaXQgc2hvdWxkPw0KDQoNCi8qKioqKioqKioqKioqKioq Kg0KKiAgVXNlLWNhc2VzIHdoaWNoIGhhdmUgYmVlbiBwcm9wb3NlZCBieSBvdGhlcnMgb3IgZXZl biBpbXBsZW1lbnRlZCwNCiogIHdoaWNoIGFyZSBkdWJpb3VzIGZvciBJTkZPIChJTUhPKToNCioq KioqKioqKioqKioqKioqLw0KMSkgU2VuZGluZyBSVFAvUlRDUCBzdGF0aXN0aWNzIGR1cmluZyBj YWxsLg0KICAgICAgICAtVGhlcmUgaXMgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcywgYW5kIHRo ZSByYXRpb25hbGUgaXMgdGhlIHNpZ25hbGluZyBwbGFuZSBib3ggdGhhdCB3YW50cyB0aGlzIGlu Zm8gaXMgbm90IGFjdHVhbGx5IHRoZSBtZWRpYSBwbGFuZSBib3ggdGhhdCBnZXRzIFJUQ1AuICBB Z2FpbiB0aGlzIGNvdWxkIChhbmQgSU1PIHNob3VsZCkgYmUgZG9uZSB3aXRoIHN1Yi9ub3QsIHNv IGl0IGNhbiBnZXQgc3RhdHMgYWZ0ZXIgdGhlIGNhbGwgaXMgb3ZlciwgYW5kIHNpbmNlIGl0IHdp bGwgcHJvYmFibHkgd2FudCBwZXJpb2RpYyByZXBvcnRzIHRoZSBvdmVyaGVhZCBvZiB0aGUgU3Vi c2NyaWJlIHNob3VsZCBiZSBkd2FyZmVkIGJ5IHRoZSBudW1iZXIgb2YgTm90aWZpZXMuDQoNCjIp IFNlbmRpbmcgYWNjZXNzLWxvY2F0aW9uIGluZm9ybWF0aW9uIGFmdGVyIGNhbGwgZXN0YWJsaXNo bWVudC4NCiAgICAgICAgLVRoZXJlIGlzIGEgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciwg YW5kIHNvbWUgaGF2ZSBwcm9wb3NlZCB0byBzZW5kIGFuIHVwZGF0ZSBmb3IgaXQgYXMgYSBwaG9u ZSByb2FtcyBhY2Nlc3MgcG9pbnRzIG9yIGNlbGxzLiAgQnV0IEkgdGhpbmsgdGhpcyBpcyBhbiBv ZGQgdGhpbmcgdG8gZG8gaW5zaWRlIGFuIEludml0ZSBzZXNzaW9uLCB2cy4gaW4gYSBzdWIvbm90 IG9yIFJlZ2lzdGVyIChhbmQgYmVzaWRlcyBoYWxmIHRoZSB0aW1lIHRoZSBuZXR3b3JrIGluc2Vy dHMgdGhpcyBoZWFkZXIsIG5vdCB0aGUgVUEpLg0KDQozKSBTZW5kaW5nIG1lZGlhLWNvbnRyb2wg aW5kaWNhdGlvbnMgKGllLCByZW1vdGUtY29udHJvbCAicGxheS9wYXVzZS9ldGMuIikNCiAgICAg ICAgLVRoaXMgaXMgZG9uZSB0b2RheSBieSBhdCBsZWFzdCBvbmUgdmVuZG9yLCBidXQgaXMgZGVi YXRhYmxlIGlmIGl0J3MgdGhlIHJpZ2h0IG1vZGVsLiAgVGhlIGFyZ3VtZW50IGlzIGl0J3MgbGlr ZSBTRFAgcmUtSW52aXRlIGZvciBob2xkLCBleGNlcHQgYXQgYSBtZWRpYSBjb250ZW50IGxheWVy IGFib3ZlIFJUUCwgc28gbm90IGRvbmUgaW4gUlRDUCBub3IgU0RQLg0KDQo0KSBTZW5kaW5nIHZp ZGVvIGZhc3QgdXBkYXRlIGNvbW1hbmQNCiAgICAgICAgLVRoaXMgaXMgYW4gaW5mb3JtYXRpb25h bCBkcmFmdCwgd2hpY2ggZG9jdW1lbnRzIHdoYXQgaGFzIGJlZW4gaW1wbGVtZW50ZWQsIGJ1dCBz dGF0ZXMgaXQgc2hvdWxkIHJlYWxseSBiZSBkb25lIGluIHRoZSBtZWRpYSBwbGFuZS4NCg0KNSkg U2VuZGluZyBwZXJpcGhlcmFsIGNvbnRyb2wgY29tbWFuZHMgKGllLCBVU0IgY29tbWFuZHMpDQog ICAgICAgIC1UaGVyZSBpcyBhY3R1YWxseSBhIHBhdGVudCBvbiB0aGlzLCBhbWF6aW5nbHkuICBT b21lb25lIHRoaW5rcyBpdCBtYWtlcyBzZW5zZSB0byBjcmVhdGUgYSBTSVAgc2Vzc2lvbiB0byB5 b3VyIGxhcHRvcCwgb3IgdmljZS12ZXJzYSwgYW5kIHRoZW4gc2VuZCBVU0IgY29tbWFuZHMgaW5z aWRlIE1JTUUgaW4gSU5GTyBtZXNzYWdlcy4gIE1ldGhpbmtzIHRoaXMgc2hvdWxkIGJlIG1lZGlh LXBsYW5lLCBpZiBhbnl0aGluZy4NCg0KNikgU2VuZGluZyBjaGFyZ2luZyBpbmZvcm1hdGlvbiBm b3IgYSBjYWxsIChpLmUuLCBtaW51dGVzIHJlbWFpbmluZyBvciBjb3N0IHNvIGZhcikuDQogICAg ICAgIC1UaGVyZSB3YXMgYSBwcm9wb3NhbCB0byB1c2UgdGhpcyBmb3IgQWR2aWNlIG9mIENoYXJn ZSBpbmZvcm1hdGlvbiBpbiBUSVNQQU4uICBJTU8gaXQgc2hvdWxkIGJlIGEgc3ViL25vdCB0aG91 Z2gsIGFzIHRoZXkgd2FudCB0aGlzIHRvIHN1cnZpdmUgdGhlIEludml0ZSBzZXNzaW9uLg0KDQot aGFkcmllbA0KDQoNCg== --===============0870440348== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0870440348==-- From sip-bounces@ietf.org Thu Dec 06 21:13:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SiU-0008AR-9J; Thu, 06 Dec 2007 21:13:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0SiT-0008AL-L1 for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SiT-0008AD-B9 for sip@ietf.org; Thu, 06 Dec 2007 21:13:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0SiS-0006gf-BD for sip@ietf.org; Thu, 06 Dec 2007 21:13:25 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2007 18:13:23 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB72DNJ9009837; Thu, 6 Dec 2007 18:13:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lB72DJU4029466; Fri, 7 Dec 2007 02:13:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:13:19 -0800 Received: from [10.21.122.251] ([10.21.122.251]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:13:19 -0800 Message-ID: <4758AC44.6030900@cisco.com> Date: Thu, 06 Dec 2007 21:13:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO use-cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 02:13:19.0297 (UTC) FILETIME=[BC16DB10:01C83876] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7120; t=1196993603; x=1197857603; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20use-cases |Sender:=20; bh=MZhV8P3wey8yYgP1UpuKGTfRErf6Yyvd9DjycEH2kzM=; b=qMKkzzsvYfmV8H1FwIbt0fgdJwVvnaDhYFPiuNFNxux1BpGNoMm2zP71TE42SyqRkvfyQSVA y8RdWc684cEcPStugCCr8PY/Uw6wweyF+4FN/W+2aGE8tdPKqZiHjU/r; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, I buy some of your use cases, but not others. Comments below. A competitor for INFO in several of these is MESSAGE. I think a good case can be made for that if the information is to be rendered to the recipient. Paul Hadriel Kaplan wrote: [snip] > /**************** > * Use-cases that I think are potentially/possibly valid for INFO: > ****************/ > 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you send me John's vcard?", Bob clicks something and voila it's sent. > -Alternatives: send a re-Invite or Update with a Call-Info, with either a URL reference, data URI, or MIME and CID URL. > -Counter-argument: IMO this type of data really belongs in MIME for a number of reasons, including length is less restricted for mime attachments; one AD has said the Data URL may be deprecated. And sending a re-Invite for this purpose seems odd. > -Also, the Call-Info header is really about the caller or callee, and thus Bob shouldn't be sending me John's vcard info in it technically. That may sound like a nit, but UA's may well store the call-info vcards into their address-books automatically and so tie it to the wrong user/call. > -Pros of using INFO: it's explicit what you're doing when you send the vcard, and you can send it knowing the other end can accept it, and you can send it based on user input. > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an icon that represents himself, sends it when he picks up the phone. > -Alternatives: send a 200ok, re-Invite, or Update with call-info, which explicitly has a type for icon. > -Counter-argument: same as for vcard, plus with call-info there is no way to know which picture format the far-end supports a priori. With a supported-package negotiation one could know. For this case MESSAGE seems entirely appropriate. (Not so much so for vcard, which probably isn't intended to be directly rendered to the recipient.) > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey let's have a con call at time X", clicks and voila his phone sends a vcalendar. > -Whether the vcalendar is related to the session or not and thus whether it should be sent in an in-dialog request or not is certainly debatable. Message method can already be used for this anyway. > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for more info or a datasheet and Bob sends a URL for Alice to open with her web-browser. > -One could also argue this is just making SIP the new SMTP, or this should be sent using MESSAGE (which really is the new SMTP). Yes to MESSAGE. > 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice does a sip-traceroute to figure out the path to Bob, by sending Info with an incrementing max-forwards type header starting at 0 (but not really max-forwards), with a sip-frag type response body or some such. > -It's debatable if certain types of B2BUA's (ie, SBCs) would ever allow this type of thing to happen, due to security concerns, but I think they may do it at domain boundary hops. I think this is a reasonable use for INFO though, maybe. > > 6) Sending geo-location information after call establishment. Alice calls Bob, a hotel receptionist. Alice asks for directions to hotel, clicks button and sends him location info of her phone (or Bob clicks button and sends her his location). > -The location conveyance draft specifically calls out INFO as acceptable for geo-loc info. Whether this is a real use-case is debatable, and obviously it could be done with a sub/not. UPDATE with geo-loc is reasonable here, or even reINVITE. > 7) Sending softkey-labels (not digit-match maps, but rather softkey button labels). Alice calls her vmail server. Vmail server sends softkey-labels for the menu items available in the response, Alice presses softkeys and sends them in INFO. > -This could (and maybe should) be done with sub/not, a la KPML, where the vmail server sends the softkey labels in the Subscribe, UA sends buttons pressed in Notifies. But this is similar to the DTMF use case so may well have the same benefit of lower overhead since buttons are rarely pressed. > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue with this session?" > -There is a patent for doing screen pop-ups using INFO. I guess Alert-Info could be used for this, but it's not clear it should? This is very definitely a use case for MESSAGE. Also, all of the above could probably be justifiably sent via MSRP - either directly or via the file transfer extensions. > /***************** > * Use-cases which have been proposed by others or even implemented, > * which are dubious for INFO (IMHO): > *****************/ > 1) Sending RTP/RTCP statistics during call. > -There is an implementation of this, and the rationale is the signaling plane box that wants this info is not actually the media plane box that gets RTCP. Again this could (and IMO should) be done with sub/not, so it can get stats after the call is over, and since it will probably want periodic reports the overhead of the Subscribe should be dwarfed by the number of Notifies. > > 2) Sending access-location information after call establishment. > -There is a P-Access-Network-Info header, and some have proposed to send an update for it as a phone roams access points or cells. But I think this is an odd thing to do inside an Invite session, vs. in a sub/not or Register (and besides half the time the network inserts this header, not the UA). > > 3) Sending media-control indications (ie, remote-control "play/pause/etc.") > -This is done today by at least one vendor, but is debatable if it's the right model. The argument is it's like SDP re-Invite for hold, except at a media content layer above RTP, so not done in RTCP nor SDP. > > 4) Sending video fast update command > -This is an informational draft, which documents what has been implemented, but states it should really be done in the media plane. > > 5) Sending peripheral control commands (ie, USB commands) > -There is actually a patent on this, amazingly. Someone thinks it makes sense to create a SIP session to your laptop, or vice-versa, and then send USB commands inside MIME in INFO messages. Methinks this should be media-plane, if anything. > > 6) Sending charging information for a call (i.e., minutes remaining or cost so far). > -There was a proposal to use this for Advice of Charge information in TISPAN. IMO it should be a sub/not though, as they want this to survive the Invite session. > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 21:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sik-0000cd-Gm; Thu, 06 Dec 2007 21:13:42 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Sii-0000TT-Pe for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:13:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sii-0000PV-9i for sip@ietf.org; Thu, 06 Dec 2007 21:13:40 -0500 Received: from smfilter2.kt.co.kr ([147.6.85.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Sie-0006hE-Q6 for sip@ietf.org; Thu, 06 Dec 2007 21:13:40 -0500 Received: from external ([147.6.42.22]) by smfilter2 (1.0) id lB72CKI00B06; Fri, 07 Dec 2007 11:12:20 +0900 Received: from MAIL04CL.oasys.kt.co.kr ([147.6.42.223]) by smtp02.oasys.kt.co.kr with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 Dec 2007 11:12:28 +0900 Received: from mail pickup service by MAIL04CL.oasys.kt.co.kr with Microsoft SMTPSVC; Fri, 7 Dec 2007 11:12:27 +0900 Priority: normal Bcc: X-AuditID: 93062d6f-acdd6bb000004100-60-4758a69159fa Subject: RE: [Sip] INFO use-cases From: =?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=?= To: "Hadriel Kaplan" Date: Fri, 7 Dec 2007 11:12:27 +0900 Message-ID: <01fe01c83876$9d5a5b20$df2a0693@oasys.kt.co.kr> Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAqGCew References: <0ae701c83871$0f108560$df2a0693@oasys.kt.co.kr> X-Mailer: Microsoft CDO for Exchange 2000 In-Reply-To: <0ae701c83871$0f108560$df2a0693@oasys.kt.co.kr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Content-Class: urn:content-classes:message Importance: normal MIME-Version: 1.0 X-Brightmail-Tracker: AAAABADI6/sH/yjCB/8plAf/YMg= X-OriginalArrivalTime: 07 Dec 2007 01:49:19.0401 (UTC) FILETIME=[61D82990:01C83873] X-Spam-Score: 2.8 (++) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=?= List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0190185869==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0190185869== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FF_01C838C2.0D420320" Content-Language: en-US Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_01FF_01C838C2.0D420320 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Dear Hadriel Kaplan and folks=0A= =0A= (in our case) =0A= Midcall INFO is used in =0A= =0A= 1) Three-way calling: to add another party to existing call =0A= 2) Call waiting: to change dialogue between two ongoing calls=0A= 3) Centrex services: call transfer, etc.=0A= =0A= THX=0A= =0A= JK Hwang=0A= KT=0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 10:48:19=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: = "=C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC]" = =0A= =C2=FC=C1=B6: "sip@ietf.org" =0A= =C1=A6=B8=F1: RE: [Sip] INFO use-cases=0A= =0A= =0A= Hi JK,=0A= I actually saw that draft but did not include it because I thought it = was essentially another DTMF-style event type, and would be subsumed = into it, but you're right I should have included that use-case. Sorry!=0A= =0A= -hadriel=0A= =0A= =0A= ________________________________________=0A= From: =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr]=0A= Sent: Thursday, December 06, 2007 8:33 PM=0A= To: Hadriel Kaplan; sip@ietf.org=0A= Subject: RE: [Sip] INFO use-cases=0A= Dear folks,=0A= How about the Midcall INFO ?=0A= When 'Hook-Flash' from the SIP or POTS phone during a dialogue, we (KT) = use INFO method from the CSCF/MGCF to AS.=0A= I submitted a draft I-D two years ago but it was not accepted,=0A= But we still use the case.=0A= Can it be another Use-Case ?=0A= JK Hwang=0A= KT=0A= =0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 8:38:36=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: "sip@ietf.org" =0A= =C2=FC=C1=B6:=0A= =C1=A6=B8=F1: [Sip] INFO use-cases=0A= =0A= =0A= Howdy,=0A= Jonathan asked for use-cases for what types of things would need an = in-dialog SIP message for user-user communication, vs. should be done = either out of dialog or in the media plane. If the only use-case is = DTMF, then we could just document the DTMF negotiation/use only and not = have to create a general info-events framework. That seems a very = reasonable argument to me. I also don't want to do work for no use.=0A= =0A= There is a counter-argument that there are proprietary uses of INFO in = the wild, and that a framework for negotiation at least removes the = manual configuration of vendor-specific profiles, which is a problem of = interop today - even if the IETF should not bless/document the specific = use cases themselves. But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread.=0A= =0A= The chairs have asked for 3 use cases, and I assume they mean 3 NEW use = cases (we already have 3 RFCs which use INFO, as well as DTMF). I am = not sure if they mean potential future use-cases, or current use-cases = (i.e., already implemented). Can I get a clarification on that?=0A= =0A= So anyway, taking the shot-gun approach, here's a first go at some = use-cases, and my personal take on whether they should be in INFO vs. = SUB/NOT vs. media-plane, FWIW.=0A= [apologize for formatting ugliness]=0A= =0A= /***************=0A= * Already standardized use-cases:=0A= ***************/=0A= 1) SIP-T/ISUP/QSIG/PSTN=0A= -Documented in RFC 3372 and RFC 4497.=0A= =0A= 2) ECMA TR/87 uaCSTA=0A= -Uses INFO to send ECMA-323 XML for monitoring and controlling = phones from a PC.=0A= =0A= 3) Sending media server control commands.=0A= -Documented in RFC4722 MSCML.=0A= =0A= =0A= /****************=0A= * Use-cases that I think are potentially/possibly valid for INFO:=0A= ****************/=0A= 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you = send me John's vcard?", Bob clicks something and voila it's sent.=0A= -Alternatives: send a re-Invite or Update with a Call-Info, with = either a URL reference, data URI, or MIME and CID URL.=0A= -Counter-argument: IMO this type of data really belongs in MIME = for a number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd.=0A= =0A= -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call.=0A= -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input.=0A= =0A= 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone.=0A= -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon.=0A= -Counter-argument: same as for vcard, plus with call-info there = is no way to know which picture format the far-end supports a priori. = With a supported-package negotiation one could know.=0A= =0A= 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey = let's have a con call at time X", clicks and voila his phone sends a = vcalendar..=0A= -Whether the vcalendar is related to the session or not and thus = whether it should be sent in an in-dialog request or not is certainly = debatable. Message method can already be used for this anyway.=0A= =0A= 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser.=0A= -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP).=0A= =0A= 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such.=0A= -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe.=0A= =0A= 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location).=0A= -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not.=0A= =0A= 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO.=0A= -This could (and maybe should) be done with sub/not, a la KPML, = where the vmail server sends the softkey labels in the Subscribe, UA = sends buttons pressed in Notifies. But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed.=0A= =0A= 8) Sending a screen-pop-up message, e.g., "Do you want to continue with = this session?"=0A= -There is a patent for doing screen pop-ups using INFO. I guess = Alert-Info could be used for this, but it's not clear it should?=0A= =0A= =0A= /*****************=0A= * Use-cases which have been proposed by others or even implemented,=0A= * which are dubious for INFO (IMHO):=0A= *****************/=0A= 1) Sending RTP/RTCP statistics during call.=0A= -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies.=0A= =0A= 2) Sending access-location information after call establishment.=0A= -There is a P-Access-Network-Info header, and some have proposed = to send an update for it as a phone roams access points or cells. But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA).=0A= =0A= 3) Sending media-control indications (ie, remote-control = "play/pause/etc.")=0A= -This is done today by at least one vendor, but is debatable if = it's the right model. The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor SDP.=0A= =0A= 4) Sending video fast update command=0A= -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane.=0A= =0A= 5) Sending peripheral control commands (ie, USB commands)=0A= -There is actually a patent on this, amazingly. Someone thinks = it makes sense to create a SIP session to your laptop, or vice-versa, = and then send USB commands inside MIME in INFO messages. Methinks this = should be media-plane, if anything.=0A= =0A= 6) Sending charging information for a call (i.e., minutes remaining or = cost so far).=0A= -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session.=0A= =0A= -hadriel ------=_NextPart_000_01FF_01C838C2.0D420320 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGJvZHk+PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxE SVY+CjxQPiZuYnNwOzwvUD4KPFA+RGVhciBIYWRyaWVsIEthcGxhbiBhbmQgZm9sa3M8L1A+CjxQ PiZuYnNwOzwvUD4KPFA+KGluIG91ciBjYXNlKSA8L1A+CjxQPk1pZGNhbGwgSU5GTyBpcyB1c2Vk IGluIDwvUD4KPFA+Jm5ic3A7PC9QPgo8UD4xKSBUaHJlZS13YXkgY2FsbGluZzogdG8gYWRkIGFu b3RoZXIgcGFydHkgdG8gZXhpc3RpbmcgY2FsbCZuYnNwOzwvUD4KPFA+MikgQ2FsbCB3YWl0aW5n OiB0byBjaGFuZ2UgZGlhbG9ndWUgYmV0d2VlbiB0d28gb25nb2luZyBjYWxsczwvUD4KPFA+Mykg Q2VudHJleCBzZXJ2aWNlczogY2FsbCB0cmFuc2ZlciwgZXRjLjwvUD4KPFA+Jm5ic3A7PC9QPgo8 UD5USFg8L1A+CjxQPiZuYnNwOzwvUD4KPFA+SksgSHdhbmc8L1A+CjxQPktUPEJSPi0tLS0tv/i6 uyC43r3DwfYtLS0tLTxCUj48Qj66uLO9ILvntvc6PC9CPiAiSGFkcmllbCBLYXBsYW4iICZsdDtI S2FwbGFuQGFjbWVwYWNrZXQuY29tJmd0OzxCUj48Qj66uLO9ILOvwqU6PC9CPiAyMDA3LTEyLTA3 IL/AwPwgMTA6NDg6MTk8QlI+PEI+ud60wiC757b3OjwvQj4gIsiywfiw5lu/rLG4wPy5rrHXt+xd IiAmbHQ7amtod2FuZ0BrdC5jby5rciZndDs8QlI+PEI+wvzBtjo8L0I+ICJzaXBAaWV0Zi5vcmci ICZsdDtzaXBAaWV0Zi5vcmcmZ3Q7PEJSPjxCPsGmuPE6PC9CPiBSRTogW1NpcF0gSU5GTyB1c2Ut Y2FzZXM8QlI+PEJSPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+PC9Q PjwvRElWPjwvRElWPgo8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCx vLiyIj4KPERJVj4KPFA+PEZPTlQgc2l6ZT0yPkhpIEpLLDxCUj5JIGFjdHVhbGx5IHNhdyB0aGF0 IGRyYWZ0IGJ1dCBkaWQgbm90IGluY2x1ZGUgaXQgYmVjYXVzZSBJIHRob3VnaHQgaXQgd2FzIGVz c2VudGlhbGx5IGFub3RoZXIgRFRNRi1zdHlsZSBldmVudCB0eXBlLCBhbmQgd291bGQgYmUgc3Vi c3VtZWQgaW50byBpdCwgYnV0IHlvdSdyZSByaWdodCBJIHNob3VsZCBoYXZlIGluY2x1ZGVkIHRo YXQgdXNlLWNhc2UuJm5ic3A7IFNvcnJ5ITxCUj48QlI+LWhhZHJpZWw8QlI+PEJSPjxCUj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkZyb206IMiywfiw5lu/rLG4 wPy5rrHXt+xdIFs8QSBocmVmPSJtYWlsdG86amtod2FuZ0BrdC5jby5rciIgdGFyZ2V0PV9ibGFu az5tYWlsdG86amtod2FuZ0BrdC5jby5rcjwvQT5dPEJSPlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciAwNiwgMjAwNyA4OjMzIFBNPEJSPlRvOiBIYWRyaWVsIEthcGxhbjsgc2lwQGlldGYub3JnPEJS PlN1YmplY3Q6IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlczxCUj5EZWFyIGZvbGtzLDxCUj4mbmJz cDtIb3cgYWJvdXQgdGhlIE1pZGNhbGwgSU5GTyA/PEJSPiZuYnNwO1doZW4gJ0hvb2stRmxhc2gn IGZyb20gdGhlIFNJUCBvciBQT1RTIHBob25lIGR1cmluZyBhIGRpYWxvZ3VlLCB3ZSAoS1QpIHVz ZSBJTkZPIG1ldGhvZCBmcm9tIHRoZSBDU0NGL01HQ0YgdG8gQVMuPEJSPiZuYnNwO0kgc3VibWl0 dGVkIGEgZHJhZnQgSS1EIHR3byB5ZWFycyBhZ28gYnV0IGl0IHdhcyBub3QgYWNjZXB0ZWQsPEJS PkJ1dCB3ZSBzdGlsbCB1c2UgdGhlIGNhc2UuPEJSPiZuYnNwO0NhbiBpdCBiZSBhbm90aGVyIFVz ZS1DYXNlID88QlI+Jm5ic3A7SksgSHdhbmc8QlI+S1Q8QlI+PEJSPi0tLS0tv/i6uyC43r3DwfYt LS0tLTxCUj66uLO9ILvntvc6ICJIYWRyaWVsIEthcGxhbiIgJmx0O0hLYXBsYW5AYWNtZXBhY2tl dC5jb20mZ3Q7PEJSPrq4s70gs6/CpTogMjAwNy0xMi0wNyC/wMD8IDg6Mzg6MzY8QlI+ud60wiC7 57b3OiAic2lwQGlldGYub3JnIiAmbHQ7c2lwQGlldGYub3JnJmd0OzxCUj7C/MG2OjxCUj7Bprjx OiBbU2lwXSBJTkZPIHVzZS1jYXNlczxCUj48QlI+PEJSPkhvd2R5LDxCUj5Kb25hdGhhbiBhc2tl ZCBmb3IgdXNlLWNhc2VzIGZvciB3aGF0IHR5cGVzIG9mIHRoaW5ncyB3b3VsZCBuZWVkIGFuIGlu LWRpYWxvZyBTSVAgbWVzc2FnZSBmb3IgdXNlci11c2VyIGNvbW11bmljYXRpb24sIHZzLiBzaG91 bGQgYmUgZG9uZSBlaXRoZXIgb3V0IG9mIGRpYWxvZyBvciBpbiB0aGUgbWVkaWEgcGxhbmUuJm5i c3A7IElmIHRoZSBvbmx5IHVzZS1jYXNlIGlzIERUTUYsIHRoZW4gd2UgY291bGQganVzdCBkb2N1 bWVudCB0aGUgRFRNRiBuZWdvdGlhdGlvbi91c2Ugb25seSBhbmQgbm90IGhhdmUgdG8gY3JlYXRl IGEgZ2VuZXJhbCBpbmZvLWV2ZW50cyBmcmFtZXdvcmsuJm5ic3A7IFRoYXQgc2VlbXMgYSB2ZXJ5 IHJlYXNvbmFibGUgYXJndW1lbnQgdG8gbWUuJm5ic3A7IEkgYWxzbyBkb24ndCB3YW50IHRvIGRv IHdvcmsgZm9yIG5vIHVzZS48QlI+PEJSPlRoZXJlIGlzIGEgY291bnRlci1hcmd1bWVudCB0aGF0 IHRoZXJlIGFyZSBwcm9wcmlldGFyeSB1c2VzIG9mIElORk8gaW4gdGhlIHdpbGQsIGFuZCB0aGF0 IGEgZnJhbWV3b3JrIGZvciBuZWdvdGlhdGlvbiBhdCBsZWFzdCByZW1vdmVzIHRoZSBtYW51YWwg Y29uZmlndXJhdGlvbiBvZiB2ZW5kb3Itc3BlY2lmaWMgcHJvZmlsZXMsIHdoaWNoIGlzIGEgcHJv YmxlbSBvZiBpbnRlcm9wIHRvZGF5IC0gZXZlbiBpZiB0aGUgSUVURiBzaG91bGQgbm90IGJsZXNz L2RvY3VtZW50IHRoZSBzcGVjaWZpYyB1c2UgY2FzZXMgdGhlbXNlbHZlcy4mbmJzcDsgQnV0IHRo YXQgd291bGQgbWFrZSB0aGUgZHJhZnQgYSB2ZXJ5IGRpZmZlcmVudCBvbmUgdGhhbiBpdCBjdXJy ZW50bHkgaXMgYXMgd2VsbCwgYW5kIEkgd2lsbCBhc2sgdGhhdCBpbiBhIHNlcGFyYXRlIGVtYWls IHRocmVhZC48QlI+PEJSPlRoZSBjaGFpcnMgaGF2ZSBhc2tlZCBmb3IgMyB1c2UgY2FzZXMsIGFu ZCBJIGFzc3VtZSB0aGV5IG1lYW4gMyBORVcgdXNlIGNhc2VzICh3ZSBhbHJlYWR5IGhhdmUgMyBS RkNzIHdoaWNoIHVzZSBJTkZPLCBhcyB3ZWxsIGFzIERUTUYpLiZuYnNwOyBJIGFtIG5vdCBzdXJl IGlmIHRoZXkgbWVhbiBwb3RlbnRpYWwgZnV0dXJlIHVzZS1jYXNlcywgb3IgY3VycmVudCB1c2Ut Y2FzZXMgKGkuZS4sIGFscmVhZHkgaW1wbGVtZW50ZWQpLiZuYnNwOyBDYW4gSSBnZXQgYSBjbGFy aWZpY2F0aW9uIG9uIHRoYXQ/PEJSPjxCUj5TbyBhbnl3YXksIHRha2luZyB0aGUgc2hvdC1ndW4g YXBwcm9hY2gsIGhlcmUncyBhIGZpcnN0IGdvIGF0IHNvbWUgdXNlLWNhc2VzLCBhbmQgbXkgcGVy c29uYWwgdGFrZSBvbiB3aGV0aGVyIHRoZXkgc2hvdWxkIGJlIGluIElORk8gdnMuIFNVQi9OT1Qg dnMuIG1lZGlhLXBsYW5lLCBGV0lXLjxCUj5bYXBvbG9naXplIGZvciBmb3JtYXR0aW5nIHVnbGlu ZXNzXTxCUj48QlI+LyoqKioqKioqKioqKioqKjxCUj4qJm5ic3A7IEFscmVhZHkgc3RhbmRhcmRp emVkIHVzZS1jYXNlczo8QlI+KioqKioqKioqKioqKioqLzxCUj4xKSBTSVAtVC9JU1VQL1FTSUcv UFNUTjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLURvY3Vt ZW50ZWQgaW4gUkZDIDMzNzIgYW5kIFJGQyA0NDk3LjxCUj48QlI+MikgRUNNQSBUUi84NyB1YUNT VEE8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1Vc2VzIElO Rk8gdG8gc2VuZCBFQ01BLTMyMyBYTUwgZm9yIG1vbml0b3JpbmcgYW5kIGNvbnRyb2xsaW5nIHBo b25lcyBmcm9tIGEgUEMuPEJSPjxCUj4zKSBTZW5kaW5nIG1lZGlhIHNlcnZlciBjb250cm9sIGNv bW1hbmRzLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLURv Y3VtZW50ZWQgaW4gUkZDNDcyMiBNU0NNTC48QlI+PEJSPjxCUj4vKioqKioqKioqKioqKioqKjxC Uj4qJm5ic3A7IFVzZS1jYXNlcyB0aGF0IEkgdGhpbmsgYXJlIHBvdGVudGlhbGx5L3Bvc3NpYmx5 IHZhbGlkIGZvciBJTkZPOjxCUj4qKioqKioqKioqKioqKioqLzxCUj4xKSBTZW5kaW5nIGEgdmNh cmQgYXN5bmNocm9ub3VzbHkuJm5ic3A7IEFsaWNlIGNhbGxzIEJvYiwgQWxpY2Ugc2F5cyAiY2Fu IHlvdSBzZW5kIG1lIEpvaG4ncyB2Y2FyZD8iLCBCb2IgY2xpY2tzIHNvbWV0aGluZyBhbmQgdm9p bGEgaXQncyBzZW50LjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLUFsdGVybmF0aXZlczogc2VuZCBhIHJlLUludml0ZSBvciBVcGRhdGUgd2l0aCBhIENhbGwt SW5mbywgd2l0aCBlaXRoZXIgYSBVUkwgcmVmZXJlbmNlLCBkYXRhIFVSSSwgb3IgTUlNRSBhbmQg Q0lEIFVSTC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1D b3VudGVyLWFyZ3VtZW50OiBJTU8gdGhpcyB0eXBlIG9mIGRhdGEgcmVhbGx5IGJlbG9uZ3MgaW4g TUlNRSBmb3IgYSBudW1iZXIgb2YgcmVhc29ucywgaW5jbHVkaW5nIGxlbmd0aCBpcyBsZXNzIHJl c3RyaWN0ZWQgZm9yIG1pbWUgYXR0YWNobWVudHM7IG9uZSBBRCBoYXMgc2FpZCB0aGUgRGF0YSBV UkwgbWF5IGJlIGRlcHJlY2F0ZWQuJm5ic3A7IEFuZCBzZW5kaW5nIGEgcmUtSW52aXRlIGZvciB0 aGlzIHB1cnBvc2Ugc2VlbXMgb2RkLjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC1BbHNvLCB0aGUgQ2FsbC1JbmZvIGhlYWRlciBpcyByZWFsbHkgYWJv dXQgdGhlIGNhbGxlciBvciBjYWxsZWUsIGFuZCB0aHVzIEJvYiBzaG91bGRuJ3QgYmUgc2VuZGlu ZyBtZSBKb2huJ3MgdmNhcmQgaW5mbyBpbiBpdCB0ZWNobmljYWxseS4mbmJzcDsgVGhhdCBtYXkg c291bmQgbGlrZSBhIG5pdCwgYnV0IFVBJ3MgbWF5IHdlbGwgc3RvcmUgdGhlIGNhbGwtaW5mbyB2 Y2FyZHMgaW50byB0aGVpciBhZGRyZXNzLWJvb2tzIGF1dG9tYXRpY2FsbHkgYW5kIHNvIHRpZSBp dCB0byB0aGUgd3JvbmcgdXNlci9jYWxsLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLVByb3Mgb2YgdXNpbmcgSU5GTzogaXQncyBleHBsaWNpdCB3aGF0IHlv dSdyZSBkb2luZyB3aGVuIHlvdSBzZW5kIHRoZSB2Y2FyZCwgYW5kIHlvdSBjYW4gc2VuZCBpdCBr bm93aW5nIHRoZSBvdGhlciBlbmQgY2FuIGFjY2VwdCBpdCwgYW5kIHlvdSBjYW4gc2VuZCBpdCBi YXNlZCBvbiB1c2VyIGlucHV0LjxCUj48QlI+MikgU2VuZGluZyBhIHVzZXItaWNvbiBqcGVnL2Jp dG1hcC9naWYuJm5ic3A7IEFsaWNlIGNhbGxzIEJvYiwgQm9iIGhhcyBhbiBpY29uIHRoYXQgcmVw cmVzZW50cyBoaW1zZWxmLCBzZW5kcyBpdCB3aGVuIGhlIHBpY2tzIHVwIHRoZSBwaG9uZS48QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1BbHRlcm5hdGl2ZXM6 IHNlbmQgYSAyMDBvaywgcmUtSW52aXRlLCBvciBVcGRhdGUgd2l0aCBjYWxsLWluZm8sIHdoaWNo IGV4cGxpY2l0bHkgaGFzIGEgdHlwZSBmb3IgaWNvbi48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1Db3VudGVyLWFyZ3VtZW50OiBzYW1lIGFzIGZvciB2Y2Fy ZCwgcGx1cyB3aXRoIGNhbGwtaW5mbyB0aGVyZSBpcyBubyB3YXkgdG8ga25vdyB3aGljaCBwaWN0 dXJlIGZvcm1hdCB0aGUgZmFyLWVuZCBzdXBwb3J0cyBhIHByaW9yaS4mbmJzcDsgV2l0aCBhIHN1 cHBvcnRlZC1wYWNrYWdlIG5lZ290aWF0aW9uIG9uZSBjb3VsZCBrbm93LjxCUj48QlI+MykgU2Vu ZGluZyBhIHZjYWxlbmRhci10eXBlIGludml0YXRpb24uJm5ic3A7IEFsaWNlIGNhbGxzIEJvYiwg Qm9iIHNheXMgImhleSBsZXQncyBoYXZlIGEgY29uIGNhbGwgYXQgdGltZSBYIiwgY2xpY2tzIGFu ZCB2b2lsYSBoaXMgcGhvbmUgc2VuZHMgYSB2Y2FsZW5kYXIuLjxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLVdoZXRoZXIgdGhlIHZjYWxlbmRhciBpcyByZWxh dGVkIHRvIHRoZSBzZXNzaW9uIG9yIG5vdCBhbmQgdGh1cyB3aGV0aGVyIGl0IHNob3VsZCBiZSBz ZW50IGluIGFuIGluLWRpYWxvZyByZXF1ZXN0IG9yIG5vdCBpcyBjZXJ0YWlubHkgZGViYXRhYmxl LiZuYnNwOyBNZXNzYWdlIG1ldGhvZCBjYW4gYWxyZWFkeSBiZSB1c2VkIGZvciB0aGlzIGFueXdh eS48QlI+PEJSPjQpIFNlbmRpbmcgYW4gSFRUUCBVUkwuJm5ic3A7IEFsaWNlIGNhbGxzIEJvYiwg YSBzYWxlcyBndXk7IEFsaWNlIGFza3MgZm9yIG1vcmUgaW5mbyBvciBhIGRhdGFzaGVldCBhbmQg Qm9iIHNlbmRzIGEgVVJMIGZvciBBbGljZSB0byBvcGVuIHdpdGggaGVyIHdlYi1icm93c2VyLjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLU9uZSBjb3VsZCBh bHNvIGFyZ3VlIHRoaXMgaXMganVzdCBtYWtpbmcgU0lQIHRoZSBuZXcgU01UUCwgb3IgdGhpcyBz aG91bGQgYmUgc2VudCB1c2luZyBNRVNTQUdFICh3aGljaCByZWFsbHkgaXMgdGhlIG5ldyBTTVRQ KS48QlI+PEJSPjUpIFNlbmRpbmcgYSBzZXNzaW9uIHRyYWNlcm91dGUuJm5ic3A7IEFsaWNlIGNh bGxzIEJvYiwgQm9iIGFuc3dlcnMsIEFsaWNlIGRvZXMgYSBzaXAtdHJhY2Vyb3V0ZSB0byBmaWd1 cmUgb3V0IHRoZSBwYXRoIHRvIEJvYiwgYnkgc2VuZGluZyBJbmZvIHdpdGggYW4gaW5jcmVtZW50 aW5nIG1heC1mb3J3YXJkcyB0eXBlIGhlYWRlciBzdGFydGluZyBhdCAwIChidXQgbm90IHJlYWxs eSBtYXgtZm9yd2FyZHMpLCB3aXRoIGEgc2lwLWZyYWcgdHlwZSByZXNwb25zZSBib2R5IG9yIHNv bWUgc3VjaC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1J dCdzIGRlYmF0YWJsZSBpZiBjZXJ0YWluIHR5cGVzIG9mIEIyQlVBJ3MgKGllLCBTQkNzKSB3b3Vs ZCBldmVyIGFsbG93IHRoaXMgdHlwZSBvZiB0aGluZyB0byBoYXBwZW4sIGR1ZSB0byBzZWN1cml0 eSBjb25jZXJucywgYnV0IEkgdGhpbmsgdGhleSBtYXkgZG8gaXQgYXQgZG9tYWluIGJvdW5kYXJ5 IGhvcHMuJm5ic3A7IEkgdGhpbmsgdGhpcyBpcyBhIHJlYXNvbmFibGUgdXNlIGZvciBJTkZPIHRo b3VnaCwgbWF5YmUuPEJSPjxCUj42KSBTZW5kaW5nIGdlby1sb2NhdGlvbiBpbmZvcm1hdGlvbiBh ZnRlciBjYWxsIGVzdGFibGlzaG1lbnQuJm5ic3A7IEFsaWNlIGNhbGxzIEJvYiwgYSBob3RlbCBy ZWNlcHRpb25pc3QuJm5ic3A7IEFsaWNlIGFza3MgZm9yIGRpcmVjdGlvbnMgdG8gaG90ZWwsIGNs aWNrcyBidXR0b24gYW5kIHNlbmRzIGhpbSBsb2NhdGlvbiBpbmZvIG9mIGhlciBwaG9uZSAob3Ig Qm9iIGNsaWNrcyBidXR0b24gYW5kIHNlbmRzIGhlciBoaXMgbG9jYXRpb24pLjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLVRoZSBsb2NhdGlvbiBjb252ZXlh bmNlIGRyYWZ0IHNwZWNpZmljYWxseSBjYWxscyBvdXQgSU5GTyBhcyBhY2NlcHRhYmxlIGZvciBn ZW8tbG9jIGluZm8uJm5ic3A7IFdoZXRoZXIgdGhpcyBpcyBhIHJlYWwgdXNlLWNhc2UgaXMgZGVi YXRhYmxlLCBhbmQgb2J2aW91c2x5IGl0IGNvdWxkIGJlIGRvbmUgd2l0aCBhIHN1Yi9ub3QuPEJS PjxCUj43KSBTZW5kaW5nIHNvZnRrZXktbGFiZWxzIChub3QgZGlnaXQtbWF0Y2ggbWFwcywgYnV0 IHJhdGhlciBzb2Z0a2V5IGJ1dHRvbiBsYWJlbHMpLiZuYnNwOyBBbGljZSBjYWxscyBoZXIgdm1h aWwgc2VydmVyLiZuYnNwOyBWbWFpbCBzZXJ2ZXIgc2VuZHMgc29mdGtleS1sYWJlbHMgZm9yIHRo ZSBtZW51IGl0ZW1zIGF2YWlsYWJsZSBpbiB0aGUgcmVzcG9uc2UsIEFsaWNlIHByZXNzZXMgc29m dGtleXMgYW5kIHNlbmRzIHRoZW0gaW4gSU5GTy48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1UaGlzIGNvdWxkIChhbmQgbWF5YmUgc2hvdWxkKSBiZSBkb25l IHdpdGggc3ViL25vdCwgYSBsYSBLUE1MLCB3aGVyZSB0aGUgdm1haWwgc2VydmVyIHNlbmRzIHRo ZSBzb2Z0a2V5IGxhYmVscyBpbiB0aGUgU3Vic2NyaWJlLCBVQSBzZW5kcyBidXR0b25zIHByZXNz ZWQgaW4gTm90aWZpZXMuJm5ic3A7IEJ1dCB0aGlzIGlzIHNpbWlsYXIgdG8gdGhlIERUTUYgdXNl IGNhc2Ugc28gbWF5IHdlbGwgaGF2ZSB0aGUgc2FtZSBiZW5lZml0IG9mIGxvd2VyIG92ZXJoZWFk IHNpbmNlIGJ1dHRvbnMgYXJlIHJhcmVseSBwcmVzc2VkLjxCUj48QlI+OCkgU2VuZGluZyBhIHNj cmVlbi1wb3AtdXAgbWVzc2FnZSwgZS5nLiwgIkRvIHlvdSB3YW50IHRvIGNvbnRpbnVlIHdpdGgg dGhpcyBzZXNzaW9uPyI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC1UaGVyZSBpcyBhIHBhdGVudCBmb3IgZG9pbmcgc2NyZWVuIHBvcC11cHMgdXNpbmcgSU5G Ty4mbmJzcDsgSSBndWVzcyBBbGVydC1JbmZvIGNvdWxkIGJlIHVzZWQgZm9yIHRoaXMsIGJ1dCBp dCdzIG5vdCBjbGVhciBpdCBzaG91bGQ/PEJSPjxCUj48QlI+LyoqKioqKioqKioqKioqKioqPEJS PiombmJzcDsgVXNlLWNhc2VzIHdoaWNoIGhhdmUgYmVlbiBwcm9wb3NlZCBieSBvdGhlcnMgb3Ig ZXZlbiBpbXBsZW1lbnRlZCw8QlI+KiZuYnNwOyB3aGljaCBhcmUgZHViaW91cyBmb3IgSU5GTyAo SU1ITyk6PEJSPioqKioqKioqKioqKioqKioqLzxCUj4xKSBTZW5kaW5nIFJUUC9SVENQIHN0YXRp c3RpY3MgZHVyaW5nIGNhbGwuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtVGhlcmUgaXMgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcywgYW5kIHRoZSByYXRp b25hbGUgaXMgdGhlIHNpZ25hbGluZyBwbGFuZSBib3ggdGhhdCB3YW50cyB0aGlzIGluZm8gaXMg bm90IGFjdHVhbGx5IHRoZSBtZWRpYSBwbGFuZSBib3ggdGhhdCBnZXRzIFJUQ1AuJm5ic3A7IEFn YWluIHRoaXMgY291bGQgKGFuZCBJTU8gc2hvdWxkKSBiZSBkb25lIHdpdGggc3ViL25vdCwgc28g aXQgY2FuIGdldCBzdGF0cyBhZnRlciB0aGUgY2FsbCBpcyBvdmVyLCBhbmQgc2luY2UgaXQgd2ls bCBwcm9iYWJseSB3YW50IHBlcmlvZGljIHJlcG9ydHMgdGhlIG92ZXJoZWFkIG9mIHRoZSBTdWJz Y3JpYmUgc2hvdWxkIGJlIGR3YXJmZWQgYnkgdGhlIG51bWJlciBvZiBOb3RpZmllcy48QlI+PEJS PjIpIFNlbmRpbmcgYWNjZXNzLWxvY2F0aW9uIGluZm9ybWF0aW9uIGFmdGVyIGNhbGwgZXN0YWJs aXNobWVudC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1U aGVyZSBpcyBhIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBoZWFkZXIsIGFuZCBzb21lIGhhdmUgcHJv cG9zZWQgdG8gc2VuZCBhbiB1cGRhdGUgZm9yIGl0IGFzIGEgcGhvbmUgcm9hbXMgYWNjZXNzIHBv aW50cyBvciBjZWxscy4mbmJzcDsgQnV0IEkgdGhpbmsgdGhpcyBpcyBhbiBvZGQgdGhpbmcgdG8g ZG8gaW5zaWRlIGFuIEludml0ZSBzZXNzaW9uLCB2cy4gaW4gYSBzdWIvbm90IG9yIFJlZ2lzdGVy IChhbmQgYmVzaWRlcyBoYWxmIHRoZSB0aW1lIHRoZSBuZXR3b3JrIGluc2VydHMgdGhpcyBoZWFk ZXIsIG5vdCB0aGUgVUEpLjxCUj48QlI+MykgU2VuZGluZyBtZWRpYS1jb250cm9sIGluZGljYXRp b25zIChpZSwgcmVtb3RlLWNvbnRyb2wgInBsYXkvcGF1c2UvZXRjLiIpPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtVGhpcyBpcyBkb25lIHRvZGF5IGJ5IGF0 IGxlYXN0IG9uZSB2ZW5kb3IsIGJ1dCBpcyBkZWJhdGFibGUgaWYgaXQncyB0aGUgcmlnaHQgbW9k ZWwuJm5ic3A7IFRoZSBhcmd1bWVudCBpcyBpdCdzIGxpa2UgU0RQIHJlLUludml0ZSBmb3IgaG9s ZCwgZXhjZXB0IGF0IGEgbWVkaWEgY29udGVudCBsYXllciBhYm92ZSBSVFAsIHNvIG5vdCBkb25l IGluIFJUQ1Agbm9yIFNEUC48QlI+PEJSPjQpIFNlbmRpbmcgdmlkZW8gZmFzdCB1cGRhdGUgY29t bWFuZDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLVRoaXMg aXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCwgd2hpY2ggZG9jdW1lbnRzIHdoYXQgaGFzIGJlZW4g aW1wbGVtZW50ZWQsIGJ1dCBzdGF0ZXMgaXQgc2hvdWxkIHJlYWxseSBiZSBkb25lIGluIHRoZSBt ZWRpYSBwbGFuZS48QlI+PEJSPjUpIFNlbmRpbmcgcGVyaXBoZXJhbCBjb250cm9sIGNvbW1hbmRz IChpZSwgVVNCIGNvbW1hbmRzKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLVRoZXJlIGlzIGFjdHVhbGx5IGEgcGF0ZW50IG9uIHRoaXMsIGFtYXppbmdseS4m bmJzcDsgU29tZW9uZSB0aGlua3MgaXQgbWFrZXMgc2Vuc2UgdG8gY3JlYXRlIGEgU0lQIHNlc3Np b24gdG8geW91ciBsYXB0b3AsIG9yIHZpY2UtdmVyc2EsIGFuZCB0aGVuIHNlbmQgVVNCIGNvbW1h bmRzIGluc2lkZSBNSU1FIGluIElORk8gbWVzc2FnZXMuJm5ic3A7IE1ldGhpbmtzIHRoaXMgc2hv dWxkIGJlIG1lZGlhLXBsYW5lLCBpZiBhbnl0aGluZy48QlI+PEJSPjYpIFNlbmRpbmcgY2hhcmdp bmcgaW5mb3JtYXRpb24gZm9yIGEgY2FsbCAoaS5lLiwgbWludXRlcyByZW1haW5pbmcgb3IgY29z dCBzbyBmYXIpLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LVRoZXJlIHdhcyBhIHByb3Bvc2FsIHRvIHVzZSB0aGlzIGZvciBBZHZpY2Ugb2YgQ2hhcmdlIGlu Zm9ybWF0aW9uIGluIFRJU1BBTi4mbmJzcDsgSU1PIGl0IHNob3VsZCBiZSBhIHN1Yi9ub3QgdGhv dWdoLCBhcyB0aGV5IHdhbnQgdGhpcyB0byBzdXJ2aXZlIHRoZSBJbnZpdGUgc2Vzc2lvbi48QlI+ PEJSPi1oYWRyaWVsPEJSPjxCUj48QlI+PC9GT05UPjwvUD48L0RJVj48L0RJVj48L2JvZHk+ ------=_NextPart_000_01FF_01C838C2.0D420320-- --===============0190185869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0190185869==-- From sip-bounces@ietf.org Thu Dec 06 21:28:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SwA-0000JD-Mp; Thu, 06 Dec 2007 21:27:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Sw8-0000Ad-TB for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:27:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sw8-0000AV-GE for sip@ietf.org; Thu, 06 Dec 2007 21:27:32 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0Sw6-0005ul-Pq for sip@ietf.org; Thu, 06 Dec 2007 21:27:32 -0500 X-VirusChecked: Checked X-Env-Sender: sam.ganesan@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1196994445!43151503!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 32117 invoked from network); 7 Dec 2007 02:27:25 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-119.messagelabs.com with SMTP; 7 Dec 2007 02:27:25 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id lB72ROYw004487 for ; Thu, 6 Dec 2007 19:27:24 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB72RNj6007114 for ; Thu, 6 Dec 2007 20:27:23 -0600 (CST) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB72RLJ7007104 for ; Thu, 6 Dec 2007 20:27:22 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] INFO use-cases Date: Thu, 6 Dec 2007 21:27:21 -0500 Message-ID: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F7@de01exm62.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases thread-index: Acg4dss5+DQy4LtiTzWhVGvTO5xqRQAADGTe References: <4758AC44.6030900@cisco.com> From: "Ganesan Sam-W00184" To: "Paul Kyzivat" , "Hadriel Kaplan" X-CFilter-Loop: Reflected X-Spam-Score: 1.8 (+) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1107572303==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1107572303== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83878.B1FD434D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83878.B1FD434D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul: =20 In fact if INFO is outlawed for anything but DTMF.... ATIS and tispan = 3 will probably use Message in doing the npt book mark stuff... And = there are quite a few proprietary use cases that will never show up on = the list. Yes I do know the argument that "they are proprietary and we = dont care about... Let the devil take them ..." I am not sure about = that one =20 Sam ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thu 12/6/2007 9:13 PM To: Hadriel Kaplan Cc: sip@ietf.org Subject: Re: [Sip] INFO use-cases Hadriel, I buy some of your use cases, but not others. Comments below. A competitor for INFO in several of these is MESSAGE. I think a good case can be made for that if the information is to be rendered to the recipient. Paul Hadriel Kaplan wrote: [snip] > /**************** > * Use-cases that I think are potentially/possibly valid for INFO: > ****************/ > 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can = you send me John's vcard?", Bob clicks something and voila it's sent. > -Alternatives: send a re-Invite or Update with a Call-Info, = with either a URL reference, data URI, or MIME and CID URL. > -Counter-argument: IMO this type of data really belongs in = MIME for a number of reasons, including length is less restricted for = mime attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd. > -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call. > -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input. > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone. > -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon. > -Counter-argument: same as for vcard, plus with call-info = there is no way to know which picture format the far-end supports a = priori. With a supported-package negotiation one could know. For this case MESSAGE seems entirely appropriate. (Not so much so for vcard, which probably isn't intended to be directly rendered to the recipient.) > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says = "hey let's have a con call at time X", clicks and voila his phone sends = a vcalendar. > -Whether the vcalendar is related to the session or not and = thus whether it should be sent in an in-dialog request or not is = certainly debatable. Message method can already be used for this = anyway. > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser. > -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP). Yes to MESSAGE. > 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such. > -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe. > > 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location). > -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not. UPDATE with geo-loc is reasonable here, or even reINVITE. > 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO. > -This could (and maybe should) be done with sub/not, a la = KPML, where the vmail server sends the softkey labels in the Subscribe, = UA sends buttons pressed in Notifies. But this is similar to the DTMF = use case so may well have the same benefit of lower overhead since = buttons are rarely pressed. > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue = with this session?" > -There is a patent for doing screen pop-ups using INFO. I = guess Alert-Info could be used for this, but it's not clear it should? This is very definitely a use case for MESSAGE. Also, all of the above could probably be justifiably sent via MSRP - either directly or via the file transfer extensions. > /***************** > * Use-cases which have been proposed by others or even implemented, > * which are dubious for INFO (IMHO): > *****************/ > 1) Sending RTP/RTCP statistics during call. > -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies. > > 2) Sending access-location information after call establishment. > -There is a P-Access-Network-Info header, and some have = proposed to send an update for it as a phone roams access points or = cells. But I think this is an odd thing to do inside an Invite session, = vs. in a sub/not or Register (and besides half the time the network = inserts this header, not the UA). > > 3) Sending media-control indications (ie, remote-control = "play/pause/etc.") > -This is done today by at least one vendor, but is debatable = if it's the right model. The argument is it's like SDP re-Invite for = hold, except at a media content layer above RTP, so not done in RTCP nor = SDP. > > 4) Sending video fast update command > -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane. > > 5) Sending peripheral control commands (ie, USB commands) > -There is actually a patent on this, amazingly. Someone = thinks it makes sense to create a SIP session to your laptop, or = vice-versa, and then send USB commands inside MIME in INFO messages. = Methinks this should be media-plane, if anything. > > 6) Sending charging information for a call (i.e., minutes remaining or = cost so far). > -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session. > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C83878.B1FD434D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] INFO use-cases=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Paul:
=0A=
 
=0A=
In fact if INFO is outlawed = for anything but DTMF....   ATIS  and tispan 3 will = probably use Message  in doing the npt book mark stuff...  And = there are quite a few proprietary use cases that will never show up on = the list.  Yes I do know the argument that "they are proprietary = and we dont care about... Let the devil take them ..."  I am not = sure about that one
=0A=
 
=0A=
Sam
=0A=

=0A=
=0A= From: Paul Kyzivat = [mailto:pkyzivat@cisco.com]
Sent: Thu 12/6/2007 9:13 = PM
To: Hadriel Kaplan
Cc: = sip@ietf.org
Subject: Re: [Sip] INFO = use-cases

=0A=
=0A=

Hadriel,

I buy some of your use cases, but not = others. Comments below.

A competitor for INFO in several of these = is MESSAGE. I think a good
case can be made for that if the = information is to be rendered to = the
recipient.

        = Paul


Hadriel Kaplan wrote:
[snip]

> = /****************
> *  Use-cases that I think are = potentially/possibly valid for INFO:
> ****************/
> = 1) Sending a vcard asynchronously.  Alice calls Bob, Alice says = "can you send me John's vcard?", Bob clicks something and voila it's = sent.
>         = -Alternatives: send a re-Invite or Update with a Call-Info, with either = a URL reference, data URI, or MIME and CID = URL.
>         = -Counter-argument: IMO this type of data really belongs in MIME for a = number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated.  And = sending a re-Invite for this purpose seems = odd.
>         -Also, the = Call-Info header is really about the caller or callee, and thus Bob = shouldn't be sending me John's vcard info in it technically.  That = may sound like a nit, but UA's may well store the call-info vcards into = their address-books automatically and so tie it to the wrong = user/call.
>         -Pros = of using INFO: it's explicit what you're doing when you send the vcard, = and you can send it knowing the other end can accept it, and you can = send it based on user input.
>
> 2) Sending a user-icon = jpeg/bitmap/gif.  Alice calls Bob, Bob has an icon that represents = himself, sends it when he picks up the = phone.
>         = -Alternatives: send a 200ok, re-Invite, or Update with call-info, which = explicitly has a type for = icon.
>         = -Counter-argument: same as for vcard, plus with call-info there is no = way to know which picture format the far-end supports a priori.  = With a supported-package negotiation one could know.

For this = case MESSAGE seems entirely appropriate.

(Not so much so for = vcard, which probably isn't intended to be directly
rendered to the = recipient.)

> 3) Sending a vcalendar-type invitation.  = Alice calls Bob, Bob says "hey let's have a con call at time X", clicks = and voila his phone sends a = vcalendar.
>         = -Whether the vcalendar is related to the session or not and thus whether = it should be sent in an in-dialog request or not is certainly = debatable.  Message method can already be used for this = anyway.
>
> 4) Sending an HTTP URL.  Alice calls Bob, a = sales guy; Alice asks for more info or a datasheet and Bob sends a URL = for Alice to open with her = web-browser.
>         = -One could also argue this is just making SIP the new SMTP, or this = should be sent using MESSAGE (which really is the new SMTP).

Yes = to MESSAGE.

> 5) Sending a session traceroute.  Alice = calls Bob, Bob answers, Alice does a sip-traceroute to figure out the = path to Bob, by sending Info with an incrementing max-forwards type = header starting at 0 (but not really max-forwards), with a sip-frag type = response body or some = such.
>         -It's = debatable if certain types of B2BUA's (ie, SBCs) would ever allow this = type of thing to happen, due to security concerns, but I think they may = do it at domain boundary hops.  I think this is a reasonable use = for INFO though, maybe.
>
> 6) Sending geo-location = information after call establishment.  Alice calls Bob, a hotel = receptionist.  Alice asks for directions to hotel, clicks button = and sends him location info of her phone (or Bob clicks button and sends = her his = location).
>         -The = location conveyance draft specifically calls out INFO as acceptable for = geo-loc info.  Whether this is a real use-case is debatable, and = obviously it could be done with a sub/not.

UPDATE with geo-loc is = reasonable here, or even reINVITE.

> 7) Sending softkey-labels = (not digit-match maps, but rather softkey button labels).  Alice = calls her vmail server.  Vmail server sends softkey-labels for the = menu items available in the response, Alice presses softkeys and sends = them in INFO.
>         = -This could (and maybe should) be done with sub/not, a la KPML, where = the vmail server sends the softkey labels in the Subscribe, UA sends = buttons pressed in Notifies.  But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed.
>
> 8) Sending a screen-pop-up message, = e.g., "Do you want to continue with this = session?"
>         -There = is a patent for doing screen pop-ups using INFO.  I guess = Alert-Info could be used for this, but it's not clear it = should?

This is very definitely a use case for = MESSAGE.

Also, all of the above could probably be justifiably = sent via MSRP -
either directly or via the file transfer = extensions.

> /*****************
> *  Use-cases = which have been proposed by others or even implemented,
> *  = which are dubious for INFO (IMHO):
> *****************/
> 1) = Sending RTP/RTCP statistics during = call.
>         -There is = an implementation of this, and the rationale is the signaling plane box = that wants this info is not actually the media plane box that gets = RTCP.  Again this could (and IMO should) be done with sub/not, so = it can get stats after the call is over, and since it will probably want = periodic reports the overhead of the Subscribe should be dwarfed by the = number of Notifies.
>
> 2) Sending access-location = information after call = establishment.
>         = -There is a P-Access-Network-Info header, and some have proposed to send = an update for it as a phone roams access points or cells.  But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA).
>
> 3) Sending media-control = indications (ie, remote-control = "play/pause/etc.")
>        = ; -This is done today by at least one vendor, but is debatable if it's = the right model.  The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor = SDP.
>
> 4) Sending video fast update = command
>         -This is = an informational draft, which documents what has been implemented, but = states it should really be done in the media plane.
>
> 5) = Sending peripheral control commands (ie, USB = commands)
>         -There = is actually a patent on this, amazingly.  Someone thinks it makes = sense to create a SIP session to your laptop, or vice-versa, and then = send USB commands inside MIME in INFO messages.  Methinks this = should be media-plane, if anything.
>
> 6) Sending charging = information for a call (i.e., minutes remaining or cost so = far).
>         -There was = a proposal to use this for Advice of Charge information in TISPAN.  = IMO it should be a sub/not though, as they want this to survive the = Invite session.
>
> -hadriel
>
>
> = _______________________________________________
> Sip mailing = list  https://www1.ietf.org= /mailman/listinfo/sip
> This list is for NEW development of = the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new = developments on the application of = sip
>


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

=0A= =0A=
------_=_NextPart_001_01C83878.B1FD434D-- --===============1107572303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1107572303==-- From sip-bounces@ietf.org Thu Dec 06 21:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0T7Y-0006Ib-7C; Thu, 06 Dec 2007 21:39:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0T7W-00069C-KA for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:39:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0T7W-00067a-9m for sip@ietf.org; Thu, 06 Dec 2007 21:39:18 -0500 Received: from itclus2.sea5.speakeasy.net ([72.1.141.56] helo=EXCHANGE-BE2.speakeasy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0T7V-00005w-Tj for sip@ietf.org; Thu, 06 Dec 2007 21:39:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Thu, 6 Dec 2007 18:39:16 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg29s54K2uSMgVsQq+p+ys7MgzBFwAbRvRQABXJFjAAGp63IAAU71TA References: From: "Jane Jiang" To: "Brett Tate" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Brett, Though IPv6 was initially designed to address the IP address space issue, I feel like the mobility feature afforded by IPv6 address design is a true value added. =20 When we are mapping from IPv6 to IPv4, we will certainly loose some information. However, when we are mapping from IPv4 to IPv6, how can we expand the digits in a way that we can actually make the mapped IPv6 address to support mobility? That is my question. Thanks! Jane -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: Thursday, December 06, 2007 10:26 AM To: Jane Jiang; sip@ietf.org Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 > I guess the purpose of this discussion is about this particular draft, > which intends to correct some mistakes existing in some RFCs. Yes; the draft is expanding beyond the current ABNF fix to also correct or more clearly document other IPv6 areas of rfc3261. > I am wondering if you will want to discuss about the impacts of=20 > mapping between IPv6 address and IPv4 address? I'm not sure which aspect of mapping you are mentioning. Draft-ietf-sipping-v6-transition and draft-ietf-sipping-ipv6-torture-tests discuss some of the potential issues. > I feel like if we simply try to match the two from each other, we will > not be able to maintain the original design beauties behind each=20 > address structure. Correct me if I am wrong. I'm not sure that I understand the matching comment. The current understanding is that an IPv6 address does not equal an IPv4 address from a SIP equality perspective. However there are obviously situations/services on a device where they might be treated the same: identity, access control, etcetera. There are situations where an IPv6 address contains an IPv4 address. However I currently doubt that we need to discuss the matter beyond highlighting such an address concerning equality and maybe additionally 503, looping, downgrading to IPv4, etcetera. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 21:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TCA-0003dw-K3; Thu, 06 Dec 2007 21:44:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0TC8-0003de-9O for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TC7-0003dW-W5 for sip@ietf.org; Thu, 06 Dec 2007 21:44:03 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TC7-0000Ro-36 for sip@ietf.org; Thu, 06 Dec 2007 21:44:03 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Thu, 6 Dec 2007 21:44:02 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 6 Dec 2007 21:44:02 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 6 Dec 2007 21:43:27 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg4dsjnLBBZdZogQhaIB2OjawmM7wAAxPmQ Message-ID: References: <4758AC44.6030900@cisco.com> In-Reply-To: <4758AC44.6030900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey Paul, Yeah I agree MESSAGE makes a lot of sense for things to be rendered nativel= y/directly to the user. Regarding using MSRP: while that is obviously possible and for some cases u= ndoubtedly the right thing to do, for some uses it is a crazy amount of ove= rhead. For example if I want to send you a vcard mid-call, it seems silly = to send a re-Invite to add an MSRP session, potentially go get msrp-relay i= nfo to do so, and/or possibly go through ICE procedures, all just to send y= ou a 100 byte little vcard I could have sent in an INFO. But clearly if I = need to send you a 10MB file it will be appropriate. My 2 cents anyway. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, December 06, 2007 9:13 PM > To: Hadriel Kaplan > Cc: sip@ietf.org > Subject: Re: [Sip] INFO use-cases > > Hadriel, > > I buy some of your use cases, but not others. Comments below. > > A competitor for INFO in several of these is MESSAGE. I think a good > case can be made for that if the information is to be rendered to the > recipient. > > Paul > > > Hadriel Kaplan wrote: > [snip] > > > /**************** > > * Use-cases that I think are potentially/possibly valid for INFO: > > ****************/ > > 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can yo= u > send me John's vcard?", Bob clicks something and voila it's sent. > > -Alternatives: send a re-Invite or Update with a Call-Info, wit= h > either a URL reference, data URI, or MIME and CID URL. > > -Counter-argument: IMO this type of data really belongs in MIME > for a number of reasons, including length is less restricted for mime > attachments; one AD has said the Data URL may be deprecated. And sending > a re-Invite for this purpose seems odd. > > -Also, the Call-Info header is really about the caller or > callee, and thus Bob shouldn't be sending me John's vcard info in it > technically. That may sound like a nit, but UA's may well store the call= - > info vcards into their address-books automatically and so tie it to the > wrong user/call. > > -Pros of using INFO: it's explicit what you're doing when you > send the vcard, and you can send it knowing the other end can accept it, > and you can send it based on user input. > > > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an > icon that represents himself, sends it when he picks up the phone. > > -Alternatives: send a 200ok, re-Invite, or Update with call- > info, which explicitly has a type for icon. > > -Counter-argument: same as for vcard, plus with call-info there > is no way to know which picture format the far-end supports a priori. > With a supported-package negotiation one could know. > > For this case MESSAGE seems entirely appropriate. > > (Not so much so for vcard, which probably isn't intended to be directly > rendered to the recipient.) > > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey > let's have a con call at time X", clicks and voila his phone sends a > vcalendar. > > -Whether the vcalendar is related to the session or not and thu= s > whether it should be sent in an in-dialog request or not is certainly > debatable. Message method can already be used for this anyway. > > > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for > more info or a datasheet and Bob sends a URL for Alice to open with her > web-browser. > > -One could also argue this is just making SIP the new SMTP, or > this should be sent using MESSAGE (which really is the new SMTP). > > Yes to MESSAGE. > > > 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice > does a sip-traceroute to figure out the path to Bob, by sending Info with > an incrementing max-forwards type header starting at 0 (but not really > max-forwards), with a sip-frag type response body or some such. > > -It's debatable if certain types of B2BUA's (ie, SBCs) would > ever allow this type of thing to happen, due to security concerns, but I > think they may do it at domain boundary hops. I think this is a > reasonable use for INFO though, maybe. > > > > 6) Sending geo-location information after call establishment. Alice > calls Bob, a hotel receptionist. Alice asks for directions to hotel, > clicks button and sends him location info of her phone (or Bob clicks > button and sends her his location). > > -The location conveyance draft specifically calls out INFO as > acceptable for geo-loc info. Whether this is a real use-case is > debatable, and obviously it could be done with a sub/not. > > UPDATE with geo-loc is reasonable here, or even reINVITE. > > > 7) Sending softkey-labels (not digit-match maps, but rather softkey > button labels). Alice calls her vmail server. Vmail server sends > softkey-labels for the menu items available in the response, Alice presse= s > softkeys and sends them in INFO. > > -This could (and maybe should) be done with sub/not, a la KPML, > where the vmail server sends the softkey labels in the Subscribe, UA send= s > buttons pressed in Notifies. But this is similar to the DTMF use case so > may well have the same benefit of lower overhead since buttons are rarely > pressed. > > > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue with > this session?" > > -There is a patent for doing screen pop-ups using INFO. I gues= s > Alert-Info could be used for this, but it's not clear it should? > > This is very definitely a use case for MESSAGE. > > Also, all of the above could probably be justifiably sent via MSRP - > either directly or via the file transfer extensions. > > > /***************** > > * Use-cases which have been proposed by others or even implemented, > > * which are dubious for INFO (IMHO): > > *****************/ > > 1) Sending RTP/RTCP statistics during call. > > -There is an implementation of this, and the rationale is the > signaling plane box that wants this info is not actually the media plane > box that gets RTCP. Again this could (and IMO should) be done with > sub/not, so it can get stats after the call is over, and since it will > probably want periodic reports the overhead of the Subscribe should be > dwarfed by the number of Notifies. > > > > 2) Sending access-location information after call establishment. > > -There is a P-Access-Network-Info header, and some have propose= d > to send an update for it as a phone roams access points or cells. But I > think this is an odd thing to do inside an Invite session, vs. in a > sub/not or Register (and besides half the time the network inserts this > header, not the UA). > > > > 3) Sending media-control indications (ie, remote-control > "play/pause/etc.") > > -This is done today by at least one vendor, but is debatable if > it's the right model. The argument is it's like SDP re-Invite for hold, > except at a media content layer above RTP, so not done in RTCP nor SDP. > > > > 4) Sending video fast update command > > -This is an informational draft, which documents what has been > implemented, but states it should really be done in the media plane. > > > > 5) Sending peripheral control commands (ie, USB commands) > > -There is actually a patent on this, amazingly. Someone thinks > it makes sense to create a SIP session to your laptop, or vice-versa, and > then send USB commands inside MIME in INFO messages. Methinks this shoul= d > be media-plane, if anything. > > > > 6) Sending charging information for a call (i.e., minutes remaining or > cost so far). > > -There was a proposal to use this for Advice of Charge > information in TISPAN. IMO it should be a sub/not though, as they want > this to survive the Invite session. > > > > -hadriel > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 21:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TGu-0005oF-CC; Thu, 06 Dec 2007 21:49:00 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0TGt-0005o0-Dx for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 21:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TGt-0005nq-4M for sip@ietf.org; Thu, 06 Dec 2007 21:48:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TGr-0000op-WE for sip@ietf.org; Thu, 06 Dec 2007 21:48:59 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 06 Dec 2007 18:48:57 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB72mvDj013488; Thu, 6 Dec 2007 18:48:57 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lB72muU4011015; Fri, 7 Dec 2007 02:48:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:48:56 -0800 Received: from [10.21.122.251] ([10.21.122.251]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:48:54 -0800 Message-ID: <4758B494.7010103@cisco.com> Date: Thu, 06 Dec 2007 21:48:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO use-cases References: <4758AC44.6030900@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2007 02:48:54.0856 (UTC) FILETIME=[B4FB4C80:01C8387B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8846; t=1196995737; x=1197859737; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20use-cases |Sender:=20; bh=VspbnWiKIOKcX+sM5h5koth2rSlFJhOLpAv82OFYgxE=; b=AoUstLn93wOCH6gP36ykOHM+SFzFOeo0BfNkU0JLIzKFQpC68EI/5AUXscVGap/pygSXqptu h7QwRjXVEeENlornAvugqfXs3r5GwoybATlhSDs/OBkKzzHLSO2ZA3G4; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Hey Paul, > Yeah I agree MESSAGE makes a lot of sense for things to be rendered natively/directly to the user. > > Regarding using MSRP: while that is obviously possible and for some cases undoubtedly the right thing to do, for some uses it is a crazy amount of overhead. For example if I want to send you a vcard mid-call, it seems silly to send a re-Invite to add an MSRP session, potentially go get msrp-relay info to do so, and/or possibly go through ICE procedures, all just to send you a 100 byte little vcard I could have sent in an INFO. But clearly if I need to send you a 10MB file it will be appropriate. My 2 cents anyway. Yes, I agree. In some cases even though it is a rediculous amount of overhead it just won't matter and will be the right thing to do anyway if the infrastructure is there to do it. In other cases that isn't so. I'm certainly open to some uses for INFO or for more marginal uses of MESSAGE. Especially if we go ahead with this INFO enhancement I think we need to draw the line carefully between INFO and MESSAGE. Paul > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, December 06, 2007 9:13 PM >> To: Hadriel Kaplan >> Cc: sip@ietf.org >> Subject: Re: [Sip] INFO use-cases >> >> Hadriel, >> >> I buy some of your use cases, but not others. Comments below. >> >> A competitor for INFO in several of these is MESSAGE. I think a good >> case can be made for that if the information is to be rendered to the >> recipient. >> >> Paul >> >> >> Hadriel Kaplan wrote: >> [snip] >> >>> /**************** >>> * Use-cases that I think are potentially/possibly valid for INFO: >>> ****************/ >>> 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you >> send me John's vcard?", Bob clicks something and voila it's sent. >>> -Alternatives: send a re-Invite or Update with a Call-Info, with >> either a URL reference, data URI, or MIME and CID URL. >>> -Counter-argument: IMO this type of data really belongs in MIME >> for a number of reasons, including length is less restricted for mime >> attachments; one AD has said the Data URL may be deprecated. And sending >> a re-Invite for this purpose seems odd. >>> -Also, the Call-Info header is really about the caller or >> callee, and thus Bob shouldn't be sending me John's vcard info in it >> technically. That may sound like a nit, but UA's may well store the call- >> info vcards into their address-books automatically and so tie it to the >> wrong user/call. >>> -Pros of using INFO: it's explicit what you're doing when you >> send the vcard, and you can send it knowing the other end can accept it, >> and you can send it based on user input. >>> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an >> icon that represents himself, sends it when he picks up the phone. >>> -Alternatives: send a 200ok, re-Invite, or Update with call- >> info, which explicitly has a type for icon. >>> -Counter-argument: same as for vcard, plus with call-info there >> is no way to know which picture format the far-end supports a priori. >> With a supported-package negotiation one could know. >> >> For this case MESSAGE seems entirely appropriate. >> >> (Not so much so for vcard, which probably isn't intended to be directly >> rendered to the recipient.) >> >>> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey >> let's have a con call at time X", clicks and voila his phone sends a >> vcalendar. >>> -Whether the vcalendar is related to the session or not and thus >> whether it should be sent in an in-dialog request or not is certainly >> debatable. Message method can already be used for this anyway. >>> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for >> more info or a datasheet and Bob sends a URL for Alice to open with her >> web-browser. >>> -One could also argue this is just making SIP the new SMTP, or >> this should be sent using MESSAGE (which really is the new SMTP). >> >> Yes to MESSAGE. >> >>> 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice >> does a sip-traceroute to figure out the path to Bob, by sending Info with >> an incrementing max-forwards type header starting at 0 (but not really >> max-forwards), with a sip-frag type response body or some such. >>> -It's debatable if certain types of B2BUA's (ie, SBCs) would >> ever allow this type of thing to happen, due to security concerns, but I >> think they may do it at domain boundary hops. I think this is a >> reasonable use for INFO though, maybe. >>> 6) Sending geo-location information after call establishment. Alice >> calls Bob, a hotel receptionist. Alice asks for directions to hotel, >> clicks button and sends him location info of her phone (or Bob clicks >> button and sends her his location). >>> -The location conveyance draft specifically calls out INFO as >> acceptable for geo-loc info. Whether this is a real use-case is >> debatable, and obviously it could be done with a sub/not. >> >> UPDATE with geo-loc is reasonable here, or even reINVITE. >> >>> 7) Sending softkey-labels (not digit-match maps, but rather softkey >> button labels). Alice calls her vmail server. Vmail server sends >> softkey-labels for the menu items available in the response, Alice presses >> softkeys and sends them in INFO. >>> -This could (and maybe should) be done with sub/not, a la KPML, >> where the vmail server sends the softkey labels in the Subscribe, UA sends >> buttons pressed in Notifies. But this is similar to the DTMF use case so >> may well have the same benefit of lower overhead since buttons are rarely >> pressed. >>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue with >> this session?" >>> -There is a patent for doing screen pop-ups using INFO. I guess >> Alert-Info could be used for this, but it's not clear it should? >> >> This is very definitely a use case for MESSAGE. >> >> Also, all of the above could probably be justifiably sent via MSRP - >> either directly or via the file transfer extensions. >> >>> /***************** >>> * Use-cases which have been proposed by others or even implemented, >>> * which are dubious for INFO (IMHO): >>> *****************/ >>> 1) Sending RTP/RTCP statistics during call. >>> -There is an implementation of this, and the rationale is the >> signaling plane box that wants this info is not actually the media plane >> box that gets RTCP. Again this could (and IMO should) be done with >> sub/not, so it can get stats after the call is over, and since it will >> probably want periodic reports the overhead of the Subscribe should be >> dwarfed by the number of Notifies. >>> 2) Sending access-location information after call establishment. >>> -There is a P-Access-Network-Info header, and some have proposed >> to send an update for it as a phone roams access points or cells. But I >> think this is an odd thing to do inside an Invite session, vs. in a >> sub/not or Register (and besides half the time the network inserts this >> header, not the UA). >>> 3) Sending media-control indications (ie, remote-control >> "play/pause/etc.") >>> -This is done today by at least one vendor, but is debatable if >> it's the right model. The argument is it's like SDP re-Invite for hold, >> except at a media content layer above RTP, so not done in RTCP nor SDP. >>> 4) Sending video fast update command >>> -This is an informational draft, which documents what has been >> implemented, but states it should really be done in the media plane. >>> 5) Sending peripheral control commands (ie, USB commands) >>> -There is actually a patent on this, amazingly. Someone thinks >> it makes sense to create a SIP session to your laptop, or vice-versa, and >> then send USB commands inside MIME in INFO messages. Methinks this should >> be media-plane, if anything. >>> 6) Sending charging information for a call (i.e., minutes remaining or >> cost so far). >>> -There was a proposal to use this for Advice of Charge >> information in TISPAN. IMO it should be a sub/not though, as they want >> this to survive the Invite session. >>> -hadriel >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 06 23:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VEP-0000EX-K6; Thu, 06 Dec 2007 23:54:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0VEN-0000EP-Rg for sip-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 23:54:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VEN-0000EH-Hf for sip@ietf.org; Thu, 06 Dec 2007 23:54:31 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0VEL-000838-FZ for sip@ietf.org; Thu, 06 Dec 2007 23:54:31 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Dec 2007 23:54:21 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB74sLS4014232; Thu, 6 Dec 2007 23:54:21 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB74sGaC001135; Fri, 7 Dec 2007 04:54:20 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 23:54:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] INFO use-cases Date: Thu, 6 Dec 2007 23:54:17 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E045363F6@xmb-rtp-215.amer.cisco.com> In-Reply-To: <01fe01c83876$9d5a5b20$df2a0693@oasys.kt.co.kr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAqGCewAAa5NCA= From: "Sanjay Sinha (sanjsinh)" To: =?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=?= , "Hadriel Kaplan" X-OriginalArrivalTime: 07 Dec 2007 04:54:19.0838 (UTC) FILETIME=[3A386DE0:01C8388D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24053; t=1197003261; x=1197867261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20INFO=20use-cases |Sender:=20 |To:=20=3D?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=3D? =3D=20,=0A=20=20=20=20=20=20=20=20=22Hadri el=20Kaplan=22=20; bh=dY7HO1s02V+sfIBjdS/2G3t9Yc9pJsCkIYQE/ztExyI=; b=HebyntzulC20f1SRz32ECL6K9ShuIgJyyHPe7UrAHJ6ffzWgTBou7qm4hS ySMPjwb2AxjXuhrvYQezi/IV1SvYLuTUzabOLxYdqvRfb7eyzaACS6bhGXUk 1+3tBGjH+1; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067816688==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2067816688== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8388D.3A039C6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8388D.3A039C6C Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable These 3 use cases below seem misuse of INFO as there are established = mechanism of doing these using non-INFO way. ________________________________ From: =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr]=20 Sent: Thursday, December 06, 2007 9:12 PM To: Hadriel Kaplan Cc: sip@ietf.org Subject: RE: [Sip] INFO use-cases =09 =09 =20 Dear Hadriel Kaplan and folks =20 (in our case)=20 Midcall INFO is used in=20 =20 1) Three-way calling: to add another party to existing call=20 2) Call waiting: to change dialogue between two ongoing calls 3) Centrex services: call transfer, etc. =20 THX =20 JK Hwang KT -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6----- =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 10:48:19 =B9=DE=B4=C2 =BB=E7=B6=F7: = "=C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC]" = =C2=FC=C1=B6: "sip@ietf.org" =C1=A6=B8=F1: RE: [Sip] INFO use-cases =09 =09 Hi JK, I actually saw that draft but did not include it because I thought it = was essentially another DTMF-style event type, and would be subsumed = into it, but you're right I should have included that use-case. Sorry! =09 -hadriel =09 =09 ________________________________________ From: =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr] Sent: Thursday, December 06, 2007 8:33 PM To: Hadriel Kaplan; sip@ietf.org Subject: RE: [Sip] INFO use-cases Dear folks, How about the Midcall INFO ? When 'Hook-Flash' from the SIP or POTS phone during a dialogue, we = (KT) use INFO method from the CSCF/MGCF to AS. I submitted a draft I-D two years ago but it was not accepted, But we still use the case. Can it be another Use-Case ? JK Hwang KT =09 -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6----- =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 8:38:36 =B9=DE=B4=C2 =BB=E7=B6=F7: "sip@ietf.org" =C2=FC=C1=B6: =C1=A6=B8=F1: [Sip] INFO use-cases =09 =09 Howdy, Jonathan asked for use-cases for what types of things would need an = in-dialog SIP message for user-user communication, vs. should be done = either out of dialog or in the media plane. If the only use-case is = DTMF, then we could just document the DTMF negotiation/use only and not = have to create a general info-events framework. That seems a very = reasonable argument to me. I also don't want to do work for no use. =09 There is a counter-argument that there are proprietary uses of INFO in = the wild, and that a framework for negotiation at least removes the = manual configuration of vendor-specific profiles, which is a problem of = interop today - even if the IETF should not bless/document the specific = use cases themselves. But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread. =09 The chairs have asked for 3 use cases, and I assume they mean 3 NEW use = cases (we already have 3 RFCs which use INFO, as well as DTMF). I am = not sure if they mean potential future use-cases, or current use-cases = (i.e., already implemented). Can I get a clarification on that? =09 So anyway, taking the shot-gun approach, here's a first go at some = use-cases, and my personal take on whether they should be in INFO vs. = SUB/NOT vs. media-plane, FWIW. [apologize for formatting ugliness] =09 /*************** * Already standardized use-cases: ***************/ 1) SIP-T/ISUP/QSIG/PSTN -Documented in RFC 3372 and RFC 4497. =09 2) ECMA TR/87 uaCSTA -Uses INFO to send ECMA-323 XML for monitoring and controlling = phones from a PC. =09 3) Sending media server control commands. -Documented in RFC4722 MSCML. =09 =09 /**************** * Use-cases that I think are potentially/possibly valid for INFO: ****************/ 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can = you send me John's vcard?", Bob clicks something and voila it's sent. -Alternatives: send a re-Invite or Update with a Call-Info, = with either a URL reference, data URI, or MIME and CID URL. -Counter-argument: IMO this type of data really belongs in MIME = for a number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd. =09 -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call. -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input. =09 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone. -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon. -Counter-argument: same as for vcard, plus with call-info there = is no way to know which picture format the far-end supports a priori. = With a supported-package negotiation one could know. =09 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey = let's have a con call at time X", clicks and voila his phone sends a = vcalendar.. -Whether the vcalendar is related to the session or not and = thus whether it should be sent in an in-dialog request or not is = certainly debatable. Message method can already be used for this = anyway. =09 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser. -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP). =09 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such. -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe. =09 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location). -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not. =09 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO. -This could (and maybe should) be done with sub/not, a la KPML, = where the vmail server sends the softkey labels in the Subscribe, UA = sends buttons pressed in Notifies. But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed. =09 8) Sending a screen-pop-up message, e.g., "Do you want to continue with = this session?" -There is a patent for doing screen pop-ups using INFO. I = guess Alert-Info could be used for this, but it's not clear it should? =09 =09 /***************** * Use-cases which have been proposed by others or even implemented, * which are dubious for INFO (IMHO): *****************/ 1) Sending RTP/RTCP statistics during call. -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies. =09 2) Sending access-location information after call establishment. -There is a P-Access-Network-Info header, and some have = proposed to send an update for it as a phone roams access points or = cells. But I think this is an odd thing to do inside an Invite session, = vs. in a sub/not or Register (and besides half the time the network = inserts this header, not the UA). =09 3) Sending media-control indications (ie, remote-control = "play/pause/etc.") -This is done today by at least one vendor, but is debatable if = it's the right model. The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor SDP. =09 4) Sending video fast update command -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane. =09 5) Sending peripheral control commands (ie, USB commands) -There is actually a patent on this, amazingly. Someone thinks = it makes sense to create a SIP session to your laptop, or vice-versa, = and then send USB commands inside MIME in INFO messages. Methinks this = should be media-plane, if anything. =09 6) Sending charging information for a call (i.e., minutes remaining or = cost so far). -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session. =09 -hadriel =09 =09 =09 ------_=_NextPart_001_01C8388D.3A039C6C Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
These 3 use cases below seem misuse of INFO as = there are=20 established mechanism of doing these using non-INFO = way.

From: = =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr]=20
Sent: Thursday, December 06, 2007 9:12 PM
To: = Hadriel=20 Kaplan
Cc: sip@ietf.org
Subject: RE: [Sip] INFO=20 use-cases

 

Dear Hadriel Kaplan and folks

 

(in our case)

Midcall INFO is used in

 

1) Three-way calling: to add another party to existing = call 

2) Call waiting: to change dialogue between two ongoing calls

3) Centrex services: call transfer, etc.

 

THX

 

JK Hwang

KT
-----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----
=BA=B8=B3=BD = =BB=E7=B6=F7: "Hadriel Kaplan"=20 <HKaplan@acmepacket.com>
=BA=B8=B3=BD =B3=AF=C2=A5: = 2007-12-07 =BF=C0=C0=FC=20 10:48:19
=B9=DE=B4=C2 =BB=E7=B6=F7: = "=C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC]" = <jkhwang@kt.co.kr>
=C2=FC=C1=B6:=20 "sip@ietf.org" <sip@ietf.org>
=C1=A6=B8=F1: RE: [Sip] = INFO=20 use-cases

Hi JK,
I actually saw that draft but did not = include it=20 because I thought it was essentially another DTMF-style event type, = and would=20 be subsumed into it, but you're right I should have included that=20 use-case. =20 = Sorry!

-hadriel


_______________________________________= _
From:=20 =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] [mailto:jkhwang@kt.co.kr]
Sent: Thursday, = December 06,=20 2007 8:33 PM
To: Hadriel Kaplan; sip@ietf.org
Subject: RE: [Sip] = INFO=20 use-cases
Dear folks,
 How about the Midcall INFO = ?
 When=20 'Hook-Flash' from the SIP or POTS phone during a dialogue, we (KT) use = INFO=20 method from the CSCF/MGCF to AS.
 I submitted a draft I-D two = years=20 ago but it was not accepted,
But we still use the = case.
 Can it be=20 another Use-Case ?
 JK Hwang
KT

-----=BF=F8=BA=BB = =B8=DE=BD=C3=C1=F6-----
=BA=B8=B3=BD =BB=E7=B6=F7:=20 "Hadriel Kaplan" <HKaplan@acmepacket.com>
=BA=B8=B3=BD = =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC=20 8:38:36
=B9=DE=B4=C2 =BB=E7=B6=F7: "sip@ietf.org" = <sip@ietf.org>
=C2=FC=C1=B6:
=C1=A6=B8=F1: [Sip] INFO=20 use-cases


Howdy,
Jonathan asked for use-cases for what = types of=20 things would need an in-dialog SIP message for user-user = communication, vs.=20 should be done either out of dialog or in the media plane.  If = the only=20 use-case is DTMF, then we could just document the DTMF negotiation/use = only=20 and not have to create a general info-events framework.  That = seems a=20 very reasonable argument to me.  I also don't want to do work for = no=20 use.

There is a counter-argument that there are proprietary = uses of=20 INFO in the wild, and that a framework for negotiation at least = removes the=20 manual configuration of vendor-specific profiles, which is a problem = of=20 interop today - even if the IETF should not bless/document the = specific use=20 cases themselves.  But that would make the draft a very different = one=20 than it currently is as well, and I will ask that in a separate email=20 thread.

The chairs have asked for 3 use cases, and I assume = they mean 3=20 NEW use cases (we already have 3 RFCs which use INFO, as well as = DTMF). =20 I am not sure if they mean potential future use-cases, or current = use-cases=20 (i.e., already implemented).  Can I get a clarification on=20 that?

So anyway, taking the shot-gun approach, here's a first = go at=20 some use-cases, and my personal take on whether they should be in INFO = vs.=20 SUB/NOT vs. media-plane, FWIW.
[apologize for formatting=20 ugliness]

/***************
*  Already standardized=20 use-cases:
***************/
1)=20 SIP-T/ISUP/QSIG/PSTN
        = -Documented=20 in RFC 3372 and RFC 4497.

2) ECMA TR/87=20 uaCSTA
        -Uses INFO to = send=20 ECMA-323 XML for monitoring and controlling phones from a = PC.

3)=20 Sending media server control=20 commands.
        -Documented in = RFC4722=20 MSCML.


/****************
*  Use-cases that I think = are=20 potentially/possibly valid for INFO:
****************/
1) = Sending a=20 vcard asynchronously.  Alice calls Bob, Alice says "can you send = me=20 John's vcard?", Bob clicks something and voila it's=20 sent.
        -Alternatives: = send a=20 re-Invite or Update with a Call-Info, with either a URL reference, = data URI,=20 or MIME and CID URL.
       =20 -Counter-argument: IMO this type of data really belongs in MIME for a = number=20 of reasons, including length is less restricted for mime attachments; = one AD=20 has said the Data URL may be deprecated.  And sending a re-Invite = for=20 this purpose seems = odd.

       =20 -Also, the Call-Info header is really about the caller or callee, and = thus Bob=20 shouldn't be sending me John's vcard info in it technically.  = That may=20 sound like a nit, but UA's may well store the call-info vcards into = their=20 address-books automatically and so tie it to the wrong=20 user/call.
        -Pros of = using INFO:=20 it's explicit what you're doing when you send the vcard, and you can = send it=20 knowing the other end can accept it, and you can send it based on user = input.

2) Sending a user-icon jpeg/bitmap/gif.  Alice = calls Bob,=20 Bob has an icon that represents himself, sends it when he picks up the = phone.
        -Alternatives: = send a=20 200ok, re-Invite, or Update with call-info, which explicitly has a = type for=20 icon.
        -Counter-argument: = same as=20 for vcard, plus with call-info there is no way to know which picture = format=20 the far-end supports a priori.  With a supported-package = negotiation one=20 could know.

3) Sending a vcalendar-type invitation.  Alice = calls=20 Bob, Bob says "hey let's have a con call at time X", clicks and voila = his=20 phone sends a = vcalendar..
       =20 -Whether the vcalendar is related to the session or not and thus = whether it=20 should be sent in an in-dialog request or not is certainly = debatable. =20 Message method can already be used for this anyway.

4) Sending = an HTTP=20 URL.  Alice calls Bob, a sales guy; Alice asks for more info or a = datasheet and Bob sends a URL for Alice to open with her=20 web-browser.
        -One could = also=20 argue this is just making SIP the new SMTP, or this should be sent = using=20 MESSAGE (which really is the new SMTP).

5) Sending a session=20 traceroute.  Alice calls Bob, Bob answers, Alice does a = sip-traceroute to=20 figure out the path to Bob, by sending Info with an incrementing = max-forwards=20 type header starting at 0 (but not really max-forwards), with a = sip-frag type=20 response body or some = such.
       =20 -It's debatable if certain types of B2BUA's (ie, SBCs) would ever = allow this=20 type of thing to happen, due to security concerns, but I think they = may do it=20 at domain boundary hops.  I think this is a reasonable use for = INFO=20 though, maybe.

6) Sending geo-location information after call=20 establishment.  Alice calls Bob, a hotel receptionist.  = Alice asks=20 for directions to hotel, clicks button and sends him location info of = her=20 phone (or Bob clicks button and sends her his=20 location).
        -The location = conveyance draft specifically calls out INFO as acceptable for geo-loc = info.  Whether this is a real use-case is debatable, and = obviously it=20 could be done with a sub/not.

7) Sending softkey-labels (not=20 digit-match maps, but rather softkey button labels).  Alice calls = her=20 vmail server.  Vmail server sends softkey-labels for the menu = items=20 available in the response, Alice presses softkeys and sends them in=20 INFO.
        -This could (and = maybe=20 should) be done with sub/not, a la KPML, where the vmail server sends = the=20 softkey labels in the Subscribe, UA sends buttons pressed in = Notifies. =20 But this is similar to the DTMF use case so may well have the same = benefit of=20 lower overhead since buttons are rarely pressed.

8) Sending a=20 screen-pop-up message, e.g., "Do you want to continue with this=20 session?"
        -There is a = patent for=20 doing screen pop-ups using INFO.  I guess Alert-Info could be = used for=20 this, but it's not clear it = should?


/*****************
* =20 Use-cases which have been proposed by others or even = implemented,
* =20 which are dubious for INFO (IMHO):
*****************/
1) Sending = RTP/RTCP statistics during = call.
       =20 -There is an implementation of this, and the rationale is the = signaling plane=20 box that wants this info is not actually the media plane box that gets = RTCP.  Again this could (and IMO should) be done with sub/not, so = it can=20 get stats after the call is over, and since it will probably want = periodic=20 reports the overhead of the Subscribe should be dwarfed by the number = of=20 Notifies.

2) Sending access-location information after call=20 establishment.
        -There is = a=20 P-Access-Network-Info header, and some have proposed to send an update = for it=20 as a phone roams access points or cells.  But I think this is an = odd=20 thing to do inside an Invite session, vs. in a sub/not or Register = (and=20 besides half the time the network inserts this header, not the = UA).

3)=20 Sending media-control indications (ie, remote-control=20 "play/pause/etc.")
        -This = is done=20 today by at least one vendor, but is debatable if it's the right = model. =20 The argument is it's like SDP re-Invite for hold, except at a media = content=20 layer above RTP, so not done in RTCP nor SDP.

4) Sending video = fast=20 update command
        -This is = an=20 informational draft, which documents what has been implemented, but = states it=20 should really be done in the media plane.

5) Sending peripheral = control=20 commands (ie, USB = commands)
       =20 -There is actually a patent on this, amazingly.  Someone thinks = it makes=20 sense to create a SIP session to your laptop, or vice-versa, and then = send USB=20 commands inside MIME in INFO messages.  Methinks this should be=20 media-plane, if anything.

6) Sending charging information for a = call=20 (i.e., minutes remaining or cost so=20 far).
        -There was a = proposal to=20 use this for Advice of Charge information in TISPAN.  IMO it = should be a=20 sub/not though, as they want this to survive the Invite=20 = session.

-hadriel


<= /BODY> ------_=_NextPart_001_01C8388D.3A039C6C-- --===============2067816688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2067816688==-- From sip-bounces@ietf.org Fri Dec 07 00:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VTo-0007kc-BK; Fri, 07 Dec 2007 00:10:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0VTm-0007kV-EZ for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 00:10:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VTm-0007kN-4K for sip@ietf.org; Fri, 07 Dec 2007 00:10:26 -0500 Received: from smfilter1.kt.co.kr ([147.6.85.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0VTi-0000Py-8q for sip@ietf.org; Fri, 07 Dec 2007 00:10:26 -0500 Received: from external ([147.6.42.21]) by smfilter1 (1.0) id lB759u20018F; Fri, 07 Dec 2007 14:09:56 +0900 Received: from MAIL04CL.oasys.kt.co.kr ([147.6.42.223]) by smtp01.oasys.kt.co.kr with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 Dec 2007 14:10:04 +0900 Received: from mail pickup service by MAIL04CL.oasys.kt.co.kr with Microsoft SMTPSVC; Fri, 7 Dec 2007 14:10:04 +0900 Priority: normal Bcc: X-AuditID: 93062d67-ad532bb000001213-4c-4758d1fe6a95 Subject: RE: [Sip] INFO use-cases X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Content-Class: urn:content-classes:message Message-ID: <01e001c8388f$6d3be620$df2a0693@oasys.kt.co.kr> MIME-Version: 1.0 Date: Fri, 7 Dec 2007 14:10:04 +0900 X-Mailer: Microsoft CDO for Exchange 2000 In-Reply-To: <01fe01c83876$9d5a5b20$df2a0693@oasys.kt.co.kr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases thread-index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAqGCewAAa5NCA= Importance: normal From: =?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=?= To: "Sanjay Sinha \(sanjsinh\)" , "Hadriel Kaplan" X-OriginalArrivalTime: 07 Dec 2007 04:54:19.0838 (UTC) FILETIME=[3A386DE0:01C8388D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24053; t=1197003261; x=1197867261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20|Subject:=20RE=3A=20[Sip]=20INFO=20use-cases|Sender:=20|To:=20=3D?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=3D?=3D=20,=0A=20=20=20=20=20=20=20=20=22Hadriel=20Kaplan=22=20; bh=dY7HO1s02V+sfIBjdS/2G3t9Yc9pJsCkIYQE/ztExyI=; b=HebyntzulC20f1SRz32ECL6K9ShuIgJyyHPe7UrAHJ6ffzWgTBou7qm4hSySMPjwb2AxjXuhrvYQezi/IV1SvYLuTUzabOLxYdqvRfb7eyzaACS6bhGXUk1+3tBGjH+1; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass (sig from cisco.com/rtpdkim1001 verified; ); X-Brightmail-Tracker: AAAABAf/KTUH/ymUB/8qWAf/YMg= X-Spam-Score: 4.6 (++++) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ks_c_5601-1987?B?yLLB+LDmW7+ssbjA/Lmusde37F0=?= List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1287765311==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1287765311== Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8388D.3A039C6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8388D.3A039C6C Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Dear sanjsinh=0A= =0A= I don't know the other way to collect "Hook-Flash" event along on-going = dialogue.=0A= What is the suggested 'non-INFO way' ? =0A= =0A= THX =0A= =0A= JK=0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Sanjay Sinha (sanjsinh)" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C8=C4 1:54:17=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: = "=C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC]" = , "Hadriel Kaplan" =0A= =C2=FC=C1=B6: "sip@ietf.org" =0A= =C1=A6=B8=F1: RE: [Sip] INFO use-cases=0A= =0A= =0A= These 3 use cases below seem misuse of INFO as there are established = mechanism of doing these using non-INFO way.=0A= =0A= =0A= =0A= =0A= From: =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr] =0A= Sent: Thursday, December 06, 2007 9:12 PM=0A= To: Hadriel Kaplan=0A= Cc: sip@ietf.org=0A= Subject: RE: [Sip] INFO use-cases=0A= =0A= =0A= =0A= Dear Hadriel Kaplan and folks=0A= =0A= (in our case) =0A= Midcall INFO is used in =0A= =0A= 1) Three-way calling: to add another party to existing call =0A= 2) Call waiting: to change dialogue between two ongoing calls=0A= 3) Centrex services: call transfer, etc.=0A= =0A= THX=0A= =0A= JK Hwang=0A= KT=0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 10:48:19=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: = "=C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC]" = =0A= =C2=FC=C1=B6: "sip@ietf.org" =0A= =C1=A6=B8=F1: RE: [Sip] INFO use-cases=0A= =0A= =0A= Hi JK,=0A= I actually saw that draft but did not include it because I thought it = was essentially another DTMF-style event type, and would be subsumed = into it, but you're right I should have included that use-case. Sorry!=0A= =0A= -hadriel=0A= =0A= =0A= ________________________________________=0A= From: =C8=B2=C1=F8=B0=E6[=BF=AC=B1=B8=C0=FC=B9=AE=B1=D7=B7=EC] = [mailto:jkhwang@kt.co.kr]=0A= Sent: Thursday, December 06, 2007 8:33 PM=0A= To: Hadriel Kaplan; sip@ietf.org=0A= Subject: RE: [Sip] INFO use-cases=0A= Dear folks,=0A= How about the Midcall INFO ?=0A= When 'Hook-Flash' from the SIP or POTS phone during a dialogue, we (KT) = use INFO method from the CSCF/MGCF to AS.=0A= I submitted a draft I-D two years ago but it was not accepted,=0A= But we still use the case.=0A= Can it be another Use-Case ?=0A= JK Hwang=0A= KT=0A= =0A= -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6-----=0A= =BA=B8=B3=BD =BB=E7=B6=F7: "Hadriel Kaplan" =0A= =BA=B8=B3=BD =B3=AF=C2=A5: 2007-12-07 =BF=C0=C0=FC 8:38:36=0A= =B9=DE=B4=C2 =BB=E7=B6=F7: "sip@ietf.org" =0A= =C2=FC=C1=B6:=0A= =C1=A6=B8=F1: [Sip] INFO use-cases=0A= =0A= =0A= Howdy,=0A= Jonathan asked for use-cases for what types of things would need an = in-dialog SIP message for user-user communication, vs. should be done = either out of dialog or in the media plane. If the only use-case is = DTMF, then we could just document the DTMF negotiation/use only and not = have to create a general info-events framework. That seems a very = reasonable argument to me. I also don't want to do work for no use.=0A= =0A= There is a counter-argument that there are proprietary uses of INFO in = the wild, and that a framework for negotiation at least removes the = manual configuration of vendor-specific profiles, which is a problem of = interop today - even if the IETF should not bless/document the specific = use cases themselves. But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread.=0A= =0A= The chairs have asked for 3 use cases, and I assume they mean 3 NEW use = cases (we already have 3 RFCs which use INFO, as well as DTMF). I am = not sure if they mean potential future use-cases, or current use-cases = (i.e., already implemented). Can I get a clarification on that?=0A= =0A= So anyway, taking the shot-gun approach, here's a first go at some = use-cases, and my personal take on whether they should be in INFO vs. = SUB/NOT vs. media-plane, FWIW.=0A= [apologize for formatting ugliness]=0A= =0A= /***************=0A= * Already standardized use-cases:=0A= ***************/=0A= 1) SIP-T/ISUP/QSIG/PSTN=0A= -Documented in RFC 3372 and RFC 4497.=0A= =0A= 2) ECMA TR/87 uaCSTA=0A= -Uses INFO to send ECMA-323 XML for monitoring and controlling = phones from a PC.=0A= =0A= 3) Sending media server control commands.=0A= -Documented in RFC4722 MSCML.=0A= =0A= =0A= /****************=0A= * Use-cases that I think are potentially/possibly valid for INFO:=0A= ****************/=0A= 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you = send me John's vcard?", Bob clicks something and voila it's sent.=0A= -Alternatives: send a re-Invite or Update with a Call-Info, with = either a URL reference, data URI, or MIME and CID URL.=0A= -Counter-argument: IMO this type of data really belongs in MIME = for a number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd.=0A= =0A= -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call.=0A= -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input.=0A= =0A= 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone.=0A= -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon.=0A= -Counter-argument: same as for vcard, plus with call-info there = is no way to know which picture format the far-end supports a priori. = With a supported-package negotiation one could know.=0A= =0A= 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey = let's have a con call at time X", clicks and voila his phone sends a = vcalendar..=0A= -Whether the vcalendar is related to the session or not and thus = whether it should be sent in an in-dialog request or not is certainly = debatable. Message method can already be used for this anyway.=0A= =0A= 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser.=0A= -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP).=0A= =0A= 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such.=0A= -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe.=0A= =0A= 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location).=0A= -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not.=0A= =0A= 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO.=0A= -This could (and maybe should) be done with sub/not, a la KPML, = where the vmail server sends the softkey labels in the Subscribe, UA = sends buttons pressed in Notifies. But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed.=0A= =0A= 8) Sending a screen-pop-up message, e.g., "Do you want to continue with = this session?"=0A= -There is a patent for doing screen pop-ups using INFO. I guess = Alert-Info could be used for this, but it's not clear it should?=0A= =0A= =0A= /*****************=0A= * Use-cases which have been proposed by others or even implemented,=0A= * which are dubious for INFO (IMHO):=0A= *****************/=0A= 1) Sending RTP/RTCP statistics during call.=0A= -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies.=0A= =0A= 2) Sending access-location information after call establishment.=0A= -There is a P-Access-Network-Info header, and some have proposed = to send an update for it as a phone roams access points or cells. But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA).=0A= =0A= 3) Sending media-control indications (ie, remote-control = "play/pause/etc.")=0A= -This is done today by at least one vendor, but is debatable if = it's the right model. The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor SDP.=0A= =0A= 4) Sending video fast update command=0A= -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane.=0A= =0A= 5) Sending peripheral control commands (ie, USB commands)=0A= -There is actually a patent on this, amazingly. Someone thinks = it makes sense to create a SIP session to your laptop, or vice-versa, = and then send USB commands inside MIME in INFO messages. Methinks this = should be media-plane, if anything.=0A= =0A= 6) Sending charging information for a call (i.e., minutes remaining or = cost so far).=0A= -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session.=0A= =0A= -hadriel ------_=_NextPart_001_01C8388D.3A039C6C Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGJvZHk+PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxE SVY+CjxQPiZuYnNwOzwvUD4KPFA+RGVhciBzYW5qc2luaDwvUD4KPFA+Jm5ic3A7PC9QPgo8UD5J IGRvbid0IGtub3cgdGhlIG90aGVyIHdheSB0byBjb2xsZWN0ICJIb29rLUZsYXNoIiBldmVudCBh bG9uZyBvbi1nb2luZyBkaWFsb2d1ZS48L1A+CjxQPldoYXQgaXMmbmJzcDt0aGUgc3VnZ2VzdGVk Jm5ic3A7JzxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj5ub24tSU5GTyB3YXk8Rk9OVCBj b2xvcj0jMDAwMDAwPicgPyA8L0ZPTlQ+PC9GT05UPjwvUD48L0RJVj48L0RJVj4KPERJViBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxESVY+Jm5ic3A7PC9ESVY+ CjxESVY+VEhYIDwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkpLPEJSPi0tLS0tv/i6uyC4 3r3DwfYtLS0tLTxCUj48Qj66uLO9ILvntvc6PC9CPiAiU2FuamF5IFNpbmhhIChzYW5qc2luaCki ICZsdDtzYW5qc2luaEBjaXNjby5jb20mZ3Q7PEJSPjxCPrq4s70gs6/CpTo8L0I+IDIwMDctMTIt MDcgv8DIxCAxOjU0OjE3PEJSPjxCPrnetMIgu+e29zo8L0I+ICLIssH4sOZbv6yxuMD8ua6x17fs XSIgJmx0O2praHdhbmdAa3QuY28ua3ImZ3Q7LCAiSGFkcmllbCBLYXBsYW4iICZsdDtIS2FwbGFu QGFjbWVwYWNrZXQuY29tJmd0OzxCUj48Qj7C/MG2OjwvQj4gInNpcEBpZXRmLm9yZyIgJmx0O3Np cEBpZXRmLm9yZyZndDs8QlI+PEI+waa48To8L0I+IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlczxC Uj48QlI+PC9ESVY+CjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTgwNTIzNTMw NC0wNzEyMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlRoZXNlIDMg dXNlIGNhc2VzIGJlbG93IHNlZW0gbWlzdXNlIG9mIElORk8gYXMgdGhlcmUgYXJlIGVzdGFibGlz aGVkIG1lY2hhbmlzbSBvZiBkb2luZyB0aGVzZSB1c2luZyBub24tSU5GTyB3YXkuPC9GT05UPjwv U1BBTj48L0RJVj4KPERJVj48QlI+PC9ESVY+CjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9IlBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4KPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhl YWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4KPEhSIHRhYkluZGV4PS0xPgo8Rk9O VCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IMiywfiw5lu/rLG4wPy5rrHXt+xdIFtt YWlsdG86amtod2FuZ0BrdC5jby5rcl0gPEJSPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgRGVjZW1i ZXIgMDYsIDIwMDcgOToxMiBQTTxCUj48Qj5Ubzo8L0I+IEhhZHJpZWwgS2FwbGFuPEJSPjxCPkNj OjwvQj4gc2lwQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW1NpcF0gSU5GTyB1c2Ut Y2FzZXM8QlI+PC9GT05UPjxCUj48L0RJVj4KPERJVj48L0RJVj4KPERJViBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxESVY+CjxQPiZuYnNwOzwvUD4KPFA+RGVh ciBIYWRyaWVsIEthcGxhbiBhbmQgZm9sa3M8L1A+CjxQPiZuYnNwOzwvUD4KPFA+KGluIG91ciBj YXNlKSA8L1A+CjxQPk1pZGNhbGwgSU5GTyBpcyB1c2VkIGluIDwvUD4KPFA+Jm5ic3A7PC9QPgo8 UD4xKSBUaHJlZS13YXkgY2FsbGluZzogdG8gYWRkIGFub3RoZXIgcGFydHkgdG8gZXhpc3Rpbmcg Y2FsbCZuYnNwOzwvUD4KPFA+MikgQ2FsbCB3YWl0aW5nOiB0byBjaGFuZ2UgZGlhbG9ndWUgYmV0 d2VlbiB0d28gb25nb2luZyBjYWxsczwvUD4KPFA+MykgQ2VudHJleCBzZXJ2aWNlczogY2FsbCB0 cmFuc2ZlciwgZXRjLjwvUD4KPFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjwvRk9O VD4mbmJzcDs8L1A+CjxQPlRIWDwvUD4KPFA+Jm5ic3A7PC9QPgo8UD5KSyBId2FuZzwvUD4KPFA+ S1Q8QlI+LS0tLS2/+Lq7ILjevcPB9i0tLS0tPEJSPjxCPrq4s70gu+e29zo8L0I+ICJIYWRyaWVs IEthcGxhbiIgJmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PEJSPjxCPrq4s70gs6/CpTo8 L0I+IDIwMDctMTItMDcgv8DA/CAxMDo0ODoxOTxCUj48Qj653rTCILvntvc6PC9CPiAiyLLB+LDm W7+ssbjA/Lmusde37F0iICZsdDtqa2h3YW5nQGt0LmNvLmtyJmd0OzxCUj48Qj7C/MG2OjwvQj4g InNpcEBpZXRmLm9yZyIgJmx0O3NpcEBpZXRmLm9yZyZndDs8QlI+PEI+waa48To8L0I+IFJFOiBb U2lwXSBJTkZPIHVzZS1jYXNlczxCUj48QlI+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWlu IGZvcm1hdCAtLT48L1A+PC9ESVY+PC9ESVY+CjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6ILG8uLIiPgo8RElWPgo8UD48Rk9OVCBzaXplPTI+SGkgSkssPEJSPkkgYWN0 dWFsbHkgc2F3IHRoYXQgZHJhZnQgYnV0IGRpZCBub3QgaW5jbHVkZSBpdCBiZWNhdXNlIEkgdGhv dWdodCBpdCB3YXMgZXNzZW50aWFsbHkgYW5vdGhlciBEVE1GLXN0eWxlIGV2ZW50IHR5cGUsIGFu ZCB3b3VsZCBiZSBzdWJzdW1lZCBpbnRvIGl0LCBidXQgeW91J3JlIHJpZ2h0IEkgc2hvdWxkIGhh dmUgaW5jbHVkZWQgdGhhdCB1c2UtY2FzZS4mbmJzcDsgU29ycnkhPEJSPjxCUj4taGFkcmllbDxC Uj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+RnJv bTogyLLB+LDmW7+ssbjA/Lmusde37F0gWzxBIGhyZWY9Im1haWx0bzpqa2h3YW5nQGt0LmNvLmty IiB0YXJnZXQ9X2JsYW5rPm1haWx0bzpqa2h3YW5nQGt0LmNvLmtyPC9BPl08QlI+U2VudDogVGh1 cnNkYXksIERlY2VtYmVyIDA2LCAyMDA3IDg6MzMgUE08QlI+VG86IEhhZHJpZWwgS2FwbGFuOyBz aXBAaWV0Zi5vcmc8QlI+U3ViamVjdDogUkU6IFtTaXBdIElORk8gdXNlLWNhc2VzPEJSPkRlYXIg Zm9sa3MsPEJSPiZuYnNwO0hvdyBhYm91dCB0aGUgTWlkY2FsbCBJTkZPID88QlI+Jm5ic3A7V2hl biAnSG9vay1GbGFzaCcgZnJvbSB0aGUgU0lQIG9yIFBPVFMgcGhvbmUgZHVyaW5nIGEgZGlhbG9n dWUsIHdlIChLVCkgdXNlIElORk8gbWV0aG9kIGZyb20gdGhlIENTQ0YvTUdDRiB0byBBUy48QlI+ Jm5ic3A7SSBzdWJtaXR0ZWQgYSBkcmFmdCBJLUQgdHdvIHllYXJzIGFnbyBidXQgaXQgd2FzIG5v dCBhY2NlcHRlZCw8QlI+QnV0IHdlIHN0aWxsIHVzZSB0aGUgY2FzZS48QlI+Jm5ic3A7Q2FuIGl0 IGJlIGFub3RoZXIgVXNlLUNhc2UgPzxCUj4mbmJzcDtKSyBId2FuZzxCUj5LVDxCUj48QlI+LS0t LS2/+Lq7ILjevcPB9i0tLS0tPEJSPrq4s70gu+e29zogIkhhZHJpZWwgS2FwbGFuIiAmbHQ7SEth cGxhbkBhY21lcGFja2V0LmNvbSZndDs8QlI+urizvSCzr8KlOiAyMDA3LTEyLTA3IL/AwPwgODoz ODozNjxCUj653rTCILvntvc6ICJzaXBAaWV0Zi5vcmciICZsdDtzaXBAaWV0Zi5vcmcmZ3Q7PEJS PsL8wbY6PEJSPsGmuPE6IFtTaXBdIElORk8gdXNlLWNhc2VzPEJSPjxCUj48QlI+SG93ZHksPEJS PkpvbmF0aGFuIGFza2VkIGZvciB1c2UtY2FzZXMgZm9yIHdoYXQgdHlwZXMgb2YgdGhpbmdzIHdv dWxkIG5lZWQgYW4gaW4tZGlhbG9nIFNJUCBtZXNzYWdlIGZvciB1c2VyLXVzZXIgY29tbXVuaWNh dGlvbiwgdnMuIHNob3VsZCBiZSBkb25lIGVpdGhlciBvdXQgb2YgZGlhbG9nIG9yIGluIHRoZSBt ZWRpYSBwbGFuZS4mbmJzcDsgSWYgdGhlIG9ubHkgdXNlLWNhc2UgaXMgRFRNRiwgdGhlbiB3ZSBj b3VsZCBqdXN0IGRvY3VtZW50IHRoZSBEVE1GIG5lZ290aWF0aW9uL3VzZSBvbmx5IGFuZCBub3Qg aGF2ZSB0byBjcmVhdGUgYSBnZW5lcmFsIGluZm8tZXZlbnRzIGZyYW1ld29yay4mbmJzcDsgVGhh dCBzZWVtcyBhIHZlcnkgcmVhc29uYWJsZSBhcmd1bWVudCB0byBtZS4mbmJzcDsgSSBhbHNvIGRv bid0IHdhbnQgdG8gZG8gd29yayBmb3Igbm8gdXNlLjxCUj48QlI+VGhlcmUgaXMgYSBjb3VudGVy LWFyZ3VtZW50IHRoYXQgdGhlcmUgYXJlIHByb3ByaWV0YXJ5IHVzZXMgb2YgSU5GTyBpbiB0aGUg d2lsZCwgYW5kIHRoYXQgYSBmcmFtZXdvcmsgZm9yIG5lZ290aWF0aW9uIGF0IGxlYXN0IHJlbW92 ZXMgdGhlIG1hbnVhbCBjb25maWd1cmF0aW9uIG9mIHZlbmRvci1zcGVjaWZpYyBwcm9maWxlcywg d2hpY2ggaXMgYSBwcm9ibGVtIG9mIGludGVyb3AgdG9kYXkgLSBldmVuIGlmIHRoZSBJRVRGIHNo b3VsZCBub3QgYmxlc3MvZG9jdW1lbnQgdGhlIHNwZWNpZmljIHVzZSBjYXNlcyB0aGVtc2VsdmVz LiZuYnNwOyBCdXQgdGhhdCB3b3VsZCBtYWtlIHRoZSBkcmFmdCBhIHZlcnkgZGlmZmVyZW50IG9u ZSB0aGFuIGl0IGN1cnJlbnRseSBpcyBhcyB3ZWxsLCBhbmQgSSB3aWxsIGFzayB0aGF0IGluIGEg c2VwYXJhdGUgZW1haWwgdGhyZWFkLjxCUj48QlI+VGhlIGNoYWlycyBoYXZlIGFza2VkIGZvciAz IHVzZSBjYXNlcywgYW5kIEkgYXNzdW1lIHRoZXkgbWVhbiAzIE5FVyB1c2UgY2FzZXMgKHdlIGFs cmVhZHkgaGF2ZSAzIFJGQ3Mgd2hpY2ggdXNlIElORk8sIGFzIHdlbGwgYXMgRFRNRikuJm5ic3A7 IEkgYW0gbm90IHN1cmUgaWYgdGhleSBtZWFuIHBvdGVudGlhbCBmdXR1cmUgdXNlLWNhc2VzLCBv ciBjdXJyZW50IHVzZS1jYXNlcyAoaS5lLiwgYWxyZWFkeSBpbXBsZW1lbnRlZCkuJm5ic3A7IENh biBJIGdldCBhIGNsYXJpZmljYXRpb24gb24gdGhhdD88QlI+PEJSPlNvIGFueXdheSwgdGFraW5n IHRoZSBzaG90LWd1biBhcHByb2FjaCwgaGVyZSdzIGEgZmlyc3QgZ28gYXQgc29tZSB1c2UtY2Fz ZXMsIGFuZCBteSBwZXJzb25hbCB0YWtlIG9uIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgaW4gSU5G TyB2cy4gU1VCL05PVCB2cy4gbWVkaWEtcGxhbmUsIEZXSVcuPEJSPlthcG9sb2dpemUgZm9yIGZv cm1hdHRpbmcgdWdsaW5lc3NdPEJSPjxCUj4vKioqKioqKioqKioqKioqPEJSPiombmJzcDsgQWxy ZWFkeSBzdGFuZGFyZGl6ZWQgdXNlLWNhc2VzOjxCUj4qKioqKioqKioqKioqKiovPEJSPjEpIFNJ UC1UL0lTVVAvUVNJRy9QU1ROPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtRG9jdW1lbnRlZCBpbiBSRkMgMzM3MiBhbmQgUkZDIDQ0OTcuPEJSPjxCUj4yKSBF Q01BIFRSLzg3IHVhQ1NUQTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLVVzZXMgSU5GTyB0byBzZW5kIEVDTUEtMzIzIFhNTCBmb3IgbW9uaXRvcmluZyBhbmQg Y29udHJvbGxpbmcgcGhvbmVzIGZyb20gYSBQQy48QlI+PEJSPjMpIFNlbmRpbmcgbWVkaWEgc2Vy dmVyIGNvbnRyb2wgY29tbWFuZHMuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtRG9jdW1lbnRlZCBpbiBSRkM0NzIyIE1TQ01MLjxCUj48QlI+PEJSPi8qKioq KioqKioqKioqKioqPEJSPiombmJzcDsgVXNlLWNhc2VzIHRoYXQgSSB0aGluayBhcmUgcG90ZW50 aWFsbHkvcG9zc2libHkgdmFsaWQgZm9yIElORk86PEJSPioqKioqKioqKioqKioqKiovPEJSPjEp IFNlbmRpbmcgYSB2Y2FyZCBhc3luY2hyb25vdXNseS4mbmJzcDsgQWxpY2UgY2FsbHMgQm9iLCBB bGljZSBzYXlzICJjYW4geW91IHNlbmQgbWUgSm9obidzIHZjYXJkPyIsIEJvYiBjbGlja3Mgc29t ZXRoaW5nIGFuZCB2b2lsYSBpdCdzIHNlbnQuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtQWx0ZXJuYXRpdmVzOiBzZW5kIGEgcmUtSW52aXRlIG9yIFVwZGF0 ZSB3aXRoIGEgQ2FsbC1JbmZvLCB3aXRoIGVpdGhlciBhIFVSTCByZWZlcmVuY2UsIGRhdGEgVVJJ LCBvciBNSU1FIGFuZCBDSUQgVVJMLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLUNvdW50ZXItYXJndW1lbnQ6IElNTyB0aGlzIHR5cGUgb2YgZGF0YSByZWFs bHkgYmVsb25ncyBpbiBNSU1FIGZvciBhIG51bWJlciBvZiByZWFzb25zLCBpbmNsdWRpbmcgbGVu Z3RoIGlzIGxlc3MgcmVzdHJpY3RlZCBmb3IgbWltZSBhdHRhY2htZW50czsgb25lIEFEIGhhcyBz YWlkIHRoZSBEYXRhIFVSTCBtYXkgYmUgZGVwcmVjYXRlZC4mbmJzcDsgQW5kIHNlbmRpbmcgYSBy ZS1JbnZpdGUgZm9yIHRoaXMgcHVycG9zZSBzZWVtcyBvZGQuPEJSPjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLUFsc28sIHRoZSBDYWxsLUluZm8gaGVhZGVy IGlzIHJlYWxseSBhYm91dCB0aGUgY2FsbGVyIG9yIGNhbGxlZSwgYW5kIHRodXMgQm9iIHNob3Vs ZG4ndCBiZSBzZW5kaW5nIG1lIEpvaG4ncyB2Y2FyZCBpbmZvIGluIGl0IHRlY2huaWNhbGx5LiZu YnNwOyBUaGF0IG1heSBzb3VuZCBsaWtlIGEgbml0LCBidXQgVUEncyBtYXkgd2VsbCBzdG9yZSB0 aGUgY2FsbC1pbmZvIHZjYXJkcyBpbnRvIHRoZWlyIGFkZHJlc3MtYm9va3MgYXV0b21hdGljYWxs eSBhbmQgc28gdGllIGl0IHRvIHRoZSB3cm9uZyB1c2VyL2NhbGwuPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtUHJvcyBvZiB1c2luZyBJTkZPOiBpdCdzIGV4 cGxpY2l0IHdoYXQgeW91J3JlIGRvaW5nIHdoZW4geW91IHNlbmQgdGhlIHZjYXJkLCBhbmQgeW91 IGNhbiBzZW5kIGl0IGtub3dpbmcgdGhlIG90aGVyIGVuZCBjYW4gYWNjZXB0IGl0LCBhbmQgeW91 IGNhbiBzZW5kIGl0IGJhc2VkIG9uIHVzZXIgaW5wdXQuPEJSPjxCUj4yKSBTZW5kaW5nIGEgdXNl ci1pY29uIGpwZWcvYml0bWFwL2dpZi4mbmJzcDsgQWxpY2UgY2FsbHMgQm9iLCBCb2IgaGFzIGFu IGljb24gdGhhdCByZXByZXNlbnRzIGhpbXNlbGYsIHNlbmRzIGl0IHdoZW4gaGUgcGlja3MgdXAg dGhlIHBob25lLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LUFsdGVybmF0aXZlczogc2VuZCBhIDIwMG9rLCByZS1JbnZpdGUsIG9yIFVwZGF0ZSB3aXRoIGNh bGwtaW5mbywgd2hpY2ggZXhwbGljaXRseSBoYXMgYSB0eXBlIGZvciBpY29uLjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLUNvdW50ZXItYXJndW1lbnQ6IHNh bWUgYXMgZm9yIHZjYXJkLCBwbHVzIHdpdGggY2FsbC1pbmZvIHRoZXJlIGlzIG5vIHdheSB0byBr bm93IHdoaWNoIHBpY3R1cmUgZm9ybWF0IHRoZSBmYXItZW5kIHN1cHBvcnRzIGEgcHJpb3JpLiZu YnNwOyBXaXRoIGEgc3VwcG9ydGVkLXBhY2thZ2UgbmVnb3RpYXRpb24gb25lIGNvdWxkIGtub3cu PEJSPjxCUj4zKSBTZW5kaW5nIGEgdmNhbGVuZGFyLXR5cGUgaW52aXRhdGlvbi4mbmJzcDsgQWxp Y2UgY2FsbHMgQm9iLCBCb2Igc2F5cyAiaGV5IGxldCdzIGhhdmUgYSBjb24gY2FsbCBhdCB0aW1l IFgiLCBjbGlja3MgYW5kIHZvaWxhIGhpcyBwaG9uZSBzZW5kcyBhIHZjYWxlbmRhci4uPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtV2hldGhlciB0aGUgdmNh bGVuZGFyIGlzIHJlbGF0ZWQgdG8gdGhlIHNlc3Npb24gb3Igbm90IGFuZCB0aHVzIHdoZXRoZXIg aXQgc2hvdWxkIGJlIHNlbnQgaW4gYW4gaW4tZGlhbG9nIHJlcXVlc3Qgb3Igbm90IGlzIGNlcnRh aW5seSBkZWJhdGFibGUuJm5ic3A7IE1lc3NhZ2UgbWV0aG9kIGNhbiBhbHJlYWR5IGJlIHVzZWQg Zm9yIHRoaXMgYW55d2F5LjxCUj48QlI+NCkgU2VuZGluZyBhbiBIVFRQIFVSTC4mbmJzcDsgQWxp Y2UgY2FsbHMgQm9iLCBhIHNhbGVzIGd1eTsgQWxpY2UgYXNrcyBmb3IgbW9yZSBpbmZvIG9yIGEg ZGF0YXNoZWV0IGFuZCBCb2Igc2VuZHMgYSBVUkwgZm9yIEFsaWNlIHRvIG9wZW4gd2l0aCBoZXIg d2ViLWJyb3dzZXIuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtT25lIGNvdWxkIGFsc28gYXJndWUgdGhpcyBpcyBqdXN0IG1ha2luZyBTSVAgdGhlIG5ldyBT TVRQLCBvciB0aGlzIHNob3VsZCBiZSBzZW50IHVzaW5nIE1FU1NBR0UgKHdoaWNoIHJlYWxseSBp cyB0aGUgbmV3IFNNVFApLjxCUj48QlI+NSkgU2VuZGluZyBhIHNlc3Npb24gdHJhY2Vyb3V0ZS4m bmJzcDsgQWxpY2UgY2FsbHMgQm9iLCBCb2IgYW5zd2VycywgQWxpY2UgZG9lcyBhIHNpcC10cmFj ZXJvdXRlIHRvIGZpZ3VyZSBvdXQgdGhlIHBhdGggdG8gQm9iLCBieSBzZW5kaW5nIEluZm8gd2l0 aCBhbiBpbmNyZW1lbnRpbmcgbWF4LWZvcndhcmRzIHR5cGUgaGVhZGVyIHN0YXJ0aW5nIGF0IDAg KGJ1dCBub3QgcmVhbGx5IG1heC1mb3J3YXJkcyksIHdpdGggYSBzaXAtZnJhZyB0eXBlIHJlc3Bv bnNlIGJvZHkgb3Igc29tZSBzdWNoLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLUl0J3MgZGViYXRhYmxlIGlmIGNlcnRhaW4gdHlwZXMgb2YgQjJCVUEncyAo aWUsIFNCQ3MpIHdvdWxkIGV2ZXIgYWxsb3cgdGhpcyB0eXBlIG9mIHRoaW5nIHRvIGhhcHBlbiwg ZHVlIHRvIHNlY3VyaXR5IGNvbmNlcm5zLCBidXQgSSB0aGluayB0aGV5IG1heSBkbyBpdCBhdCBk b21haW4gYm91bmRhcnkgaG9wcy4mbmJzcDsgSSB0aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSB1 c2UgZm9yIElORk8gdGhvdWdoLCBtYXliZS48QlI+PEJSPjYpIFNlbmRpbmcgZ2VvLWxvY2F0aW9u IGluZm9ybWF0aW9uIGFmdGVyIGNhbGwgZXN0YWJsaXNobWVudC4mbmJzcDsgQWxpY2UgY2FsbHMg Qm9iLCBhIGhvdGVsIHJlY2VwdGlvbmlzdC4mbmJzcDsgQWxpY2UgYXNrcyBmb3IgZGlyZWN0aW9u cyB0byBob3RlbCwgY2xpY2tzIGJ1dHRvbiBhbmQgc2VuZHMgaGltIGxvY2F0aW9uIGluZm8gb2Yg aGVyIHBob25lIChvciBCb2IgY2xpY2tzIGJ1dHRvbiBhbmQgc2VuZHMgaGVyIGhpcyBsb2NhdGlv bikuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtVGhlIGxv Y2F0aW9uIGNvbnZleWFuY2UgZHJhZnQgc3BlY2lmaWNhbGx5IGNhbGxzIG91dCBJTkZPIGFzIGFj Y2VwdGFibGUgZm9yIGdlby1sb2MgaW5mby4mbmJzcDsgV2hldGhlciB0aGlzIGlzIGEgcmVhbCB1 c2UtY2FzZSBpcyBkZWJhdGFibGUsIGFuZCBvYnZpb3VzbHkgaXQgY291bGQgYmUgZG9uZSB3aXRo IGEgc3ViL25vdC48QlI+PEJSPjcpIFNlbmRpbmcgc29mdGtleS1sYWJlbHMgKG5vdCBkaWdpdC1t YXRjaCBtYXBzLCBidXQgcmF0aGVyIHNvZnRrZXkgYnV0dG9uIGxhYmVscykuJm5ic3A7IEFsaWNl IGNhbGxzIGhlciB2bWFpbCBzZXJ2ZXIuJm5ic3A7IFZtYWlsIHNlcnZlciBzZW5kcyBzb2Z0a2V5 LWxhYmVscyBmb3IgdGhlIG1lbnUgaXRlbXMgYXZhaWxhYmxlIGluIHRoZSByZXNwb25zZSwgQWxp Y2UgcHJlc3NlcyBzb2Z0a2V5cyBhbmQgc2VuZHMgdGhlbSBpbiBJTkZPLjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLVRoaXMgY291bGQgKGFuZCBtYXliZSBz aG91bGQpIGJlIGRvbmUgd2l0aCBzdWIvbm90LCBhIGxhIEtQTUwsIHdoZXJlIHRoZSB2bWFpbCBz ZXJ2ZXIgc2VuZHMgdGhlIHNvZnRrZXkgbGFiZWxzIGluIHRoZSBTdWJzY3JpYmUsIFVBIHNlbmRz IGJ1dHRvbnMgcHJlc3NlZCBpbiBOb3RpZmllcy4mbmJzcDsgQnV0IHRoaXMgaXMgc2ltaWxhciB0 byB0aGUgRFRNRiB1c2UgY2FzZSBzbyBtYXkgd2VsbCBoYXZlIHRoZSBzYW1lIGJlbmVmaXQgb2Yg bG93ZXIgb3ZlcmhlYWQgc2luY2UgYnV0dG9ucyBhcmUgcmFyZWx5IHByZXNzZWQuPEJSPjxCUj44 KSBTZW5kaW5nIGEgc2NyZWVuLXBvcC11cCBtZXNzYWdlLCBlLmcuLCAiRG8geW91IHdhbnQgdG8g Y29udGludWUgd2l0aCB0aGlzIHNlc3Npb24/IjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLVRoZXJlIGlzIGEgcGF0ZW50IGZvciBkb2luZyBzY3JlZW4gcG9w LXVwcyB1c2luZyBJTkZPLiZuYnNwOyBJIGd1ZXNzIEFsZXJ0LUluZm8gY291bGQgYmUgdXNlZCBm b3IgdGhpcywgYnV0IGl0J3Mgbm90IGNsZWFyIGl0IHNob3VsZD88QlI+PEJSPjxCUj4vKioqKioq KioqKioqKioqKio8QlI+KiZuYnNwOyBVc2UtY2FzZXMgd2hpY2ggaGF2ZSBiZWVuIHByb3Bvc2Vk IGJ5IG90aGVycyBvciBldmVuIGltcGxlbWVudGVkLDxCUj4qJm5ic3A7IHdoaWNoIGFyZSBkdWJp b3VzIGZvciBJTkZPIChJTUhPKTo8QlI+KioqKioqKioqKioqKioqKiovPEJSPjEpIFNlbmRpbmcg UlRQL1JUQ1Agc3RhdGlzdGljcyBkdXJpbmcgY2FsbC48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1UaGVyZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlz LCBhbmQgdGhlIHJhdGlvbmFsZSBpcyB0aGUgc2lnbmFsaW5nIHBsYW5lIGJveCB0aGF0IHdhbnRz IHRoaXMgaW5mbyBpcyBub3QgYWN0dWFsbHkgdGhlIG1lZGlhIHBsYW5lIGJveCB0aGF0IGdldHMg UlRDUC4mbmJzcDsgQWdhaW4gdGhpcyBjb3VsZCAoYW5kIElNTyBzaG91bGQpIGJlIGRvbmUgd2l0 aCBzdWIvbm90LCBzbyBpdCBjYW4gZ2V0IHN0YXRzIGFmdGVyIHRoZSBjYWxsIGlzIG92ZXIsIGFu ZCBzaW5jZSBpdCB3aWxsIHByb2JhYmx5IHdhbnQgcGVyaW9kaWMgcmVwb3J0cyB0aGUgb3Zlcmhl YWQgb2YgdGhlIFN1YnNjcmliZSBzaG91bGQgYmUgZHdhcmZlZCBieSB0aGUgbnVtYmVyIG9mIE5v dGlmaWVzLjxCUj48QlI+MikgU2VuZGluZyBhY2Nlc3MtbG9jYXRpb24gaW5mb3JtYXRpb24gYWZ0 ZXIgY2FsbCBlc3RhYmxpc2htZW50LjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLVRoZXJlIGlzIGEgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciwgYW5k IHNvbWUgaGF2ZSBwcm9wb3NlZCB0byBzZW5kIGFuIHVwZGF0ZSBmb3IgaXQgYXMgYSBwaG9uZSBy b2FtcyBhY2Nlc3MgcG9pbnRzIG9yIGNlbGxzLiZuYnNwOyBCdXQgSSB0aGluayB0aGlzIGlzIGFu IG9kZCB0aGluZyB0byBkbyBpbnNpZGUgYW4gSW52aXRlIHNlc3Npb24sIHZzLiBpbiBhIHN1Yi9u b3Qgb3IgUmVnaXN0ZXIgKGFuZCBiZXNpZGVzIGhhbGYgdGhlIHRpbWUgdGhlIG5ldHdvcmsgaW5z ZXJ0cyB0aGlzIGhlYWRlciwgbm90IHRoZSBVQSkuPEJSPjxCUj4zKSBTZW5kaW5nIG1lZGlhLWNv bnRyb2wgaW5kaWNhdGlvbnMgKGllLCByZW1vdGUtY29udHJvbCAicGxheS9wYXVzZS9ldGMuIik8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1UaGlzIGlzIGRv bmUgdG9kYXkgYnkgYXQgbGVhc3Qgb25lIHZlbmRvciwgYnV0IGlzIGRlYmF0YWJsZSBpZiBpdCdz IHRoZSByaWdodCBtb2RlbC4mbmJzcDsgVGhlIGFyZ3VtZW50IGlzIGl0J3MgbGlrZSBTRFAgcmUt SW52aXRlIGZvciBob2xkLCBleGNlcHQgYXQgYSBtZWRpYSBjb250ZW50IGxheWVyIGFib3ZlIFJU UCwgc28gbm90IGRvbmUgaW4gUlRDUCBub3IgU0RQLjxCUj48QlI+NCkgU2VuZGluZyB2aWRlbyBm YXN0IHVwZGF0ZSBjb21tYW5kPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtVGhpcyBpcyBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0LCB3aGljaCBkb2N1bWVudHMg d2hhdCBoYXMgYmVlbiBpbXBsZW1lbnRlZCwgYnV0IHN0YXRlcyBpdCBzaG91bGQgcmVhbGx5IGJl IGRvbmUgaW4gdGhlIG1lZGlhIHBsYW5lLjxCUj48QlI+NSkgU2VuZGluZyBwZXJpcGhlcmFsIGNv bnRyb2wgY29tbWFuZHMgKGllLCBVU0IgY29tbWFuZHMpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtVGhlcmUgaXMgYWN0dWFsbHkgYSBwYXRlbnQgb24gdGhp cywgYW1hemluZ2x5LiZuYnNwOyBTb21lb25lIHRoaW5rcyBpdCBtYWtlcyBzZW5zZSB0byBjcmVh dGUgYSBTSVAgc2Vzc2lvbiB0byB5b3VyIGxhcHRvcCwgb3IgdmljZS12ZXJzYSwgYW5kIHRoZW4g c2VuZCBVU0IgY29tbWFuZHMgaW5zaWRlIE1JTUUgaW4gSU5GTyBtZXNzYWdlcy4mbmJzcDsgTWV0 aGlua3MgdGhpcyBzaG91bGQgYmUgbWVkaWEtcGxhbmUsIGlmIGFueXRoaW5nLjxCUj48QlI+Nikg U2VuZGluZyBjaGFyZ2luZyBpbmZvcm1hdGlvbiBmb3IgYSBjYWxsIChpLmUuLCBtaW51dGVzIHJl bWFpbmluZyBvciBjb3N0IHNvIGZhcikuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtVGhlcmUgd2FzIGEgcHJvcG9zYWwgdG8gdXNlIHRoaXMgZm9yIEFkdmlj ZSBvZiBDaGFyZ2UgaW5mb3JtYXRpb24gaW4gVElTUEFOLiZuYnNwOyBJTU8gaXQgc2hvdWxkIGJl IGEgc3ViL25vdCB0aG91Z2gsIGFzIHRoZXkgd2FudCB0aGlzIHRvIHN1cnZpdmUgdGhlIEludml0 ZSBzZXNzaW9uLjxCUj48QlI+LWhhZHJpZWw8QlI+PEJSPjxCUj48L0ZPTlQ+PC9QPjwvRElWPjwv RElWPjwvQkxPQ0tRVU9URT48L0RJVj48L2JvZHk+ ------_=_NextPart_001_01C8388D.3A039C6C-- --===============1287765311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1287765311==-- From sip-bounces@ietf.org Fri Dec 07 00:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VZR-0008I2-Pi; Fri, 07 Dec 2007 00:16:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0VZQ-0008Hg-RY for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 00:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0VZQ-0008HY-Hy for sip@ietf.org; Fri, 07 Dec 2007 00:16:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0VZP-0000ek-9E for sip@ietf.org; Fri, 07 Dec 2007 00:16:16 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC70521295; Fri, 7 Dec 2007 06:14:33 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-41-4758d6b91067 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC07221179; Fri, 7 Dec 2007 06:14:33 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 06:14:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 06:11:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg4e720MWNQEr4bSuyG3N7Vp+zH/AAE+S7X References: <4758AC44.6030900@cisco.com> <4758B494.7010103@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 07 Dec 2007 05:14:33.0439 (UTC) FILETIME=[0D953EF0:01C83890] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 Just to clarify, when we talk about MESSAGE I assume we do allow it to = be used within the invite dialog if appropriate (RFC3428 does allow it)? =20 Regards, =20 Christer ________________________________ L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@cisco.com] L=E4hetetty: pe 7.12.2007 3:48 Vastaanottaja: Hadriel Kaplan Kopio: sip@ietf.org Aihe: Re: [Sip] INFO use-cases Hadriel Kaplan wrote: > Hey Paul, > Yeah I agree MESSAGE makes a lot of sense for things to be rendered = natively/directly to the user. > > Regarding using MSRP: while that is obviously possible and for some = cases undoubtedly the right thing to do, for some uses it is a crazy = amount of overhead. For example if I want to send you a vcard mid-call, = it seems silly to send a re-Invite to add an MSRP session, potentially = go get msrp-relay info to do so, and/or possibly go through ICE = procedures, all just to send you a 100 byte little vcard I could have = sent in an INFO. But clearly if I need to send you a 10MB file it will = be appropriate. My 2 cents anyway. Yes, I agree. In some cases even though it is a rediculous amount of overhead it just won't matter and will be the right thing to do anyway if the infrastructure is there to do it. In other cases that isn't so. I'm certainly open to some uses for INFO or for more marginal uses of MESSAGE. Especially if we go ahead with this INFO enhancement I think we need to draw the line carefully between INFO and MESSAGE. Paul > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, December 06, 2007 9:13 PM >> To: Hadriel Kaplan >> Cc: sip@ietf.org >> Subject: Re: [Sip] INFO use-cases >> >> Hadriel, >> >> I buy some of your use cases, but not others. Comments below. >> >> A competitor for INFO in several of these is MESSAGE. I think a good >> case can be made for that if the information is to be rendered to the >> recipient. >> >> Paul >> >> >> Hadriel Kaplan wrote: >> [snip] >> >>> /**************** >>> * Use-cases that I think are potentially/possibly valid for INFO: >>> ****************/ >>> 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can = you >> send me John's vcard?", Bob clicks something and voila it's sent. >>> -Alternatives: send a re-Invite or Update with a Call-Info, = with >> either a URL reference, data URI, or MIME and CID URL. >>> -Counter-argument: IMO this type of data really belongs in = MIME >> for a number of reasons, including length is less restricted for mime >> attachments; one AD has said the Data URL may be deprecated. And = sending >> a re-Invite for this purpose seems odd. >>> -Also, the Call-Info header is really about the caller or >> callee, and thus Bob shouldn't be sending me John's vcard info in it >> technically. That may sound like a nit, but UA's may well store the = call- >> info vcards into their address-books automatically and so tie it to = the >> wrong user/call. >>> -Pros of using INFO: it's explicit what you're doing when = you >> send the vcard, and you can send it knowing the other end can accept = it, >> and you can send it based on user input. >>> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an >> icon that represents himself, sends it when he picks up the phone. >>> -Alternatives: send a 200ok, re-Invite, or Update with call- >> info, which explicitly has a type for icon. >>> -Counter-argument: same as for vcard, plus with call-info = there >> is no way to know which picture format the far-end supports a priori. >> With a supported-package negotiation one could know. >> >> For this case MESSAGE seems entirely appropriate. >> >> (Not so much so for vcard, which probably isn't intended to be = directly >> rendered to the recipient.) >> >>> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says = "hey >> let's have a con call at time X", clicks and voila his phone sends a >> vcalendar. >>> -Whether the vcalendar is related to the session or not and = thus >> whether it should be sent in an in-dialog request or not is certainly >> debatable. Message method can already be used for this anyway. >>> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks = for >> more info or a datasheet and Bob sends a URL for Alice to open with = her >> web-browser. >>> -One could also argue this is just making SIP the new SMTP, = or >> this should be sent using MESSAGE (which really is the new SMTP). >> >> Yes to MESSAGE. >> >>> 5) Sending a session traceroute. Alice calls Bob, Bob answers, = Alice >> does a sip-traceroute to figure out the path to Bob, by sending Info = with >> an incrementing max-forwards type header starting at 0 (but not = really >> max-forwards), with a sip-frag type response body or some such. >>> -It's debatable if certain types of B2BUA's (ie, SBCs) would >> ever allow this type of thing to happen, due to security concerns, = but I >> think they may do it at domain boundary hops. I think this is a >> reasonable use for INFO though, maybe. >>> 6) Sending geo-location information after call establishment. Alice >> calls Bob, a hotel receptionist. Alice asks for directions to hotel, >> clicks button and sends him location info of her phone (or Bob clicks >> button and sends her his location). >>> -The location conveyance draft specifically calls out INFO = as >> acceptable for geo-loc info. Whether this is a real use-case is >> debatable, and obviously it could be done with a sub/not. >> >> UPDATE with geo-loc is reasonable here, or even reINVITE. >> >>> 7) Sending softkey-labels (not digit-match maps, but rather softkey >> button labels). Alice calls her vmail server. Vmail server sends >> softkey-labels for the menu items available in the response, Alice = presses >> softkeys and sends them in INFO. >>> -This could (and maybe should) be done with sub/not, a la = KPML, >> where the vmail server sends the softkey labels in the Subscribe, UA = sends >> buttons pressed in Notifies. But this is similar to the DTMF use = case so >> may well have the same benefit of lower overhead since buttons are = rarely >> pressed. >>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue = with >> this session?" >>> -There is a patent for doing screen pop-ups using INFO. I = guess >> Alert-Info could be used for this, but it's not clear it should? >> >> This is very definitely a use case for MESSAGE. >> >> Also, all of the above could probably be justifiably sent via MSRP - >> either directly or via the file transfer extensions. >> >>> /***************** >>> * Use-cases which have been proposed by others or even implemented, >>> * which are dubious for INFO (IMHO): >>> *****************/ >>> 1) Sending RTP/RTCP statistics during call. >>> -There is an implementation of this, and the rationale is = the >> signaling plane box that wants this info is not actually the media = plane >> box that gets RTCP. Again this could (and IMO should) be done with >> sub/not, so it can get stats after the call is over, and since it = will >> probably want periodic reports the overhead of the Subscribe should = be >> dwarfed by the number of Notifies. >>> 2) Sending access-location information after call establishment. >>> -There is a P-Access-Network-Info header, and some have = proposed >> to send an update for it as a phone roams access points or cells. = But I >> think this is an odd thing to do inside an Invite session, vs. in a >> sub/not or Register (and besides half the time the network inserts = this >> header, not the UA). >>> 3) Sending media-control indications (ie, remote-control >> "play/pause/etc.") >>> -This is done today by at least one vendor, but is debatable = if >> it's the right model. The argument is it's like SDP re-Invite for = hold, >> except at a media content layer above RTP, so not done in RTCP nor = SDP. >>> 4) Sending video fast update command >>> -This is an informational draft, which documents what has = been >> implemented, but states it should really be done in the media plane. >>> 5) Sending peripheral control commands (ie, USB commands) >>> -There is actually a patent on this, amazingly. Someone = thinks >> it makes sense to create a SIP session to your laptop, or vice-versa, = and >> then send USB commands inside MIME in INFO messages. Methinks this = should >> be media-plane, if anything. >>> 6) Sending charging information for a call (i.e., minutes remaining = or >> cost so far). >>> -There was a proposal to use this for Advice of Charge >> information in TISPAN. IMO it should be a sub/not though, as they = want >> this to survive the Invite session. >>> -hadriel >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 01:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0WKl-0007oP-5O; Fri, 07 Dec 2007 01:05:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0WKk-0007oE-4d for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 01:05:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0WKj-0007o5-Q0 for sip@ietf.org; Fri, 07 Dec 2007 01:05:09 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0WKi-0002aG-MQ for sip@ietf.org; Fri, 07 Dec 2007 01:05:09 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 7 Dec 2007 01:05:08 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 7 Dec 2007 01:05:08 -0500 From: Hadriel Kaplan To: Christer Holmberg , Paul Kyzivat Date: Fri, 7 Dec 2007 01:04:32 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg4e720MWNQEr4bSuyG3N7Vp+zH/AAE+S7XAAHD8PA= Message-ID: References: <4758AC44.6030900@cisco.com> <4758B494.7010103@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yup, it's allowed. Section 4: "A UAC MAY associate a MESSAGE request with = an existing dialog." -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, December 07, 2007 12:12 AM > To: Paul Kyzivat; Hadriel Kaplan > Cc: sip@ietf.org > Subject: VS: [Sip] INFO use-cases > > Hi, > > Just to clarify, when we talk about MESSAGE I assume we do allow it to be > used within the invite dialog if appropriate (RFC3428 does allow it)? > > Regards, > > Christer > > ________________________________ > > L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@cisco.com] > L=E4hetetty: pe 7.12.2007 3:48 > Vastaanottaja: Hadriel Kaplan > Kopio: sip@ietf.org > Aihe: Re: [Sip] INFO use-cases > > > > > > Hadriel Kaplan wrote: > > Hey Paul, > > Yeah I agree MESSAGE makes a lot of sense for things to be rendered > natively/directly to the user. > > > > Regarding using MSRP: while that is obviously possible and for some > cases undoubtedly the right thing to do, for some uses it is a crazy > amount of overhead. For example if I want to send you a vcard mid-call, > it seems silly to send a re-Invite to add an MSRP session, potentially go > get msrp-relay info to do so, and/or possibly go through ICE procedures, > all just to send you a 100 byte little vcard I could have sent in an INFO= . > But clearly if I need to send you a 10MB file it will be appropriate. My > 2 cents anyway. > > Yes, I agree. In some cases even though it is a rediculous amount of > overhead it just won't matter and will be the right thing to do anyway > if the infrastructure is there to do it. In other cases that isn't so. > I'm certainly open to some uses for INFO or for more marginal uses of > MESSAGE. > > Especially if we go ahead with this INFO enhancement I think we need to > draw the line carefully between INFO and MESSAGE. > > Paul > > > -hadriel > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, December 06, 2007 9:13 PM > >> To: Hadriel Kaplan > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] INFO use-cases > >> > >> Hadriel, > >> > >> I buy some of your use cases, but not others. Comments below. > >> > >> A competitor for INFO in several of these is MESSAGE. I think a good > >> case can be made for that if the information is to be rendered to the > >> recipient. > >> > >> Paul > >> > >> > >> Hadriel Kaplan wrote: > >> [snip] > >> > >>> /**************** > >>> * Use-cases that I think are potentially/possibly valid for INFO: > >>> ****************/ > >>> 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can > you > >> send me John's vcard?", Bob clicks something and voila it's sent. > >>> -Alternatives: send a re-Invite or Update with a Call-Info, > with > >> either a URL reference, data URI, or MIME and CID URL. > >>> -Counter-argument: IMO this type of data really belongs in > MIME > >> for a number of reasons, including length is less restricted for mime > >> attachments; one AD has said the Data URL may be deprecated. And > sending > >> a re-Invite for this purpose seems odd. > >>> -Also, the Call-Info header is really about the caller or > >> callee, and thus Bob shouldn't be sending me John's vcard info in it > >> technically. That may sound like a nit, but UA's may well store the > call- > >> info vcards into their address-books automatically and so tie it to th= e > >> wrong user/call. > >>> -Pros of using INFO: it's explicit what you're doing when you > >> send the vcard, and you can send it knowing the other end can accept > it, > >> and you can send it based on user input. > >>> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an > >> icon that represents himself, sends it when he picks up the phone. > >>> -Alternatives: send a 200ok, re-Invite, or Update with call- > >> info, which explicitly has a type for icon. > >>> -Counter-argument: same as for vcard, plus with call-info > there > >> is no way to know which picture format the far-end supports a priori. > >> With a supported-package negotiation one could know. > >> > >> For this case MESSAGE seems entirely appropriate. > >> > >> (Not so much so for vcard, which probably isn't intended to be directl= y > >> rendered to the recipient.) > >> > >>> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says > "hey > >> let's have a con call at time X", clicks and voila his phone sends a > >> vcalendar. > >>> -Whether the vcalendar is related to the session or not and > thus > >> whether it should be sent in an in-dialog request or not is certainly > >> debatable. Message method can already be used for this anyway. > >>> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for > >> more info or a datasheet and Bob sends a URL for Alice to open with he= r > >> web-browser. > >>> -One could also argue this is just making SIP the new SMTP, o= r > >> this should be sent using MESSAGE (which really is the new SMTP). > >> > >> Yes to MESSAGE. > >> > >>> 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice > >> does a sip-traceroute to figure out the path to Bob, by sending Info > with > >> an incrementing max-forwards type header starting at 0 (but not really > >> max-forwards), with a sip-frag type response body or some such. > >>> -It's debatable if certain types of B2BUA's (ie, SBCs) would > >> ever allow this type of thing to happen, due to security concerns, but > I > >> think they may do it at domain boundary hops. I think this is a > >> reasonable use for INFO though, maybe. > >>> 6) Sending geo-location information after call establishment. Alice > >> calls Bob, a hotel receptionist. Alice asks for directions to hotel, > >> clicks button and sends him location info of her phone (or Bob clicks > >> button and sends her his location). > >>> -The location conveyance draft specifically calls out INFO as > >> acceptable for geo-loc info. Whether this is a real use-case is > >> debatable, and obviously it could be done with a sub/not. > >> > >> UPDATE with geo-loc is reasonable here, or even reINVITE. > >> > >>> 7) Sending softkey-labels (not digit-match maps, but rather softkey > >> button labels). Alice calls her vmail server. Vmail server sends > >> softkey-labels for the menu items available in the response, Alice > presses > >> softkeys and sends them in INFO. > >>> -This could (and maybe should) be done with sub/not, a la > KPML, > >> where the vmail server sends the softkey labels in the Subscribe, UA > sends > >> buttons pressed in Notifies. But this is similar to the DTMF use case > so > >> may well have the same benefit of lower overhead since buttons are > rarely > >> pressed. > >>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue > with > >> this session?" > >>> -There is a patent for doing screen pop-ups using INFO. I > guess > >> Alert-Info could be used for this, but it's not clear it should? > >> > >> This is very definitely a use case for MESSAGE. > >> > >> Also, all of the above could probably be justifiably sent via MSRP - > >> either directly or via the file transfer extensions. > >> > >>> /***************** > >>> * Use-cases which have been proposed by others or even implemented, > >>> * which are dubious for INFO (IMHO): > >>> *****************/ > >>> 1) Sending RTP/RTCP statistics during call. > >>> -There is an implementation of this, and the rationale is the > >> signaling plane box that wants this info is not actually the media > plane > >> box that gets RTCP. Again this could (and IMO should) be done with > >> sub/not, so it can get stats after the call is over, and since it will > >> probably want periodic reports the overhead of the Subscribe should be > >> dwarfed by the number of Notifies. > >>> 2) Sending access-location information after call establishment. > >>> -There is a P-Access-Network-Info header, and some have > proposed > >> to send an update for it as a phone roams access points or cells. But > I > >> think this is an odd thing to do inside an Invite session, vs. in a > >> sub/not or Register (and besides half the time the network inserts thi= s > >> header, not the UA). > >>> 3) Sending media-control indications (ie, remote-control > >> "play/pause/etc.") > >>> -This is done today by at least one vendor, but is debatable > if > >> it's the right model. The argument is it's like SDP re-Invite for > hold, > >> except at a media content layer above RTP, so not done in RTCP nor SDP= . > >>> 4) Sending video fast update command > >>> -This is an informational draft, which documents what has bee= n > >> implemented, but states it should really be done in the media plane. > >>> 5) Sending peripheral control commands (ie, USB commands) > >>> -There is actually a patent on this, amazingly. Someone > thinks > >> it makes sense to create a SIP session to your laptop, or vice-versa, > and > >> then send USB commands inside MIME in INFO messages. Methinks this > should > >> be media-plane, if anything. > >>> 6) Sending charging information for a call (i.e., minutes remaining o= r > >> cost so far). > >>> -There was a proposal to use this for Advice of Charge > >> information in TISPAN. IMO it should be a sub/not though, as they wan= t > >> this to survive the Invite session. > >>> -hadriel > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >>> > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 01:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wti-00063b-PJ; Fri, 07 Dec 2007 01:41:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Wtg-00063W-KS for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 01:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wtg-00063N-0l for sip@ietf.org; Fri, 07 Dec 2007 01:41:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Wtd-00048z-C5 for sip@ietf.org; Fri, 07 Dec 2007 01:41:15 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2007 22:41:13 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB76fC2e018833; Thu, 6 Dec 2007 22:41:12 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB76f887027359; Fri, 7 Dec 2007 06:41:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 22:41:07 -0800 Received: from [10.21.122.251] ([10.21.122.251]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 22:41:07 -0800 Message-ID: <4758EB03.2050600@cisco.com> Date: Fri, 07 Dec 2007 01:41:07 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] INFO use-cases References: <4758AC44.6030900@cisco.com> <4758B494.7010103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Dec 2007 06:41:07.0525 (UTC) FILETIME=[257FDF50:01C8389C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10018; t=1197009672; x=1197873672; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20INFO=20use-cases |Sender:=20; bh=JtGpLJYLqI57M7EptBqgaVFC4HkfiLZuHTLxwmXshic=; b=Tj2KfeueL8MCm8vzJyOEHh1Cj+ot4rF1sNfHzY00fwZ4PS8hh/T74DmJuJbTgtIsJpsprP+5 1A3llHGT455eGkATZjd0gai961fJPZkpv8YuPj/DGkSB2ISMIwC2i04q; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, AFAIK it is permitted within a dialog. It just is improper to establish a dialog for the purpose of using MESSAGE for an IM session. Using it in support of an existing dialog should be fine. Paul Christer Holmberg wrote: > Hi, > > Just to clarify, when we talk about MESSAGE I assume we do allow it to be used within the invite dialog if appropriate (RFC3428 does allow it)? > > Regards, > > Christer > > ________________________________ > > Lähettäjä: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Lähetetty: pe 7.12.2007 3:48 > Vastaanottaja: Hadriel Kaplan > Kopio: sip@ietf.org > Aihe: Re: [Sip] INFO use-cases > > > > > > Hadriel Kaplan wrote: >> Hey Paul, >> Yeah I agree MESSAGE makes a lot of sense for things to be rendered natively/directly to the user. >> >> Regarding using MSRP: while that is obviously possible and for some cases undoubtedly the right thing to do, for some uses it is a crazy amount of overhead. For example if I want to send you a vcard mid-call, it seems silly to send a re-Invite to add an MSRP session, potentially go get msrp-relay info to do so, and/or possibly go through ICE procedures, all just to send you a 100 byte little vcard I could have sent in an INFO. But clearly if I need to send you a 10MB file it will be appropriate. My 2 cents anyway. > > Yes, I agree. In some cases even though it is a rediculous amount of > overhead it just won't matter and will be the right thing to do anyway > if the infrastructure is there to do it. In other cases that isn't so. > I'm certainly open to some uses for INFO or for more marginal uses of > MESSAGE. > > Especially if we go ahead with this INFO enhancement I think we need to > draw the line carefully between INFO and MESSAGE. > > Paul > >> -hadriel >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Thursday, December 06, 2007 9:13 PM >>> To: Hadriel Kaplan >>> Cc: sip@ietf.org >>> Subject: Re: [Sip] INFO use-cases >>> >>> Hadriel, >>> >>> I buy some of your use cases, but not others. Comments below. >>> >>> A competitor for INFO in several of these is MESSAGE. I think a good >>> case can be made for that if the information is to be rendered to the >>> recipient. >>> >>> Paul >>> >>> >>> Hadriel Kaplan wrote: >>> [snip] >>> >>>> /**************** >>>> * Use-cases that I think are potentially/possibly valid for INFO: >>>> ****************/ >>>> 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you >>> send me John's vcard?", Bob clicks something and voila it's sent. >>>> -Alternatives: send a re-Invite or Update with a Call-Info, with >>> either a URL reference, data URI, or MIME and CID URL. >>>> -Counter-argument: IMO this type of data really belongs in MIME >>> for a number of reasons, including length is less restricted for mime >>> attachments; one AD has said the Data URL may be deprecated. And sending >>> a re-Invite for this purpose seems odd. >>>> -Also, the Call-Info header is really about the caller or >>> callee, and thus Bob shouldn't be sending me John's vcard info in it >>> technically. That may sound like a nit, but UA's may well store the call- >>> info vcards into their address-books automatically and so tie it to the >>> wrong user/call. >>>> -Pros of using INFO: it's explicit what you're doing when you >>> send the vcard, and you can send it knowing the other end can accept it, >>> and you can send it based on user input. >>>> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an >>> icon that represents himself, sends it when he picks up the phone. >>>> -Alternatives: send a 200ok, re-Invite, or Update with call- >>> info, which explicitly has a type for icon. >>>> -Counter-argument: same as for vcard, plus with call-info there >>> is no way to know which picture format the far-end supports a priori. >>> With a supported-package negotiation one could know. >>> >>> For this case MESSAGE seems entirely appropriate. >>> >>> (Not so much so for vcard, which probably isn't intended to be directly >>> rendered to the recipient.) >>> >>>> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey >>> let's have a con call at time X", clicks and voila his phone sends a >>> vcalendar. >>>> -Whether the vcalendar is related to the session or not and thus >>> whether it should be sent in an in-dialog request or not is certainly >>> debatable. Message method can already be used for this anyway. >>>> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for >>> more info or a datasheet and Bob sends a URL for Alice to open with her >>> web-browser. >>>> -One could also argue this is just making SIP the new SMTP, or >>> this should be sent using MESSAGE (which really is the new SMTP). >>> >>> Yes to MESSAGE. >>> >>>> 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice >>> does a sip-traceroute to figure out the path to Bob, by sending Info with >>> an incrementing max-forwards type header starting at 0 (but not really >>> max-forwards), with a sip-frag type response body or some such. >>>> -It's debatable if certain types of B2BUA's (ie, SBCs) would >>> ever allow this type of thing to happen, due to security concerns, but I >>> think they may do it at domain boundary hops. I think this is a >>> reasonable use for INFO though, maybe. >>>> 6) Sending geo-location information after call establishment. Alice >>> calls Bob, a hotel receptionist. Alice asks for directions to hotel, >>> clicks button and sends him location info of her phone (or Bob clicks >>> button and sends her his location). >>>> -The location conveyance draft specifically calls out INFO as >>> acceptable for geo-loc info. Whether this is a real use-case is >>> debatable, and obviously it could be done with a sub/not. >>> >>> UPDATE with geo-loc is reasonable here, or even reINVITE. >>> >>>> 7) Sending softkey-labels (not digit-match maps, but rather softkey >>> button labels). Alice calls her vmail server. Vmail server sends >>> softkey-labels for the menu items available in the response, Alice presses >>> softkeys and sends them in INFO. >>>> -This could (and maybe should) be done with sub/not, a la KPML, >>> where the vmail server sends the softkey labels in the Subscribe, UA sends >>> buttons pressed in Notifies. But this is similar to the DTMF use case so >>> may well have the same benefit of lower overhead since buttons are rarely >>> pressed. >>>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue with >>> this session?" >>>> -There is a patent for doing screen pop-ups using INFO. I guess >>> Alert-Info could be used for this, but it's not clear it should? >>> >>> This is very definitely a use case for MESSAGE. >>> >>> Also, all of the above could probably be justifiably sent via MSRP - >>> either directly or via the file transfer extensions. >>> >>>> /***************** >>>> * Use-cases which have been proposed by others or even implemented, >>>> * which are dubious for INFO (IMHO): >>>> *****************/ >>>> 1) Sending RTP/RTCP statistics during call. >>>> -There is an implementation of this, and the rationale is the >>> signaling plane box that wants this info is not actually the media plane >>> box that gets RTCP. Again this could (and IMO should) be done with >>> sub/not, so it can get stats after the call is over, and since it will >>> probably want periodic reports the overhead of the Subscribe should be >>> dwarfed by the number of Notifies. >>>> 2) Sending access-location information after call establishment. >>>> -There is a P-Access-Network-Info header, and some have proposed >>> to send an update for it as a phone roams access points or cells. But I >>> think this is an odd thing to do inside an Invite session, vs. in a >>> sub/not or Register (and besides half the time the network inserts this >>> header, not the UA). >>>> 3) Sending media-control indications (ie, remote-control >>> "play/pause/etc.") >>>> -This is done today by at least one vendor, but is debatable if >>> it's the right model. The argument is it's like SDP re-Invite for hold, >>> except at a media content layer above RTP, so not done in RTCP nor SDP. >>>> 4) Sending video fast update command >>>> -This is an informational draft, which documents what has been >>> implemented, but states it should really be done in the media plane. >>>> 5) Sending peripheral control commands (ie, USB commands) >>>> -There is actually a patent on this, amazingly. Someone thinks >>> it makes sense to create a SIP session to your laptop, or vice-versa, and >>> then send USB commands inside MIME in INFO messages. Methinks this should >>> be media-plane, if anything. >>>> 6) Sending charging information for a call (i.e., minutes remaining or >>> cost so far). >>>> -There was a proposal to use this for Advice of Charge >>> information in TISPAN. IMO it should be a sub/not though, as they want >>> this to survive the Invite session. >>>> -hadriel >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 01:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wzs-0000GC-Fw; Fri, 07 Dec 2007 01:47:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0Wzq-0000Fo-W4 for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 01:47:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wzq-0000Fd-KK for sip@ietf.org; Fri, 07 Dec 2007 01:47:38 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Wzo-0004OA-3a for sip@ietf.org; Fri, 07 Dec 2007 01:47:38 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 7 Dec 2007 01:47:35 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 7 Dec 2007 01:47:35 -0500 From: Hadriel Kaplan To: =?utf-8?B?7Zmp7KeE6rK9W+yXsOq1rOyghOusuOq3uOujuV0=?= , "Sanjay Sinha (sanjsinh)" Date: Fri, 7 Dec 2007 01:46:56 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAqGCewAAa5NCAAAsOWcA== Message-ID: References: <01fe01c83876$9d5a5b20$df2a0693@oasys.kt.co.kr> <01e001c8388f$6d3be620$df2a0693@oasys.kt.co.kr> In-Reply-To: <01e001c8388f$6d3be620$df2a0693@oasys.kt.co.kr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5111b5a9ab7dba405901980ae5cc17e9 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485038598==" Errors-To: sip-bounces@ietf.org --===============0485038598== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273926572mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273926572mailacmepacke_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgY29uZnVzaW9uIGp1c3QgY2FtZSBmcm9tIHlvdXIgZGVzY3JpYmluZyB3aGF0 IHB1cnBvc2UgeW91IHdhbnRlZCB0aGUgaG9vay1mbGFzaCBpbmRpY2F0aW9uIGZvciwgd2hpY2gg d2FzIGZvciBhcHBsaWNhdGlvbiBmZWF0dXJlcyAoMy13YXkgY2FsbGluZywgY2FsbCB3YWl0aW5n LCB0cmFuc2ZlcikuICBTSVAgb2J2aW91c2x5IGV4cGVjdHMgc3VjaCB0aGluZ3MgdG8gYmUgZG9u ZS9pbml0aWF0ZWQgYnkgdGhlIFVB4oCZcyB0aGVtc2VsdmVzIG5hdGl2ZWx5LCBieSBoYW5kbGlu ZyBtdWx0aXBsZSBzZXNzaW9ucywgUkVGRVJzLCBldGMuIOKAkyB2cy4gdXNpbmcgYSBjZW50cmFs aXplZCBhcHAtc2VydmVyIHRvIGNvbnRhaW4gdGhlIGVudGlyZSBzZXJ2aWNlIGxvZ2ljIGFuZCB0 cmVhdGluZyB0aGUgcGhvbmUgYXMgYSBQT1RTIGxpbmUuICBJbiB5b3VyIGRyYWZ0IHlvdSBoYWQg TUdDUC1jb250cm9sbGVkIHBob25lIHNlcnZpY2VkIGJ5IGFuIE1HQywgd2hpY2ggd2FzIGFjdGlu ZyBhcyBhIFNJUCBVQSBidXQgZXhwZWN0aW5nIGEgc2VwYXJhdGUgU0lQIEFwcCBTZXJ2ZXIgdG8g ZG8gaXRzIGRpcnR5IHdvcmsuICBUaGF0IE1HQyByZWFsbHkgaXMgYSBzdGFuZC1hbG9uZSBTSVAg VUEgYW5kIHRodXMgY291bGQvc2hvdWxkIGhhbmRsZSB0aGUgc2VydmljZSBsb2dpYy4gIE90aGVy d2lzZSBpdOKAmXMganVzdCB1c2luZyBTSVAgYXMgYSB0dW5uZWxpbmcgdHJhbnNwb3J0IGZvciBN R0NQIGluIGEgd2F5IChhdCBsZWFzdCBhcmNoaXRlY3R1cmFsbHkpLiAgRm9yIGV4YW1wbGUgaWYg eW91ciBTSVAgVUEgcmVjZWl2ZXMgYSBjYWxsIGRpcmVjdGx5IGZyb20gYW5vdGhlciBwcm94eS9V QSwgdGhlIOKAnGZlYXR1cmVz4oCdIG5vIGxvbmdlciB3b3JrIGJlY2F1c2UgdGhlIEFwcCBTZXJ2 ZXIgaXMgbm90IGluIHRoZSBsb29wLg0KDQpTbyBJIHRoaW5rIGl04oCYcyBqdXN0IHNhZmVyL2Ns ZWFuZXIgaWYgeW91IGRlc2NyaWJlIHlvdXIgdXNlLWNhc2UgYXMgc2ltcGx5IHdhbnRpbmcgdG8g Z2V0IGhvb2stZmxhc2ggaW5kaWNhdGlvbiwgYXMganVzdCBhbm90aGVyIGZvcm0gb2YgYXN5bmNo cm9ub3VzIHVzZXIgaW5wdXQgc2ltaWxhciBpbiBjb25jZXB0IHRvIGEgc29mdC1idXR0b24gb3Ig RFRNRi4gIChpdOKAmXMgYWN0dWFsbHkgbm90IGNsZWFyIHRvIG1lIGhvb2stZmxhc2ggYWN0dWFs bHkgaXMgc3VjaCBhIHRoaW5nLCBiZWNhdXNlIGl04oCZcyByZWFsbHkgc3lub255bW91cyB3aXRo IGEgaG9sZC90cmFuc2Zlci9jb25mZXJlbmNlIGJ1dHRvbiwgYnV0IGl04oCZcyBhcmd1YWJsZSBh dCBsZWFzdCkNCg0KLWhhZHJpZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IO2ZqeynhOqyvVvsl7DqtazsoITrrLjqt7jro7ldIFttYWlsdG86amtod2FuZ0BrdC5j by5rcl0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDcsIDIwMDcgMTI6MTAgQU0NClRvOiBTYW5q YXkgU2luaGEgKHNhbmpzaW5oKTsgSGFkcmllbCBLYXBsYW4NCkNjOiBzaXBAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlcw0KDQoNCg0KDQpEZWFyIHNhbmpzaW5oDQoN Cg0KDQpJIGRvbid0IGtub3cgdGhlIG90aGVyIHdheSB0byBjb2xsZWN0ICJIb29rLUZsYXNoIiBl dmVudCBhbG9uZyBvbi1nb2luZyBkaWFsb2d1ZS4NCg0KV2hhdCBpcyB0aGUgc3VnZ2VzdGVkICdu b24tSU5GTyB3YXknID8NCg0KVEhYDQoNCkpLDQotLS0tLeybkOuzuCDrqZTsi5zsp4AtLS0tLQ0K 67O064K4IOyCrOuejDogIlNhbmpheSBTaW5oYSAoc2FuanNpbmgpIiA8c2FuanNpbmhAY2lzY28u Y29tPg0K67O064K4IOuCoOynnDogMjAwNy0xMi0wNyDsmKTtm4QgMTo1NDoxNw0K67Cb64qUIOyC rOuejDogIu2ZqeynhOqyvVvsl7DqtazsoITrrLjqt7jro7ldIiA8amtod2FuZ0BrdC5jby5rcj4s ICJIYWRyaWVsIEthcGxhbiIgPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQrssLjsobA6ICJzaXBA aWV0Zi5vcmciIDxzaXBAaWV0Zi5vcmc+DQrsoJzrqqk6IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNl cw0KVGhlc2UgMyB1c2UgY2FzZXMgYmVsb3cgc2VlbSBtaXN1c2Ugb2YgSU5GTyBhcyB0aGVyZSBh cmUgZXN0YWJsaXNoZWQgbWVjaGFuaXNtIG9mIGRvaW5nIHRoZXNlIHVzaW5nIG5vbi1JTkZPIHdh eS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IO2ZqeynhOqyvVvs l7DqtazsoITrrLjqt7jro7ldIFttYWlsdG86amtod2FuZ0BrdC5jby5rcl0NClNlbnQ6IFRodXJz ZGF5LCBEZWNlbWJlciAwNiwgMjAwNyA5OjEyIFBNDQpUbzogSGFkcmllbCBLYXBsYW4NCkNjOiBz aXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlcw0KDQoNCg0KRGVh ciBIYWRyaWVsIEthcGxhbiBhbmQgZm9sa3MNCg0KDQoNCihpbiBvdXIgY2FzZSkNCg0KTWlkY2Fs bCBJTkZPIGlzIHVzZWQgaW4NCg0KDQoNCjEpIFRocmVlLXdheSBjYWxsaW5nOiB0byBhZGQgYW5v dGhlciBwYXJ0eSB0byBleGlzdGluZyBjYWxsDQoNCjIpIENhbGwgd2FpdGluZzogdG8gY2hhbmdl IGRpYWxvZ3VlIGJldHdlZW4gdHdvIG9uZ29pbmcgY2FsbHMNCg0KMykgQ2VudHJleCBzZXJ2aWNl czogY2FsbCB0cmFuc2ZlciwgZXRjLg0KDQoNCg0KVEhYDQoNCg0KDQpKSyBId2FuZw0KDQpLVA0K LS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS0NCuuztOuCuCDsgqzrnow6ICJIYWRyaWVsIEthcGxh biIgPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQrrs7Trgrgg64Kg7KecOiAyMDA3LTEyLTA3IOyY pOyghCAxMDo0ODoxOQ0K67Cb64qUIOyCrOuejDogIu2ZqeynhOqyvVvsl7DqtazsoITrrLjqt7jr o7ldIiA8amtod2FuZ0BrdC5jby5rcj4NCuywuOyhsDogInNpcEBpZXRmLm9yZyIgPHNpcEBpZXRm Lm9yZz4NCuygnOuqqTogUkU6IFtTaXBdIElORk8gdXNlLWNhc2VzDQoNCg0KDQpIaSBKSywNCkkg YWN0dWFsbHkgc2F3IHRoYXQgZHJhZnQgYnV0IGRpZCBub3QgaW5jbHVkZSBpdCBiZWNhdXNlIEkg dGhvdWdodCBpdCB3YXMgZXNzZW50aWFsbHkgYW5vdGhlciBEVE1GLXN0eWxlIGV2ZW50IHR5cGUs IGFuZCB3b3VsZCBiZSBzdWJzdW1lZCBpbnRvIGl0LCBidXQgeW91J3JlIHJpZ2h0IEkgc2hvdWxk IGhhdmUgaW5jbHVkZWQgdGhhdCB1c2UtY2FzZS4gIFNvcnJ5IQ0KDQotaGFkcmllbA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IO2ZqeynhOqyvVvs l7DqtazsoITrrLjqt7jro7ldIFttYWlsdG86amtod2FuZ0BrdC5jby5rcl0NClNlbnQ6IFRodXJz ZGF5LCBEZWNlbWJlciAwNiwgMjAwNyA4OjMzIFBNDQpUbzogSGFkcmllbCBLYXBsYW47IHNpcEBp ZXRmLm9yZw0KU3ViamVjdDogUkU6IFtTaXBdIElORk8gdXNlLWNhc2VzDQpEZWFyIGZvbGtzLA0K IEhvdyBhYm91dCB0aGUgTWlkY2FsbCBJTkZPID8NCiBXaGVuICdIb29rLUZsYXNoJyBmcm9tIHRo ZSBTSVAgb3IgUE9UUyBwaG9uZSBkdXJpbmcgYSBkaWFsb2d1ZSwgd2UgKEtUKSB1c2UgSU5GTyBt ZXRob2QgZnJvbSB0aGUgQ1NDRi9NR0NGIHRvIEFTLg0KIEkgc3VibWl0dGVkIGEgZHJhZnQgSS1E IHR3byB5ZWFycyBhZ28gYnV0IGl0IHdhcyBub3QgYWNjZXB0ZWQsDQpCdXQgd2Ugc3RpbGwgdXNl IHRoZSBjYXNlLg0KIENhbiBpdCBiZSBhbm90aGVyIFVzZS1DYXNlID8NCiBKSyBId2FuZw0KS1QN Cg0KLS0tLS3sm5Drs7gg66mU7Iuc7KeALS0tLS0NCuuztOuCuCDsgqzrnow6ICJIYWRyaWVsIEth cGxhbiIgPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQrrs7Trgrgg64Kg7KecOiAyMDA3LTEyLTA3 IOyYpOyghCA4OjM4OjM2DQrrsJvripQg7IKs656MOiAic2lwQGlldGYub3JnIiA8c2lwQGlldGYu b3JnPg0K7LC47KGwOg0K7KCc66qpOiBbU2lwXSBJTkZPIHVzZS1jYXNlcw0KDQoNCkhvd2R5LA0K Sm9uYXRoYW4gYXNrZWQgZm9yIHVzZS1jYXNlcyBmb3Igd2hhdCB0eXBlcyBvZiB0aGluZ3Mgd291 bGQgbmVlZCBhbiBpbi1kaWFsb2cgU0lQIG1lc3NhZ2UgZm9yIHVzZXItdXNlciBjb21tdW5pY2F0 aW9uLCB2cy4gc2hvdWxkIGJlIGRvbmUgZWl0aGVyIG91dCBvZiBkaWFsb2cgb3IgaW4gdGhlIG1l ZGlhIHBsYW5lLiAgSWYgdGhlIG9ubHkgdXNlLWNhc2UgaXMgRFRNRiwgdGhlbiB3ZSBjb3VsZCBq dXN0IGRvY3VtZW50IHRoZSBEVE1GIG5lZ290aWF0aW9uL3VzZSBvbmx5IGFuZCBub3QgaGF2ZSB0 byBjcmVhdGUgYSBnZW5lcmFsIGluZm8tZXZlbnRzIGZyYW1ld29yay4gIFRoYXQgc2VlbXMgYSB2 ZXJ5IHJlYXNvbmFibGUgYXJndW1lbnQgdG8gbWUuICBJIGFsc28gZG9uJ3Qgd2FudCB0byBkbyB3 b3JrIGZvciBubyB1c2UuDQoNClRoZXJlIGlzIGEgY291bnRlci1hcmd1bWVudCB0aGF0IHRoZXJl IGFyZSBwcm9wcmlldGFyeSB1c2VzIG9mIElORk8gaW4gdGhlIHdpbGQsIGFuZCB0aGF0IGEgZnJh bWV3b3JrIGZvciBuZWdvdGlhdGlvbiBhdCBsZWFzdCByZW1vdmVzIHRoZSBtYW51YWwgY29uZmln dXJhdGlvbiBvZiB2ZW5kb3Itc3BlY2lmaWMgcHJvZmlsZXMsIHdoaWNoIGlzIGEgcHJvYmxlbSBv ZiBpbnRlcm9wIHRvZGF5IC0gZXZlbiBpZiB0aGUgSUVURiBzaG91bGQgbm90IGJsZXNzL2RvY3Vt ZW50IHRoZSBzcGVjaWZpYyB1c2UgY2FzZXMgdGhlbXNlbHZlcy4gIEJ1dCB0aGF0IHdvdWxkIG1h a2UgdGhlIGRyYWZ0IGEgdmVyeSBkaWZmZXJlbnQgb25lIHRoYW4gaXQgY3VycmVudGx5IGlzIGFz IHdlbGwsIGFuZCBJIHdpbGwgYXNrIHRoYXQgaW4gYSBzZXBhcmF0ZSBlbWFpbCB0aHJlYWQuDQoN ClRoZSBjaGFpcnMgaGF2ZSBhc2tlZCBmb3IgMyB1c2UgY2FzZXMsIGFuZCBJIGFzc3VtZSB0aGV5 IG1lYW4gMyBORVcgdXNlIGNhc2VzICh3ZSBhbHJlYWR5IGhhdmUgMyBSRkNzIHdoaWNoIHVzZSBJ TkZPLCBhcyB3ZWxsIGFzIERUTUYpLiAgSSBhbSBub3Qgc3VyZSBpZiB0aGV5IG1lYW4gcG90ZW50 aWFsIGZ1dHVyZSB1c2UtY2FzZXMsIG9yIGN1cnJlbnQgdXNlLWNhc2VzIChpLmUuLCBhbHJlYWR5 IGltcGxlbWVudGVkKS4gIENhbiBJIGdldCBhIGNsYXJpZmljYXRpb24gb24gdGhhdD8NCg0KU28g YW55d2F5LCB0YWtpbmcgdGhlIHNob3QtZ3VuIGFwcHJvYWNoLCBoZXJlJ3MgYSBmaXJzdCBnbyBh dCBzb21lIHVzZS1jYXNlcywgYW5kIG15IHBlcnNvbmFsIHRha2Ugb24gd2hldGhlciB0aGV5IHNo b3VsZCBiZSBpbiBJTkZPIHZzLiBTVUIvTk9UIHZzLiBtZWRpYS1wbGFuZSwgRldJVy4NClthcG9s b2dpemUgZm9yIGZvcm1hdHRpbmcgdWdsaW5lc3NdDQoNCi8qKioqKioqKioqKioqKioNCiogIEFs cmVhZHkgc3RhbmRhcmRpemVkIHVzZS1jYXNlczoNCioqKioqKioqKioqKioqKi8NCjEpIFNJUC1U L0lTVVAvUVNJRy9QU1RODQogICAgICAgIC1Eb2N1bWVudGVkIGluIFJGQyAzMzcyIGFuZCBSRkMg NDQ5Ny4NCg0KMikgRUNNQSBUUi84NyB1YUNTVEENCiAgICAgICAgLVVzZXMgSU5GTyB0byBzZW5k IEVDTUEtMzIzIFhNTCBmb3IgbW9uaXRvcmluZyBhbmQgY29udHJvbGxpbmcgcGhvbmVzIGZyb20g YSBQQy4NCg0KMykgU2VuZGluZyBtZWRpYSBzZXJ2ZXIgY29udHJvbCBjb21tYW5kcy4NCiAgICAg ICAgLURvY3VtZW50ZWQgaW4gUkZDNDcyMiBNU0NNTC4NCg0KDQovKioqKioqKioqKioqKioqKg0K KiAgVXNlLWNhc2VzIHRoYXQgSSB0aGluayBhcmUgcG90ZW50aWFsbHkvcG9zc2libHkgdmFsaWQg Zm9yIElORk86DQoqKioqKioqKioqKioqKioqLw0KMSkgU2VuZGluZyBhIHZjYXJkIGFzeW5jaHJv bm91c2x5LiAgQWxpY2UgY2FsbHMgQm9iLCBBbGljZSBzYXlzICJjYW4geW91IHNlbmQgbWUgSm9o bidzIHZjYXJkPyIsIEJvYiBjbGlja3Mgc29tZXRoaW5nIGFuZCB2b2lsYSBpdCdzIHNlbnQuDQog ICAgICAgIC1BbHRlcm5hdGl2ZXM6IHNlbmQgYSByZS1JbnZpdGUgb3IgVXBkYXRlIHdpdGggYSBD YWxsLUluZm8sIHdpdGggZWl0aGVyIGEgVVJMIHJlZmVyZW5jZSwgZGF0YSBVUkksIG9yIE1JTUUg YW5kIENJRCBVUkwuDQogICAgICAgIC1Db3VudGVyLWFyZ3VtZW50OiBJTU8gdGhpcyB0eXBlIG9m IGRhdGEgcmVhbGx5IGJlbG9uZ3MgaW4gTUlNRSBmb3IgYSBudW1iZXIgb2YgcmVhc29ucywgaW5j bHVkaW5nIGxlbmd0aCBpcyBsZXNzIHJlc3RyaWN0ZWQgZm9yIG1pbWUgYXR0YWNobWVudHM7IG9u ZSBBRCBoYXMgc2FpZCB0aGUgRGF0YSBVUkwgbWF5IGJlIGRlcHJlY2F0ZWQuICBBbmQgc2VuZGlu ZyBhIHJlLUludml0ZSBmb3IgdGhpcyBwdXJwb3NlIHNlZW1zIG9kZC4NCg0KICAgICAgICAtQWxz bywgdGhlIENhbGwtSW5mbyBoZWFkZXIgaXMgcmVhbGx5IGFib3V0IHRoZSBjYWxsZXIgb3IgY2Fs bGVlLCBhbmQgdGh1cyBCb2Igc2hvdWxkbid0IGJlIHNlbmRpbmcgbWUgSm9obidzIHZjYXJkIGlu Zm8gaW4gaXQgdGVjaG5pY2FsbHkuICBUaGF0IG1heSBzb3VuZCBsaWtlIGEgbml0LCBidXQgVUEn cyBtYXkgd2VsbCBzdG9yZSB0aGUgY2FsbC1pbmZvIHZjYXJkcyBpbnRvIHRoZWlyIGFkZHJlc3Mt Ym9va3MgYXV0b21hdGljYWxseSBhbmQgc28gdGllIGl0IHRvIHRoZSB3cm9uZyB1c2VyL2NhbGwu DQogICAgICAgIC1Qcm9zIG9mIHVzaW5nIElORk86IGl0J3MgZXhwbGljaXQgd2hhdCB5b3UncmUg ZG9pbmcgd2hlbiB5b3Ugc2VuZCB0aGUgdmNhcmQsIGFuZCB5b3UgY2FuIHNlbmQgaXQga25vd2lu ZyB0aGUgb3RoZXIgZW5kIGNhbiBhY2NlcHQgaXQsIGFuZCB5b3UgY2FuIHNlbmQgaXQgYmFzZWQg b24gdXNlciBpbnB1dC4NCg0KMikgU2VuZGluZyBhIHVzZXItaWNvbiBqcGVnL2JpdG1hcC9naWYu ICBBbGljZSBjYWxscyBCb2IsIEJvYiBoYXMgYW4gaWNvbiB0aGF0IHJlcHJlc2VudHMgaGltc2Vs Ziwgc2VuZHMgaXQgd2hlbiBoZSBwaWNrcyB1cCB0aGUgcGhvbmUuDQogICAgICAgIC1BbHRlcm5h dGl2ZXM6IHNlbmQgYSAyMDBvaywgcmUtSW52aXRlLCBvciBVcGRhdGUgd2l0aCBjYWxsLWluZm8s IHdoaWNoIGV4cGxpY2l0bHkgaGFzIGEgdHlwZSBmb3IgaWNvbi4NCiAgICAgICAgLUNvdW50ZXIt YXJndW1lbnQ6IHNhbWUgYXMgZm9yIHZjYXJkLCBwbHVzIHdpdGggY2FsbC1pbmZvIHRoZXJlIGlz IG5vIHdheSB0byBrbm93IHdoaWNoIHBpY3R1cmUgZm9ybWF0IHRoZSBmYXItZW5kIHN1cHBvcnRz IGEgcHJpb3JpLiAgV2l0aCBhIHN1cHBvcnRlZC1wYWNrYWdlIG5lZ290aWF0aW9uIG9uZSBjb3Vs ZCBrbm93Lg0KDQozKSBTZW5kaW5nIGEgdmNhbGVuZGFyLXR5cGUgaW52aXRhdGlvbi4gIEFsaWNl IGNhbGxzIEJvYiwgQm9iIHNheXMgImhleSBsZXQncyBoYXZlIGEgY29uIGNhbGwgYXQgdGltZSBY IiwgY2xpY2tzIGFuZCB2b2lsYSBoaXMgcGhvbmUgc2VuZHMgYSB2Y2FsZW5kYXIuLg0KICAgICAg ICAtV2hldGhlciB0aGUgdmNhbGVuZGFyIGlzIHJlbGF0ZWQgdG8gdGhlIHNlc3Npb24gb3Igbm90 IGFuZCB0aHVzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHNlbnQgaW4gYW4gaW4tZGlhbG9nIHJlcXVl c3Qgb3Igbm90IGlzIGNlcnRhaW5seSBkZWJhdGFibGUuICBNZXNzYWdlIG1ldGhvZCBjYW4gYWxy ZWFkeSBiZSB1c2VkIGZvciB0aGlzIGFueXdheS4NCg0KNCkgU2VuZGluZyBhbiBIVFRQIFVSTC4g IEFsaWNlIGNhbGxzIEJvYiwgYSBzYWxlcyBndXk7IEFsaWNlIGFza3MgZm9yIG1vcmUgaW5mbyBv ciBhIGRhdGFzaGVldCBhbmQgQm9iIHNlbmRzIGEgVVJMIGZvciBBbGljZSB0byBvcGVuIHdpdGgg aGVyIHdlYi1icm93c2VyLg0KICAgICAgICAtT25lIGNvdWxkIGFsc28gYXJndWUgdGhpcyBpcyBq dXN0IG1ha2luZyBTSVAgdGhlIG5ldyBTTVRQLCBvciB0aGlzIHNob3VsZCBiZSBzZW50IHVzaW5n IE1FU1NBR0UgKHdoaWNoIHJlYWxseSBpcyB0aGUgbmV3IFNNVFApLg0KDQo1KSBTZW5kaW5nIGEg c2Vzc2lvbiB0cmFjZXJvdXRlLiAgQWxpY2UgY2FsbHMgQm9iLCBCb2IgYW5zd2VycywgQWxpY2Ug ZG9lcyBhIHNpcC10cmFjZXJvdXRlIHRvIGZpZ3VyZSBvdXQgdGhlIHBhdGggdG8gQm9iLCBieSBz ZW5kaW5nIEluZm8gd2l0aCBhbiBpbmNyZW1lbnRpbmcgbWF4LWZvcndhcmRzIHR5cGUgaGVhZGVy IHN0YXJ0aW5nIGF0IDAgKGJ1dCBub3QgcmVhbGx5IG1heC1mb3J3YXJkcyksIHdpdGggYSBzaXAt ZnJhZyB0eXBlIHJlc3BvbnNlIGJvZHkgb3Igc29tZSBzdWNoLg0KICAgICAgICAtSXQncyBkZWJh dGFibGUgaWYgY2VydGFpbiB0eXBlcyBvZiBCMkJVQSdzIChpZSwgU0JDcykgd291bGQgZXZlciBh bGxvdyB0aGlzIHR5cGUgb2YgdGhpbmcgdG8gaGFwcGVuLCBkdWUgdG8gc2VjdXJpdHkgY29uY2Vy bnMsIGJ1dCBJIHRoaW5rIHRoZXkgbWF5IGRvIGl0IGF0IGRvbWFpbiBib3VuZGFyeSBob3BzLiAg SSB0aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSB1c2UgZm9yIElORk8gdGhvdWdoLCBtYXliZS4N Cg0KNikgU2VuZGluZyBnZW8tbG9jYXRpb24gaW5mb3JtYXRpb24gYWZ0ZXIgY2FsbCBlc3RhYmxp c2htZW50LiAgQWxpY2UgY2FsbHMgQm9iLCBhIGhvdGVsIHJlY2VwdGlvbmlzdC4gIEFsaWNlIGFz a3MgZm9yIGRpcmVjdGlvbnMgdG8gaG90ZWwsIGNsaWNrcyBidXR0b24gYW5kIHNlbmRzIGhpbSBs b2NhdGlvbiBpbmZvIG9mIGhlciBwaG9uZSAob3IgQm9iIGNsaWNrcyBidXR0b24gYW5kIHNlbmRz IGhlciBoaXMgbG9jYXRpb24pLg0KICAgICAgICAtVGhlIGxvY2F0aW9uIGNvbnZleWFuY2UgZHJh ZnQgc3BlY2lmaWNhbGx5IGNhbGxzIG91dCBJTkZPIGFzIGFjY2VwdGFibGUgZm9yIGdlby1sb2Mg aW5mby4gIFdoZXRoZXIgdGhpcyBpcyBhIHJlYWwgdXNlLWNhc2UgaXMgZGViYXRhYmxlLCBhbmQg b2J2aW91c2x5IGl0IGNvdWxkIGJlIGRvbmUgd2l0aCBhIHN1Yi9ub3QuDQoNCjcpIFNlbmRpbmcg c29mdGtleS1sYWJlbHMgKG5vdCBkaWdpdC1tYXRjaCBtYXBzLCBidXQgcmF0aGVyIHNvZnRrZXkg YnV0dG9uIGxhYmVscykuICBBbGljZSBjYWxscyBoZXIgdm1haWwgc2VydmVyLiAgVm1haWwgc2Vy dmVyIHNlbmRzIHNvZnRrZXktbGFiZWxzIGZvciB0aGUgbWVudSBpdGVtcyBhdmFpbGFibGUgaW4g dGhlIHJlc3BvbnNlLCBBbGljZSBwcmVzc2VzIHNvZnRrZXlzIGFuZCBzZW5kcyB0aGVtIGluIElO Rk8uDQogICAgICAgIC1UaGlzIGNvdWxkIChhbmQgbWF5YmUgc2hvdWxkKSBiZSBkb25lIHdpdGgg c3ViL25vdCwgYSBsYSBLUE1MLCB3aGVyZSB0aGUgdm1haWwgc2VydmVyIHNlbmRzIHRoZSBzb2Z0 a2V5IGxhYmVscyBpbiB0aGUgU3Vic2NyaWJlLCBVQSBzZW5kcyBidXR0b25zIHByZXNzZWQgaW4g Tm90aWZpZXMuICBCdXQgdGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBEVE1GIHVzZSBjYXNlIHNvIG1h eSB3ZWxsIGhhdmUgdGhlIHNhbWUgYmVuZWZpdCBvZiBsb3dlciBvdmVyaGVhZCBzaW5jZSBidXR0 b25zIGFyZSByYXJlbHkgcHJlc3NlZC4NCg0KOCkgU2VuZGluZyBhIHNjcmVlbi1wb3AtdXAgbWVz c2FnZSwgZS5nLiwgIkRvIHlvdSB3YW50IHRvIGNvbnRpbnVlIHdpdGggdGhpcyBzZXNzaW9uPyIN CiAgICAgICAgLVRoZXJlIGlzIGEgcGF0ZW50IGZvciBkb2luZyBzY3JlZW4gcG9wLXVwcyB1c2lu ZyBJTkZPLiAgSSBndWVzcyBBbGVydC1JbmZvIGNvdWxkIGJlIHVzZWQgZm9yIHRoaXMsIGJ1dCBp dCdzIG5vdCBjbGVhciBpdCBzaG91bGQ/DQoNCg0KLyoqKioqKioqKioqKioqKioqDQoqICBVc2Ut Y2FzZXMgd2hpY2ggaGF2ZSBiZWVuIHByb3Bvc2VkIGJ5IG90aGVycyBvciBldmVuIGltcGxlbWVu dGVkLA0KKiAgd2hpY2ggYXJlIGR1YmlvdXMgZm9yIElORk8gKElNSE8pOg0KKioqKioqKioqKioq KioqKiovDQoxKSBTZW5kaW5nIFJUUC9SVENQIHN0YXRpc3RpY3MgZHVyaW5nIGNhbGwuDQogICAg ICAgIC1UaGVyZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzLCBhbmQgdGhlIHJhdGlvbmFs ZSBpcyB0aGUgc2lnbmFsaW5nIHBsYW5lIGJveCB0aGF0IHdhbnRzIHRoaXMgaW5mbyBpcyBub3Qg YWN0dWFsbHkgdGhlIG1lZGlhIHBsYW5lIGJveCB0aGF0IGdldHMgUlRDUC4gIEFnYWluIHRoaXMg Y291bGQgKGFuZCBJTU8gc2hvdWxkKSBiZSBkb25lIHdpdGggc3ViL25vdCwgc28gaXQgY2FuIGdl dCBzdGF0cyBhZnRlciB0aGUgY2FsbCBpcyBvdmVyLCBhbmQgc2luY2UgaXQgd2lsbCBwcm9iYWJs eSB3YW50IHBlcmlvZGljIHJlcG9ydHMgdGhlIG92ZXJoZWFkIG9mIHRoZSBTdWJzY3JpYmUgc2hv dWxkIGJlIGR3YXJmZWQgYnkgdGhlIG51bWJlciBvZiBOb3RpZmllcy4NCg0KMikgU2VuZGluZyBh Y2Nlc3MtbG9jYXRpb24gaW5mb3JtYXRpb24gYWZ0ZXIgY2FsbCBlc3RhYmxpc2htZW50Lg0KICAg ICAgICAtVGhlcmUgaXMgYSBQLUFjY2Vzcy1OZXR3b3JrLUluZm8gaGVhZGVyLCBhbmQgc29tZSBo YXZlIHByb3Bvc2VkIHRvIHNlbmQgYW4gdXBkYXRlIGZvciBpdCBhcyBhIHBob25lIHJvYW1zIGFj Y2VzcyBwb2ludHMgb3IgY2VsbHMuICBCdXQgSSB0aGluayB0aGlzIGlzIGFuIG9kZCB0aGluZyB0 byBkbyBpbnNpZGUgYW4gSW52aXRlIHNlc3Npb24sIHZzLiBpbiBhIHN1Yi9ub3Qgb3IgUmVnaXN0 ZXIgKGFuZCBiZXNpZGVzIGhhbGYgdGhlIHRpbWUgdGhlIG5ldHdvcmsgaW5zZXJ0cyB0aGlzIGhl YWRlciwgbm90IHRoZSBVQSkuDQoNCjMpIFNlbmRpbmcgbWVkaWEtY29udHJvbCBpbmRpY2F0aW9u cyAoaWUsIHJlbW90ZS1jb250cm9sICJwbGF5L3BhdXNlL2V0Yy4iKQ0KICAgICAgICAtVGhpcyBp cyBkb25lIHRvZGF5IGJ5IGF0IGxlYXN0IG9uZSB2ZW5kb3IsIGJ1dCBpcyBkZWJhdGFibGUgaWYg aXQncyB0aGUgcmlnaHQgbW9kZWwuICBUaGUgYXJndW1lbnQgaXMgaXQncyBsaWtlIFNEUCByZS1J bnZpdGUgZm9yIGhvbGQsIGV4Y2VwdCBhdCBhIG1lZGlhIGNvbnRlbnQgbGF5ZXIgYWJvdmUgUlRQ LCBzbyBub3QgZG9uZSBpbiBSVENQIG5vciBTRFAuDQoNCjQpIFNlbmRpbmcgdmlkZW8gZmFzdCB1 cGRhdGUgY29tbWFuZA0KICAgICAgICAtVGhpcyBpcyBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0LCB3 aGljaCBkb2N1bWVudHMgd2hhdCBoYXMgYmVlbiBpbXBsZW1lbnRlZCwgYnV0IHN0YXRlcyBpdCBz aG91bGQgcmVhbGx5IGJlIGRvbmUgaW4gdGhlIG1lZGlhIHBsYW5lLg0KDQo1KSBTZW5kaW5nIHBl cmlwaGVyYWwgY29udHJvbCBjb21tYW5kcyAoaWUsIFVTQiBjb21tYW5kcykNCiAgICAgICAgLVRo ZXJlIGlzIGFjdHVhbGx5IGEgcGF0ZW50IG9uIHRoaXMsIGFtYXppbmdseS4gIFNvbWVvbmUgdGhp bmtzIGl0IG1ha2VzIHNlbnNlIHRvIGNyZWF0ZSBhIFNJUCBzZXNzaW9uIHRvIHlvdXIgbGFwdG9w LCBvciB2aWNlLXZlcnNhLCBhbmQgdGhlbiBzZW5kIFVTQiBjb21tYW5kcyBpbnNpZGUgTUlNRSBp biBJTkZPIG1lc3NhZ2VzLiAgTWV0aGlua3MgdGhpcyBzaG91bGQgYmUgbWVkaWEtcGxhbmUsIGlm IGFueXRoaW5nLg0KDQo2KSBTZW5kaW5nIGNoYXJnaW5nIGluZm9ybWF0aW9uIGZvciBhIGNhbGwg KGkuZS4sIG1pbnV0ZXMgcmVtYWluaW5nIG9yIGNvc3Qgc28gZmFyKS4NCiAgICAgICAgLVRoZXJl IHdhcyBhIHByb3Bvc2FsIHRvIHVzZSB0aGlzIGZvciBBZHZpY2Ugb2YgQ2hhcmdlIGluZm9ybWF0 aW9uIGluIFRJU1BBTi4gIElNTyBpdCBzaG91bGQgYmUgYSBzdWIvbm90IHRob3VnaCwgYXMgdGhl eSB3YW50IHRoaXMgdG8gc3Vydml2ZSB0aGUgSW52aXRlIHNlc3Npb24uDQoNCi1oYWRyaWVsDQoN Cg== --_000_E6C2E8958BA59A4FB960963D475F7AC30273926572mailacmepacke_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJDaXR5Ii8+DQo8bzpTbWFydFRhZ1R5 cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRh Z3MiDQogbmFtZT0icGxhY2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJQZXJzb25OYW1l Ii8+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVs dCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBG b250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHdWxpbTsNCglw YW5vc2UtMToyIDExIDYgMCAwIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQEd1bGltIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpHdWxpbTt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpHdWxpbTt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5TZWN0aW9uMQ0K CXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5n PUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1ibHVlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkn PkkgdGhpbmsgdGhlIGNvbmZ1c2lvbiBqdXN0IGNhbWUgZnJvbSB5b3VyIGRlc2NyaWJpbmcNCndo YXQgcHVycG9zZSB5b3Ugd2FudGVkIHRoZSBob29rLWZsYXNoIGluZGljYXRpb24gZm9yLCB3aGlj aCB3YXMgZm9yDQphcHBsaWNhdGlvbiBmZWF0dXJlcyAoMy13YXkgY2FsbGluZywgY2FsbCB3YWl0 aW5nLCB0cmFuc2ZlcikuwqAgU0lQIG9idmlvdXNseQ0KZXhwZWN0cyBzdWNoIHRoaW5ncyB0byBi ZSBkb25lL2luaXRpYXRlZCBieSB0aGUgVUHigJlzIHRoZW1zZWx2ZXMgbmF0aXZlbHksIGJ5DQpo YW5kbGluZyBtdWx0aXBsZSBzZXNzaW9ucywgUkVGRVJzLCBldGMuIOKAkyB2cy4gdXNpbmcgYSBj ZW50cmFsaXplZCBhcHAtc2VydmVyDQp0byBjb250YWluIHRoZSBlbnRpcmUgc2VydmljZSBsb2dp YyBhbmQgdHJlYXRpbmcgdGhlIHBob25lIGFzIGEgUE9UUyBsaW5lLiDCoEluDQp5b3VyIGRyYWZ0 IHlvdSBoYWQgTUdDUC1jb250cm9sbGVkIHBob25lIHNlcnZpY2VkIGJ5IGFuIE1HQywgd2hpY2gg d2FzIGFjdGluZw0KYXMgYSBTSVAgVUEgYnV0IGV4cGVjdGluZyBhIHNlcGFyYXRlIFNJUCBBcHAg U2VydmVyIHRvIGRvIGl0cyBkaXJ0eSB3b3JrLiDCoFRoYXQNCk1HQyByZWFsbHkgaXMgYSBzdGFu ZC1hbG9uZSBTSVAgVUEgYW5kIHRodXMgY291bGQvc2hvdWxkIGhhbmRsZSB0aGUgc2VydmljZQ0K bG9naWMuIMKgT3RoZXJ3aXNlIGl04oCZcyBqdXN0IHVzaW5nIFNJUCBhcyBhIHR1bm5lbGluZyB0 cmFuc3BvcnQgZm9yIE1HQ1AgaW4gYQ0Kd2F5IChhdCBsZWFzdCBhcmNoaXRlY3R1cmFsbHkpLsKg IEZvciBleGFtcGxlIGlmIHlvdXIgU0lQIFVBIHJlY2VpdmVzIGEgY2FsbA0KZGlyZWN0bHkgZnJv bSBhbm90aGVyIHByb3h5L1VBLCB0aGUg4oCcZmVhdHVyZXPigJ0gbm8gbG9uZ2VyIHdvcmsgYmVj YXVzZSB0aGUgQXBwDQpTZXJ2ZXIgaXMgbm90IGluIHRoZSBsb29wLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2 eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 Jz5TbyBJIHRoaW5rIGl04oCYcyBqdXN0IHNhZmVyL2NsZWFuZXIgaWYgeW91DQpkZXNjcmliZSB5 b3VyIHVzZS1jYXNlIGFzIHNpbXBseSB3YW50aW5nIHRvIGdldCBob29rLWZsYXNoIGluZGljYXRp b24sIGFzIGp1c3QNCmFub3RoZXIgZm9ybSBvZiBhc3luY2hyb25vdXMgdXNlciBpbnB1dCBzaW1p bGFyIGluIGNvbmNlcHQgdG8gYSBzb2Z0LWJ1dHRvbiBvcg0KRFRNRi4gwqAoaXTigJlzIGFjdHVh bGx5IG5vdCBjbGVhciB0byBtZSBob29rLWZsYXNoIGFjdHVhbGx5IGlzIHN1Y2ggYSB0aGluZywN CmJlY2F1c2UgaXTigJlzIHJlYWxseSBzeW5vbnltb3VzIHdpdGggYSBob2xkL3RyYW5zZmVyL2Nv bmZlcmVuY2UgYnV0dG9uLCBidXQgaXTigJlzDQphcmd1YWJsZSBhdCBsZWFzdCk8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6bmF2eSc+LWhhZHJpZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+ DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4 dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT1HdWxpbT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0 YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxz cGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPu2ZqeynhOqyvTwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpUYWhvbWEnPls8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4g bGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+7Jew6rWs7KCE66y46re466O5PC9zcGFu PjwvZm9udD48Zm9udCBzaXplPTINCmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+XQ0KW21haWx0bzpqa2h3YW5nQGt0LmNvLmtyXSA8 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBG cmlkYXksIERlY2VtYmVyIDA3LCAyMDA3DQoxMjoxMCBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiA8c3QxOlBlcnNvbk5hbWUgdzpzdD0ib24i PlNhbmpheQ0KIFNpbmhhPC9zdDE6UGVyc29uTmFtZT4gKHNhbmpzaW5oKTsgSGFkcmllbCBLYXBs YW48YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4g PHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5zaXBAaWV0Zi5vcmc8L3N0MTpQZXJzb25OYW1lPjxi cj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+ IFJFOiBbU2lwXSBJTkZPIHVzZS1jYXNlczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9R3VsaW0+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHA+PGZvbnQgc2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PkRlYXIgc2FuanNpbmg8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBz aXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxm b250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPUd1bGltPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz5JIGRvbid0IGtub3cgdGhlDQpvdGhlciB3YXkgdG8gY29sbGVj dCAmcXVvdDtIb29rLUZsYXNoJnF1b3Q7IGV2ZW50IGFsb25nIG9uLWdvaW5nIGRpYWxvZ3VlLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPUd1bGlt PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5XaGF0IGlzPC9zcGFuPjwvZm9udD48Zm9u dA0Kc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+dGhlIHN1Z2dlc3Rl ZDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPic8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlDQpmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJs dWUnPm5vbi1JTkZPDQp3YXk8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6YmxhY2snPicgPyA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgZmFjZT1HdWxpbT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+VEhYIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGZvbnQgc2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5K Szxicj4NCi0tLS0tPHNwYW4gbGFuZz1LTz7sm5Drs7gg66mU7Iuc7KeAPC9zcGFuPi0tLS0tPGJy Pg0KPC9zcGFuPjwvZm9udD48Yj48Zm9udCBzaXplPTI+PHNwYW4gbGFuZz1LTyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LXdlaWdodDoNCmJvbGQnPuuztOuCuDwvc3Bhbj48L2ZvbnQ+PC9i PjxiPjxmb250IHNpemU9Mj48c3BhbiBsYW5nPUtPIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC13ZWlnaHQ6Ym9sZCc+IDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3Bh biBsYW5nPUtPDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDpib2xkJz7sgqzr now8L3NwYW4+PC9mb250PjwvYj48Yj48Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXpl PTI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gJnF1b3Q7PHN0MTpQZXJzb25OYW1l IHc6c3Q9Im9uIj5TYW5qYXkgU2luaGE8L3N0MTpQZXJzb25OYW1lPg0KKHNhbmpzaW5oKSZxdW90 OyAmbHQ7c2FuanNpbmhAY2lzY28uY29tJmd0Ozxicj4NCjwvc3Bhbj48L2ZvbnQ+PGI+PGZvbnQg c2l6ZT0yPjxzcGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC13ZWlnaHQ6 DQpib2xkJz7rs7Trgrg8L3NwYW4+PC9mb250PjwvYj48Yj48Zm9udCBzaXplPTI+PHNwYW4gbGFu Zz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtd2VpZ2h0OmJvbGQnPiA8L3NwYW4+ PC9mb250PjwvYj48Yj48Zm9udCBzaXplPTI+PHNwYW4gbGFuZz1LTw0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+64Kg7KecPC9zcGFuPjwvZm9udD48L2I+PGI+PGZv bnQgc2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDpib2xk Jz46PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+IDIwMDctMTItMDcgPHNwYW4gbGFuZz1LTz7smKTtm4Q8L3NwYW4+IDE6NTQ6MTc8 YnI+DQo8L3NwYW4+PC9mb250PjxiPjxmb250IHNpemU9Mj48c3BhbiBsYW5nPUtPIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0Og0KYm9sZCc+67Cb64qUPC9zcGFuPjwvZm9udD48 L2I+PGI+PGZvbnQgc2l6ZT0yPjxzcGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LXdlaWdodDpib2xkJz4gPC9zcGFuPjwvZm9udD48L2I+PGI+PGZvbnQgc2l6ZT0yPjxz cGFuIGxhbmc9S08NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQnPuyC rOuejDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNp emU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAmcXVvdDs8c3BhbiBsYW5nPUtP Pu2ZqeynhOqyvTwvc3Bhbj5bPHNwYW4gbGFuZz1LTz7sl7DqtazsoITrrLjqt7jro7k8L3NwYW4+ XSZxdW90Ow0KJmx0O2praHdhbmdAa3QuY28ua3ImZ3Q7LCAmcXVvdDtIYWRyaWVsIEthcGxhbiZx dW90Ow0KJmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PGJyPg0KPC9zcGFuPjwvZm9udD48 Yj48Zm9udCBzaXplPTI+PHNwYW4gbGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LXdlaWdodDoNCmJvbGQnPuywuOyhsDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+ PC9mb250PjwvYj48Zm9udCBzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPg0K JnF1b3Q7PHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5zaXBAaWV0Zi5vcmc8L3N0MTpQZXJzb25O YW1lPiZxdW90OyAmbHQ7PHN0MTpQZXJzb25OYW1lDQp3OnN0PSJvbiI+c2lwQGlldGYub3JnPC9z dDE6UGVyc29uTmFtZT4mZ3Q7PGJyPg0KPC9zcGFuPjwvZm9udD48Yj48Zm9udCBzaXplPTI+PHNw YW4gbGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDoNCmJvbGQnPuyg nOuqqTwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBz aXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPg0KUkU6IFtTaXBdIElORk8gdXNl LWNhc2VzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+VGhlc2Ug MyB1c2UgY2FzZXMgYmVsb3cgc2VlbSBtaXN1c2Ugb2YNCklORk8gYXMgdGhlcmUgYXJlIGVzdGFi bGlzaGVkIG1lY2hhbmlzbSBvZiBkb2luZyB0aGVzZSB1c2luZyBub24tSU5GTyB3YXkuPC9zcGFu PjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8YmxvY2txdW90 ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ow0KbWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCg0KPGRpdiBjbGFzcz1Nc29O b3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0y DQpmYWNlPUd1bGltPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4NCg0KPGhyIHNpemU9 MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYkluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250DQpzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxz cGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPu2ZqeynhOqyvTwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpUYWhvbWEnPls8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4g bGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+7Jew6rWs7KCE66y46re466O5PC9zcGFu PjwvZm9udD48Zm9udCBzaXplPTINCmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+XQ0KW21haWx0bzpqa2h3YW5nQGt0LmNvLmtyXSA8 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBU aHVyc2RheSwgRGVjZW1iZXIgMDYsIDIwMDcNCjk6MTIgUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0n Zm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gSGFkcmllbCBLYXBsYW48YnI+DQo8Yj48 c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gPHN0MTpQZXJzb25O YW1lIHc6c3Q9Im9uIj5zaXBAaWV0Zi5vcmc8L3N0MTpQZXJzb25OYW1lPjxicj4NCjxiPjxzcGFu IHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBbU2lwXSBJ TkZPIHVzZS1jYXNlczwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0K PGRpdj4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFj ZT1HdWxpbT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RGVhciBIYWRyaWVsIEthcGxh bg0KYW5kIGZvbGtzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT1HdWxpbT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+KGluIG91ciBjYXNlKSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cD48Zm9udCBzaXplPTIgZmFjZT1HdWxpbT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+TWlkY2FsbCBJTkZPIGlzIHVzZWQNCmluIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjEpIFRocmVlLXdheSBjYWxs aW5nOg0KdG8gYWRkIGFub3RoZXIgcGFydHkgdG8gZXhpc3RpbmcgY2FsbDwvc3Bhbj48L2ZvbnQ+ PGZvbnQgc2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9m b250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPUd1bGltPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4yKSBDYWxsIHdhaXRpbmc6IHRvDQpjaGFuZ2UgZGlh bG9ndWUgYmV0d2VlbiB0d28gb25nb2luZyBjYWxsczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPUd1bGltPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz4zKSBDZW50cmV4IHNlcnZpY2VzOg0KY2FsbCB0cmFuc2ZlciwgZXRjLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlRI WDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwPjxmb250IHNpemU9MiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPkpLIEh3YW5nPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHA+PGZvbnQg c2l6ZT0yIGZhY2U9R3VsaW0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPktUPGJyPg0K LS0tLS08c3BhbiBsYW5nPUtPPuybkOuzuCDrqZTsi5zsp4A8L3NwYW4+LS0tLS08YnI+DQo8L3Nw YW4+PC9mb250PjxiPjxmb250IHNpemU9Mj48c3BhbiBsYW5nPUtPIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtd2VpZ2h0Og0KYm9sZCc+67O064K4PC9zcGFuPjwvZm9udD48L2I+PGI+PGZv bnQgc2l6ZT0yPjxzcGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LXdl aWdodDpib2xkJz4gPC9zcGFuPjwvZm9udD48L2I+PGI+PGZvbnQgc2l6ZT0yPjxzcGFuIGxhbmc9 S08NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQnPuyCrOuejDwvc3Bh bj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mj48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAmcXVvdDtIYWRyaWVsIEthcGxhbiZxdW90Ow0K Jmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PGJyPg0KPC9zcGFuPjwvZm9udD48Yj48Zm9u dCBzaXplPTI+PHNwYW4gbGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdo dDoNCmJvbGQnPuuztOuCuDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3BhbiBs YW5nPUtPIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC13ZWlnaHQ6Ym9sZCc+IDwvc3Bh bj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3BhbiBsYW5nPUtPDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LXdlaWdodDpib2xkJz7rgqDsp5w8L3NwYW4+PC9mb250PjwvYj48Yj48 Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0OmJv bGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz4gMjAwNy0xMi0wNyA8c3BhbiBsYW5nPUtPPuyYpOyghDwvc3Bhbj4gMTA6NDg6 MTk8YnI+DQo8L3NwYW4+PC9mb250PjxiPjxmb250IHNpemU9Mj48c3BhbiBsYW5nPUtPIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0Og0KYm9sZCc+67Cb64qUPC9zcGFuPjwvZm9u dD48L2I+PGI+PGZvbnQgc2l6ZT0yPjxzcGFuIGxhbmc9S08gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LXdlaWdodDpib2xkJz4gPC9zcGFuPjwvZm9udD48L2I+PGI+PGZvbnQgc2l6ZT0y PjxzcGFuIGxhbmc9S08NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQn PuyCrOuejDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250 IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAmcXVvdDs8c3BhbiBsYW5n PUtPPu2ZqeynhOqyvTwvc3Bhbj5bPHNwYW4gbGFuZz1LTz7sl7DqtazsoITrrLjqt7jro7k8L3Nw YW4+XSZxdW90Ow0KJmx0O2praHdhbmdAa3QuY28ua3ImZ3Q7PGJyPg0KPC9zcGFuPjwvZm9udD48 Yj48Zm9udCBzaXplPTI+PHNwYW4gbGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LXdlaWdodDoNCmJvbGQnPuywuOyhsDwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+ PC9mb250PjwvYj48Zm9udCBzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPg0K JnF1b3Q7PHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5zaXBAaWV0Zi5vcmc8L3N0MTpQZXJzb25O YW1lPiZxdW90OyAmbHQ7PHN0MTpQZXJzb25OYW1lDQp3OnN0PSJvbiI+c2lwQGlldGYub3JnPC9z dDE6UGVyc29uTmFtZT4mZ3Q7PGJyPg0KPC9zcGFuPjwvZm9udD48Yj48Zm9udCBzaXplPTI+PHNw YW4gbGFuZz1LTyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LXdlaWdodDoNCmJvbGQnPuyg nOuqqTwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250IHNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBz aXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPg0KUkU6IFtTaXBdIElORk8gdXNl LWNhc2VzPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0 IC0tPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn Pjxmb250IHNpemU9MiBmYWNlPUd1bGltPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQn PkhpIEpLLDxicj4NCkkgYWN0dWFsbHkgc2F3IHRoYXQgZHJhZnQgYnV0IGRpZCBub3QgaW5jbHVk ZSBpdCBiZWNhdXNlIEkgdGhvdWdodCBpdCB3YXMNCmVzc2VudGlhbGx5IGFub3RoZXIgRFRNRi1z dHlsZSBldmVudCB0eXBlLCBhbmQgd291bGQgYmUgc3Vic3VtZWQgaW50byBpdCwgYnV0DQp5b3Un cmUgcmlnaHQgSSBzaG91bGQgaGF2ZSBpbmNsdWRlZCB0aGF0IHVzZS1jYXNlLjwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBTb3Jy eSE8YnI+DQo8YnI+DQotaGFkcmllbDxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpGcm9tOiA8c3BhbiBsYW5nPUtPPu2ZqeynhOqy vTwvc3Bhbj5bPHNwYW4gbGFuZz1LTz7sl7DqtazsoITrrLjqt7jro7k8L3NwYW4+XSBbPGENCmhy ZWY9Im1haWx0bzpqa2h3YW5nQGt0LmNvLmtyIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmpraHdh bmdAa3QuY28ua3I8L2E+XTxicj4NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNiwgMjAwNyA4 OjMzIFBNPGJyPg0KVG86IEhhZHJpZWwgS2FwbGFuOyA8c3QxOlBlcnNvbk5hbWUgdzpzdD0ib24i PnNpcEBpZXRmLm9yZzwvc3QxOlBlcnNvbk5hbWU+PGJyPg0KU3ViamVjdDogUkU6IFtTaXBdIElO Rk8gdXNlLWNhc2VzPGJyPg0KRGVhciBmb2xrcyw8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZv bnQgc2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SG93IGFib3V0IHRoZSBN aWRjYWxsIElORk8gPzxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTI+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5XaGVuICdIb29rLUZsYXNoJyBmcm9tIHRoZSBTSVAg b3IgUE9UUyBwaG9uZSBkdXJpbmcgYQ0KZGlhbG9ndWUsIHdlIChLVCkgdXNlIElORk8gbWV0aG9k IGZyb20gdGhlIENTQ0YvTUdDRiB0byBBUy48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0K Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQg c2l6ZT0yPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SSBzdWJtaXR0ZWQgYSBkcmFm dCBJLUQgdHdvIHllYXJzIGFnbyBidXQgaXQgd2FzIG5vdA0KYWNjZXB0ZWQsPGJyPg0KQnV0IHdl IHN0aWxsIHVzZSB0aGUgY2FzZS48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0y PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Q2FuIGl0IGJlIGFub3RoZXIgVXNlLUNh c2UgPzxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTI+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz5KSyBId2FuZzxicj4NCktUPGJyPg0KPGJyPg0KLS0tLS08c3BhbiBs YW5nPUtPPuybkOuzuCDrqZTsi5zsp4A8L3NwYW4+LS0tLS08YnI+DQo8c3BhbiBsYW5nPUtPPuuz tOuCuCDsgqzrnow8L3NwYW4+OiAmcXVvdDtIYWRyaWVsIEthcGxhbiZxdW90Ow0KJmx0O0hLYXBs YW5AYWNtZXBhY2tldC5jb20mZ3Q7PGJyPg0KPHNwYW4gbGFuZz1LTz7rs7Trgrgg64Kg7KecPC9z cGFuPjogMjAwNy0xMi0wNyA8c3BhbiBsYW5nPUtPPuyYpOyghDwvc3Bhbj4gODozODozNjxicj4N CjxzcGFuIGxhbmc9S08+67Cb64qUIOyCrOuejDwvc3Bhbj46ICZxdW90OzxzdDE6UGVyc29uTmFt ZSB3OnN0PSJvbiI+c2lwQGlldGYub3JnPC9zdDE6UGVyc29uTmFtZT4mcXVvdDsNCiZsdDs8c3Qx OlBlcnNvbk5hbWUgdzpzdD0ib24iPnNpcEBpZXRmLm9yZzwvc3QxOlBlcnNvbk5hbWU+Jmd0Ozxi cj4NCjxzcGFuIGxhbmc9S08+7LC47KGwPC9zcGFuPjo8YnI+DQo8c3BhbiBsYW5nPUtPPuygnOuq qTwvc3Bhbj46IFtTaXBdIElORk8gdXNlLWNhc2VzPGJyPg0KPGJyPg0KPGJyPg0KSG93ZHksPGJy Pg0KSm9uYXRoYW4gYXNrZWQgZm9yIHVzZS1jYXNlcyBmb3Igd2hhdCB0eXBlcyBvZiB0aGluZ3Mg d291bGQgbmVlZCBhbiBpbi1kaWFsb2cNClNJUCBtZXNzYWdlIGZvciB1c2VyLXVzZXIgY29tbXVu aWNhdGlvbiwgdnMuIHNob3VsZCBiZSBkb25lIGVpdGhlciBvdXQgb2YNCmRpYWxvZyBvciBpbiB0 aGUgbWVkaWEgcGxhbmUuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+IElmIHRoZSBvbmx5IHVzZS1jYXNlIGlzIERUTUYsIHRoZW4g d2UNCmNvdWxkIGp1c3QgZG9jdW1lbnQgdGhlIERUTUYgbmVnb3RpYXRpb24vdXNlIG9ubHkgYW5k IG5vdCBoYXZlIHRvIGNyZWF0ZSBhDQpnZW5lcmFsIGluZm8tZXZlbnRzIGZyYW1ld29yay48L3Nw YW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4gVGhhdCBzZWVtcyBhIHZlcnkgcmVhc29uYWJsZSBhcmd1bWVudCB0bw0KbWUuPC9zcGFuPjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3Nw YW4+PC9mb250Pjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBJ IGFsc28gZG9uJ3Qgd2FudCB0byBkbyB3b3JrIGZvciBubyB1c2UuPGJyPg0KPGJyPg0KVGhlcmUg aXMgYSBjb3VudGVyLWFyZ3VtZW50IHRoYXQgdGhlcmUgYXJlIHByb3ByaWV0YXJ5IHVzZXMgb2Yg SU5GTyBpbiB0aGUNCndpbGQsIGFuZCB0aGF0IGEgZnJhbWV3b3JrIGZvciBuZWdvdGlhdGlvbiBh dCBsZWFzdCByZW1vdmVzIHRoZSBtYW51YWwgY29uZmlndXJhdGlvbg0Kb2YgdmVuZG9yLXNwZWNp ZmljIHByb2ZpbGVzLCB3aGljaCBpcyBhIHByb2JsZW0gb2YgaW50ZXJvcCB0b2RheSAtIGV2ZW4g aWYgdGhlDQpJRVRGIHNob3VsZCBub3QgYmxlc3MvZG9jdW1lbnQgdGhlIHNwZWNpZmljIHVzZSBj YXNlcyB0aGVtc2VsdmVzLjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9MiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBCdXQgdGhhdCB3b3VsZCBtYWtlIHRoZSBkcmFmdCBhIHZl cnkNCmRpZmZlcmVudCBvbmUgdGhhbiBpdCBjdXJyZW50bHkgaXMgYXMgd2VsbCwgYW5kIEkgd2ls bCBhc2sgdGhhdCBpbiBhIHNlcGFyYXRlDQplbWFpbCB0aHJlYWQuPGJyPg0KPGJyPg0KVGhlIGNo YWlycyBoYXZlIGFza2VkIGZvciAzIHVzZSBjYXNlcywgYW5kIEkgYXNzdW1lIHRoZXkgbWVhbiAz IE5FVyB1c2UgY2FzZXMNCih3ZSBhbHJlYWR5IGhhdmUgMyBSRkNzIHdoaWNoIHVzZSBJTkZPLCBh cyB3ZWxsIGFzIERUTUYpLjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9MiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBJIGFtIG5vdCBzdXJlIGlmIHRoZXkgbWVhbiBwb3RlbnRp YWwNCmZ1dHVyZSB1c2UtY2FzZXMsIG9yIGN1cnJlbnQgdXNlLWNhc2VzIChpLmUuLCBhbHJlYWR5 IGltcGxlbWVudGVkKS48L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz4gQ2FuIEkgZ2V0IGEgY2xhcmlmaWNhdGlvbiBvbiB0aGF0Pzxi cj4NCjxicj4NClNvIGFueXdheSwgdGFraW5nIHRoZSBzaG90LWd1biBhcHByb2FjaCwgaGVyZSdz IGEgZmlyc3QgZ28gYXQgc29tZSB1c2UtY2FzZXMsDQphbmQgbXkgcGVyc29uYWwgdGFrZSBvbiB3 aGV0aGVyIHRoZXkgc2hvdWxkIGJlIGluIElORk8gdnMuIFNVQi9OT1QgdnMuDQptZWRpYS1wbGFu ZSwgRldJVy48YnI+DQpbYXBvbG9naXplIGZvciBmb3JtYXR0aW5nIHVnbGluZXNzXTxicj4NCjxi cj4NCi8qKioqKioqKioqKioqKio8YnI+DQoqPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9 Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBBbHJlYWR5IHN0YW5kYXJkaXplZCB1 c2UtY2FzZXM6PGJyPg0KKioqKioqKioqKioqKioqLzxicj4NCjEpIFNJUC1UL0lTVVAvUVNJRy9Q U1ROPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAtRG9j dW1lbnRlZCBpbiBSRkMgMzM3MiBhbmQgUkZDIDQ0OTcuPGJyPg0KPGJyPg0KMikgRUNNQSBUUi84 NyB1YUNTVEE8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ IC1Vc2VzIElORk8gdG8gc2VuZCBFQ01BLTMyMyBYTUwgZm9yDQptb25pdG9yaW5nIGFuZCBjb250 cm9sbGluZyBwaG9uZXMgZnJvbSBhIFBDLjxicj4NCjxicj4NCjMpIFNlbmRpbmcgbWVkaWEgc2Vy dmVyIGNvbnRyb2wgY29tbWFuZHMuPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiAtRG9jdW1lbnRlZCBpbiBSRkM0NzIyIE1TQ01MLjxicj4NCjxicj4NCjxi cj4NCi8qKioqKioqKioqKioqKioqPGJyPg0KKjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udCBzaXpl PTI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gVXNlLWNhc2VzIHRoYXQgSSB0aGlu ayBhcmUgcG90ZW50aWFsbHkvcG9zc2libHkgdmFsaWQNCmZvciBJTkZPOjxicj4NCioqKioqKioq KioqKioqKiovPGJyPg0KMSkgU2VuZGluZyBhIHZjYXJkIGFzeW5jaHJvbm91c2x5Ljwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3Nw YW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiA8 c3QxOkNpdHkgdzpzdD0ib24iPkFsaWNlPC9zdDE6Q2l0eT4NCmNhbGxzIEJvYiwgPHN0MTpDaXR5 IHc6c3Q9Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj5BbGljZTwvc3QxOnBsYWNlPjwvc3QxOkNp dHk+DQpzYXlzICZxdW90O2NhbiB5b3Ugc2VuZCBtZSBKb2huJ3MgdmNhcmQ/JnF1b3Q7LCBCb2Ig Y2xpY2tzIHNvbWV0aGluZyBhbmQgdm9pbGENCml0J3Mgc2VudC48YnI+DQo8L3NwYW4+PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IC1BbHRlcm5hdGl2ZXM6IHNlbmQgYSByZS1J bnZpdGUgb3INClVwZGF0ZSB3aXRoIGEgQ2FsbC1JbmZvLCB3aXRoIGVpdGhlciBhIFVSTCByZWZl cmVuY2UsIGRhdGEgVVJJLCBvciBNSU1FIGFuZCBDSUQNClVSTC48YnI+DQo8L3NwYW4+PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IC1Db3VudGVyLWFyZ3VtZW50OiBJTU8gdGhp cyB0eXBlIG9mIGRhdGENCnJlYWxseSBiZWxvbmdzIGluIE1JTUUgZm9yIGEgbnVtYmVyIG9mIHJl YXNvbnMsIGluY2x1ZGluZyBsZW5ndGggaXMgbGVzcw0KcmVzdHJpY3RlZCBmb3IgbWltZSBhdHRh Y2htZW50czsgb25lIEFEIGhhcyBzYWlkIHRoZSBEYXRhIFVSTCBtYXkgYmUNCmRlcHJlY2F0ZWQu PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+IEFuZCBzZW5kaW5nIGEgcmUtSW52aXRlIGZvciB0aGlzIHB1cnBvc2UNCnNlZW1zIG9k ZC48YnI+DQo8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ IC1BbHNvLCB0aGUgQ2FsbC1JbmZvIGhlYWRlciBpcyByZWFsbHkNCmFib3V0IHRoZSBjYWxsZXIg b3IgY2FsbGVlLCBhbmQgdGh1cyBCb2Igc2hvdWxkbid0IGJlIHNlbmRpbmcgbWUgSm9obidzIHZj YXJkDQppbmZvIGluIGl0IHRlY2huaWNhbGx5Ljwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXpl PTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBUaGF0IG1heSBzb3VuZCBsaWtlIGEg bml0LCBidXQgVUEncyBtYXkNCndlbGwgc3RvcmUgdGhlIGNhbGwtaW5mbyB2Y2FyZHMgaW50byB0 aGVpciBhZGRyZXNzLWJvb2tzIGF1dG9tYXRpY2FsbHkgYW5kIHNvDQp0aWUgaXQgdG8gdGhlIHdy b25nIHVzZXIvY2FsbC48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+IC1Qcm9zIG9mIHVzaW5nIElORk86IGl0J3MgZXhwbGljaXQgd2hhdA0KeW91J3JlIGRv aW5nIHdoZW4geW91IHNlbmQgdGhlIHZjYXJkLCBhbmQgeW91IGNhbiBzZW5kIGl0IGtub3dpbmcg dGhlIG90aGVyIGVuZA0KY2FuIGFjY2VwdCBpdCwgYW5kIHlvdSBjYW4gc2VuZCBpdCBiYXNlZCBv biB1c2VyIGlucHV0Ljxicj4NCjxicj4NCjIpIFNlbmRpbmcgYSB1c2VyLWljb24ganBlZy9iaXRt YXAvZ2lmLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiA8c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFs aWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4NCmNhbGxzIEJvYiwgQm9iIGhhcyBhbiBpY29uIHRo YXQgcmVwcmVzZW50cyBoaW1zZWxmLCBzZW5kcyBpdCB3aGVuIGhlIHBpY2tzIHVwDQp0aGUgcGhv bmUuPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAtQWx0 ZXJuYXRpdmVzOiBzZW5kIGEgMjAwb2ssIHJlLUludml0ZSwNCm9yIFVwZGF0ZSB3aXRoIGNhbGwt aW5mbywgd2hpY2ggZXhwbGljaXRseSBoYXMgYSB0eXBlIGZvciBpY29uLjxicj4NCjwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6 ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gLUNvdW50ZXItYXJndW1lbnQ6IHNh bWUgYXMgZm9yIHZjYXJkLA0KcGx1cyB3aXRoIGNhbGwtaW5mbyB0aGVyZSBpcyBubyB3YXkgdG8g a25vdyB3aGljaCBwaWN0dXJlIGZvcm1hdCB0aGUgZmFyLWVuZA0Kc3VwcG9ydHMgYSBwcmlvcmku PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+IFdpdGggYSBzdXBwb3J0ZWQtcGFja2FnZSBuZWdvdGlhdGlvbiBvbmUNCmNvdWxkIGtu b3cuPGJyPg0KPGJyPg0KMykgU2VuZGluZyBhIHZjYWxlbmRhci10eXBlIGludml0YXRpb24uPC9z cGFuPjwvZm9udD48Zm9udCBzaXplPTINCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+IDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpw bGFjZT48L3N0MTpDaXR5Pg0KY2FsbHMgQm9iLCBCb2Igc2F5cyAmcXVvdDtoZXkgbGV0J3MgaGF2 ZSBhIGNvbiBjYWxsIGF0IHRpbWUgWCZxdW90OywgY2xpY2tzIGFuZA0Kdm9pbGEgaGlzIHBob25l IHNlbmRzIGEgdmNhbGVuZGFyLi48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+IC1XaGV0aGVyIHRoZSB2Y2FsZW5kYXIgaXMgcmVsYXRlZCB0byB0aGUNCnNl c3Npb24gb3Igbm90IGFuZCB0aHVzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHNlbnQgaW4gYW4gaW4t ZGlhbG9nIHJlcXVlc3Qgb3INCm5vdCBpcyBjZXJ0YWlubHkgZGViYXRhYmxlLjwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+ PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBNZXNz YWdlIG1ldGhvZCBjYW4gYWxyZWFkeSBiZSB1c2VkIGZvcg0KdGhpcyBhbnl3YXkuPGJyPg0KPGJy Pg0KNCkgU2VuZGluZyBhbiBIVFRQIFVSTC48L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0y PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gPHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGlj ZTwvc3QxOkNpdHk+DQpjYWxscyBCb2IsIGEgc2FsZXMgZ3V5OyA8c3QxOkNpdHkgdzpzdD0ib24i PkFsaWNlPC9zdDE6Q2l0eT4gYXNrcyBmb3IgbW9yZSBpbmZvDQpvciBhIGRhdGFzaGVldCBhbmQg Qm9iIHNlbmRzIGEgVVJMIGZvciA8c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0i b24iPkFsaWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4NCnRvIG9wZW4gd2l0aCBoZXIgd2ViLWJy b3dzZXIuPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw YW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAt T25lIGNvdWxkIGFsc28gYXJndWUgdGhpcyBpcyBqdXN0DQptYWtpbmcgU0lQIHRoZSBuZXcgU01U UCwgb3IgdGhpcyBzaG91bGQgYmUgc2VudCB1c2luZyBNRVNTQUdFICh3aGljaCByZWFsbHkgaXMN CnRoZSBuZXcgU01UUCkuPGJyPg0KPGJyPg0KNSkgU2VuZGluZyBhIHNlc3Npb24gdHJhY2Vyb3V0 ZS48L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mg0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz4gQWxpY2UgY2FsbHMgQm9iLCBCb2IgYW5zd2VycywgQWxpY2UgZG9lcw0KYSBzaXAt dHJhY2Vyb3V0ZSB0byBmaWd1cmUgb3V0IHRoZSBwYXRoIHRvIEJvYiwgYnkgc2VuZGluZyBJbmZv IHdpdGggYW4NCmluY3JlbWVudGluZyBtYXgtZm9yd2FyZHMgdHlwZSBoZWFkZXIgc3RhcnRpbmcg YXQgMCAoYnV0IG5vdCByZWFsbHkNCm1heC1mb3J3YXJkcyksIHdpdGggYSBzaXAtZnJhZyB0eXBl IHJlc3BvbnNlIGJvZHkgb3Igc29tZSBzdWNoLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz4gLUl0J3MgZGViYXRhYmxlIGlmIGNlcnRhaW4gdHlwZXMgb2YN CkIyQlVBJ3MgKGllLCBTQkNzKSB3b3VsZCBldmVyIGFsbG93IHRoaXMgdHlwZSBvZiB0aGluZyB0 byBoYXBwZW4sIGR1ZSB0bw0Kc2VjdXJpdHkgY29uY2VybnMsIGJ1dCBJIHRoaW5rIHRoZXkgbWF5 IGRvIGl0IGF0IGRvbWFpbiBib3VuZGFyeSBob3BzLjwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9 MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpz aXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBJIHRoaW5rIHRoaXMgaXMgYSBy ZWFzb25hYmxlIHVzZSBmb3INCklORk8gdGhvdWdoLCBtYXliZS48YnI+DQo8YnI+DQo2KSBTZW5k aW5nIGdlby1sb2NhdGlvbiBpbmZvcm1hdGlvbiBhZnRlciBjYWxsIGVzdGFibGlzaG1lbnQuPC9z cGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+IDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpw bGFjZT48L3N0MTpDaXR5Pg0KY2FsbHMgQm9iLCBhIGhvdGVsIHJlY2VwdGlvbmlzdC48L3NwYW4+ PC9mb250Pjxmb250IHNpemU9Mg0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9z cGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4g PHN0MTpDaXR5IHc6c3Q9Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj5BbGljZTwvc3QxOnBsYWNl Pjwvc3QxOkNpdHk+DQphc2tzIGZvciBkaXJlY3Rpb25zIHRvIGhvdGVsLCBjbGlja3MgYnV0dG9u IGFuZCBzZW5kcyBoaW0gbG9jYXRpb24gaW5mbyBvZiBoZXINCnBob25lIChvciBCb2IgY2xpY2tz IGJ1dHRvbiBhbmQgc2VuZHMgaGVyIGhpcyBsb2NhdGlvbikuPGJyPg0KPC9zcGFuPjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAtVGhlIGxvY2F0aW9uIGNvbnZleWFuY2UgZHJh ZnQNCnNwZWNpZmljYWxseSBjYWxscyBvdXQgSU5GTyBhcyBhY2NlcHRhYmxlIGZvciBnZW8tbG9j IGluZm8uPC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+IFdoZXRoZXIgdGhpcyBpcyBhIHJlYWwgdXNlLWNhc2UgaXMNCmRlYmF0YWJs ZSwgYW5kIG9idmlvdXNseSBpdCBjb3VsZCBiZSBkb25lIHdpdGggYSBzdWIvbm90Ljxicj4NCjxi cj4NCjcpIFNlbmRpbmcgc29mdGtleS1sYWJlbHMgKG5vdCBkaWdpdC1tYXRjaCBtYXBzLCBidXQg cmF0aGVyIHNvZnRrZXkgYnV0dG9uDQpsYWJlbHMpLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpz aXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiA8c3QxOkNpdHkgdzpzdD0ib24i PjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4NCmNhbGxz IGhlciB2bWFpbCBzZXJ2ZXIuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IFZtYWlsIHNlcnZlciBzZW5kcyBzb2Z0a2V5LWxhYmVs cyBmb3INCnRoZSBtZW51IGl0ZW1zIGF2YWlsYWJsZSBpbiB0aGUgcmVzcG9uc2UsIDxzdDE6Q2l0 eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFjZT48L3N0MTpD aXR5Pg0KcHJlc3NlcyBzb2Z0a2V5cyBhbmQgc2VuZHMgdGhlbSBpbiBJTkZPLjxicj4NCjwvc3Bh bj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0K c2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gLVRoaXMgY291bGQgKGFuZCBt YXliZSBzaG91bGQpIGJlIGRvbmUNCndpdGggc3ViL25vdCwgYSBsYSBLUE1MLCB3aGVyZSB0aGUg dm1haWwgc2VydmVyIHNlbmRzIHRoZSBzb2Z0a2V5IGxhYmVscyBpbiB0aGUNClN1YnNjcmliZSwg VUEgc2VuZHMgYnV0dG9ucyBwcmVzc2VkIGluIE5vdGlmaWVzLjwvc3Bhbj48L2ZvbnQ+PGZvbnQg c2l6ZT0yDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxm b250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBCdXQgdGhpcyBpcyBz aW1pbGFyIHRvIHRoZSBEVE1GIHVzZSBjYXNlDQpzbyBtYXkgd2VsbCBoYXZlIHRoZSBzYW1lIGJl bmVmaXQgb2YgbG93ZXIgb3ZlcmhlYWQgc2luY2UgYnV0dG9ucyBhcmUgcmFyZWx5DQpwcmVzc2Vk Ljxicj4NCjxicj4NCjgpIFNlbmRpbmcgYSBzY3JlZW4tcG9wLXVwIG1lc3NhZ2UsIGUuZy4sICZx dW90O0RvIHlvdSB3YW50IHRvIGNvbnRpbnVlIHdpdGgNCnRoaXMgc2Vzc2lvbj8mcXVvdDs8YnI+ DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IC1UaGVyZSBpcyBh IHBhdGVudCBmb3IgZG9pbmcgc2NyZWVuDQpwb3AtdXBzIHVzaW5nIElORk8uPC9zcGFuPjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IEkgZ3Vl c3MgQWxlcnQtSW5mbyBjb3VsZCBiZSB1c2VkIGZvcg0KdGhpcywgYnV0IGl0J3Mgbm90IGNsZWFy IGl0IHNob3VsZD88YnI+DQo8YnI+DQo8YnI+DQovKioqKioqKioqKioqKioqKio8YnI+DQoqPC9z cGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPiBVc2UtY2FzZXMgd2hpY2ggaGF2ZSBiZWVuIHByb3Bvc2VkIGJ5IG90aGVycyBvciBldmVu DQppbXBsZW1lbnRlZCw8YnI+DQoqPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDs8L3NwYW4+PC9mb250Pjxmb250IHNpemU9Mj48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiB3aGljaCBhcmUgZHViaW91cyBmb3IgSU5GTyAo SU1ITyk6PGJyPg0KKioqKioqKioqKioqKioqKiovPGJyPg0KMSkgU2VuZGluZyBSVFAvUlRDUCBz dGF0aXN0aWNzIGR1cmluZyBjYWxsLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4gLVRoZXJlIGlzIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoaXMsIGFuZA0K dGhlIHJhdGlvbmFsZSBpcyB0aGUgc2lnbmFsaW5nIHBsYW5lIGJveCB0aGF0IHdhbnRzIHRoaXMg aW5mbyBpcyBub3QgYWN0dWFsbHkNCnRoZSBtZWRpYSBwbGFuZSBib3ggdGhhdCBnZXRzIFJUQ1Au PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTINCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+IEFnYWluIHRoaXMgY291bGQgKGFuZCBJTU8gc2hvdWxkKSBiZQ0KZG9uZSB3aXRoIHN1 Yi9ub3QsIHNvIGl0IGNhbiBnZXQgc3RhdHMgYWZ0ZXIgdGhlIGNhbGwgaXMgb3ZlciwgYW5kIHNp bmNlIGl0DQp3aWxsIHByb2JhYmx5IHdhbnQgcGVyaW9kaWMgcmVwb3J0cyB0aGUgb3ZlcmhlYWQg b2YgdGhlIFN1YnNjcmliZSBzaG91bGQgYmUNCmR3YXJmZWQgYnkgdGhlIG51bWJlciBvZiBOb3Rp Zmllcy48YnI+DQo8YnI+DQoyKSBTZW5kaW5nIGFjY2Vzcy1sb2NhdGlvbiBpbmZvcm1hdGlvbiBh ZnRlciBjYWxsIGVzdGFibGlzaG1lbnQuPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPiAtVGhlcmUgaXMgYSBQLUFjY2Vzcy1OZXR3b3JrLUluZm8NCmhlYWRl ciwgYW5kIHNvbWUgaGF2ZSBwcm9wb3NlZCB0byBzZW5kIGFuIHVwZGF0ZSBmb3IgaXQgYXMgYSBw aG9uZSByb2FtcyBhY2Nlc3MNCnBvaW50cyBvciBjZWxscy48L3NwYW4+PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9u dA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gQnV0IEkgdGhpbmsgdGhp cyBpcyBhbiBvZGQgdGhpbmcgdG8gZG8NCmluc2lkZSBhbiBJbnZpdGUgc2Vzc2lvbiwgdnMuIGlu IGEgc3ViL25vdCBvciBSZWdpc3RlciAoYW5kIGJlc2lkZXMgaGFsZiB0aGUNCnRpbWUgdGhlIG5l dHdvcmsgaW5zZXJ0cyB0aGlzIGhlYWRlciwgbm90IHRoZSBVQSkuPGJyPg0KPGJyPg0KMykgU2Vu ZGluZyBtZWRpYS1jb250cm9sIGluZGljYXRpb25zIChpZSwgcmVtb3RlLWNvbnRyb2wNCiZxdW90 O3BsYXkvcGF1c2UvZXRjLiZxdW90Oyk8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+IC1UaGlzIGlzIGRvbmUgdG9kYXkgYnkgYXQgbGVhc3Qgb25lDQp2ZW5k b3IsIGJ1dCBpcyBkZWJhdGFibGUgaWYgaXQncyB0aGUgcmlnaHQgbW9kZWwuPC9zcGFuPjwvZm9u dD48Zm9udCBzaXplPTINCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IFRoZSBh cmd1bWVudCBpcyBpdCdzIGxpa2UgU0RQIHJlLUludml0ZQ0KZm9yIGhvbGQsIGV4Y2VwdCBhdCBh IG1lZGlhIGNvbnRlbnQgbGF5ZXIgYWJvdmUgUlRQLCBzbyBub3QgZG9uZSBpbiBSVENQIG5vcg0K U0RQLjxicj4NCjxicj4NCjQpIFNlbmRpbmcgdmlkZW8gZmFzdCB1cGRhdGUgY29tbWFuZDxicj4N Cjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48 Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4gLVRoaXMgaXMgYW4g aW5mb3JtYXRpb25hbCBkcmFmdCwgd2hpY2gNCmRvY3VtZW50cyB3aGF0IGhhcyBiZWVuIGltcGxl bWVudGVkLCBidXQgc3RhdGVzIGl0IHNob3VsZCByZWFsbHkgYmUgZG9uZSBpbiB0aGUNCm1lZGlh IHBsYW5lLjxicj4NCjxicj4NCjUpIFNlbmRpbmcgcGVyaXBoZXJhbCBjb250cm9sIGNvbW1hbmRz IChpZSwgVVNCIGNvbW1hbmRzKTxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz4gLVRoZXJlIGlzIGFjdHVhbGx5IGEgcGF0ZW50IG9uIHRoaXMsDQphbWF6aW5n bHkuPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+IFNvbWVvbmUgdGhpbmtzIGl0IG1ha2VzIHNlbnNlIHRvIGNyZWF0ZQ0KYSBTSVAg c2Vzc2lvbiB0byB5b3VyIGxhcHRvcCwgb3IgdmljZS12ZXJzYSwgYW5kIHRoZW4gc2VuZCBVU0Ig Y29tbWFuZHMgaW5zaWRlDQpNSU1FIGluIElORk8gbWVzc2FnZXMuPC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PGZvbnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IE1ldGhpbmtzIHRo aXMgc2hvdWxkIGJlIG1lZGlhLXBsYW5lLCBpZg0KYW55dGhpbmcuPGJyPg0KPGJyPg0KNikgU2Vu ZGluZyBjaGFyZ2luZyBpbmZvcm1hdGlvbiBmb3IgYSBjYWxsIChpLmUuLCBtaW51dGVzIHJlbWFp bmluZyBvciBjb3N0IHNvDQpmYXIpLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0yPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4gLVRoZXJlIHdhcyBhIHByb3Bvc2FsIHRvIHVzZSB0aGlzIGZvcg0KQWR2 aWNlIG9mIENoYXJnZSBpbmZvcm1hdGlvbiBpbiBUSVNQQU4uPC9zcGFuPjwvZm9udD48Zm9udCBz aXplPTINCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PGZv bnQNCnNpemU9Mj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+IElNTyBpdCBzaG91bGQg YmUgYSBzdWIvbm90IHRob3VnaCwgYXMNCnRoZXkgd2FudCB0aGlzIHRvIHN1cnZpdmUgdGhlIElu dml0ZSBzZXNzaW9uLjxicj4NCjxicj4NCi1oYWRyaWVsPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+DQoN CjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_E6C2E8958BA59A4FB960963D475F7AC30273926572mailacmepacke_-- --===============0485038598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0485038598==-- From sip-bounces@ietf.org Fri Dec 07 07:58:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0cld-0008M8-UL; Fri, 07 Dec 2007 07:57:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0clc-0008M2-IB for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 07:57:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0clc-0008Lp-6Y for sip@ietf.org; Fri, 07 Dec 2007 07:57:20 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0cla-0001vz-Oz for sip@ietf.org; Fri, 07 Dec 2007 07:57:19 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EF26A20B3B; Fri, 7 Dec 2007 13:57:17 +0100 (CET) X-AuditID: c1b4fb3c-aff97bb0000030cf-96-4759432de2f3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 82CC920401; Fri, 7 Dec 2007 13:57:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 05:54:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 05:54:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg4e720MWNQEr4bSuyG3N7Vp+zH/AAELgqV References: <4758AC44.6030900@cisco.com> <4758B494.7010103@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hadriel Kaplan" X-OriginalArrivalTime: 07 Dec 2007 04:54:29.0684 (UTC) FILETIME=[4016CF40:01C8388D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 I guess the MSRP overhead issue applies also to other cases where there = may be some small amount of data sent at some point during the session. = User-to-user information is one example. =20 But, I fully agree that INFO shall not be used for sending 10MB of data. =20 Regards, =20 Christer ________________________________ L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@cisco.com] L=E4hetetty: pe 7.12.2007 3:48 Vastaanottaja: Hadriel Kaplan Kopio: sip@ietf.org Aihe: Re: [Sip] INFO use-cases Hadriel Kaplan wrote: > Hey Paul, > Yeah I agree MESSAGE makes a lot of sense for things to be rendered = natively/directly to the user. > > Regarding using MSRP: while that is obviously possible and for some = cases undoubtedly the right thing to do, for some uses it is a crazy = amount of overhead. For example if I want to send you a vcard mid-call, = it seems silly to send a re-Invite to add an MSRP session, potentially = go get msrp-relay info to do so, and/or possibly go through ICE = procedures, all just to send you a 100 byte little vcard I could have = sent in an INFO. But clearly if I need to send you a 10MB file it will = be appropriate. My 2 cents anyway. Yes, I agree. In some cases even though it is a rediculous amount of overhead it just won't matter and will be the right thing to do anyway if the infrastructure is there to do it. In other cases that isn't so. I'm certainly open to some uses for INFO or for more marginal uses of MESSAGE. Especially if we go ahead with this INFO enhancement I think we need to draw the line carefully between INFO and MESSAGE. Paul > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, December 06, 2007 9:13 PM >> To: Hadriel Kaplan >> Cc: sip@ietf.org >> Subject: Re: [Sip] INFO use-cases >> >> Hadriel, >> >> I buy some of your use cases, but not others. Comments below. >> >> A competitor for INFO in several of these is MESSAGE. I think a good >> case can be made for that if the information is to be rendered to the >> recipient. >> >> Paul >> >> >> Hadriel Kaplan wrote: >> [snip] >> >>> /**************** >>> * Use-cases that I think are potentially/possibly valid for INFO: >>> ****************/ >>> 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can = you >> send me John's vcard?", Bob clicks something and voila it's sent. >>> -Alternatives: send a re-Invite or Update with a Call-Info, = with >> either a URL reference, data URI, or MIME and CID URL. >>> -Counter-argument: IMO this type of data really belongs in = MIME >> for a number of reasons, including length is less restricted for mime >> attachments; one AD has said the Data URL may be deprecated. And = sending >> a re-Invite for this purpose seems odd. >>> -Also, the Call-Info header is really about the caller or >> callee, and thus Bob shouldn't be sending me John's vcard info in it >> technically. That may sound like a nit, but UA's may well store the = call- >> info vcards into their address-books automatically and so tie it to = the >> wrong user/call. >>> -Pros of using INFO: it's explicit what you're doing when = you >> send the vcard, and you can send it knowing the other end can accept = it, >> and you can send it based on user input. >>> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an >> icon that represents himself, sends it when he picks up the phone. >>> -Alternatives: send a 200ok, re-Invite, or Update with call- >> info, which explicitly has a type for icon. >>> -Counter-argument: same as for vcard, plus with call-info = there >> is no way to know which picture format the far-end supports a priori. >> With a supported-package negotiation one could know. >> >> For this case MESSAGE seems entirely appropriate. >> >> (Not so much so for vcard, which probably isn't intended to be = directly >> rendered to the recipient.) >> >>> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says = "hey >> let's have a con call at time X", clicks and voila his phone sends a >> vcalendar. >>> -Whether the vcalendar is related to the session or not and = thus >> whether it should be sent in an in-dialog request or not is certainly >> debatable. Message method can already be used for this anyway. >>> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks = for >> more info or a datasheet and Bob sends a URL for Alice to open with = her >> web-browser. >>> -One could also argue this is just making SIP the new SMTP, = or >> this should be sent using MESSAGE (which really is the new SMTP). >> >> Yes to MESSAGE. >> >>> 5) Sending a session traceroute. Alice calls Bob, Bob answers, = Alice >> does a sip-traceroute to figure out the path to Bob, by sending Info = with >> an incrementing max-forwards type header starting at 0 (but not = really >> max-forwards), with a sip-frag type response body or some such. >>> -It's debatable if certain types of B2BUA's (ie, SBCs) would >> ever allow this type of thing to happen, due to security concerns, = but I >> think they may do it at domain boundary hops. I think this is a >> reasonable use for INFO though, maybe. >>> 6) Sending geo-location information after call establishment. Alice >> calls Bob, a hotel receptionist. Alice asks for directions to hotel, >> clicks button and sends him location info of her phone (or Bob clicks >> button and sends her his location). >>> -The location conveyance draft specifically calls out INFO = as >> acceptable for geo-loc info. Whether this is a real use-case is >> debatable, and obviously it could be done with a sub/not. >> >> UPDATE with geo-loc is reasonable here, or even reINVITE. >> >>> 7) Sending softkey-labels (not digit-match maps, but rather softkey >> button labels). Alice calls her vmail server. Vmail server sends >> softkey-labels for the menu items available in the response, Alice = presses >> softkeys and sends them in INFO. >>> -This could (and maybe should) be done with sub/not, a la = KPML, >> where the vmail server sends the softkey labels in the Subscribe, UA = sends >> buttons pressed in Notifies. But this is similar to the DTMF use = case so >> may well have the same benefit of lower overhead since buttons are = rarely >> pressed. >>> 8) Sending a screen-pop-up message, e.g., "Do you want to continue = with >> this session?" >>> -There is a patent for doing screen pop-ups using INFO. I = guess >> Alert-Info could be used for this, but it's not clear it should? >> >> This is very definitely a use case for MESSAGE. >> >> Also, all of the above could probably be justifiably sent via MSRP - >> either directly or via the file transfer extensions. >> >>> /***************** >>> * Use-cases which have been proposed by others or even implemented, >>> * which are dubious for INFO (IMHO): >>> *****************/ >>> 1) Sending RTP/RTCP statistics during call. >>> -There is an implementation of this, and the rationale is = the >> signaling plane box that wants this info is not actually the media = plane >> box that gets RTCP. Again this could (and IMO should) be done with >> sub/not, so it can get stats after the call is over, and since it = will >> probably want periodic reports the overhead of the Subscribe should = be >> dwarfed by the number of Notifies. >>> 2) Sending access-location information after call establishment. >>> -There is a P-Access-Network-Info header, and some have = proposed >> to send an update for it as a phone roams access points or cells. = But I >> think this is an odd thing to do inside an Invite session, vs. in a >> sub/not or Register (and besides half the time the network inserts = this >> header, not the UA). >>> 3) Sending media-control indications (ie, remote-control >> "play/pause/etc.") >>> -This is done today by at least one vendor, but is debatable = if >> it's the right model. The argument is it's like SDP re-Invite for = hold, >> except at a media content layer above RTP, so not done in RTCP nor = SDP. >>> 4) Sending video fast update command >>> -This is an informational draft, which documents what has = been >> implemented, but states it should really be done in the media plane. >>> 5) Sending peripheral control commands (ie, USB commands) >>> -There is actually a patent on this, amazingly. Someone = thinks >> it makes sense to create a SIP session to your laptop, or vice-versa, = and >> then send USB commands inside MIME in INFO messages. Methinks this = should >> be media-plane, if anything. >>> 6) Sending charging information for a call (i.e., minutes remaining = or >> cost so far). >>> -There was a proposal to use this for Advice of Charge >> information in TISPAN. IMO it should be a sub/not though, as they = want >> this to survive the Invite session. >>> -hadriel >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 09:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0e0H-0002eA-Dk; Fri, 07 Dec 2007 09:16:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0e0G-0002dw-G2 for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 09:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0e0G-0002de-6H for sip@ietf.org; Fri, 07 Dec 2007 09:16:32 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0e0A-0006MD-Ky for sip@ietf.org; Fri, 07 Dec 2007 09:16:32 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0E3A322459; Fri, 7 Dec 2007 15:12:32 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-34-475954cfb550 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEC0F21EB8; Fri, 7 Dec 2007 15:12:31 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 02:22:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 02:22:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/AADmHLU= References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> From: "Christer Holmberg" To: "Ganesan Sam-W00184" , "Hadriel Kaplan" , X-OriginalArrivalTime: 07 Dec 2007 01:22:30.0324 (UTC) FILETIME=[A2C27F40:01C8386F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 Use-case 1: ----------------- =20 One use-case is the transport of user-to-user information, and the = reasons people don't think it's feasible to establish a media plane = connection for this are (at least): =20 1. The information will not be sent for every call, and when sent the = amount of information is relatively small 2. In interworking cases the information may be received out-of-band = from the "other side", so it is seen as unfeasible to send it down to = the MG - in some cases the interworking may even be performed without a = MG. =20 =20 Use-case 2: ----------------- =20 Pretty much the same arguments are also used for sending DTMF = out-of-band. In addition there may be intermediate entities, without = media access, which are interested in the DTMF information. =20 =20 (I hope we have understood the arguments why people want to use INFO = instead of SUB/NOT, so I will not go into that again.) =20 Regards, =20 Christer ________________________________ L=E4hett=E4j=E4: Ganesan Sam-W00184 [mailto:sam.ganesan@motorola.com] L=E4hetetty: pe 7.12.2007 1:46 Vastaanottaja: Hadriel Kaplan; sip@ietf.org Aihe: RE: [Sip] INFO use-cases I also know of a use case where video npt bookmarks are sent over INFO = across the SIP path while using SIP for video stream set up. Tispan 3 = is actually writing specs on this and so is ATIS... =20 =20 =20 Sam ________________________________ From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thu 12/6/2007 6:38 PM To: sip@ietf.org Subject: [Sip] INFO use-cases Howdy, Jonathan asked for use-cases for what types of things would need an = in-dialog SIP message for user-user communication, vs. should be done = either out of dialog or in the media plane. If the only use-case is = DTMF, then we could just document the DTMF negotiation/use only and not = have to create a general info-events framework. That seems a very = reasonable argument to me. I also don't want to do work for no use. There is a counter-argument that there are proprietary uses of INFO in = the wild, and that a framework for negotiation at least removes the = manual configuration of vendor-specific profiles, which is a problem of = interop today - even if the IETF should not bless/document the specific = use cases themselves. But that would make the draft a very different = one than it currently is as well, and I will ask that in a separate = email thread. The chairs have asked for 3 use cases, and I assume they mean 3 NEW use = cases (we already have 3 RFCs which use INFO, as well as DTMF). I am = not sure if they mean potential future use-cases, or current use-cases = (i.e., already implemented). Can I get a clarification on that? So anyway, taking the shot-gun approach, here's a first go at some = use-cases, and my personal take on whether they should be in INFO vs. = SUB/NOT vs. media-plane, FWIW. [apologize for formatting ugliness] /*************** * Already standardized use-cases: ***************/ 1) SIP-T/ISUP/QSIG/PSTN -Documented in RFC 3372 and RFC 4497. 2) ECMA TR/87 uaCSTA -Uses INFO to send ECMA-323 XML for monitoring and controlling = phones from a PC. 3) Sending media server control commands. -Documented in RFC4722 MSCML. /**************** * Use-cases that I think are potentially/possibly valid for INFO: ****************/ 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you = send me John's vcard?", Bob clicks something and voila it's sent. -Alternatives: send a re-Invite or Update with a Call-Info, with = either a URL reference, data URI, or MIME and CID URL. -Counter-argument: IMO this type of data really belongs in MIME = for a number of reasons, including length is less restricted for mime = attachments; one AD has said the Data URL may be deprecated. And = sending a re-Invite for this purpose seems odd. -Also, the Call-Info header is really about the caller or = callee, and thus Bob shouldn't be sending me John's vcard info in it = technically. That may sound like a nit, but UA's may well store the = call-info vcards into their address-books automatically and so tie it to = the wrong user/call. -Pros of using INFO: it's explicit what you're doing when you = send the vcard, and you can send it knowing the other end can accept it, = and you can send it based on user input. 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an = icon that represents himself, sends it when he picks up the phone. -Alternatives: send a 200ok, re-Invite, or Update with = call-info, which explicitly has a type for icon. -Counter-argument: same as for vcard, plus with call-info there = is no way to know which picture format the far-end supports a priori. = With a supported-package negotiation one could know. 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey = let's have a con call at time X", clicks and voila his phone sends a = vcalendar. -Whether the vcalendar is related to the session or not and thus = whether it should be sent in an in-dialog request or not is certainly = debatable. Message method can already be used for this anyway. 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for = more info or a datasheet and Bob sends a URL for Alice to open with her = web-browser. -One could also argue this is just making SIP the new SMTP, or = this should be sent using MESSAGE (which really is the new SMTP). 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice = does a sip-traceroute to figure out the path to Bob, by sending Info = with an incrementing max-forwards type header starting at 0 (but not = really max-forwards), with a sip-frag type response body or some such. -It's debatable if certain types of B2BUA's (ie, SBCs) would = ever allow this type of thing to happen, due to security concerns, but I = think they may do it at domain boundary hops. I think this is a = reasonable use for INFO though, maybe. 6) Sending geo-location information after call establishment. Alice = calls Bob, a hotel receptionist. Alice asks for directions to hotel, = clicks button and sends him location info of her phone (or Bob clicks = button and sends her his location). -The location conveyance draft specifically calls out INFO as = acceptable for geo-loc info. Whether this is a real use-case is = debatable, and obviously it could be done with a sub/not. 7) Sending softkey-labels (not digit-match maps, but rather softkey = button labels). Alice calls her vmail server. Vmail server sends = softkey-labels for the menu items available in the response, Alice = presses softkeys and sends them in INFO. -This could (and maybe should) be done with sub/not, a la KPML, = where the vmail server sends the softkey labels in the Subscribe, UA = sends buttons pressed in Notifies. But this is similar to the DTMF use = case so may well have the same benefit of lower overhead since buttons = are rarely pressed. 8) Sending a screen-pop-up message, e.g., "Do you want to continue with = this session?" -There is a patent for doing screen pop-ups using INFO. I guess = Alert-Info could be used for this, but it's not clear it should? /***************** * Use-cases which have been proposed by others or even implemented, * which are dubious for INFO (IMHO): *****************/ 1) Sending RTP/RTCP statistics during call. -There is an implementation of this, and the rationale is the = signaling plane box that wants this info is not actually the media plane = box that gets RTCP. Again this could (and IMO should) be done with = sub/not, so it can get stats after the call is over, and since it will = probably want periodic reports the overhead of the Subscribe should be = dwarfed by the number of Notifies. 2) Sending access-location information after call establishment. -There is a P-Access-Network-Info header, and some have proposed = to send an update for it as a phone roams access points or cells. But I = think this is an odd thing to do inside an Invite session, vs. in a = sub/not or Register (and besides half the time the network inserts this = header, not the UA). 3) Sending media-control indications (ie, remote-control = "play/pause/etc.") -This is done today by at least one vendor, but is debatable if = it's the right model. The argument is it's like SDP re-Invite for hold, = except at a media content layer above RTP, so not done in RTCP nor SDP. 4) Sending video fast update command -This is an informational draft, which documents what has been = implemented, but states it should really be done in the media plane. 5) Sending peripheral control commands (ie, USB commands) -There is actually a patent on this, amazingly. Someone thinks = it makes sense to create a SIP session to your laptop, or vice-versa, = and then send USB commands inside MIME in INFO messages. Methinks this = should be media-plane, if anything. 6) Sending charging information for a call (i.e., minutes remaining or = cost so far). -There was a proposal to use this for Advice of Charge = information in TISPAN. IMO it should be a sub/not though, as they want = this to survive the Invite session. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 09:33:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0eGX-00087W-W4; Fri, 07 Dec 2007 09:33:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0eGX-00087R-Dm for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 09:33:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0eGX-00087I-31 for sip@ietf.org; Fri, 07 Dec 2007 09:33:21 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0eGW-0006fx-K6 for sip@ietf.org; Fri, 07 Dec 2007 09:33:20 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D047623CCC; Fri, 7 Dec 2007 15:20:04 +0100 (CET) X-AuditID: c1b4fb3e-b06a2bb00000459d-b7-47595694d824 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AEB0E23D24; Fri, 7 Dec 2007 15:20:04 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 22:20:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Thu, 6 Dec 2007 22:18:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: Acg4Q/R4rWlklrR6TRmLmVeo6+/EsQACYuej References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> From: "Christer Holmberg" To: , X-OriginalArrivalTime: 06 Dec 2007 21:20:38.0899 (UTC) FILETIME=[D946C430:01C8384D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 No matter how we'll fix this, I guess it would be a valid essential = correction? =20 Regards, =20 Christer ________________________________ L=E4hett=E4j=E4: Dale.Worley@comcast.net = [mailto:Dale.Worley@comcast.net] L=E4hetetty: to 6.12.2007 21:09 Vastaanottaja: sip@ietf.org Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? From: Jonathan Rosenberg This strikes me as a problem in theory and not in practice. AFAICT, = the only characters you can't use are ascii 0x00-0x19 (0x20 is space and = is possible through the LWS construct as Christer pointed out). Is there = a practical use case for any of these? They are: HT (horizontal tab) should be included, but that's also in LWS. As for the remaining characters, I don't think that anyone has ever *intended* that they be used in SIP headers, and their inclusion in quoted-pair was a typographical error. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 11:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fif-0000o1-Sh; Fri, 07 Dec 2007 11:06:29 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0fie-0000nt-AQ for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 11:06:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fie-0000nj-0w for sip@ietf.org; Fri, 07 Dec 2007 11:06:28 -0500 Received: from ns7.neustar.com ([156.154.24.88] helo=neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fid-0005jT-KI for sip@ietf.org; Fri, 07 Dec 2007 11:06:28 -0500 Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.2982877; Fri, 07 Dec 2007 11:06:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 11:06:03 -0500 Message-ID: <31D151A3D66E404AACBBB0247ACA54A7029CEB@STNTEXCH11.cis.neustar.com> In-Reply-To: <069501c83772$eac35b50$6e7a150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC4474 and E.164 Thread-Index: Acg3cubjZCbtBfqaQoubFoytikhjbwBdh+3g From: "Peterson, Jon" To: "Dan Wing" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Cullen Jennings Subject: [Sip] RE: RFC4474 and E.164 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm certainly not going to claim that Section 11 of RFC4474, or my older = work in RFC3824, adequately describes the situation with telephone = numbers in SIP today. The sentence you highlight below was intended to = suggest that the appearance of telephone numbers as the user part of a = SIP URI, rather than as a bare TEL URI with no host portion, constitutes = the "majority of cases". It was not making a statement either way about = whether or not SBCs are involved in the majority of calls. The guidance = given in RFC4474 for signing such telephony-related SIP URIs for = Identity is obviously non-optimal when an intermediary such as an SBC = must modify content covered by the signature, but of course, that is = also true for all the rest of the guidance in RFC4474. My primary concern in the microphone discussion was to separate out the = difficulties of managing telephone numbers in this context from (in my = perspective) the unrelated and excessive dilution of necessary security = properties which was proposed to accommodate SBCs. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, December 05, 2007 11:13 AM > To: sip@ietf.org; Peterson, Jon > Cc: 'Jason Fischl'; jdrosen@cisco.com; 'Cullen Jennings' > Subject: RFC4474 and E.164=20 >=20 >=20 > Jon, >=20 > At the microphone I believe you were referring to section 11=20 > of RFC4474. The > first paragraph is relevant to today's discussion in SIP and=20 > I highlighted a > specific sentence. The highlighted sentence does not=20 > consider session border > controllers which, on today's deployments, _are_ the majority of cases > (majority of call minutes and the majority of phone calls): >=20 > 11. Identity and the TEL URI Scheme >=20 > Since many SIP applications provide a Voice over IP (VoIP) service, > telephone numbers are commonly used as identities in SIP=20 > deployments. > In the majority of cases, this is not problematic for the identity > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mechanism described in this document. Telephone numbers commonly > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > appear in the username portion of a SIP URI (e.g., > 'sip:+17005551008@chicago.example.com;user=3Dphone'). That = username > conforms to the syntax of the TEL URI scheme (RFC 3966 [13]). For > this sort of SIP address-of-record, chicago.example.com is the > appropriate signatory. >=20 > The rest of the section is available at: > http://tools.ietf.org/html/rfc4474#section-11 > but discusses only the TEL URI (which has no domain name). >=20 >=20 > We will need more text in Jason's document to discuss this in=20 > more detail. >=20 > -d >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 11:08:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fkS-0004cb-AR; Fri, 07 Dec 2007 11:08:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0fkQ-0004cR-GK for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 11:08:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fkQ-0004cJ-6p for sip@ietf.org; Fri, 07 Dec 2007 11:08:18 -0500 Received: from out003.iad.hostedmail.net ([209.225.56.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fkP-0005rd-V8 for sip@ietf.org; Fri, 07 Dec 2007 11:08:18 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out003.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 11:08:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 11:08:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3515, RFC 4508, RFC 3261: angle bracket requirement Thread-Index: Acg462BWPDGbK5u4SUS/qoou1biMUg== From: "Brett Tate" To: X-OriginalArrivalTime: 07 Dec 2007 16:08:21.0088 (UTC) FILETIME=[63157600:01C838EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] RFC 3515, RFC 4508, RFC 3261: angle bracket requirement X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The following rfc3261 section 20 text defines when a name-addr must be used instead of an addr-spec. However the text currently does not appear generic enough to apply to all headers. RFC 3261 section 20: "The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters." RFC 3515 does not mention the rfc3261 rules. RFC 4508 only mentions the parameter impacts. Does the rfc3261 rule concerning comma and question mark apply to the refer-to header? =20 Does the rfc3261 rule apply to all sip headers defined as containing name-addr or addr-spec? And if so, should the text be update per sip-essential-correction process? If comma and question mark aspects of the rfc3261 text is not relevant Refer-To, what is reason for the difference? Thanks, Brett _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 11:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fwv-00080W-Vl; Fri, 07 Dec 2007 11:21:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0fwu-00080R-DR for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 11:21:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fwu-00080J-2d for sip@ietf.org; Fri, 07 Dec 2007 11:21:12 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0fwt-0006BT-Ie for sip@ietf.org; Fri, 07 Dec 2007 11:21:11 -0500 Received: from [130.129.82.232] (vancouver.ietf.org [130.129.82.232]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id lB7GL8wi015356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2007 10:21:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17CCEE89-5545-4D86-A413-C8C8E4B2F6F5@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] RFC 3515, RFC 4508, RFC 3261: angle bracket requirement Date: Fri, 7 Dec 2007 08:21:07 -0800 To: "Brett Tate" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/5029/Fri Dec 7 08:12:18 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That language is intended to apply to any uses of name-addr. There's a closely related bug captured already: http://bugs.sipit.net/ show_bug.cgi?id=765 RjS On Dec 7, 2007, at 8:08 AM, Brett Tate wrote: > The following rfc3261 section 20 text defines when a name-addr must be > used instead of an addr-spec. However the text currently does not > appear generic enough to apply to all headers. > > RFC 3261 section 20: "The Contact, From, and To header fields > contain a > URI. If the URI contains a comma, question mark or semicolon, the URI > MUST be enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not > URI parameters." > > RFC 3515 does not mention the rfc3261 rules. RFC 4508 only > mentions the > parameter impacts. > > Does the rfc3261 rule concerning comma and question mark apply to the > refer-to header? > > Does the rfc3261 rule apply to all sip headers defined as containing > name-addr or addr-spec? And if so, should the text be update per > sip-essential-correction process? > > If comma and question mark aspects of the rfc3261 text is not relevant > Refer-To, what is reason for the difference? > > Thanks, > Brett > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 13:45:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iCI-0006gF-GE; Fri, 07 Dec 2007 13:45:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0iCH-0006g3-G5 for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 13:45:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0iCH-0006fu-3e for sip@ietf.org; Fri, 07 Dec 2007 13:45:13 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0iCF-0000kH-S6 for sip@ietf.org; Fri, 07 Dec 2007 13:45:12 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 7 Dec 2007 13:45:11 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 7 Dec 2007 13:45:11 -0500 From: Hadriel Kaplan To: Christer Holmberg , Ganesan Sam-W00184 , "sip@ietf.org" Date: Fri, 7 Dec 2007 13:40:43 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/AADmHLUAI/URYA== Message-ID: References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, but I think we do have to recognize there really are use cases that a= re simply wrong to do using INFO. There's nothing the IETF or anyone can d= o to stop people from doing them (there's no RFC interpol), but that doesn'= t mean we should give them explicit blessing either, and a draft such as Er= ic's really is the best we can do if we can't find legitimate use cases. T= hat's why I like Jonathan's proposal for finding good use-cases, which is w= hat I wanted to say at the mic at the end of that debate. There is, though, another aspect to this. As we all know, interoperability= is a major SIP issue, and even if we discourage INFO use we know it will b= e used. So an unresolved question in my mind is whether we should define a= t least how such proprietary use can be signaled, to avoid vendor-specific = static configuration profile proliferation making interop harder. In other= words: not accept draft proposals for INFO use, not be bothered with repea= ting these discussions anymore in the IETF, etc.; but at least give them a = standardized way to negotiate it so their UAs can interoperate with legitim= ate IETF-following UAs without needing configuration. -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, December 06, 2007 8:22 PM > To: Ganesan Sam-W00184; Hadriel Kaplan; sip@ietf.org > Subject: VS: [Sip] INFO use-cases > > Hi, > > Use-case 1: > ----------------- > > One use-case is the transport of user-to-user information, and the reason= s > people don't think it's feasible to establish a media plane connection fo= r > this are (at least): > > 1. The information will not be sent for every call, and when sent the > amount of information is relatively small > 2. In interworking cases the information may be received out-of-band from > the "other side", so it is seen as unfeasible to send it down to the MG - > in some cases the interworking may even be performed without a MG. > > > Use-case 2: > ----------------- > > Pretty much the same arguments are also used for sending DTMF out-of-band= . > In addition there may be intermediate entities, without media access, > which are interested in the DTMF information. > > > (I hope we have understood the arguments why people want to use INFO > instead of SUB/NOT, so I will not go into that again.) > > Regards, > > Christer > > ________________________________ > > L=E4hett=E4j=E4: Ganesan Sam-W00184 [mailto:sam.ganesan@motorola.com] > L=E4hetetty: pe 7.12.2007 1:46 > Vastaanottaja: Hadriel Kaplan; sip@ietf.org > Aihe: RE: [Sip] INFO use-cases > > > I also know of a use case where video npt bookmarks are sent over INFO > across the SIP path while using SIP for video stream set up. Tispan 3 is > actually writing specs on this and so is ATIS... > > > Sam > > ________________________________ > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thu 12/6/2007 6:38 PM > To: sip@ietf.org > Subject: [Sip] INFO use-cases > > > > Howdy, > Jonathan asked for use-cases for what types of things would need an in- > dialog SIP message for user-user communication, vs. should be done either > out of dialog or in the media plane. If the only use-case is DTMF, then > we could just document the DTMF negotiation/use only and not have to > create a general info-events framework. That seems a very reasonable > argument to me. I also don't want to do work for no use. > > There is a counter-argument that there are proprietary uses of INFO in th= e > wild, and that a framework for negotiation at least removes the manual > configuration of vendor-specific profiles, which is a problem of interop > today - even if the IETF should not bless/document the specific use cases > themselves. But that would make the draft a very different one than it > currently is as well, and I will ask that in a separate email thread. > > The chairs have asked for 3 use cases, and I assume they mean 3 NEW use > cases (we already have 3 RFCs which use INFO, as well as DTMF). I am not > sure if they mean potential future use-cases, or current use-cases (i.e., > already implemented). Can I get a clarification on that? > > So anyway, taking the shot-gun approach, here's a first go at some use- > cases, and my personal take on whether they should be in INFO vs. SUB/NOT > vs. media-plane, FWIW. > [apologize for formatting ugliness] > > /*************** > * Already standardized use-cases: > ***************/ > 1) SIP-T/ISUP/QSIG/PSTN > -Documented in RFC 3372 and RFC 4497. > > 2) ECMA TR/87 uaCSTA > -Uses INFO to send ECMA-323 XML for monitoring and controlling > phones from a PC. > > 3) Sending media server control commands. > -Documented in RFC4722 MSCML. > > > /**************** > * Use-cases that I think are potentially/possibly valid for INFO: > ****************/ > 1) Sending a vcard asynchronously. Alice calls Bob, Alice says "can you > send me John's vcard?", Bob clicks something and voila it's sent. > -Alternatives: send a re-Invite or Update with a Call-Info, with > either a URL reference, data URI, or MIME and CID URL. > -Counter-argument: IMO this type of data really belongs in MIME > for a number of reasons, including length is less restricted for mime > attachments; one AD has said the Data URL may be deprecated. And sending > a re-Invite for this purpose seems odd. > > -Also, the Call-Info header is really about the caller or callee, > and thus Bob shouldn't be sending me John's vcard info in it technically. > That may sound like a nit, but UA's may well store the call-info vcards > into their address-books automatically and so tie it to the wrong > user/call. > -Pros of using INFO: it's explicit what you're doing when you sen= d > the vcard, and you can send it knowing the other end can accept it, and > you can send it based on user input. > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an icon > that represents himself, sends it when he picks up the phone. > -Alternatives: send a 200ok, re-Invite, or Update with call-info, > which explicitly has a type for icon. > -Counter-argument: same as for vcard, plus with call-info there i= s > no way to know which picture format the far-end supports a priori. With = a > supported-package negotiation one could know. > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says "hey > let's have a con call at time X", clicks and voila his phone sends a > vcalendar. > -Whether the vcalendar is related to the session or not and thus > whether it should be sent in an in-dialog request or not is certainly > debatable. Message method can already be used for this anyway. > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for mor= e > info or a datasheet and Bob sends a URL for Alice to open with her web- > browser. > -One could also argue this is just making SIP the new SMTP, or > this should be sent using MESSAGE (which really is the new SMTP). > > 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice doe= s > a sip-traceroute to figure out the path to Bob, by sending Info with an > incrementing max-forwards type header starting at 0 (but not really max- > forwards), with a sip-frag type response body or some such. > -It's debatable if certain types of B2BUA's (ie, SBCs) would ever > allow this type of thing to happen, due to security concerns, but I think > they may do it at domain boundary hops. I think this is a reasonable use > for INFO though, maybe. > > 6) Sending geo-location information after call establishment. Alice call= s > Bob, a hotel receptionist. Alice asks for directions to hotel, clicks > button and sends him location info of her phone (or Bob clicks button and > sends her his location). > -The location conveyance draft specifically calls out INFO as > acceptable for geo-loc info. Whether this is a real use-case is > debatable, and obviously it could be done with a sub/not. > > 7) Sending softkey-labels (not digit-match maps, but rather softkey butto= n > labels). Alice calls her vmail server. Vmail server sends softkey-label= s > for the menu items available in the response, Alice presses softkeys and > sends them in INFO. > -This could (and maybe should) be done with sub/not, a la KPML, > where the vmail server sends the softkey labels in the Subscribe, UA send= s > buttons pressed in Notifies. But this is similar to the DTMF use case so > may well have the same benefit of lower overhead since buttons are rarely > pressed. > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue with > this session?" > -There is a patent for doing screen pop-ups using INFO. I guess > Alert-Info could be used for this, but it's not clear it should? > > > /***************** > * Use-cases which have been proposed by others or even implemented, > * which are dubious for INFO (IMHO): > *****************/ > 1) Sending RTP/RTCP statistics during call. > -There is an implementation of this, and the rationale is the > signaling plane box that wants this info is not actually the media plane > box that gets RTCP. Again this could (and IMO should) be done with > sub/not, so it can get stats after the call is over, and since it will > probably want periodic reports the overhead of the Subscribe should be > dwarfed by the number of Notifies. > > 2) Sending access-location information after call establishment. > -There is a P-Access-Network-Info header, and some have proposed > to send an update for it as a phone roams access points or cells. But I > think this is an odd thing to do inside an Invite session, vs. in a > sub/not or Register (and besides half the time the network inserts this > header, not the UA). > > 3) Sending media-control indications (ie, remote-control > "play/pause/etc.") > -This is done today by at least one vendor, but is debatable if > it's the right model. The argument is it's like SDP re-Invite for hold, > except at a media content layer above RTP, so not done in RTCP nor SDP. > > 4) Sending video fast update command > -This is an informational draft, which documents what has been > implemented, but states it should really be done in the media plane. > > 5) Sending peripheral control commands (ie, USB commands) > -There is actually a patent on this, amazingly. Someone thinks i= t > makes sense to create a SIP session to your laptop, or vice-versa, and > then send USB commands inside MIME in INFO messages. Methinks this shoul= d > be media-plane, if anything. > > 6) Sending charging information for a call (i.e., minutes remaining or > cost so far). > -There was a proposal to use this for Advice of Charge informatio= n > in TISPAN. IMO it should be a sub/not though, as they want this to > survive the Invite session. > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 14:13:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0icw-0004lG-RS; Fri, 07 Dec 2007 14:12:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0icu-0004j3-HD for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:12:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ict-0004gn-Ls for sip@ietf.org; Fri, 07 Dec 2007 14:12:43 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ics-0003Sh-Fp for sip@ietf.org; Fri, 07 Dec 2007 14:12:43 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB7JCTqM013541; Fri, 7 Dec 2007 13:12:34 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 13:12:33 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 20:12:31 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 20:12:35 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019F7590@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases Thread-index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/AADmHLUAJa29AA== References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> From: "DRAGE, Keith \(Keith\)" To: "Christer Holmberg" , "Ganesan Sam-W00184" , "Hadriel Kaplan" , X-OriginalArrivalTime: 07 Dec 2007 19:12:31.0512 (UTC) FILETIME=[1DA65980:01C83905] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In regard to your use case 1, then if we follow the Alan Johnston draft, = this would be a header being transported rather than a body, whereas all = the cases we have been discussing so far have been message body = transport issues. If you mean something different, then it would be = probably be better to use a different term that "user to user". Regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, December 07, 2007 1:22 AM > To: Ganesan Sam-W00184; Hadriel Kaplan; sip@ietf.org > Subject: VS: [Sip] INFO use-cases >=20 > Hi, > =20 > Use-case 1: > ----------------- > =20 > One use-case is the transport of user-to-user information,=20 > and the reasons people don't think it's feasible to establish=20 > a media plane connection for this are (at least): > =20 > 1. The information will not be sent for every call, and when=20 > sent the amount of information is relatively small 2. In=20 > interworking cases the information may be received=20 > out-of-band from the "other side", so it is seen as=20 > unfeasible to send it down to the MG - in some cases the=20 > interworking may even be performed without a MG. > =20 > =20 > Use-case 2: > ----------------- > =20 > Pretty much the same arguments are also used for sending DTMF=20 > out-of-band. In addition there may be intermediate entities,=20 > without media access, which are interested in the DTMF information. > =20 > =20 > (I hope we have understood the arguments why people want to=20 > use INFO instead of SUB/NOT, so I will not go into that again.) > =20 > Regards, > =20 > Christer >=20 > ________________________________ >=20 > L=E4hett=E4j=E4: Ganesan Sam-W00184 [mailto:sam.ganesan@motorola.com] > L=E4hetetty: pe 7.12.2007 1:46 > Vastaanottaja: Hadriel Kaplan; sip@ietf.org > Aihe: RE: [Sip] INFO use-cases >=20 >=20 > I also know of a use case where video npt bookmarks are sent=20 > over INFO across the SIP path while using SIP for video=20 > stream set up. Tispan 3 is actually writing specs on this=20 > and so is ATIS... =20 > =20 > =20 > Sam >=20 > ________________________________ >=20 > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thu 12/6/2007 6:38 PM > To: sip@ietf.org > Subject: [Sip] INFO use-cases >=20 >=20 >=20 > Howdy, > Jonathan asked for use-cases for what types of things would=20 > need an in-dialog SIP message for user-user communication,=20 > vs. should be done either out of dialog or in the media=20 > plane. If the only use-case is DTMF, then we could just=20 > document the DTMF negotiation/use only and not have to create=20 > a general info-events framework. That seems a very=20 > reasonable argument to me. I also don't want to do work for no use. >=20 > There is a counter-argument that there are proprietary uses=20 > of INFO in the wild, and that a framework for negotiation at=20 > least removes the manual configuration of vendor-specific=20 > profiles, which is a problem of interop today - even if the=20 > IETF should not bless/document the specific use cases=20 > themselves. But that would make the draft a very different=20 > one than it currently is as well, and I will ask that in a=20 > separate email thread. >=20 > The chairs have asked for 3 use cases, and I assume they mean=20 > 3 NEW use cases (we already have 3 RFCs which use INFO, as=20 > well as DTMF). I am not sure if they mean potential future=20 > use-cases, or current use-cases (i.e., already implemented). =20 > Can I get a clarification on that? >=20 > So anyway, taking the shot-gun approach, here's a first go at=20 > some use-cases, and my personal take on whether they should=20 > be in INFO vs. SUB/NOT vs. media-plane, FWIW. > [apologize for formatting ugliness] >=20 > /*************** > * Already standardized use-cases: > ***************/ > 1) SIP-T/ISUP/QSIG/PSTN > -Documented in RFC 3372 and RFC 4497. >=20 > 2) ECMA TR/87 uaCSTA > -Uses INFO to send ECMA-323 XML for monitoring and=20 > controlling phones from a PC. >=20 > 3) Sending media server control commands. > -Documented in RFC4722 MSCML. >=20 >=20 > /**************** > * Use-cases that I think are potentially/possibly valid for INFO: > ****************/ > 1) Sending a vcard asynchronously. Alice calls Bob, Alice=20 > says "can you send me John's vcard?", Bob clicks something=20 > and voila it's sent. > -Alternatives: send a re-Invite or Update with a=20 > Call-Info, with either a URL reference, data URI, or MIME and CID URL. > -Counter-argument: IMO this type of data really=20 > belongs in MIME for a number of reasons, including length is=20 > less restricted for mime attachments; one AD has said the=20 > Data URL may be deprecated. And sending a re-Invite for this=20 > purpose seems odd. > -Also, the Call-Info header is really about the=20 > caller or callee, and thus Bob shouldn't be sending me John's=20 > vcard info in it technically. That may sound like a nit, but=20 > UA's may well store the call-info vcards into their=20 > address-books automatically and so tie it to the wrong user/call. > -Pros of using INFO: it's explicit what you're doing=20 > when you send the vcard, and you can send it knowing the=20 > other end can accept it, and you can send it based on user input. >=20 > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob=20 > has an icon that represents himself, sends it when he picks=20 > up the phone. > -Alternatives: send a 200ok, re-Invite, or Update=20 > with call-info, which explicitly has a type for icon. > -Counter-argument: same as for vcard, plus with=20 > call-info there is no way to know which picture format the=20 > far-end supports a priori. With a supported-package=20 > negotiation one could know. >=20 > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob=20 > says "hey let's have a con call at time X", clicks and voila=20 > his phone sends a vcalendar. > -Whether the vcalendar is related to the session or=20 > not and thus whether it should be sent in an in-dialog=20 > request or not is certainly debatable. Message method can=20 > already be used for this anyway. >=20 > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice=20 > asks for more info or a datasheet and Bob sends a URL for=20 > Alice to open with her web-browser. > -One could also argue this is just making SIP the new=20 > SMTP, or this should be sent using MESSAGE (which really is=20 > the new SMTP). >=20 > 5) Sending a session traceroute. Alice calls Bob, Bob=20 > answers, Alice does a sip-traceroute to figure out the path=20 > to Bob, by sending Info with an incrementing max-forwards=20 > type header starting at 0 (but not really max-forwards), with=20 > a sip-frag type response body or some such. > -It's debatable if certain types of B2BUA's (ie,=20 > SBCs) would ever allow this type of thing to happen, due to=20 > security concerns, but I think they may do it at domain=20 > boundary hops. I think this is a reasonable use for INFO=20 > though, maybe. >=20 > 6) Sending geo-location information after call establishment.=20 > Alice calls Bob, a hotel receptionist. Alice asks for=20 > directions to hotel, clicks button and sends him location=20 > info of her phone (or Bob clicks button and sends her his location). > -The location conveyance draft specifically calls out=20 > INFO as acceptable for geo-loc info. Whether this is a real=20 > use-case is debatable, and obviously it could be done with a sub/not. >=20 > 7) Sending softkey-labels (not digit-match maps, but rather=20 > softkey button labels). Alice calls her vmail server. Vmail=20 > server sends softkey-labels for the menu items available in=20 > the response, Alice presses softkeys and sends them in INFO. > -This could (and maybe should) be done with sub/not,=20 > a la KPML, where the vmail server sends the softkey labels in=20 > the Subscribe, UA sends buttons pressed in Notifies. But=20 > this is similar to the DTMF use case so may well have the=20 > same benefit of lower overhead since buttons are rarely pressed. >=20 > 8) Sending a screen-pop-up message, e.g., "Do you want to=20 > continue with this session?" > -There is a patent for doing screen pop-ups using=20 > INFO. I guess Alert-Info could be used for this, but it's=20 > not clear it should? >=20 >=20 > /***************** > * Use-cases which have been proposed by others or even implemented, > * which are dubious for INFO (IMHO): > *****************/ > 1) Sending RTP/RTCP statistics during call. > -There is an implementation of this, and the=20 > rationale is the signaling plane box that wants this info is=20 > not actually the media plane box that gets RTCP. Again this=20 > could (and IMO should) be done with sub/not, so it can get=20 > stats after the call is over, and since it will probably want=20 > periodic reports the overhead of the Subscribe should be=20 > dwarfed by the number of Notifies. >=20 > 2) Sending access-location information after call establishment. > -There is a P-Access-Network-Info header, and some=20 > have proposed to send an update for it as a phone roams=20 > access points or cells. But I think this is an odd thing to=20 > do inside an Invite session, vs. in a sub/not or Register=20 > (and besides half the time the network inserts this header,=20 > not the UA). >=20 > 3) Sending media-control indications (ie, remote-control=20 > "play/pause/etc.") > -This is done today by at least one vendor, but is=20 > debatable if it's the right model. The argument is it's like=20 > SDP re-Invite for hold, except at a media content layer above=20 > RTP, so not done in RTCP nor SDP. >=20 > 4) Sending video fast update command > -This is an informational draft, which documents what=20 > has been implemented, but states it should really be done in=20 > the media plane. >=20 > 5) Sending peripheral control commands (ie, USB commands) > -There is actually a patent on this, amazingly. =20 > Someone thinks it makes sense to create a SIP session to your=20 > laptop, or vice-versa, and then send USB commands inside MIME=20 > in INFO messages. Methinks this should be media-plane, if anything. >=20 > 6) Sending charging information for a call (i.e., minutes=20 > remaining or cost so far). > -There was a proposal to use this for Advice of=20 > Charge information in TISPAN. IMO it should be a sub/not=20 > though, as they want this to survive the Invite session. >=20 > -hadriel >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 14:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0it4-0004cg-SI; Fri, 07 Dec 2007 14:29:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0it3-0004aq-D9 for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:29:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0it3-0004aY-3L for sip@ietf.org; Fri, 07 Dec 2007 14:29:25 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0it0-0004RW-C3 for sip@ietf.org; Fri, 07 Dec 2007 14:29:25 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E213121FA6; Fri, 7 Dec 2007 20:28:31 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-4f-47599edf8803 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CD0BF21FE1; Fri, 7 Dec 2007 20:28:31 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 19:55:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 19:55:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/AADmHLUAI/URYAABF2PQ References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Ganesan Sam-W00184" , X-OriginalArrivalTime: 07 Dec 2007 18:55:37.0420 (UTC) FILETIME=[C13430C0:01C83902] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >Yeah, but I think we do have to recognize there really are=20 >use cases that are simply wrong to do using INFO. I agree. I've never said anything else :) >There's nothing the IETF or anyone can do to stop people from doing=20 >them (there's no RFC interpol), but that doesn't mean we=20 >should give them explicit blessing either, and a draft such=20 >as Eric's really is the best we can do if we can't find=20 >legitimate use cases. That's why I like Jonathan's proposal=20 >for finding good use-cases, which is what I wanted to say at=20 >the mic at the end of that debate. Yes, and that is what we are trying to do now. The two use-cases I gave I believe are valid use-cases for INFO. Or, was your mail a reply to Sam's mail? Regards, Christer >=20 > There is, though, another aspect to this. As we all know,=20 > interoperability is a major SIP issue, and even if we=20 > discourage INFO use we know it will be used. So an=20 > unresolved question in my mind is whether we should define at=20 > least how such proprietary use can be signaled, to avoid=20 > vendor-specific static configuration profile proliferation=20 > making interop harder. In other words: not accept draft=20 > proposals for INFO use, not be bothered with repeating these=20 > discussions anymore in the IETF, etc.; but at least give them=20 > a standardized way to negotiate it so their UAs can=20 > interoperate with legitimate IETF-following UAs without=20 > needing configuration. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, December 06, 2007 8:22 PM > > To: Ganesan Sam-W00184; Hadriel Kaplan; sip@ietf.org > > Subject: VS: [Sip] INFO use-cases > > > > Hi, > > > > Use-case 1: > > ----------------- > > > > One use-case is the transport of user-to-user information, and the=20 > > reasons people don't think it's feasible to establish a media plane=20 > > connection for this are (at least): > > > > 1. The information will not be sent for every call, and=20 > when sent the=20 > > amount of information is relatively small 2. In=20 > interworking cases the=20 > > information may be received out-of-band from the "other=20 > side", so it=20 > > is seen as unfeasible to send it down to the MG - in some cases the=20 > > interworking may even be performed without a MG. > > > > > > Use-case 2: > > ----------------- > > > > Pretty much the same arguments are also used for sending=20 > DTMF out-of-band. > > In addition there may be intermediate entities, without=20 > media access,=20 > > which are interested in the DTMF information. > > > > > > (I hope we have understood the arguments why people want to=20 > use INFO=20 > > instead of SUB/NOT, so I will not go into that again.) > > > > Regards, > > > > Christer > > > > ________________________________ > > > > L=E4hett=E4j=E4: Ganesan Sam-W00184 = [mailto:sam.ganesan@motorola.com] > > L=E4hetetty: pe 7.12.2007 1:46 > > Vastaanottaja: Hadriel Kaplan; sip@ietf.org > > Aihe: RE: [Sip] INFO use-cases > > > > > > I also know of a use case where video npt bookmarks are=20 > sent over INFO=20 > > across the SIP path while using SIP for video stream set=20 > up. Tispan 3=20 > > is actually writing specs on this and so is ATIS... > > > > > > Sam > > > > ________________________________ > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Thu 12/6/2007 6:38 PM > > To: sip@ietf.org > > Subject: [Sip] INFO use-cases > > > > > > > > Howdy, > > Jonathan asked for use-cases for what types of things would need an=20 > > in- dialog SIP message for user-user communication, vs.=20 > should be done=20 > > either out of dialog or in the media plane. If the only=20 > use-case is=20 > > DTMF, then we could just document the DTMF negotiation/use only and=20 > > not have to create a general info-events framework. That=20 > seems a very=20 > > reasonable argument to me. I also don't want to do work for no use. > > > > There is a counter-argument that there are proprietary uses=20 > of INFO in=20 > > the wild, and that a framework for negotiation at least removes the=20 > > manual configuration of vendor-specific profiles, which is=20 > a problem=20 > > of interop today - even if the IETF should not bless/document the=20 > > specific use cases themselves. But that would make the=20 > draft a very=20 > > different one than it currently is as well, and I will ask=20 > that in a separate email thread. > > > > The chairs have asked for 3 use cases, and I assume they mean 3 NEW=20 > > use cases (we already have 3 RFCs which use INFO, as well=20 > as DTMF). I=20 > > am not sure if they mean potential future use-cases, or current=20 > > use-cases (i.e., already implemented). Can I get a=20 > clarification on that? > > > > So anyway, taking the shot-gun approach, here's a first go at some=20 > > use- cases, and my personal take on whether they should be=20 > in INFO vs.=20 > > SUB/NOT vs. media-plane, FWIW. > > [apologize for formatting ugliness] > > > > /*************** > > * Already standardized use-cases: > > ***************/ > > 1) SIP-T/ISUP/QSIG/PSTN > > -Documented in RFC 3372 and RFC 4497. > > > > 2) ECMA TR/87 uaCSTA > > -Uses INFO to send ECMA-323 XML for monitoring and=20 > controlling=20 > > phones from a PC. > > > > 3) Sending media server control commands. > > -Documented in RFC4722 MSCML. > > > > > > /**************** > > * Use-cases that I think are potentially/possibly valid for INFO: > > ****************/ > > 1) Sending a vcard asynchronously. Alice calls Bob, Alice=20 > says "can=20 > > you send me John's vcard?", Bob clicks something and voila=20 > it's sent. > > -Alternatives: send a re-Invite or Update with a Call-Info,=20 > > with either a URL reference, data URI, or MIME and CID URL. > > -Counter-argument: IMO this type of data really belongs in=20 > > MIME for a number of reasons, including length is less=20 > restricted for=20 > > mime attachments; one AD has said the Data URL may be=20 > deprecated. And=20 > > sending a re-Invite for this purpose seems odd. > > > > -Also, the Call-Info header is really about the caller or=20 > > callee, and thus Bob shouldn't be sending me John's vcard=20 > info in it technically. > > That may sound like a nit, but UA's may well store the call-info=20 > > vcards into their address-books automatically and so tie it to the=20 > > wrong user/call. > > -Pros of using INFO: it's explicit what you're=20 > doing when you=20 > > send the vcard, and you can send it knowing the other end=20 > can accept=20 > > it, and you can send it based on user input. > > > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob,=20 > Bob has an=20 > > icon that represents himself, sends it when he picks up the phone. > > -Alternatives: send a 200ok, re-Invite, or Update with=20 > > call-info, which explicitly has a type for icon. > > -Counter-argument: same as for vcard, plus with call-info=20 > > there is no way to know which picture format the far-end supports a=20 > > priori. With a supported-package negotiation one could know. > > > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says=20 > > "hey let's have a con call at time X", clicks and voila his phone=20 > > sends a vcalendar. > > -Whether the vcalendar is related to the session or not and=20 > > thus whether it should be sent in an in-dialog request or not is=20 > > certainly debatable. Message method can already be used=20 > for this anyway. > > > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy;=20 > Alice asks for=20 > > more info or a datasheet and Bob sends a URL for Alice to open with=20 > > her web- browser. > > -One could also argue this is just making SIP the=20 > new SMTP, or=20 > > this should be sent using MESSAGE (which really is the new SMTP). > > > > 5) Sending a session traceroute. Alice calls Bob, Bob=20 > answers, Alice=20 > > does a sip-traceroute to figure out the path to Bob, by=20 > sending Info=20 > > with an incrementing max-forwards type header starting at 0=20 > (but not=20 > > really max- forwards), with a sip-frag type response body=20 > or some such. > > -It's debatable if certain types of B2BUA's (ie,=20 > SBCs) would=20 > > ever allow this type of thing to happen, due to security=20 > concerns, but=20 > > I think they may do it at domain boundary hops. I think this is a=20 > > reasonable use for INFO though, maybe. > > > > 6) Sending geo-location information after call=20 > establishment. Alice=20 > > calls Bob, a hotel receptionist. Alice asks for directions=20 > to hotel,=20 > > clicks button and sends him location info of her phone (or=20 > Bob clicks=20 > > button and sends her his location). > > -The location conveyance draft specifically calls=20 > out INFO as=20 > > acceptable for geo-loc info. Whether this is a real use-case is=20 > > debatable, and obviously it could be done with a sub/not. > > > > 7) Sending softkey-labels (not digit-match maps, but rather softkey=20 > > button labels). Alice calls her vmail server. Vmail server sends=20 > > softkey-labels for the menu items available in the response, Alice=20 > > presses softkeys and sends them in INFO. > > -This could (and maybe should) be done with sub/not, a la=20 > > KPML, where the vmail server sends the softkey labels in the=20 > > Subscribe, UA sends buttons pressed in Notifies. But this=20 > is similar=20 > > to the DTMF use case so may well have the same benefit of lower=20 > > overhead since buttons are rarely pressed. > > > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue=20 > > with this session?" > > -There is a patent for doing screen pop-ups using INFO. I=20 > > guess Alert-Info could be used for this, but it's not clear=20 > it should? > > > > > > /***************** > > * Use-cases which have been proposed by others or even implemented, > > * which are dubious for INFO (IMHO): > > *****************/ > > 1) Sending RTP/RTCP statistics during call. > > -There is an implementation of this, and the=20 > rationale is the=20 > > signaling plane box that wants this info is not actually the media=20 > > plane box that gets RTCP. Again this could (and IMO=20 > should) be done=20 > > with sub/not, so it can get stats after the call is over,=20 > and since it=20 > > will probably want periodic reports the overhead of the Subscribe=20 > > should be dwarfed by the number of Notifies. > > > > 2) Sending access-location information after call establishment. > > -There is a P-Access-Network-Info header, and some have=20 > > proposed to send an update for it as a phone roams access points or=20 > > cells. But I think this is an odd thing to do inside an Invite=20 > > session, vs. in a sub/not or Register (and besides half the=20 > time the=20 > > network inserts this header, not the UA). > > > > 3) Sending media-control indications (ie, remote-control > > "play/pause/etc.") > > -This is done today by at least one vendor, but is=20 > debatable=20 > > if it's the right model. The argument is it's like SDP=20 > re-Invite for=20 > > hold, except at a media content layer above RTP, so not=20 > done in RTCP nor SDP. > > > > 4) Sending video fast update command > > -This is an informational draft, which documents=20 > what has been=20 > > implemented, but states it should really be done in the media plane. > > > > 5) Sending peripheral control commands (ie, USB commands) > > -There is actually a patent on this, amazingly. Someone=20 > > thinks it makes sense to create a SIP session to your laptop, or=20 > > vice-versa, and then send USB commands inside MIME in INFO=20 > messages. =20 > > Methinks this should be media-plane, if anything. > > > > 6) Sending charging information for a call (i.e., minutes=20 > remaining or=20 > > cost so far). > > -There was a proposal to use this for Advice of Charge=20 > > information in TISPAN. IMO it should be a sub/not though, as they=20 > > want this to survive the Invite session. > > > > -hadriel > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 14:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ixO-0002W4-4g; Fri, 07 Dec 2007 14:33:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0ixN-0002Vr-5N for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:33:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ixM-0002Vj-Qj for sip@ietf.org; Fri, 07 Dec 2007 14:33:52 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0ixM-000419-D8 for sip@ietf.org; Fri, 07 Dec 2007 14:33:52 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lB7JXLCe014304; Fri, 7 Dec 2007 13:33:26 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 13:33:21 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 20:33:19 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2007 20:33:19 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180019F7594@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-sip-fork-loop-fix-06 Thread-index: Acg5CAVYvVaurdFmT0G+mU6ExOtR0A== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 07 Dec 2007 19:33:19.0676 (UTC) FILETIME=[059D0FC0:01C83908] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: alan.ietf@polyphase.ca, slawrence@bluesocket.com Subject: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) This document has a somewhat complicated history, in that we completed it once in the WG and sent it to the IESG, but it came back from them because of concerns over security issues. The editor's have now followed the instructions from the previous meeting, i.e. to: Integrated Max-Breadth based on working group discussion of the secdir review Added a paragraph pointing out that removing or modifying other node's branch parameters defeats their ability to loop detect Moved the total number of messages from O(2^70) to O(2^71) based on an observation by Jan Kolomaznik. To see this, note that the total number of requests is the sum from i=3D0 to Max-Forwards of 2^i which is 2^(Max-Forwards+1) - 1. The point of the text doesn't change - (the point being that the number is _big_). Made the new 4xx concrete (choosing 440) Added a sentence reinforcing that if you forward to only one branch, you still potentially have a constant multiplier of messages in the network as Max-Forwards runs out (based on feedback from Thomas Cross.) These changes are significant enough to justify a revised WGLC, and I would therefore like the working group to review the document and provide comments to the SIP list and authors by=20 Friday 21st December 2007.=20 It would be appropriate to concentrate on the text with the changes identified about. The document may be found at: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-06.txt And the wdiff document may be found at: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dhttp://tools.iet= f.o rg/id/draft-ietf-sip-fork-loop-fix-06.txt [Note that unfortunately this identifies a significant portion of text as new text, when it fact it merely moved.] Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 14:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0izh-0004zI-4F; Fri, 07 Dec 2007 14:36:17 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0izg-0004z8-9h for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:36:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0izf-0004z0-Nf for sip@ietf.org; Fri, 07 Dec 2007 14:36:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0izf-0004gf-8J for sip@ietf.org; Fri, 07 Dec 2007 14:36:15 -0500 Received: from [130.129.20.184] (dhcp-14b8.ietf70.org [130.129.20.184]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB7JaA8H028373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Dec 2007 13:36:12 -0600 In-Reply-To: References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DB733B8-4F76-4539-9AF0-A654EFED1033@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO use-cases Date: Fri, 7 Dec 2007 13:36:08 -0600 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 7, 2007, at 12:40 PM, Hadriel Kaplan wrote: > > There is, though, another aspect to this. As we all know, > interoperability is a major SIP issue, and even if we discourage > INFO use we know it will be used. So an unresolved question in my > mind is whether we should define at least how such proprietary use > can be signaled, to avoid vendor-specific static configuration > profile proliferation making interop harder. In other words: not > accept draft proposals for INFO use, not be bothered with repeating > these discussions anymore in the IETF, etc.; but at least give them > a standardized way to negotiate it so their UAs can interoperate > with legitimate IETF-following UAs without needing configuration. > I agree completely. There are arguably some good uses for INFO, and very likely there will be people who choose to do very silly things with it. I really don't want to waste SIP working group time deciding which are which. I just want to set up a framework that keeps all these uses, good or bad, silly or ingenious, from stepping on each other. The only question in my mind is whether the registry for INFO package names should be "specification required" or "First come, first served". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 16:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kQ2-0005tj-Jt; Fri, 07 Dec 2007 16:07:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0kQ0-0005pY-Sh for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 16:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0kQ0-0005n6-I2 for sip@ietf.org; Fri, 07 Dec 2007 16:07:32 -0500 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0kQ0-0002PD-Be for sip@ietf.org; Fri, 07 Dec 2007 16:07:32 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Dec 2007 16:07:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Date: Fri, 7 Dec 2007 16:07:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00 Thread-Index: Acg29s54K2uSMgVsQq+p+ys7MgzBFwAbRvRQABXJFjAAGp63IAAU71TAACSvjAA= From: "Brett Tate" To: "Jane Jiang" , X-OriginalArrivalTime: 07 Dec 2007 21:07:36.0691 (UTC) FILETIME=[31750C30:01C83915] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Though IPv6 was initially designed to address the IP address=20 > space issue, I feel like the mobility feature afforded by=20 > IPv6 address design is a true value added. =20 >=20 > When we are mapping from IPv6 to IPv4, we will certainly=20 > loose some information. However, when we are mapping from=20 > IPv4 to IPv6, how can we expand the digits in a way that we=20 > can actually make the mapped IPv6 address to support=20 > mobility? The IPv6 mobility topic would likely be beyond intended purpose of the draft. Your question would potentially be relevant to draft-ietf-sipping-v6-transition. =20 If IPv6 mobility has impacts upon SIP which have not been analyzed within SIPPING or another working group, the community would likely welcome the analysis even if it doesn't produce new SIP related requirements. Thanks, Brett _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 07 21:39:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pau-00021F-Az; Fri, 07 Dec 2007 21:39:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J0pas-000217-Ht for sip-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 21:39:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0pas-00020z-5R for sip@ietf.org; Fri, 07 Dec 2007 21:39:06 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0paq-0000HB-Pp for sip@ietf.org; Fri, 07 Dec 2007 21:39:06 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 7 Dec 2007 21:39:04 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 7 Dec 2007 21:39:04 -0500 From: Hadriel Kaplan To: Christer Holmberg , Ganesan Sam-W00184 , "sip@ietf.org" Date: Fri, 7 Dec 2007 21:38:53 -0500 Subject: RE: [Sip] INFO use-cases Thread-Topic: [Sip] INFO use-cases Thread-Index: Acg3ydNeNz+dQlO5QPavx5sRH0hBKgAoLYO/AADmHLUAI/URYAABF2PQAA/ItuA= Message-ID: References: <0A7B3E4DF2B4484F933C26AE3DF6F74E01EE66F5@de01exm62.ds.mot.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry I should have clarified - meant that just as a general comment, but p= artly because I thought you were saying anything fitting into your use-case= -1 would qualify as legitimate use. I didn't mean to imply you weren't in agreement. :) -hadriel > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, December 07, 2007 1:56 PM > To: Hadriel Kaplan; Ganesan Sam-W00184; sip@ietf.org > Subject: RE: [Sip] INFO use-cases > > > Hi, > > >Yeah, but I think we do have to recognize there really are > >use cases that are simply wrong to do using INFO. > > I agree. I've never said anything else :) > > >There's nothing the IETF or anyone can do to stop people from doing > >them (there's no RFC interpol), but that doesn't mean we > >should give them explicit blessing either, and a draft such > >as Eric's really is the best we can do if we can't find > >legitimate use cases. That's why I like Jonathan's proposal > >for finding good use-cases, which is what I wanted to say at > >the mic at the end of that debate. > > Yes, and that is what we are trying to do now. > > The two use-cases I gave I believe are valid use-cases for INFO. > > Or, was your mail a reply to Sam's mail? > > Regards, > > Christer > > > > > > > > > > There is, though, another aspect to this. As we all know, > > interoperability is a major SIP issue, and even if we > > discourage INFO use we know it will be used. So an > > unresolved question in my mind is whether we should define at > > least how such proprietary use can be signaled, to avoid > > vendor-specific static configuration profile proliferation > > making interop harder. In other words: not accept draft > > proposals for INFO use, not be bothered with repeating these > > discussions anymore in the IETF, etc.; but at least give them > > a standardized way to negotiate it so their UAs can > > interoperate with legitimate IETF-following UAs without > > needing configuration. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, December 06, 2007 8:22 PM > > > To: Ganesan Sam-W00184; Hadriel Kaplan; sip@ietf.org > > > Subject: VS: [Sip] INFO use-cases > > > > > > Hi, > > > > > > Use-case 1: > > > ----------------- > > > > > > One use-case is the transport of user-to-user information, and the > > > reasons people don't think it's feasible to establish a media plane > > > connection for this are (at least): > > > > > > 1. The information will not be sent for every call, and > > when sent the > > > amount of information is relatively small 2. In > > interworking cases the > > > information may be received out-of-band from the "other > > side", so it > > > is seen as unfeasible to send it down to the MG - in some cases the > > > interworking may even be performed without a MG. > > > > > > > > > Use-case 2: > > > ----------------- > > > > > > Pretty much the same arguments are also used for sending > > DTMF out-of-band. > > > In addition there may be intermediate entities, without > > media access, > > > which are interested in the DTMF information. > > > > > > > > > (I hope we have understood the arguments why people want to > > use INFO > > > instead of SUB/NOT, so I will not go into that again.) > > > > > > Regards, > > > > > > Christer > > > > > > ________________________________ > > > > > > L=E4hett=E4j=E4: Ganesan Sam-W00184 [mailto:sam.ganesan@motorola.com] > > > L=E4hetetty: pe 7.12.2007 1:46 > > > Vastaanottaja: Hadriel Kaplan; sip@ietf.org > > > Aihe: RE: [Sip] INFO use-cases > > > > > > > > > I also know of a use case where video npt bookmarks are > > sent over INFO > > > across the SIP path while using SIP for video stream set > > up. Tispan 3 > > > is actually writing specs on this and so is ATIS... > > > > > > > > > Sam > > > > > > ________________________________ > > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Thu 12/6/2007 6:38 PM > > > To: sip@ietf.org > > > Subject: [Sip] INFO use-cases > > > > > > > > > > > > Howdy, > > > Jonathan asked for use-cases for what types of things would need an > > > in- dialog SIP message for user-user communication, vs. > > should be done > > > either out of dialog or in the media plane. If the only > > use-case is > > > DTMF, then we could just document the DTMF negotiation/use only and > > > not have to create a general info-events framework. That > > seems a very > > > reasonable argument to me. I also don't want to do work for no use. > > > > > > There is a counter-argument that there are proprietary uses > > of INFO in > > > the wild, and that a framework for negotiation at least removes the > > > manual configuration of vendor-specific profiles, which is > > a problem > > > of interop today - even if the IETF should not bless/document the > > > specific use cases themselves. But that would make the > > draft a very > > > different one than it currently is as well, and I will ask > > that in a separate email thread. > > > > > > The chairs have asked for 3 use cases, and I assume they mean 3 NEW > > > use cases (we already have 3 RFCs which use INFO, as well > > as DTMF). I > > > am not sure if they mean potential future use-cases, or current > > > use-cases (i.e., already implemented). Can I get a > > clarification on that? > > > > > > So anyway, taking the shot-gun approach, here's a first go at some > > > use- cases, and my personal take on whether they should be > > in INFO vs. > > > SUB/NOT vs. media-plane, FWIW. > > > [apologize for formatting ugliness] > > > > > > /*************** > > > * Already standardized use-cases: > > > ***************/ > > > 1) SIP-T/ISUP/QSIG/PSTN > > > -Documented in RFC 3372 and RFC 4497. > > > > > > 2) ECMA TR/87 uaCSTA > > > -Uses INFO to send ECMA-323 XML for monitoring and > > controlling > > > phones from a PC. > > > > > > 3) Sending media server control commands. > > > -Documented in RFC4722 MSCML. > > > > > > > > > /**************** > > > * Use-cases that I think are potentially/possibly valid for INFO: > > > ****************/ > > > 1) Sending a vcard asynchronously. Alice calls Bob, Alice > > says "can > > > you send me John's vcard?", Bob clicks something and voila > > it's sent. > > > -Alternatives: send a re-Invite or Update with a Call-Info, > > > with either a URL reference, data URI, or MIME and CID URL. > > > -Counter-argument: IMO this type of data really belongs in > > > MIME for a number of reasons, including length is less > > restricted for > > > mime attachments; one AD has said the Data URL may be > > deprecated. And > > > sending a re-Invite for this purpose seems odd. > > > > > > -Also, the Call-Info header is really about the caller or > > > callee, and thus Bob shouldn't be sending me John's vcard > > info in it technically. > > > That may sound like a nit, but UA's may well store the call-info > > > vcards into their address-books automatically and so tie it to the > > > wrong user/call. > > > -Pros of using INFO: it's explicit what you're > > doing when you > > > send the vcard, and you can send it knowing the other end > > can accept > > > it, and you can send it based on user input. > > > > > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, > > Bob has an > > > icon that represents himself, sends it when he picks up the phone. > > > -Alternatives: send a 200ok, re-Invite, or Update with > > > call-info, which explicitly has a type for icon. > > > -Counter-argument: same as for vcard, plus with call-info > > > there is no way to know which picture format the far-end supports a > > > priori. With a supported-package negotiation one could know. > > > > > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says > > > "hey let's have a con call at time X", clicks and voila his phone > > > sends a vcalendar. > > > -Whether the vcalendar is related to the session or not and > > > thus whether it should be sent in an in-dialog request or not is > > > certainly debatable. Message method can already be used > > for this anyway. > > > > > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; > > Alice asks for > > > more info or a datasheet and Bob sends a URL for Alice to open with > > > her web- browser. > > > -One could also argue this is just making SIP the > > new SMTP, or > > > this should be sent using MESSAGE (which really is the new SMTP). > > > > > > 5) Sending a session traceroute. Alice calls Bob, Bob > > answers, Alice > > > does a sip-traceroute to figure out the path to Bob, by > > sending Info > > > with an incrementing max-forwards type header starting at 0 > > (but not > > > really max- forwards), with a sip-frag type response body > > or some such. > > > -It's debatable if certain types of B2BUA's (ie, > > SBCs) would > > > ever allow this type of thing to happen, due to security > > concerns, but > > > I think they may do it at domain boundary hops. I think this is a > > > reasonable use for INFO though, maybe. > > > > > > 6) Sending geo-location information after call > > establishment. Alice > > > calls Bob, a hotel receptionist. Alice asks for directions > > to hotel, > > > clicks button and sends him location info of her phone (or > > Bob clicks > > > button and sends her his location). > > > -The location conveyance draft specifically calls > > out INFO as > > > acceptable for geo-loc info. Whether this is a real use-case is > > > debatable, and obviously it could be done with a sub/not. > > > > > > 7) Sending softkey-labels (not digit-match maps, but rather softkey > > > button labels). Alice calls her vmail server. Vmail server sends > > > softkey-labels for the menu items available in the response, Alice > > > presses softkeys and sends them in INFO. > > > -This could (and maybe should) be done with sub/not, a la > > > KPML, where the vmail server sends the softkey labels in the > > > Subscribe, UA sends buttons pressed in Notifies. But this > > is similar > > > to the DTMF use case so may well have the same benefit of lower > > > overhead since buttons are rarely pressed. > > > > > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue > > > with this session?" > > > -There is a patent for doing screen pop-ups using INFO. I > > > guess Alert-Info could be used for this, but it's not clear > > it should? > > > > > > > > > /***************** > > > * Use-cases which have been proposed by others or even implemented, > > > * which are dubious for INFO (IMHO): > > > *****************/ > > > 1) Sending RTP/RTCP statistics during call. > > > -There is an implementation of this, and the > > rationale is the > > > signaling plane box that wants this info is not actually the media > > > plane box that gets RTCP. Again this could (and IMO > > should) be done > > > with sub/not, so it can get stats after the call is over, > > and since it > > > will probably want periodic reports the overhead of the Subscribe > > > should be dwarfed by the number of Notifies. > > > > > > 2) Sending access-location information after call establishment. > > > -There is a P-Access-Network-Info header, and some have > > > proposed to send an update for it as a phone roams access points or > > > cells. But I think this is an odd thing to do inside an Invite > > > session, vs. in a sub/not or Register (and besides half the > > time the > > > network inserts this header, not the UA). > > > > > > 3) Sending media-control indications (ie, remote-control > > > "play/pause/etc.") > > > -This is done today by at least one vendor, but is > > debatable > > > if it's the right model. The argument is it's like SDP > > re-Invite for > > > hold, except at a media content layer above RTP, so not > > done in RTCP nor SDP. > > > > > > 4) Sending video fast update command > > > -This is an informational draft, which documents > > what has been > > > implemented, but states it should really be done in the media plane. > > > > > > 5) Sending peripheral control commands (ie, USB commands) > > > -There is actually a patent on this, amazingly. Someone > > > thinks it makes sense to create a SIP session to your laptop, or > > > vice-versa, and then send USB commands inside MIME in INFO > > messages. > > > Methinks this should be media-plane, if anything. > > > > > > 6) Sending charging information for a call (i.e., minutes > > remaining or > > > cost so far). > > > -There was a proposal to use this for Advice of Charge > > > information in TISPAN. IMO it should be a sub/not though, as they > > > want this to survive the Invite session. > > > > > > -hadriel > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 11 02:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1zv5-0006Wl-QV; Tue, 11 Dec 2007 02:52:47 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J1zv4-0006Wb-KG for sip-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 02:52:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1zuy-0006WR-IZ for sip@ietf.org; Tue, 11 Dec 2007 02:52:40 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1zuy-00067x-5e for sip@ietf.org; Tue, 11 Dec 2007 02:52:40 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JSV00989KA8PF@siemenscomms.co.uk> for sip@ietf.org; Tue, 11 Dec 2007 07:46:56 +0000 (GMT) Date: Tue, 11 Dec 2007 07:46:56 +0000 From: "Elwell, John" To: Jonathan Rosenberg , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D8890@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comments on hitchhikers-guide-04 Thread-Index: Acg7eFDnFCHbYejGSDmXpfi45pr/NA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Sip] Comments on hitchhikers-guide-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thanks for taking care of most of my review comments. The following is outstanding: "As such, this document formally defines a "SIP specification" as: o Any specification that defines an extension to RFC 3261, where an extension is a mechanism that changes or updates in some way a behavior specified there." This means RFC 3261 is not a SIP specification! Suggest: "The basic SIP specification, RFC 3261 [RFC3261], or any specification that defines an extension to RFC 3261..." John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 11 03:26:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J20RU-000309-1F; Tue, 11 Dec 2007 03:26:16 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J20RT-000302-3P for sip-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 03:26:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J20RS-0002zq-Q6 for sip@ietf.org; Tue, 11 Dec 2007 03:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lQW-0006cq-K5 for sip@ietf.org; Mon, 10 Dec 2007 11:24:16 -0500 Received: from web54205.mail.re2.yahoo.com ([206.190.39.247]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J1lQU-0004wr-C1 for sip@ietf.org; Mon, 10 Dec 2007 11:24:16 -0500 Received: (qmail 6965 invoked by uid 60001); 10 Dec 2007 16:24:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Vx3DfT9RM7K7n33tE8mrbPWIkeFymOMp6qQWYEw5aUIsQUIPhNa/SYgZalGvw/qvb6qgU8UHlS5SxIRmL1eZe0SAhBipKXPtRoeD9Df4qZQDS5EQNfB0jANxHOgEkDNGaP4pK6siQripRWv+hjvGurDbv1SC4erKLGqTpvrwk3Y=; X-YMail-OSG: iVulzXoVM1kujtOGf2D.gSVEbD63Upf1xOXpFBljvTYYeO9fvIQi29EDw0sTuMtNnWd7AVaWpGR1I7zqe431qCK5E6lkJUjohGhV Received: from [194.237.142.7] by web54205.mail.re2.yahoo.com via HTTP; Tue, 11 Dec 2007 00:24:13 CST Date: Tue, 11 Dec 2007 00:24:13 +0800 (CST) From: Tonny Kung To: sip@ietf.org MIME-Version: 1.0 Message-ID: <178310.3302.qm@web54205.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-TMDA-Confirmed: Tue, 11 Dec 2007 03:26:14 -0500 Subject: [Sip] To-tag in CANCEL response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mail2tonny-sip@yahoo.com.hk List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0190799030==" Errors-To: sip-bounces@ietf.org --===============0190799030== Content-Type: multipart/alternative; boundary="0-2109566690-1197303853=:3302" Content-Transfer-Encoding: 8bit --0-2109566690-1197303853=:3302 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit Hi, I'm a bit confused about which is the correct behavior for the CANCEL response handling with regard to the To-tag. There seems to be contradiction between RFC3261 and RFC3665. Here's the scenario: (as stated in RFC3665, section: 3.8) Alice Proxy 1 Proxy 2 Bob | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 F3 |--------------->| INVITE F4 | |<---------------| 100 F5 |--------------->| | |<---------------| | | | | 180 F6 | | | 180 F7 |<---------------| | 180 F8 |<---------------| | |<---------------| | | | CANCEL F9 | | | |--------------->| | | | 200 F10 | | | |<---------------| CANCEL F11 | | | |--------------->| | | | 200 F12 | | | |<---------------| | | | | CANCEL F13 | | | |--------------->| | | | 200 F14 | | | |<---------------| | | | 487 F15 | | | |<---------------| | | | ACK F16 | | | 487 F17 |--------------->| | |<---------------| | | | ACK F18 | | | 487 F19 |--------------->| | |<---------------| | | | ACK F20 | | | |--------------->| | | | | | | Questions: 1) All the 200 OK for the CANCEL responses do not contain any To-tags. But according to RFC3261 section 16.10, a stateful proxy should act as a UAS, which then require the response to have a To-tag. Isn't it? 2) Assume that CANCEL response should contain a To-tag, then what tag should it use? The same one as in the 180 response, which then should match the 487 response for INVITE as well? 3) If the proxy never received any provisional response, except for 100 trying, meaning it has not received any To-tag, then when it received the CANCEL request, should it generate a local To-tag in the response? 4) And since RFC3261 only stated that the To-tag in the CANCEL response SHOULD, not MUST, matches the one in the 487 response, I suppose it is OK to pass the 487 response from the UAS (Bob) towards the UAC (Alice) without changing the To-tag to match the one in the CANCEL response? Hope someone could clarify it. Thanks for your time. Best Regards, Tonny --------------------------------- Yahoo! ºô¤W¦w¥þ§ð²¤¡A±Ð§A¦p¦ó¨¾½d¶Â«È! ¤F¸Ñ§ó¦h --0-2109566690-1197303853=:3302 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: 8bit Hi,

I'm a bit confused about which is the correct behavior for the CANCEL response handling with regard to the To-tag. There seems to be contradiction between RFC3261 and RFC3665.

Here's the scenario: (as stated in RFC3665, section: 3.8)

   Alice           Proxy 1          Proxy 2            Bob
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |     100  F3    |--------------->|   INVITE F4    |
     |<---------------|     100  F5    |--------------->|
     |                |<---------------|                |
     |                |                |      180 F6    |
     |                |     180 F7     |<---------------|
     |     180 F8     |<---------------|                |
     |<---------------|                |                |
     |   CANCEL F9    |    
            |                |
     |--------------->|                |                |
     |     200 F10    |                |                |
     |<---------------|   CANCEL F11   |                |
     |                |--------------->|                |
     |                |     200 F12    |                |
     |                |<---------------|                |
     |                |                |   CANCEL F13   |
     |                |                |--------------->|
     |                |                |     200 F14    |
     |                |                |<---------------|
     |                |                |     487 F15    |
     |                |                |<---------------|
     |                |                |     ACK F16    |
     |                |     487 F17    |--------------->|
     |                |<---------------|                |
     |      
          |     ACK F18    |                |
     |     487 F19    |--------------->|                |
     |<---------------|                |                |
     |     ACK F20    |                |                |
     |--------------->|                |                |
     |                |                |                |

Questions:

1) All the 200 OK for the CANCEL responses do not contain any To-tags. But according to RFC3261 section 16.10, a stateful proxy should act as a UAS, which then require the response to have a To-tag. Isn't it?

2) Assume that CANCEL response should contain a To-tag, then what tag should it use? The same one as in the 180 response, which then should match the 487 response for INVITE as well?

3) If the proxy never received any provisional response, except for 100 trying, meaning it has not received any To-tag, then when it received the CANCEL request, should it generate a local To-tag in the response?

4) And since RFC3261 only stated that the To-tag in the CANCEL response SHOULD, not MUST, matches the one in the 487 response, I suppose it is OK to pass the 487 response from the UAS (Bob) towards the UAC (Alice) without changing the To-tag to match the one in the CANCEL response?

Hope someone could clarify it. Thanks for your time.

Best Regards,
Tonny

Yahoo! ºô¤W¦w¥þ§ð²¤¡A±Ð§A¦p¦ó¨¾½d¶Â«È! ¤F¸Ñ§ó¦h --0-2109566690-1197303853=:3302-- --===============0190799030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0190799030==-- From sip-bounces@ietf.org Tue Dec 11 08:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J255a-0003Ao-9X; Tue, 11 Dec 2007 08:23:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J255Z-0003Ai-6R for sip-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 08:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J255Y-0003Aa-Rd for sip@ietf.org; Tue, 11 Dec 2007 08:23:56 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J255Y-0005Tp-FC for sip@ietf.org; Tue, 11 Dec 2007 08:23:56 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Tue, 11 Dec 2007 08:23:55 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 11 Dec 2007 08:23:55 -0500 From: Bob Penfield To: "mail2tonny-sip@yahoo.com.hk" , "sip@ietf.org" Date: Tue, 11 Dec 2007 08:23:43 -0500 Subject: RE: [Sip] To-tag in CANCEL response Thread-Topic: RE: [Sip] To-tag in CANCEL response Thread-Index: Acg7+QzrNDIxOWIgSeuK9+yCosya1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "sip-implementors@lists.cs.columbia.edu" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > 1) All the 200 OK for the CANCEL responses do not contain > any To-tags. But according to RFC3261 section 16.10, a > stateful proxy should act as a UAS, which then require > the response to have a To-tag. Isn't it? This is an error in RFC 3665. All final responses must have to-tag. > 2) Assume that CANCEL response should contain a To-tag, then > what tag should it use? The same one as in the 180 response, > which then should match the 487 response for INVITE as well? The UAS should use the same to-tag for the 200-OK to the CANCEL that it use= d in the 180, and that same to-tag should be used in the 487 response for t= he INVITE. As it says in section 9.2 of RFC 3261 : ....the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. >3) If the proxy never received any provisional response, > except for 100 trying, meaning it has not received any To-tag, > then when it received the CANCEL request, should it generate > a local To-tag in the response? Yes. The CANCEL is hop-by-hop and each proxy is responding as a UAS, so it = generates its own to-tag. If it previously forwarded a 1xx response with a = to-tag, it may use that to-tag. > 4) And since RFC3261 only stated that the To-tag in the CANCEL > response SHOULD, not MUST, matches the one in the 487 response, > I suppose it is OK to pass the 487 response from the UAS (Bob) > towards the UAC (Alice) without changing the To-tag to match > the one in the CANCEL response? Yes. Proxies should not change the to-tag in a response it is proxies back = toward the UAC (see page 110 of RFC 3261). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 11 12:56:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29L1-0001sR-W4; Tue, 11 Dec 2007 12:56:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J29Kz-0001rE-OQ for sip-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:56:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29Kz-0001qz-DD for sip@ietf.org; Tue, 11 Dec 2007 12:56:09 -0500 Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J29Ky-0003Yz-RH for sip@ietf.org; Tue, 11 Dec 2007 12:56:09 -0500 Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id PVtd1Y00R0S2fkC0A00h00; Tue, 11 Dec 2007 17:56:13 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id PVwB1Y0070umElk0800000; Tue, 11 Dec 2007 17:56:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=UXeeI-G3cWwA:10 a=7ve1Lv5gKS6LgMQl-9cA:9 a=SPuTauds8LXcz7lxSMcA:7 a=ltfTVlal3uYi2BU-EWmz_FskvTMA:4 a=TZm1MNU2oDwA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lBBHu5PC021115 for ; Tue, 11 Dec 2007 12:56:05 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lBBHu5ZJ021111; Tue, 11 Dec 2007 12:56:05 -0500 Date: Tue, 11 Dec 2007 12:56:05 -0500 Message-Id: <200712111756.lBBHu5ZJ021111@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (brett@broadsoft.com) Subject: Re: [Sip] RFC 3515, RFC 4508, RFC 3261: angle bracket requirement References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Brett Tate" The following rfc3261 section 20 text defines when a name-addr must be used instead of an addr-spec. However the text currently does not appear generic enough to apply to all headers. RFC 3261 section 20: "The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters." RFC 3515 does not mention the rfc3261 rules. RFC 4508 only mentions the parameter impacts. Does the rfc3261 rule concerning comma and question mark apply to the refer-to header? Does the rfc3261 rule apply to all sip headers defined as containing name-addr or addr-spec? And if so, should the text be update per sip-essential-correction process? If comma and question mark aspects of the rfc3261 text is not relevant Refer-To, what is reason for the difference? The shortest statement of the real rule is "In locations where the grammar allows either name-addr or addr-spec to appear, the following restriction applies: If the URI contains a comma, question mark or semicolon, the name-addr form must be used." This rule covers all extension headers, etc., because it is necessary to disambiguate "name-addr / addr-spec". As you can see from section 2.1 of RFC 3515, Refer-To allows both name-addr and addr-spec and so is subject to this disambiguation rule. I've overstated things above -- the restriction is needed to disambiguate appearances of semicolon. The restriction in regard to comma is needed to disambiguate uses of addr-spec in lists. The restriction in regard to question mark doesn't seem to be needed for disambiguation -- I wonder why it's there. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 12 01:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2L0p-0003xK-P3; Wed, 12 Dec 2007 01:24:07 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2L0o-0003xA-1h for sip-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 01:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2L0n-0003x2-MY for sip@ietf.org; Wed, 12 Dec 2007 01:24:05 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2L0m-0006bx-Uw for sip@ietf.org; Wed, 12 Dec 2007 01:24:05 -0500 Received: by rv-out-0910.google.com with SMTP id l15so90047rvb.49 for ; Tue, 11 Dec 2007 22:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=XJedT/HuPX0Ea/1IsoN1mZ8C/AVLj+uaYH1RKQbGxiI=; b=DRQo/ePkhccmysY/FslLRpvgX5kGPR8ge6vemJtXzw71XZtRFOtrhvR9m5WiohvH9QQ1cF9gNDUUxJvnPHZFLO8WDQPPO4TiUQGzM7Ae9OXyAMlCxI0rrYbizgauBZAQEZMkbiuNI+ZpPArfRTrabbXf7csItx8tUPt8uKxll7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=YfP49lS0WvyP+BseAz811rBu1m5gWWtv+Z05J0OPn5lo7Fz4MjCpdFNV5yN2oxX0l/08U1GJK2J15L8oRVVG5Pz3Q+AVJRKMOlEexM3rqZ8ExMEZgWC+Uvi4B1/Ni/e4wXCRh7GA8qQ0cumsNi+tOMbREamAHdA44lmgT5T8qlM= Received: by 10.140.179.18 with SMTP id b18mr131045rvf.139.1197440644269; Tue, 11 Dec 2007 22:24:04 -0800 (PST) Received: by 10.141.22.6 with HTTP; Tue, 11 Dec 2007 22:24:04 -0800 (PST) Message-ID: <52a9bccc0712112224q1dac9773k68cc128d503a4b66@mail.gmail.com> Date: Wed, 12 Dec 2007 11:54:04 +0530 From: "Jagan Mohan" To: "SIP list" , "SIP Implementors" MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Sip] Session-level value overriden by media-level value in SDP (RFC 4566) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455598705==" Errors-To: sip-bounces@ietf.org --===============0455598705== Content-Type: multipart/alternative; boundary="----=_Part_7668_4560580.1197440644275" ------=_Part_7668_4560580.1197440644275 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, For example, a SIP message has the following SDP: v=0 c=IN IP4 0.0.0.0 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 a=sendonly I would like to know whether a=sendonly or c=IN IP4 0.0.0.0 should take into effect in this particular case. From RFC 4566: ============ Section 5, Page 8 mentions the following: An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. Each media-level section starts with an "m=" line and continues to the next media-level section or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Section 5, Page 10 mentions the following: [The connection ("c=") and attribute ("a=") information in the session-level section applies to all the media of that session unless overridden by connection information or an attribute of the same name in the media description.] I find the above statements to be slightly contradictory. Please clarify. Thanks, Jagan ------=_Part_7668_4560580.1197440644275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
      For example, a SIP message has the following SDP:
 
      v=0
      c=IN IP4 0.0.0.0
      t=2873397496 2873404696
      m=audio 49170 RTP/AVP 0
      a=sendonly
 
   I would like to know whether a=sendonly or c=IN IP4 0.0.0.0 should take into effect in this particular case.

   From RFC 4566:
   ============
 
   Section 5, Page 8 mentions the following:
 
   An SDP session description consists of a session-level section
   followed by zero or more media-level sections.  The session-level
   part starts with a "v=" line and continues to the first media-level
   section.  Each media-level section starts with an "m=" line and
   continues to the next media-level section or end of the whole session
   description.  In general, session-level values are the default for
   all media unless overridden by an equivalent media-level value.
 
 
  Section 5, Page 10 mentions the following:
 
   [The connection ("c=") and attribute ("a=") information in the
   session-level section applies to all the media of that session unless
   overridden by connection information or an attribute of the same name
   in the media description.]
 
   I find the above statements to be slightly contradictory.
 
   Please clarify.
 
Thanks,
Jagan 
------=_Part_7668_4560580.1197440644275-- --===============0455598705== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0455598705==-- From sip-bounces@ietf.org Wed Dec 12 07:45:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Qwh-0007bx-5B; Wed, 12 Dec 2007 07:44:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2Qwf-0007bs-0g for sip-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 07:44:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Qwe-0007bk-Ll for sip@ietf.org; Wed, 12 Dec 2007 07:44:12 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Qwc-0000fy-1u for sip@ietf.org; Wed, 12 Dec 2007 07:44:12 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AD2082143E; Wed, 12 Dec 2007 13:41:28 +0100 (CET) X-AuditID: c1b4fb3c-af796bb0000030cf-2a-475fd6f83f6e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C4BF214B7; Wed, 12 Dec 2007 13:41:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 13:41:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: VS: VS: [Sip] Delivering request-URI and parameters to UAS via proxy Date: Wed, 12 Dec 2007 13:41:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] Delivering request-URI and parameters to UAS via proxy Thread-Index: Acg4JGkAop/2ZJQeT3OmQxox75ZkSgAWUS+Y References: <5D1A7985295922448D5550C94DE29180019B7E52@DEEXC1U01.de.lucent.com> <47572024.9000901@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Dec 2007 12:41:28.0389 (UTC) FILETIME=[509AA750:01C83CBC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0258924361==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0258924361== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83CBC.5063EEA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83CBC.5063EEA8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have had an off-line discussion with Jonathan about this, but I'll let = everyone else know too. =20 One issue with Jonathan's proposed mechanism is that it is assumes that = the entity/proxy who wants to use it (instead of modifying the R-URI = value) KNOWS whether the next hop device also supports the mechanism or = not. I think that assumption makes the usability of the proposed = solution extremely limited and "undynamic", and services which rely on = the mechanism will be dependent on whether intermediates (which have = nothing to do with the service as such) support the mechanism =20 Also, assuming that one or more entities/proxies in the path have = already used the mechanism, and now an entity/proxy realizes that the = next hop device does NOT support it. This most likely means that that = entity/proxy now will have to "fix" the INVITE (e.g put the "correct" = URI back into the R-URI etc), in order for the next hop to be able to = deal with it correctly (at least the home proxy of the terminating user = would need the "fix" in order to find the registered contact, and an MGC = to correctly map the called party number). =20 And, yes, I AM thinking about an alternative solution, and my intention = IS to submit a draft before the deadline. =20 Regards, =20 Christer ________________________________ L=E4hett=E4j=E4: Jonathan Rosenberg [mailto:jdrosen@cisco.com] L=E4hetetty: ke 5.12.2007 23:03 Vastaanottaja: Christer Holmberg Kopio: sip@ietf.org; DRAGE, Keith (Keith) Aihe: Re: VS: [Sip] Delivering request-URI and parameters to UAS via = proxy Christer Holmberg wrote: > Hi, > > In order to think about documenting "alternative solutions", I have a > question for clarifications regarding the scope of the problem we are > trying to solve. > > The MECHANISM part of the draft says that a UA supporting the > mechanism would indicate it to the registrar, and the registrar would > only use the mechanism in case the UA has indicated support for it > (that is also shown in the example in the draft). For when a proxy is talking to a registered UA, yes. > It has also been > claimed that this would be backward compatible with an MGC which uses > the R-URI to map to ISUP Called Party number, because the MGC does > not register so the mechanism would not be used towards it. That is not the intent. The idea is, any proxy that is translating a request-URI, is doing so based on some kind of mapping table. There are many ways that this mapping table can get into the proxy: 1. dynamically through register 2. provisioned 3. through an enum query etc. If we take provisioning as an example (i.e., someone enters phone number routing rules via prefix matching rules), when those rules are provisioned, they would include a flag which says whether the destination is loose-route compliant. If they are loose route compliant, the proxy uses a Route header, else it uses r-uri translation as is currently done. > > My question is: does this mean that the only entity allowed to use > this mechanism is the registrar, since the mechanism is used based on > whether the UA supports it or not? As above, no. > > When reading the USE-CASE part of the draft, I would say that the > answer is "no". Because, as I understand the text, there could be > non-registrar entities in the path, which today normally would > re-write the R-URI, but would now instead use this mechanism. Is my > understanding correct? Yes. > > If so, my next question is: these non-registrar entities have no clue > about whether the terminating UA supports the mechanism or not, or > whether the call will be routed towards an MGC. So, what happens if > the request is routed towards an UA that has not indicated support, > or towards an MGC? The MGC may not be able to map the R-URI. Hopefully the above paragraph answers your question. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net = PHONE: (408) 902-3084 http://www.cisco.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C83CBC.5063EEA8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: VS: [Sip] Delivering request-URI and = parameters to UAS via proxy
Hi,
 
I have had an off-line = discussion with=20 Jonathan about this, but I'll let everyone else know too.
 
One issue with = Jonathan's proposed=20 mechanism is that it is assumes that the entity/proxy who = wants to use=20 it (instead of modifying the R-URI value) KNOWS whether the next = hop device=20 also supports the mechanism or not. I think that=20 assumption makes the usability of the proposed solution extremely = limited=20 and "undynamic", and services which rely on the mechanism will be = dependent=20 on whether intermediates (which have nothing to do with the service as = such)=20 support the mechanism
 
Also, assuming that one or = more=20 entities/proxies in the path have already used the mechanism, and now an = entity/proxy realizes that the next hop device does NOT support=20 it. This most=20 likely means that = that=20 entity/proxy now will have to "fix" the INVITE (e.g put the "correct"=20 URI back into the R-URI etc), in order for the next hop to be able to = deal with=20 it correctly (at least the home proxy of the terminating user would = need=20 the "fix" in order to find the registered contact, and an MGC to = correctly=20 map the called party number).
 
And, yes, I AM thinking about = an=20 alternative solution, and my intention IS to submit a draft before the=20 deadline.
 
Regards,
 
Christer

L=E4hett=E4j=E4: Jonathan Rosenberg=20 [mailto:jdrosen@cisco.com]
L=E4hetetty: ke 5.12.2007=20 23:03
Vastaanottaja: Christer Holmberg
Kopio: = sip@ietf.org;=20 DRAGE, Keith (Keith)
Aihe: Re: VS: [Sip] Delivering = request-URI and=20 parameters to UAS via proxy



Christer Holmberg wrote:
> Hi,
>
> = In order to=20 think about documenting "alternative solutions", I have a
> = question for=20 clarifications regarding the scope of the problem we are
> trying = to=20 solve.
>
> The MECHANISM part of the draft says that a UA = supporting=20 the
> mechanism would indicate it to the registrar, and the = registrar=20 would
> only use the mechanism in case the UA has indicated = support for=20 it
> (that is also shown in the example in the draft).

For = when a=20 proxy is talking to a registered UA, yes.

> It has also = been
>=20 claimed that this would be backward compatible with an MGC which = uses
>=20 the R-URI to map to ISUP Called Party number, because the MGC = does
> not=20 register so the mechanism would not be used towards it.

That is = not the=20 intent.

The idea is, any proxy that is translating a request-URI, = is=20 doing so
based on some kind of mapping table. There are many ways = that=20 this
mapping table can get into the proxy:

1. dynamically = through=20 register
2. provisioned
3. through an enum query
etc.

If = we take=20 provisioning as an example (i.e., someone enters phone number
routing = rules=20 via prefix matching rules), when those rules are
provisioned, they = would=20 include a flag which says whether the
destination is loose-route = compliant.=20 If they are loose route compliant,
the proxy uses a Route header, = else it=20 uses r-uri translation as is
currently done.

>
> My = question=20 is: does this mean that the only entity allowed to use
> this = mechanism is=20 the registrar, since the mechanism is used based on
> whether the = UA=20 supports it or not?

As above, no.

>
> When = reading the=20 USE-CASE part of the draft, I would say that the
> answer is "no". = Because, as I understand the text, there could be
> non-registrar = entities=20 in the path, which today normally would
> re-write the R-URI, but = would=20 now instead use this mechanism. Is my
> understanding=20 correct?

Yes.

>
> If so, my next question is: = these=20 non-registrar entities have no clue
> about whether the = terminating UA=20 supports the mechanism or not, or
> whether the call will be = routed=20 towards an MGC. So, what happens if
> the request is routed = towards an UA=20 that has not indicated support,
> or towards an MGC? The MGC may = not be=20 able to map the R-URI.

Hopefully the above paragraph answers your = question.

-Jonathan R.


--
Jonathan D. Rosenberg,=20 Ph.D.           &n= bsp;      =20 499 Thornall St.
Cisco=20 Fellow           &= nbsp;           &n= bsp;          =20 Edison, NJ 08837
Cisco, Voice Technology = Group
jdrosen@cisco.com
http://www.jdrosen.net  &n= bsp;           &nb= sp;         =20 PHONE: (408) 902-3084
http://www.cisco.com


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

------_=_NextPart_001_01C83CBC.5063EEA8-- --===============0258924361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0258924361==-- From sip-bounces@ietf.org Wed Dec 12 23:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fMN-0005CY-0q; Wed, 12 Dec 2007 23:07:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2fMK-0005CR-Qx for sip-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:07:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fMK-0005CI-G3 for sip@ietf.org; Wed, 12 Dec 2007 23:07:40 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2fMK-00071L-4u for sip@ietf.org; Wed, 12 Dec 2007 23:07:40 -0500 Received: by nf-out-0910.google.com with SMTP id d21so384154nfb.39 for ; Wed, 12 Dec 2007 20:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type; bh=QfCbEiNX5zXDhMqKpk3qDOBv/bEb5VmIwkTxI19Hx70=; b=D86P3oYYsZNc7c249vxYiN1PgpbilcpMjtlxt/GB2Vk+NR9Ym80uz/FZ1+g6FGuVCjKRO3WiLJdSVP5v1skWvT17FvLbSTdbrIdFjfAY5ycG8xJcpa41s4UJqdvlm4ivfly2f1paS5FDEM9MFUCT07/5CChrUjfRoFiKzI0LeJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type; b=iUTjNvpyfj0V4rK5GoFDwfIxy544LLlbqYmXmALOPWSXnjDjbKLDPZ/i+MON23gs78yz9t9okx1hOr9JYjTz1qBWR1kBQ+AxB+ayv5pgUXSlfmrJrLrE/RygKm02sL1i2IaSQlv23g7Qe4mOsU2YOA95+zq82g4I2Qu3JcHSczg= Received: by 10.78.138.14 with SMTP id l14mr1734500hud.23.1197518859091; Wed, 12 Dec 2007 20:07:39 -0800 (PST) Received: by 10.78.75.8 with HTTP; Wed, 12 Dec 2007 20:07:39 -0800 (PST) Message-ID: <7bfdc29a0712122007od2fbb6w6c29b3ecc8b2402e@mail.gmail.com> Date: Thu, 13 Dec 2007 10:07:39 +0600 From: "Imran M Yousuf" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] Direction on Buddy List format for SIP Simple X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: imran@smart-it-engineering.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1582046072==" Errors-To: sip-bounces@ietf.org --===============1582046072== Content-Type: multipart/alternative; boundary="----=_Part_31333_3769455.1197518859088" ------=_Part_31333_3769455.1197518859088 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I was wondering how is Buddy List be exchanged between SIP Server and SIP UA. Can someone please direct me to some document in relate to this. Thank you, -- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@smartitengineering.com Mobile: +880-1711402557 ------=_Part_31333_3769455.1197518859088 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I was wondering how is Buddy List be exchanged between SIP Server and SIP UA. Can someone please direct me to some document in relate to this.

Thank you,

--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557 ------=_Part_31333_3769455.1197518859088-- --===============1582046072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1582046072==-- From sip-bounces@ietf.org Wed Dec 12 23:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fkd-0006ew-Hd; Wed, 12 Dec 2007 23:32:47 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2fkc-0006T6-Eb for sip-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 23:32:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2fkc-0006QS-35 for sip@ietf.org; Wed, 12 Dec 2007 23:32:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2fjz-0005ci-I3 for sip@ietf.org; Wed, 12 Dec 2007 23:32:07 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2fjz-0005Ye-7z for sip@ietf.org; Wed, 12 Dec 2007 23:32:07 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1046935wah.25 for ; Wed, 12 Dec 2007 20:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=dpicKIA2ST+Cr4vcvsf+IN2eayLjsukKrfbDG0cUIxU=; b=cW1PZWg1INAcj+62ZHe8w5/nxFZkFT6sYdfrvoBLcA9agGdqH8ls6EhMj70SJys4Gp/7R62fmtNzASN06j0iQ6dQ/5t7nS12deRYwXZoq8i8gXUwOnftvmb+lgQ5Ux4FXSWXqNCjuB2meqqfHAif5anbA7n8NkR6MjZwxQfgnf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XAHqEAuPDOagqqfiu1Wh9zPFXoP3EHv9pj0NQXHDa3OJ1iwGHiciVGTTDU6aj4DDMbA5jJamARRgpZtxcIzQkj6Z9A4E3eQUfiZSBT2QsWCNtgLgqM5SjWMB3QkLpX2k6PktoDMbOtNEWoJq8CFFMTntETF9pzpz4yIqYmt41vE= Received: by 10.115.89.1 with SMTP id r1mr1755093wal.8.1197520326087; Wed, 12 Dec 2007 20:32:06 -0800 (PST) Received: by 10.114.155.16 with HTTP; Wed, 12 Dec 2007 20:32:06 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 13:32:06 +0900 From: "Simon Flannery" To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-TMDA-Confirmed: Wed, 12 Dec 2007 23:32:46 -0500 Subject: [Sip] Early or Late media X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, I know this is a SIP dedicated mail list and not designed for IMS related questions but I do not know where else I could post. I would like to check my understanding of Early and Late media also know as Early (or Late) operating mode: - Using Early media, the inviting user may talk immediately, and the core network should buffer the media before the invited user (or users) accept the session - The received media is buffered until at least the first invited user accepts the invitation - The buffered media is also sent to all users that accept the invitation - Conversely, Late media mimics a traditional phone call where the inviting user must wait until at least one inviting user accepts the session before being allowed to send media Is my understanding correct? Are any of the dot points in error? Thanks in advance, Simon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 00:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gE3-0005PJ-1J; Thu, 13 Dec 2007 00:03:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2gE0-0005PD-Q6 for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:03:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gE0-0005P5-DE for sip@ietf.org; Thu, 13 Dec 2007 00:03:08 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2gDy-00085G-SA for sip@ietf.org; Thu, 13 Dec 2007 00:03:08 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2007 21:03:06 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBD53653001467; Wed, 12 Dec 2007 21:03:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBD5320i010313; Thu, 13 Dec 2007 05:03:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:03:01 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:03:01 -0800 Message-ID: <4760BD2C.5030506@cisco.com> Date: Thu, 13 Dec 2007 00:03:40 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] INFO use-cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 05:03:01.0601 (UTC) FILETIME=[6FB1A510:01C83D45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12641; t=1197522186; x=1198386186; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20INFO=20use-cases |Sender:=20; bh=D5LZ+xZETqMWOOltYvvbvYYdBLusBGTFWyHCup14Yd4=; b=b4/+J61hZ1tUXrhXzcpYDS4N0X965h3UR/ihwbWv2waVzI0vjL+ju5V9o+ MdhmSj+T2mzfu8A+U9p5AVNDACF93WjXJHbl/SGBXeXwG0woS7wT/QLPgE1x G/kNRa4lIh; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, Thanks much for putting down some use cases. These are helpful for a good discussion. Some comments below, but I will say that I'm now convinced that we should go ahead and define an info-framework. The real compelling argument, I think, is one you make below. Even if we tell everyone they shouldn't, its clear that folks are going to be doing this. So, instead of saying no, and leaving us with an non-interoperable mess, lets define how it works, and give some guidance on what the issues are and when you might want to step back and think about whether something else (SUB/NOT, media plane, MESSAGE) would be a better choice. It is very reminiscent of the NAT discussion. Sure, we all agree NAT is bad and it makes things harder for lots of apps, and there are better ways (v6). But, the architecturally right thing was not as easily deployable as the quick-fix NAT solution, and so the latter won out. In hindsight, we would have been much better off had we immediately standardized clear behaviors for NAT, and not ignored them and just declared them bad. INFO is the same. Sure, there'll often be better ways. But folks have spoken with their implementations, that it is more easily deployable than any of the other solutions. So lets not re-do the NAT mistake, lets define how it works, and not just say 'they're bad', and then end up regretting it in a few years when there are hundreds of INFO usages out there. More below: Hadriel Kaplan wrote: > Howdy, Jonathan asked for use-cases for what types of things would > need an in-dialog SIP message for user-user communication, vs. should > be done either out of dialog or in the media plane. If the only > use-case is DTMF, then we could just document the DTMF > negotiation/use only and not have to create a general info-events > framework. That seems a very reasonable argument to me. I also > don't want to do work for no use. > > There is a counter-argument that there are proprietary uses of INFO > in the wild, and that a framework for negotiation at least removes > the manual configuration of vendor-specific profiles, which is a > problem of interop today - even if the IETF should not bless/document > the specific use cases themselves. But that would make the draft a > very different one than it currently is as well, and I will ask that > in a separate email thread. > > The chairs have asked for 3 use cases, and I assume they mean 3 NEW > use cases (we already have 3 RFCs which use INFO, as well as DTMF). > I am not sure if they mean potential future use-cases, or current > use-cases (i.e., already implemented). Can I get a clarification on > that? > > So anyway, taking the shot-gun approach, here's a first go at some > use-cases, and my personal take on whether they should be in INFO vs. > SUB/NOT vs. media-plane, FWIW. [apologize for formatting ugliness] > > /*************** * Already standardized use-cases: ***************/ > 1) SIP-T/ISUP/QSIG/PSTN -Documented in RFC 3372 and RFC 4497. > > 2) ECMA TR/87 uaCSTA -Uses INFO to send ECMA-323 XML for monitoring > and controlling phones from a PC. > > 3) Sending media server control commands. -Documented in RFC4722 > MSCML. > > > /**************** * Use-cases that I think are potentially/possibly > valid for INFO: ****************/ 1) Sending a vcard asynchronously. > Alice calls Bob, Alice says "can you send me John's vcard?", Bob > clicks something and voila it's sent. -Alternatives: send a re-Invite > or Update with a Call-Info, with either a URL reference, data URI, or > MIME and CID URL. -Counter-argument: IMO this type of data really > belongs in MIME for a number of reasons, including length is less > restricted for mime attachments; one AD has said the Data URL may be > deprecated. And sending a re-Invite for this purpose seems odd. > -Also, the Call-Info header is really about the caller or callee, and > thus Bob shouldn't be sending me John's vcard info in it technically. That argument is bogus since RFC 3261 clearly says call-info is about the caller or callee: The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. There is also a purpose parameter (a close cousin to the info-event, I'll note), which is specifically about vcard. That said, I agree data URI is bad so the real use case for call-info is when the vcard is to be sent by indirection. But its clear that indirection is much more of a pain than just sending the darn thing; you need to store it somewhere, get a URL, and then make sure that URL is derefenceable from the target, figure out when its retrieved, and then delete the content once retrieved at some point. Thats clearly a lot harder than just including it. Another alternative would be MESSAGE, but I think thats wrong. The reason is that MESSAGE should only be used when the one and only purpose of the content is to *render*. A vcard isn't just rendered; one can imagine a UA saying to a user, "bob has sent his vcard, would you like to add to your contacts?" and that is NOT rendering. So MESSAGE is wrong. ANother choice is the media channel. I agree here the overhead is high for that relative to the size of the content. So I think this is a reasonable use case in fact. > That may sound like a nit, but UA's may well store the call-info > vcards into their address-books automatically and so tie it to the > wrong user/call. -Pros of using INFO: it's explicit what you're doing > when you send the vcard, and you can send it knowing the other end > can accept it, and you can send it based on user input. > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an > icon that represents himself, sends it when he picks up the phone. > -Alternatives: send a 200ok, re-Invite, or Update with call-info, > which explicitly has a type for icon. -Counter-argument: same as for > vcard, plus with call-info there is no way to know which picture > format the far-end supports a priori. With a supported-package > negotiation one could know. Well, here I think the arguments are a bit more compelling for a media-path channel. This could be big, very possibly bigger than 1500 bytes, and this puts us into issues with SIP. > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says > "hey let's have a con call at time X", clicks and voila his phone > sends a vcalendar. -Whether the vcalendar is related to the session > or not and thus whether it should be sent in an in-dialog request or > not is certainly debatable. Message method can already be used for > this anyway. Well, I'll disagree with MESSAGE again under the argument that the intention here is not to render, but to have some kind of automated handling which depends on the purpose of the content (and not just the type). But I think this also passes the litmus test for cases where the other choices besides INFO are going to add complexity, overhead, or latency for no benefit; SUB/NOT is a lot of work when you have no idea if you would ever even receive it. Media-path setup would be overly complex and a lot of messages for something which is very likely to never be sent. The size of these is small, so in the signaling path is reasonable. > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for > more info or a datasheet and Bob sends a URL for Alice to open with > her web-browser. -One could also argue this is just making SIP the > new SMTP, or this should be sent using MESSAGE (which really is the > new SMTP). Well, here we already have something defined - REFER with an http URL. See draft-ietf-sipping-app-interaction-framework. > > 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice > does a sip-traceroute to figure out the path to Bob, by sending Info > with an incrementing max-forwards type header starting at 0 (but not > really max-forwards), Max-FOrwards but not really Max-Forwards?? > with a sip-frag type response body or some > such. -It's debatable if certain types of B2BUA's (ie, SBCs) would > ever allow this type of thing to happen, due to security concerns, > but I think they may do it at domain boundary hops. I think this is > a reasonable use for INFO though, maybe. I'm much less convinced here. This would require handling at proxies and we haven't been discussing usage of INFO at proxies like this. Only e2e. > > 6) Sending geo-location information after call establishment. Alice > calls Bob, a hotel receptionist. Alice asks for directions to hotel, > clicks button and sends him location info of her phone (or Bob clicks > button and sends her his location). -The location conveyance draft > specifically calls out INFO as acceptable for geo-loc info. Whether > this is a real use-case is debatable, and obviously it could be done > with a sub/not. SUB/NOT seems a bit better here, I think, since the recipient knows that they want it. > > 7) Sending softkey-labels (not digit-match maps, but rather softkey > button labels). Alice calls her vmail server. Vmail server sends > softkey-labels for the menu items available in the response, Alice > presses softkeys and sends them in INFO. -This could (and maybe > should) be done with sub/not, a la KPML, where the vmail server sends > the softkey labels in the Subscribe, UA sends buttons pressed in > Notifies. But this is similar to the DTMF use case so may well have > the same benefit of lower overhead since buttons are rarely pressed. Rarely pressed yes, but this is an application specifically looking for them. This is squarely in the territory of draft-ietf-sipping-app-interaction-framework and is better handled by those mechanisms. > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue > with this session?" -There is a patent for doing screen pop-ups using > INFO. I guess Alert-Info could be used for this, but it's not clear > it should? See discussion on indirection above. I think this is reasonable for INFO also. > > > /***************** * Use-cases which have been proposed by others or > even implemented, * which are dubious for INFO (IMHO): > *****************/ 1) Sending RTP/RTCP statistics during call. -There > is an implementation of this, and the rationale is the signaling > plane box that wants this info is not actually the media plane box > that gets RTCP. Again this could (and IMO should) be done with > sub/not, so it can get stats after the call is over, and since it > will probably want periodic reports the overhead of the Subscribe > should be dwarfed by the number of Notifies. Agree SUB/NOT is better. Its already been defined that way. > > 2) Sending access-location information after call establishment. > -There is a P-Access-Network-Info header, and some have proposed to > send an update for it as a phone roams access points or cells. But I > think this is an odd thing to do inside an Invite session, vs. in a > sub/not or Register (and besides half the time the network inserts > this header, not the UA). > > 3) Sending media-control indications (ie, remote-control > "play/pause/etc.") -This is done today by at least one vendor, but is > debatable if it's the right model. The argument is it's like SDP > re-Invite for hold, except at a media content layer above RTP, so not > done in RTCP nor SDP. I think this is much better done via a media-plane session. There is a requirement for low latency here and there will be a lot of these that get sent. > > 4) Sending video fast update command -This is an informational draft, > which documents what has been implemented, but states it should > really be done in the media plane. Agree. > > 5) Sending peripheral control commands (ie, USB commands) -There is > actually a patent on this, amazingly. Someone thinks it makes sense > to create a SIP session to your laptop, or vice-versa, and then send > USB commands inside MIME in INFO messages. Methinks this should be > media-plane, if anything. Agree. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 00:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gGB-0006r3-A3; Thu, 13 Dec 2007 00:05:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2gG7-0006qK-40 for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:05:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gG6-0006pp-Mn for sip@ietf.org; Thu, 13 Dec 2007 00:05:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2gG6-000887-7t for sip@ietf.org; Thu, 13 Dec 2007 00:05:18 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 21:05:17 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id lBD55HDJ025190; Wed, 12 Dec 2007 21:05:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBD55Fmw028353; Thu, 13 Dec 2007 05:05:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:05:17 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:05:17 -0800 Message-ID: <4760BDB4.5040107@cisco.com> Date: Thu, 13 Dec 2007 00:05:56 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Dec 2007 05:05:17.0180 (UTC) FILETIME=[C0815BC0:01C83D45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2280; t=1197522317; x=1198386317; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20SIPit21=3A=20BNF=20futu re-proofing=20problem? |Sender:=20; bh=XIhJMtUwjSGk7dldpc577ytWvpbf2HzhsxM8fFSvDDQ=; b=K76U3vYhhPzszjffbvt2Sc8CV5v+4OR4qKjg6Ln/+0bd3/9LfKGdwUUpWG m1TFnCVGoKE+jUZTqF3KCu/PdYQFpDsAUz8yBFMv3oSYVjv1/Vw5iWQVlGLr Cuur2iYl4g; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correction, yes. Essential? Hardly. This is another question around essential corrections. I think they not only need to clearly represent a bug or a fix, but need to be one that is important enough to merit documenting. Just like software, sometimes you don't ever bother fixing those sev 5s. Ever. -Jonathan R. Christer Holmberg wrote: > Hi, > > No matter how we'll fix this, I guess it would be a valid essential correction? > > Regards, > > Christer > > ________________________________ > > Lähettäjä: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Lähetetty: to 6.12.2007 21:09 > Vastaanottaja: sip@ietf.org > Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? > > > > From: Jonathan Rosenberg > > This strikes me as a problem in theory and not in practice. AFAICT, the > only characters you can't use are ascii 0x00-0x19 (0x20 is space and is > possible through the LWS construct as Christer pointed out). Is there a > practical use case for any of these? They are: > > HT (horizontal tab) should be included, but that's also in LWS. As > for the remaining characters, I don't think that anyone has ever > *intended* that they be used in SIP headers, and their inclusion in > quoted-pair was a typographical error. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 00:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gNa-0005i2-5V; Thu, 13 Dec 2007 00:13:02 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2gNZ-0005hw-6s for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:13:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2gNY-0005ho-TF for sip@ietf.org; Thu, 13 Dec 2007 00:13:00 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2gNY-0006Hj-FI for sip@ietf.org; Thu, 13 Dec 2007 00:13:00 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Dec 2007 21:13:00 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBD5D0Q0005405 for ; Wed, 12 Dec 2007 21:13:00 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBD5Cx0i016601 for ; Thu, 13 Dec 2007 05:12:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:12:59 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 21:12:59 -0800 Message-ID: <4760BF83.2020507@cisco.com> Date: Thu, 13 Dec 2007 00:13:39 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 05:12:59.0761 (UTC) FILETIME=[D4399E10:01C83D46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1997; t=1197522780; x=1198386780; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20proposed=20litmus=20tests=20for=20INFO |Sender:=20; bh=8fzPEjbh1OznjOaK30aNuyflrfQakHFyCg3MyZKE74M=; b=Yz+vDYrc1Qc60EwobEt+27JuzDNYJwiSrsXaw/tatI4wT7NZ6Rmt7wffVI gRQa99RJnOppzHblJtBkF6QyWqTkDQc6CiOj9JcMet3gLxbk4xOZpqn/nqI4 5aUcx2e3/V; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] proposed litmus tests for INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Based on Hadriels use cases, I'd like to suggest some litmus tests that one can use to help determine if something is best done by INFO or something else: Cases where a media-plane session is the best solution: * there are requirements for low latency delivery (camera control for example) * there are requirements that the data shouldn't be retransmitted since latency trumps reliability (coordinate updates for a pointer on a whiteboard or something like that) * the data consists of a large number of messages that are likely to be sent during the duration of the session * the data is potentially very large Cases where SUB-NOT is the best solution: * the entity that wants to receive the data knows with high probability that the other side is likely to send a notification with the data, and it knows specifically what type of data it needs to receive * the entity that wants to receive the data is likely to receive a multiplicity of events containing that data Cases where INFO is the best solution: * the recipient of the data has no idea if the sender will ever generate the data; the recipient is just saying that it knows how to handle it, should the sender have something to send * the recipient could potentially handle many different types of data with the above characteristic * the size of the data that is to be sent is small and infrequent, at most a few times during the session * the data needs to be sent reliably and latency is not much of an issue * the data has no impact on SIP dialog state, transaction state, media session states or intermediate proxy or b2bua states -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 00:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2guw-0004gB-7B; Thu, 13 Dec 2007 00:47:30 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2guv-0004g0-4z for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 00:47:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2guu-0004fs-Ls for sip@ietf.org; Thu, 13 Dec 2007 00:47:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2gut-0006mD-GB for sip@ietf.org; Thu, 13 Dec 2007 00:47:28 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Dec 2007 00:47:28 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD5lRrM021228; Thu, 13 Dec 2007 00:47:27 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBD5lRa8017115; Thu, 13 Dec 2007 05:47:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 00:47:26 -0500 Received: from [10.86.242.179] ([10.86.242.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 00:47:26 -0500 Message-ID: <4760C76D.4010706@cisco.com> Date: Thu, 13 Dec 2007 00:47:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] INFO use-cases References: <4760BD2C.5030506@cisco.com> In-Reply-To: <4760BD2C.5030506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 05:47:26.0568 (UTC) FILETIME=[A4235680:01C83D4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10148; t=1197524847; x=1198388847; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20use-cases |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=wzonEkDrAqfOZ9ekH2OV2ASlxhfFjnPMaW8em8PDdnw=; b=XSfIlO4+JHqTLof/gKboMWwlbiukJNm7M7Ox6SNtdgelgjqiCYkENaFSVo k90qWS/gZGIijxJgFPLfYBbtY92dtHuX226zqp1EnVf2+7etkM8axd8nZDZE arTh4MgHS4; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm including some comments to Jonathan's comments, inline. Paul Jonathan Rosenberg wrote: > Hadriel, [snip] >> /**************** * Use-cases that I think are potentially/possibly >> valid for INFO: ****************/ 1) Sending a vcard asynchronously. >> Alice calls Bob, Alice says "can you send me John's vcard?", Bob >> clicks something and voila it's sent. -Alternatives: send a re-Invite >> or Update with a Call-Info, with either a URL reference, data URI, or >> MIME and CID URL. -Counter-argument: IMO this type of data really >> belongs in MIME for a number of reasons, including length is less >> restricted for mime attachments; one AD has said the Data URL may be >> deprecated. And sending a re-Invite for this purpose seems odd. >> -Also, the Call-Info header is really about the caller or callee, and >> thus Bob shouldn't be sending me John's vcard info in it technically. > > That argument is bogus since RFC 3261 clearly says call-info is about > the caller or callee: > > The Call-Info header field provides additional information about the > caller or callee, depending on whether it is found in a request or > response. > > There is also a purpose parameter (a close cousin to the info-event, > I'll note), which is specifically about vcard. > > That said, I agree data URI is bad so the real use case for call-info is > when the vcard is to be sent by indirection. But its clear that > indirection is much more of a pain than just sending the darn thing; you > need to store it somewhere, get a URL, and then make sure that URL is > derefenceable from the target, figure out when its retrieved, and then > delete the content once retrieved at some point. Thats clearly a lot > harder than just including it. Apparently the data url has been declared politically incorrect. But an Alert-Info or Call-Info with a CID URI should be quite reasonable in cases where you want to include the content in the message. (We just have to get settled what the Content-Disposition should be.) > Another alternative would be MESSAGE, but I think thats wrong. The > reason is that MESSAGE should only be used when the one and only purpose > of the content is to *render*. A vcard isn't just rendered; one can > imagine a UA saying to a user, "bob has sent his vcard, would you like > to add to your contacts?" and that is NOT rendering. So MESSAGE is wrong. > > ANother choice is the media channel. I agree here the overhead is high > for that relative to the size of the content. > > So I think this is a reasonable use case in fact. > >> That may sound like a nit, but UA's may well store the call-info >> vcards into their address-books automatically and so tie it to the >> wrong user/call. -Pros of using INFO: it's explicit what you're doing >> when you send the vcard, and you can send it knowing the other end >> can accept it, and you can send it based on user input. >> >> 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, Bob has an >> icon that represents himself, sends it when he picks up the phone. >> -Alternatives: send a 200ok, re-Invite, or Update with call-info, >> which explicitly has a type for icon. -Counter-argument: same as for >> vcard, plus with call-info there is no way to know which picture >> format the far-end supports a priori. With a supported-package >> negotiation one could know. > > Well, here I think the arguments are a bit more compelling for a > media-path channel. This could be big, very possibly bigger than 1500 > bytes, and this puts us into issues with SIP. 3261 defines both a Call-Info purpose of "icon" and a Content-Disposition of "icon" as ways to send a picture of the caller. >> 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says >> "hey let's have a con call at time X", clicks and voila his phone >> sends a vcalendar. -Whether the vcalendar is related to the session >> or not and thus whether it should be sent in an in-dialog request or >> not is certainly debatable. Message method can already be used for >> this anyway. > > Well, I'll disagree with MESSAGE again under the argument that the > intention here is not to render, but to have some kind of automated > handling which depends on the purpose of the content (and not just the > type). But I think this also passes the litmus test for cases where the > other choices besides INFO are going to add complexity, overhead, or > latency for no benefit; SUB/NOT is a lot of work when you have no idea > if you would ever even receive it. Media-path setup would be overly > complex and a lot of messages for something which is very likely to > never be sent. The size of these is small, so in the signaling path is > reasonable. Frankly the whole Content-Disposition meaning is still a bit up in the air IMO. It may be worth a discussion of what it means to have a content disposition other than "render" in a MESSAGE. >> 4) Sending an HTTP URL. Alice calls Bob, a sales guy; Alice asks for >> more info or a datasheet and Bob sends a URL for Alice to open with >> her web-browser. -One could also argue this is just making SIP the >> new SMTP, or this should be sent using MESSAGE (which really is the >> new SMTP). > > Well, here we already have something defined - REFER with an http URL. > See draft-ietf-sipping-app-interaction-framework. > > >> >> 5) Sending a session traceroute. Alice calls Bob, Bob answers, Alice >> does a sip-traceroute to figure out the path to Bob, by sending Info >> with an incrementing max-forwards type header starting at 0 (but not >> really max-forwards), > > Max-FOrwards but not really Max-Forwards?? > >> with a sip-frag type response body or some >> such. -It's debatable if certain types of B2BUA's (ie, SBCs) would >> ever allow this type of thing to happen, due to security concerns, >> but I think they may do it at domain boundary hops. I think this is >> a reasonable use for INFO though, maybe. > > I'm much less convinced here. This would require handling at proxies and > we haven't been discussing usage of INFO at proxies like this. Only e2e. > >> >> 6) Sending geo-location information after call establishment. Alice >> calls Bob, a hotel receptionist. Alice asks for directions to hotel, >> clicks button and sends him location info of her phone (or Bob clicks >> button and sends her his location). -The location conveyance draft >> specifically calls out INFO as acceptable for geo-loc info. Whether >> this is a real use-case is debatable, and obviously it could be done >> with a sub/not. > > SUB/NOT seems a bit better here, I think, since the recipient knows that > they want it. > >> >> 7) Sending softkey-labels (not digit-match maps, but rather softkey >> button labels). Alice calls her vmail server. Vmail server sends >> softkey-labels for the menu items available in the response, Alice >> presses softkeys and sends them in INFO. -This could (and maybe >> should) be done with sub/not, a la KPML, where the vmail server sends >> the softkey labels in the Subscribe, UA sends buttons pressed in >> Notifies. But this is similar to the DTMF use case so may well have >> the same benefit of lower overhead since buttons are rarely pressed. > > Rarely pressed yes, but this is an application specifically looking for > them. This is squarely in the territory of > draft-ietf-sipping-app-interaction-framework and is better handled by > those mechanisms. > >> >> 8) Sending a screen-pop-up message, e.g., "Do you want to continue >> with this session?" -There is a patent for doing screen pop-ups using >> INFO. I guess Alert-Info could be used for this, but it's not clear >> it should? > > See discussion on indirection above. I think this is reasonable for INFO > also. Why isn't this a place that where MESSAGE *is* appropriate? Sure seems like it is to me. >> >> /***************** * Use-cases which have been proposed by others or >> even implemented, * which are dubious for INFO (IMHO): >> *****************/ 1) Sending RTP/RTCP statistics during call. -There >> is an implementation of this, and the rationale is the signaling >> plane box that wants this info is not actually the media plane box >> that gets RTCP. Again this could (and IMO should) be done with >> sub/not, so it can get stats after the call is over, and since it >> will probably want periodic reports the overhead of the Subscribe >> should be dwarfed by the number of Notifies. > > Agree SUB/NOT is better. Its already been defined that way. > >> >> 2) Sending access-location information after call establishment. >> -There is a P-Access-Network-Info header, and some have proposed to >> send an update for it as a phone roams access points or cells. But I >> think this is an odd thing to do inside an Invite session, vs. in a >> sub/not or Register (and besides half the time the network inserts >> this header, not the UA). >> >> 3) Sending media-control indications (ie, remote-control >> "play/pause/etc.") -This is done today by at least one vendor, but is >> debatable if it's the right model. The argument is it's like SDP >> re-Invite for hold, except at a media content layer above RTP, so not >> done in RTCP nor SDP. > > I think this is much better done via a media-plane session. There is a > requirement for low latency here and there will be a lot of these that > get sent. > >> >> 4) Sending video fast update command -This is an informational draft, >> which documents what has been implemented, but states it should >> really be done in the media plane. > > Agree. > > >> >> 5) Sending peripheral control commands (ie, USB commands) -There is >> actually a patent on this, amazingly. Someone thinks it makes sense >> to create a SIP session to your laptop, or vice-versa, and then send >> USB commands inside MIME in INFO messages. Methinks this should be >> media-plane, if anything. > > Agree. > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 03:42:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jde-0000ff-CD; Thu, 13 Dec 2007 03:41:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2jdc-0000cr-KI for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 03:41:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jdc-0000aH-6Z for sip@ietf.org; Thu, 13 Dec 2007 03:41:48 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2jdb-0004HT-EL for sip@ietf.org; Thu, 13 Dec 2007 03:41:48 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id lBD8fL5h028802; Thu, 13 Dec 2007 09:41:26 +0100 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Dec 2007 09:41:41 +0100 Message-ID: <4760F098.4060506@alcatel-lucent.fr> Date: Thu, 13 Dec 2007 09:43:04 +0100 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> In-Reply-To: <4760BDB4.5040107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 13 Dec 2007 08:41:41.0404 (UTC) FILETIME=[FBB4B5C0:01C83D63] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id lBD8fL5h028802 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Correction, yes. Essential? Hardly. > > This is another question around essential corrections. I think they=20 > not only need to clearly represent a bug or a fix, but need to be one=20 > that is important enough to merit documenting. Just like software,=20 > sometimes you don't ever bother fixing those sev 5s. Ever. Just would like to raise a small warning with the "essential" vs=20 "non-essential" debate... Sometimes the most "costly" bugs (in terms of=20 interoperability problems) are the smallest stupid nits. Just one example, the FIRST proxy example of the RFC 3665 is broken...=20 Contact of subsequent request is not correctly pushed in the Request URI=20 with transport parameter, so, at SIPIT, I already have seen many UAs that behave incorrectly because of this... Ok this is clearly written in=20 3261, but you know how developers do: "don't have time to read this long=20 RFC, I will just look at the example :p"... And the place you generally look at is 3665, and then, it is broken (!)...=20 This is not "fixed" and I assume it will probably never be... By the way=20 this is a question: would it be interesting for somebody to fix 3665 examples, and if yes, how to proceed? + Thomas > > -Jonathan R. > > Christer Holmberg wrote: >> Hi, >> =20 >> No matter how we'll fix this, I guess it would be a valid essential=20 >> correction? >> =20 >> Regards, >> =20 >> Christer >> >> ________________________________ >> >> L=E4hett=E4j=E4: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.n= et] >> L=E4hetetty: to 6.12.2007 21:09 >> Vastaanottaja: sip@ietf.org >> Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? >> >> >> >> From: Jonathan Rosenberg >> >> This strikes me as a problem in theory and not in practice.=20 >> AFAICT, the >> only characters you can't use are ascii 0x00-0x19 (0x20 is space=20 >> and is >> possible through the LWS construct as Christer pointed out). Is=20 >> there a >> practical use case for any of these? They are: >> >> HT (horizontal tab) should be included, but that's also in LWS. As >> for the remaining characters, I don't think that anyone has ever >> *intended* that they be used in SIP headers, and their inclusion in >> quoted-pair was a typographical error. >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 05:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2lK1-00050S-HB; Thu, 13 Dec 2007 05:29:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2lK0-00050N-2i for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 05:29:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2lJz-00050F-Kn for sip@ietf.org; Thu, 13 Dec 2007 05:29:39 -0500 Received: from smtp3.versatel.nl ([62.58.50.90] helo=smtp6.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2lJx-00067E-DA for sip@ietf.org; Thu, 13 Dec 2007 05:29:39 -0500 Received: (qmail 22457 invoked by uid 0); 13 Dec 2007 10:30:38 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Dec 2007 10:30:38 -0000 Message-ID: <47610985.6080108@zonnet.nl> Date: Thu, 13 Dec 2007 11:29:25 +0100 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] ABNF error in RFC4474 (SIP Identity)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jon, Cullen, In RFC4474 there is an example (page 19): Identity: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" while the ABNF says: Identity = "Identity" HCOLON signed-identity-digest signed-identity-digest = LDQUOT *32LHEX *RDQUOT "32LHEX" means 32 hex digits in lower case (as used for e.g. request-digest in RFC3261), but this does not seem to be the intention here? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 08:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2noP-0004AV-L9; Thu, 13 Dec 2007 08:09:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2noO-0004AQ-IA for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 08:09:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2noO-0004AI-7n for sip@ietf.org; Thu, 13 Dec 2007 08:09:12 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2noM-0001FR-F9 for sip@ietf.org; Thu, 13 Dec 2007 08:09:12 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B89B420803; Thu, 13 Dec 2007 14:09:09 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-60-47612ef58bd6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9E5A62086D; Thu, 13 Dec 2007 14:09:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 14:09:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Thu, 13 Dec 2007 14:09:08 +0100 Message-ID: In-Reply-To: <4760F098.4060506@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: Acg9ZAJK0sRJC3wFTf2ra7ZEXt4CDAAJMFFA References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> <4760F098.4060506@alcatel-lucent.fr> From: "Christer Holmberg" To: "Thomas Froment" , "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Dec 2007 13:09:09.0470 (UTC) FILETIME=[59193FE0:01C83D89] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My opinion is that people who only implement based on examples, without = reading the actual protocol specification, have themselves to blame - = and they are going to run into problems sooner or later, no matter how = correct the exmaples are.=20 If people are too lazy to read 3261 I don't think there is anything IETF = can do - or even should spend time on doing. Regards, Christer=20 > -----Original Message----- > From: Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr]=20 > Sent: 13. joulukuuta 2007 10:43 > To: Jonathan Rosenberg > Cc: Christer Holmberg; sip@ietf.org > Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? >=20 > Jonathan Rosenberg wrote: > > Correction, yes. Essential? Hardly. > > > > This is another question around essential corrections. I think they=20 > > not only need to clearly represent a bug or a fix, but need=20 > to be one=20 > > that is important enough to merit documenting. Just like software,=20 > > sometimes you don't ever bother fixing those sev 5s. Ever. > Just would like to raise a small warning with the "essential"=20 > vs "non-essential" debate... Sometimes the most "costly" bugs=20 > (in terms of interoperability problems) are the smallest stupid nits. > Just one example, the FIRST proxy example of the RFC 3665 is=20 > broken...=20 > Contact of subsequent request is not correctly pushed in the=20 > Request URI with transport parameter, so, at SIPIT, I already=20 > have seen many UAs that behave incorrectly because of this...=20 > Ok this is clearly written in 3261, but you know how=20 > developers do: "don't have time to read this long RFC, I will=20 > just look at the example :p"... And the place you generally=20 > look at is 3665, and then, it is broken (!)...=20 > This is not "fixed" and I assume it will probably never be...=20 > By the way this is a question: would it be interesting for=20 > somebody to fix 3665 examples, and if yes, how to proceed? > + > Thomas >=20 >=20 > > > > -Jonathan R. > > > > Christer Holmberg wrote: > >> Hi, > >> =20 > >> No matter how we'll fix this, I guess it would be a valid=20 > essential=20 > >> correction? > >> =20 > >> Regards, > >> =20 > >> Christer > >> > >> ________________________________ > >> > >> L=E4hett=E4j=E4: Dale.Worley@comcast.net = [mailto:Dale.Worley@comcast.net] > >> L=E4hetetty: to 6.12.2007 21:09 > >> Vastaanottaja: sip@ietf.org > >> Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? > >> > >> > >> > >> From: Jonathan Rosenberg > >> > >> This strikes me as a problem in theory and not in practice.=20 > >> AFAICT, the > >> only characters you can't use are ascii 0x00-0x19 (0x20=20 > is space=20 > >> and is > >> possible through the LWS construct as Christer pointed out). Is=20 > >> there a > >> practical use case for any of these? They are: > >> > >> HT (horizontal tab) should be included, but that's also in=20 > LWS. As=20 > >> for the remaining characters, I don't think that anyone has ever > >> *intended* that they be used in SIP headers, and their=20 > inclusion in=20 > >> quoted-pair was a typographical error. > >> > >> Dale > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 08:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nuM-0007VA-2P; Thu, 13 Dec 2007 08:15:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2nuL-0007V0-6H for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 08:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nuK-0007Ur-Ss for sip@ietf.org; Thu, 13 Dec 2007 08:15:20 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2nuI-0001Oq-Bm for sip@ietf.org; Thu, 13 Dec 2007 08:15:20 -0500 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lBDDDWGn021803; Thu, 13 Dec 2007 14:13:32 +0100 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Dec 2007 14:15:10 +0100 Message-ID: <476130B1.4070104@alcatel-lucent.fr> Date: Thu, 13 Dec 2007 14:16:33 +0100 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> <4760F098.4060506@alcatel-lucent.fr> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 13:15:10.0655 (UTC) FILETIME=[3061B4F0:01C83D8A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > My opinion is that people who only implement based on examples, without reading the actual protocol specification, have themselves to blame - and they are going to run into problems sooner or later, no matter how correct the exmaples are. > > If people are too lazy to read 3261 I don't think there is anything IETF can do - or even should spend time on doing. I agree, but if you don't care about the first example of the most basic example of an RFC being broken and not fixed, you should not be surprised if interoperability problems occur with new implementations.. This was the topic of interoperability workshop: new implementors seem to all fall in the same "traps". I just wanted to outline that "small fix" is not synonym of "non-essential". + _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 11:48:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rE9-0001Bf-Ul; Thu, 13 Dec 2007 11:48:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2rE8-0001Ba-Rc for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 11:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rE8-0001BR-6q for sip@ietf.org; Thu, 13 Dec 2007 11:48:00 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rE6-0001A1-4V for sip@ietf.org; Thu, 13 Dec 2007 11:48:00 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3BE7B20101; Thu, 13 Dec 2007 17:47:57 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-10-4761623df8d0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18E79200E9; Thu, 13 Dec 2007 17:47:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 17:47:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] proposed litmus tests for INFO Date: Thu, 13 Dec 2007 17:47:56 +0100 Message-ID: <7A875FE512FD074BBD289B8F21D8F1F301F3F9E0DC@esealmw113.eemea.ericsson.se> In-Reply-To: <4760BF83.2020507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] proposed litmus tests for INFO Thread-Index: Acg9YNEnDEbGRjDRQOq5REOWMqSkKAAJVYjw References: <4760BF83.2020507@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Dec 2007 16:47:56.0858 (UTC) FILETIME=[E9A1B1A0:01C83DA7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think this is a good start, but I have some comments: Media-plane stuff: ------------------ This looks rather ok, but I am not sure I understand the retransmission = issue. The CSeq will take care of that, won't it? Or, do you mean that retransmission can delay the information to reach = the recevier? If so, isn't it covered with the first bullet (low = latency)? SUB-NOT vs INFO stuff: ---------------------- For INFO I think we should say that it can be used when the data may be = sent is associated to the dialog sent within, and is sent only for the = duration of that dialog (unless a media-plane session is more = appropriate for that specific data type, of course). For INFO I think we should also add cases when there are dialog-path = intermediates (without media access) interested in the data. For SUB-NOT I think we should add text about data which is not = associated to an invite dialog, or not associated to the lifetime of an = invite dialog.=20 I think that the current SUB-NOT bullets could be applicable to INFO = also. I don't think we can forget the multiple dialog issue with SUB-NOT = (which is one of the reasons why people use INFO in the first place). Of = course that doesn't automatically mean that people are allowed to use = INFO for anything they could also use SUB-NOT for, but I see no reason = why INFO can't be used e.g. in cases where it is "very likely that some = data will be sent" (ISUP is one example, where in many cases nodes will = know it will be sent). To me one important difference between INFO and SUB-NOT is, as described = earlier, whether the data is associated with a specific invite dialog, = and whether the data will only be sent during the lifetime of that = invite dialog. If not, SUB-NOT is better. What do you mean by "multiplicity of events containing that data"? Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 13. joulukuuta 2007 7:14 > To: IETF SIP List > Subject: [Sip] proposed litmus tests for INFO > > Based on Hadriels use cases, I'd like to suggest some litmus > tests that one can use to help determine if something is best > done by INFO or something else: > > Cases where a media-plane session is the best solution: > > * there are requirements for low latency delivery (camera > control for > example) > > * there are requirements that the data shouldn't be > retransmitted since latency trumps reliability (coordinate > updates for a pointer on a whiteboard or something like that) > > * the data consists of a large number of messages that are > likely to be sent during the duration of the session > > * the data is potentially very large > > Cases where SUB-NOT is the best solution: > > * the entity that wants to receive the data knows with > high probability that the other side is likely to send a > notification with the data, and it knows specifically what > type of data it needs to receive > > * the entity that wants to receive the data is likely to > receive a multiplicity of events containing that data > > Cases where INFO is the best solution: > > * the recipient of the data has no idea if the sender will > ever generate the data; the recipient is just saying that it > knows how to handle it, should the sender have something to send > > * the recipient could potentially handle many different > types of data with the above characteristic > > * the size of the data that is to be sent is small and > infrequent, at most a few times during the session > > * the data needs to be sent reliably and latency is not > much of an issue > > * the data has no impact on SIP dialog state, transaction > state, media session states or intermediate proxy or b2bua states > > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 499 Thornall St. > Cisco Fellow Edison, NJ 08837 > Cisco, Voice Technology Group > jdrosen@cisco.com > http://www.jdrosen.net = PHONE: (408) 902-3084 > http://www.cisco.com =20 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 12:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2s6j-0000yj-1P; Thu, 13 Dec 2007 12:44:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2s6h-0000ye-7z for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 12:44:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2s6g-0000wx-Sf for sip@ietf.org; Thu, 13 Dec 2007 12:44:22 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2s6g-0003cF-7z for sip@ietf.org; Thu, 13 Dec 2007 12:44:22 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4D6EE20664; Thu, 13 Dec 2007 18:44:21 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-61-47616f75095d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3A886203E5; Thu, 13 Dec 2007 18:44:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 18:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Thu, 13 Dec 2007 18:44:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: Acg9jgdF81cop/EbRpm0TfQqimCjwgAIMB+j References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> <4760F098.4060506@alcatel-lucent.fr> <476130B1.4070104@alcatel-lucent.fr> From: "Christer Holmberg" To: "Thomas Froment" X-OriginalArrivalTime: 13 Dec 2007 17:44:20.0996 (UTC) FILETIME=[CABC2C40:01C83DAF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is how it should be: =20 1. I implement RFC3261 (and whatever extensions needed) =20 2. I start to test, and I realize that the outcome is not according to = the example. =20 3. I send an e-mail to some SIP list, get a reply that there is a bug in = the example and that it was good that I found it, and that it will be = reported in some bugzilla. =20 4. I interop with other people who have done the same =20 Of course it is bad if there are bugs in an RFC, but my point is that = fixing an example call flow is probably not going to help = interoperability very much in the long run, if people don't read the = protocol spec... =20 Regards, =20 Christer =20 =20 =20 =20 ________________________________ From: Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr] Sent: Thu 13/12/2007 14:16 To: Christer Holmberg Cc: sip@ietf.org Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? Christer Holmberg wrote: > My opinion is that people who only implement based on examples, = without reading the actual protocol specification, have themselves to = blame - and they are going to run into problems sooner or later, no = matter how correct the exmaples are. > > If people are too lazy to read 3261 I don't think there is anything = IETF can do - or even should spend time on doing. I agree, but if you don't care about the first example of the most basic example of an RFC being broken and not fixed, you should not be surprised if interoperability problems occur with new implementations.. This was the topic of interoperability workshop: new implementors seem to all fall in the same "traps". I just wanted to outline that "small fix" is not synonym of = "non-essential". + _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 15:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v0G-000651-Hh; Thu, 13 Dec 2007 15:49:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2v0F-00064o-DR for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 15:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v0F-00064g-3b for sip@ietf.org; Thu, 13 Dec 2007 15:49:55 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2v0D-0001AU-G6 for sip@ietf.org; Thu, 13 Dec 2007 15:49:55 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBDKno0G015701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Dec 2007 14:49:52 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Early or Late media Date: Thu, 13 Dec 2007 14:49:44 -0600 To: Simon Flannery X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 12, 2007, at 10:32 PM, Simon Flannery wrote: > > I would like to check my understanding of Early and Late media also > know as Early (or Late) operating mode: > > - Using Early media, the inviting user may talk immediately, and the > core network should buffer the media before the invited user (or > users) accept the session > - The received media is buffered until at least the first invited user > accepts the invitation > - The buffered media is also sent to all users that accept the > invitation > - Conversely, Late media mimics a traditional phone call where the > inviting user must wait until at least one inviting user accepts the > session before being allowed to send media > > Is my understanding correct? Are any of the dot points in error? > > Welcome to one of the most confusing aspects among the many confusing aspects of SIP that were introduced by our attempts to compensate for the broken signaling model of ISUP. Personally, I think we unwittingly introduced a nightmarish level of complexity and should have just said "no! If you need two stage signaling, finalize the first stage with a 200 OK and then re-INVITE if the SDP changes for the second session." But we didn't do that, so we have what we have. IETF seems to use the terms "early media" and "early session", although I'm afraid I don't completely understand the nuances despite having struggled with them for many years. I suspect I don't want to understand just because the whole thing hurts my delicate sensibilities. I'm told that RFC 3960 is a useful reference for this discussion. Both uses of "early" refer to the transmission of media before completion of some phase of the signaling. Sometimes this is mean to be "before completion of the offer/answer phase" (that is, after an "offer", but before an "answer", and sometimes (as defined in RFC 3960) before the completion of a final response (generally a 200) to an INVITE request. RFC 3960 uses the following definition: Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. Within a dialog, early media occurs from the moment the initial INVITE is sent until the User Agent Server (UAS) generates a final response. It may be unidirectional or bidirectional, and can be generated by the caller, the callee, or both. Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status). Early media generated by the caller typically consists of voice commands or dual tone multi-frequency (DTMF) tones to drive interactive voice response (IVR) systems. In IETF and general IMS environments (AFAIK), there is no expectation that early media will be buffered. Anything not received by a listener is expected to be discarded. However, OMA's Push to talk Over Cellular (POC) specification does (or at least did, the last time I looked) allow a predictive mode where a POC controller (which is for all practical purposes a SIP B2BUA with media handling) can "answer" on behalf of a POC terminal with which it has an active relationship. The POC controller then buffers media while it activates the radio bearer needed to send the media on to the terminating POC client. Since the POC controller has effectively "answered" the INVITE request with a terminal response and media answer, I don't believe this mode qualifies as "early media" by any of the definitions in use around the IETF. Good luck in sorting this all out. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 17:45:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wnl-0000xU-2w; Thu, 13 Dec 2007 17:45:09 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2wnj-0000x7-2U for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wni-0000wz-Oc for sip@ietf.org; Thu, 13 Dec 2007 17:45:06 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2wng-0004eb-Uv for sip@ietf.org; Thu, 13 Dec 2007 17:45:06 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Thu, 13 Dec 2007 17:45:04 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 13 Dec 2007 17:45:04 -0500 From: Hadriel Kaplan To: "sip@ietf.org" Date: Thu, 13 Dec 2007 17:42:16 -0500 Thread-Topic: I-D Action:draft-kaplan-sip-info-use-cases-00.txt Thread-Index: Acg92Wkf0j/onyfQTH2FpqiOqmY0ow== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Sip] I-D Action:draft-kaplan-sip-info-use-cases-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673765060==" Errors-To: sip-bounces@ietf.org --===============1673765060== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273AB6F66mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB6F66mailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, The SIP WG chairs asked me to summarize the INFO use-case emails on the SIP= WG mailing list into a draft, so people don't need to go through the lengt= hy emails. This is not intended to be a long-lasting document, but rather = something to reference for the INFO discussion at hand. Also, I realize th= is is really a SIPPING thing in some ways, but the discussion is due to a S= IP WG discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt My apologies if I did not get everyone's arguments into the draft - just dr= op me a note for the next rev. (someone's already sent me another use-case = for a next rev) -hadriel --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB6F66mailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Howdy,

The SIP WG chairs asked me to summarize the INFO use-case emails on= the SIP WG mailing list into a draft, so people don’t need to go through = the lengthy emails.  This is not intended to be a long-lasting document, b= ut rather something to reference for the INFO discussion at hand.  Also, I reali= ze this is really a SIPPING thing in some ways, but the discussion is due to a SIP = WG discussion.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases= -00.txt

 

My apologies if I did not get everyone’s arguments into the d= raft - just drop me a note for the next rev. (someone’s already sent me another use-case for a next rev)

 

-hadriel

--_000_E6C2E8958BA59A4FB960963D475F7AC30273AB6F66mailacmepacke_-- --===============1673765060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1673765060==-- From sip-bounces@ietf.org Thu Dec 13 17:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wtR-0000Et-0b; Thu, 13 Dec 2007 17:51:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2wtQ-0000AR-5n for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:51:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wtP-000050-Pp for sip@ietf.org; Thu, 13 Dec 2007 17:50:59 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2wtO-0004qI-W4 for sip@ietf.org; Thu, 13 Dec 2007 17:50:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lBDMow4o027907 for ; Thu, 13 Dec 2007 16:50:58 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lBDMowj18921 for ; Thu, 13 Dec 2007 16:50:58 -0600 (CST) Message-ID: <4761B751.5010101@alcatel-lucent.com> Date: Thu, 13 Dec 2007 16:50:57 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Summary of WGLC on connect-reuse-08 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: As a follow up to the 1-slide summary Keith was kind enough to present at the Vancouver IETF, here are some further notes from the WGLC review done by Dale and Hadriel (thanks!) on connect-reuse-08. These notes also include the post WGLC discussion we had on the mailing list leading to the Vancouver IETF. If I am grossly mistaken in summarizing any of the points below, please let me know. Otherwise, I will prepare for an update to the draft based on the summary and consensus reached as detailed below. 1) Assume A opens a TCP connection to B. The -08 version had prohibited B from using the same TCP connection to send requests to A. The WG appears to think that this should be relaxed; i.e., A MAY accept requests over the connection from B, however, B MUST NOT use this connection to send requests to A unless it has some way of verifying the identity of that party to the same level of assurance as it would have by doing the DNS lookup and establishing its own connection. In either case, the "alias" parameter will NOT be added by A for a TCP transport when it opens a connection to B. 2) Name-based virtual servers (i.e., multiple servers on same IP+port) present a challenge for TCP connection reuse, and in such scenarios, reuse over TCP is prohibited. 3) Document terminology to clarify terms such as "TCP Connection Reuse" and "TCP Connection Sharing" (this input was provided to me through private email.) I will open up a separate thread on this to nail down the exact terms and their definitions. 4) Clarify portions of the draft as suggested by Dale, including making sure that the reader is not given an impression that the "alias table" is mandatory. I will be working on -09 over the next few weeks. If your recollection of the consensus reached does not match the above summary, please let me know. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 17:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wtW-0000Vt-TD; Thu, 13 Dec 2007 17:51:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2wtV-0000Rf-3g for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wtU-0000RK-PD for sip@ietf.org; Thu, 13 Dec 2007 17:51:04 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2wtS-0004lx-HL for sip@ietf.org; Thu, 13 Dec 2007 17:51:04 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lBDMp2UH027989 for ; Thu, 13 Dec 2007 16:51:02 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lBDMp2j19210 for ; Thu, 13 Dec 2007 16:51:02 -0600 (CST) Message-ID: <4761B755.60007@lucent.com> Date: Thu, 13 Dec 2007 16:51:01 -0600 From: "Vijay K. Gurbani" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi: During the WGLC review of connect-reuse-08, I received a private email requesting that the document contain explanation of terms being used. To quote the email: > A connection is established, and two things can happen.... > > 1. One end sends multiple messages over the same connection > for multiple sessions, where these sessions are sequential. > Example: A sends INVITE to B, and all dialog messages for the > call sessions traverse the same TCP connection until the BYE > and 200 OK BYE is completed, at which time the connection > is not torn down but remains up and a subsequent INVITE session > is then initiated over the same connection. We had been > calling this TCP Connection Reuse. > > 2. One end sends multiple messages over the same connection > for multiple simultaneous sessions. Example: A sends INVITE to > B for one call session and then sends another INVITE to B for > another call session and so on. Each session is maintained in > parallel with the others, and all dialog messages for all > sessions traverse the same TCP connection until the BYE and > 200 OK BYE is completed for each session. We had been calling > this TCP Connection Sharing. > > These are not just our usages of the terms, but are also being > used by our customers as well. Note that there are existing techniques in SIP to disambiguate multiple dialogs/sessions arriving on the same TCP stream. So the difference between connection reuse and connection sharing is not tied to whether the sessions are sequential or not. Rather, the difference is whether or not the connection can be used to send requests in the backwards direction. More specifically, Connection Reuse: The process of using the same connection to send new requests in the backwards direction (i.e., A opens a connection to B to send requests, and B uses the same connection to send new requests to A.) Connection sharing: The process of using the same connection to send multiple requests on the same connection (and of course, receive multiple responses over the connection.) A shared connection will not be reused for requests in the backwards direction. Comments? Thoughts? Suggestions? Other terms to document? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 13 20:47:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2zdi-0007il-PU; Thu, 13 Dec 2007 20:46:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J2zdh-0007eO-1i for sip-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 20:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2zdg-0007eG-Np for sip@ietf.org; Thu, 13 Dec 2007 20:46:56 -0500 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2zdg-0008Ck-2R for sip@ietf.org; Thu, 13 Dec 2007 20:46:56 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1806229wah.25 for ; Thu, 13 Dec 2007 17:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=uGaXZXbZ+56p65tiw4Jr+CtzmLn9awQ8ipS3e3PSaYI=; b=hGTbhN/8vljd04+8/OggLRw9MYDbQmSvveiuM49Ed69zC5umUCrJnCaQo9pD43u5OjXxQwpguN2AJRZx0izxypOV4qrzrVwNIAZ/mpcqKn3l0eci6QdR5lw4VqVkaZRHXw01d179M3zIghVb8VLGEIjw4QNYl3ZbdsNA3xMF7Yg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PAFlxVGRw44SvG6o5MJ6b0x2hGoCexrm5dyrBmjW80OaBpmLQNGDM6T1E/0H+eP6EtFQLPUR/Wxo2dFO3p1JQF87JyftJCVSvpz4rBmqOH7zvso3XZf0/wlQZ5xwC/15zjv54BPtkdIwWT6C3I+kcd5JZf8t93ljK0X/6fRFJi8= Received: by 10.115.33.1 with SMTP id l1mr549353waj.17.1197596815303; Thu, 13 Dec 2007 17:46:55 -0800 (PST) Received: by 10.114.155.16 with HTTP; Thu, 13 Dec 2007 17:46:55 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 10:46:55 +0900 From: "Simon Flannery" To: "Dean Willis" Subject: Re: [Sip] Early or Late media In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thank you Dean for your prompt response and making this source of confusion sound so simple. Regards, Simon On 12/14/07, Dean Willis wrote: > > On Dec 12, 2007, at 10:32 PM, Simon Flannery wrote: > > > > I would like to check my understanding of Early and Late media also > > know as Early (or Late) operating mode: > > > > - Using Early media, the inviting user may talk immediately, and the > > core network should buffer the media before the invited user (or > > users) accept the session > > - The received media is buffered until at least the first invited user > > accepts the invitation > > - The buffered media is also sent to all users that accept the > > invitation > > - Conversely, Late media mimics a traditional phone call where the > > inviting user must wait until at least one inviting user accepts the > > session before being allowed to send media > > > > Is my understanding correct? Are any of the dot points in error? > > > > > > Welcome to one of the most confusing aspects among the many confusing > aspects of SIP that were introduced by our attempts to compensate for > the broken signaling model of ISUP. Personally, I think we > unwittingly introduced a nightmarish level of complexity and should > have just said "no! If you need two stage signaling, finalize the > first stage with a 200 OK and then re-INVITE if the SDP changes for > the second session." But we didn't do that, so we have what we have. > > IETF seems to use the terms "early media" and "early session", > although I'm afraid I don't completely understand the nuances despite > having struggled with them for many years. I suspect I don't want to > understand just because the whole thing hurts my delicate > sensibilities. I'm told that RFC 3960 is a useful reference for this > discussion. > > Both uses of "early" refer to the transmission of media before > completion of some phase of the signaling. Sometimes this is mean to > be "before completion of the offer/answer phase" (that is, after an > "offer", but before an "answer", and sometimes (as defined in RFC > 3960) before the completion of a final response (generally a 200) to > an INVITE request. > > RFC 3960 uses the following definition: > > Early media refers to media (e.g., audio and video) that is > exchanged > before a particular session is accepted by the called user. > Within a > dialog, early media occurs from the moment the initial INVITE is > sent > until the User Agent Server (UAS) generates a final response. It > may > be unidirectional or bidirectional, and can be generated by the > caller, the callee, or both. Typical examples of early media > generated by the callee are ringing tone and announcements (e.g., > queuing status). Early media generated by the caller typically > consists of voice commands or dual tone multi-frequency (DTMF) tones > to drive interactive voice response (IVR) systems. > > In IETF and general IMS environments (AFAIK), there is no expectation > that early media will be buffered. Anything not received by a > listener is expected to be discarded. > > However, OMA's Push to talk Over Cellular (POC) specification does > (or at least did, the last time I looked) allow a predictive mode > where a POC controller (which is for all practical purposes a SIP > B2BUA with media handling) can "answer" on behalf of a POC terminal > with which it has an active relationship. The POC controller then > buffers media while it activates the radio bearer needed to send the > media on to the terminating POC client. Since the POC controller has > effectively "answered" the INVITE request with a terminal response > and media answer, I don't believe this mode qualifies as "early > media" by any of the definitions in use around the IETF. > > Good luck in sorting this all out. > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 03:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35fV-00040C-5q; Fri, 14 Dec 2007 03:13:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J35fT-0003zx-Bf for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 03:13:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35fM-0003vF-Ts for sip@ietf.org; Fri, 14 Dec 2007 03:13:04 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J35fM-0007W4-GK for sip@ietf.org; Fri, 14 Dec 2007 03:13:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Dec 2007 00:13:03 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBE8D4ZS014591; Fri, 14 Dec 2007 00:13:04 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBE8D3CD013748; Fri, 14 Dec 2007 08:13:03 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Simon Flannery'" References: Subject: RE: [Sip] Early or Late media Date: Fri, 14 Dec 2007 00:13:03 -0800 Message-ID: <165601c83e29$26728600$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acg9yc3Ex1JHGMGLTCmxYP2xyWd0kQAXtQ9g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1918; t=1197619984; x=1198483984; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Early=20or=20Late=20media |Sender:=20; bh=//x1wAWNYaoX4dVwunrN9vP6rYypMcEDe1cQP6biTfg=; b=cW2hQ9mInyBMK2uHWzawyXeAv46ipLfoq0Kp1JOYZXyrEmvYwjhUj7rmT2 Y42IyZZwXJ6xQrG/H3H2gwLKbzNdlDm/auuH5XjDxQlgOe6rCE/ebbUrTIF6 yPoQo/nfI0; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ... > In IETF and general IMS environments (AFAIK), there is no > expectation that early media will be buffered. Brian Stucker's draft-sipping-stucker-media-path-middleboxes-00 does mention a situation where queuing can occur with 'latching' (commonly done by SBCs when they do 'hosted NAT traversal'): ... 13. Media from the UAS is relayed to the UAC. It is up to local policy at the media relay as to whether or not packets that had arrived from the UAS for the UAC are queued or dropped prior to ^^^^^^ the UAC's address/port information being updated in step 11. ... This might be what Simon was thinking about (or had heard about). -d > Anything > not received by a listener is expected to be discarded. > > However, OMA's Push to talk Over Cellular (POC) specification does > (or at least did, the last time I looked) allow a predictive mode > where a POC controller (which is for all practical purposes a SIP > B2BUA with media handling) can "answer" on behalf of a POC terminal > with which it has an active relationship. The POC controller then > buffers media while it activates the radio bearer needed to send the > media on to the terminating POC client. Since the POC controller has > effectively "answered" the INVITE request with a terminal response > and media answer, I don't believe this mode qualifies as "early > media" by any of the definitions in use around the IETF. > > Good luck in sorting this all out. > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 12:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EP8-0006tZ-R8; Fri, 14 Dec 2007 12:32:54 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3EP7-0006tS-93 for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 12:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EP6-0006tJ-Vf for sip@ietf.org; Fri, 14 Dec 2007 12:32:52 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3EP6-00039V-N0 for sip@ietf.org; Fri, 14 Dec 2007 12:32:52 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 12:32:52 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 12:32:52 -0500 From: Hadriel Kaplan To: "sip@ietf.org" Date: Fri, 14 Dec 2007 12:27:52 -0500 Thread-Topic: MESSAGE for rendering Thread-Index: Acg+dqgqYS7BX6waS9O7owPwRjXqag== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] MESSAGE for rendering X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Regarding the INFO use-case discussion, one comment from people is MESSAGE = is really for things to be rendered to the user, and not for such things as= vcards or vcalendars. Not that I want to contradict myself on it being a = valid use-case for INFO, but personally I'm not so sure that vcard/vcalenda= r is wrong for MESSAGE. I mean we can argue if sending that type of data i= s really justification for an "Instant Message" request, but I'm talking mo= re about whether content that isn't directly rendered to the user can be pu= t into MESSAGE. In some ways a vcard/vcalendar *is* being rendered to the user - it's just = that by definition the content type is formatted in a vcard or vcalendar fo= rmat and needs to be interpreted, if the app understands it. Just as, for = example, a MESSAGE can contain message/cpim when we don't really expect to = visibly render the message/cpim headers without interpretation. It just so happens that some applications know a vcard/vcalendar type conte= nt can be integrated into their contact or calendar program, and bypass "re= ndering" it directly to the user in visible form. From a SIP protocol pers= pective it is still user "data" for "rendering". -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 12:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EYJ-0004jN-Im; Fri, 14 Dec 2007 12:42:23 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3EYI-0004i0-6H for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 12:42:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EYH-0004hs-Ra for sip@ietf.org; Fri, 14 Dec 2007 12:42:21 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3EYH-0004A9-8J for sip@ietf.org; Fri, 14 Dec 2007 12:42:21 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBEHgJX6023939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Dec 2007 11:42:20 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Fri, 14 Dec 2007 11:42:13 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Sip] On The Essentialness of Corrections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith has been kind enough to define a process for rolling up all the updates/corrections/revisions to RFC 3261 we might process in a given year into a single document. This process is documented in draft- drage-sip-essential-correction-02. We hope to apply this same process to other RFCs in the core set. We've recently been having some discussion on what, if any, drafts should be steered into this process vs. conventional standards and BCP tracks. Let's revisit the rationale for the "essential corrections" process: the idea is to reduce the number of documents that an implementer will have to read in order to produce a correct implementation of our RFCs. Problems and their corrections belong not in a bug-tracking system, but need to be resolved in IETF-published documents. I believe that Jonathan sees draft-ietf-sip-hitchhikers-guide-04 as the place where all of the core RFCs, their extensions, and corrections thereto are put into a usable order and given the perspective needed to make them work. That's certainly one way to track the relationships between various documents, and I think we need it. But I think we need something else. There are two primal approaches to updating RFCs. In one, every change is an optional extension to the RFC that might or might not be used. Negotiation mechanisms like option tags are required for every extension, as is fallback behavior to operation without that extension. The nature of the core protocol remains unchanged -- perhaps certain modalities are never exercised, but they remain in the specifications as paths that need to be tested for when considering compliance against the specifications. The second approach is to issue revisions that actually change the specification, potentially eliminating or replacing entire blocks of functionality that need no longer be tested, and potentially inserting new behavior that becomes "the standard" against which implementations are judged. The most obvious way to make these sort of changes to an RFC is to issue a new RFC that replaces (and makes obsolete) an older one. IETF also allows new RFCs to "revise" older ones, essentially including them by reference into a new specification. The problem with this approach is that it might be possible for many such revisions to be made to a large spec such as RFC 3261, and it then becomes very difficult to effectively "merge" all these changes into a working specification against which one can implement (and test) correctly. Out "essential corrections" process is an attempt to manage the complexity of many revisions by collecting those revisions into periodic batches and issuing each batch as an RFC that revises a core specification. The question is: Which, if any, changes need to be processed as extensions and which as revisions? Here's a test I'd like to propose: If the change is such that if we were re-writing the affected RFC we'd include the new behavior as normative behavior, then we track it as a revision. This allows us to fully deprecate the behavior that it replaces, such that we no longer have to consider the old behavior when compliance testing. If we can't deprecate the replaced behavior, then we really do have an extension (not a revision), and we need an extension negotiation mechanism to know when it can be used or is being used. I'd actually like to see us go beyond the batching of "essential corrections" and start maintaining complete and fully-revised versions of the normative behaviors as internet drafts, perhaps occasionally publishing them as RFCs that replace the older versions. So for example with RFC 3261, we'd maintain a "draft-ietf-sip-rfc3261- bis" that would start as a copy of RFC 3261 (with current boilerplate, of course) and then be edited to reflect the changes documented in each "essential correction" we agree to. Then instead of telling implementors to go read RFC 3261 plus a dozen more potentially conflicting revision documents, we could just say "see draft-ietf-sip-rfc3261-bis-xx". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 12:48:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EdX-00007G-M8; Fri, 14 Dec 2007 12:47:47 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3EdV-00007B-Vn for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 12:47:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EdV-000072-LW for sip@ietf.org; Fri, 14 Dec 2007 12:47:45 -0500 Received: from harjus.tutpro.com ([192.98.100.3] helo=taimen.tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3EdV-0004Ih-9p for sip@ietf.org; Fri, 14 Dec 2007 12:47:45 -0500 Received: by taimen.tutpro.com (Postfix, from userid 1000) id 3E66633AD54; Fri, 14 Dec 2007 19:48:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18274.49630.187002.201831@harjus.tutpro.com> Date: Fri, 14 Dec 2007 19:48:14 +0200 To: Dean Willis Subject: [Sip] On The Essentialness of Corrections In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > Then instead > of telling implementors to go read RFC 3261 plus a dozen more > potentially conflicting revision documents, we could just say "see > draft-ietf-sip-rfc3261-bis-xx". that sounds like a good idea. would only corrections go to the bis documents or would also clarifications be allowed? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 15:05:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Gm1-0000RF-Cr; Fri, 14 Dec 2007 15:04:41 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Gm0-0000R9-6Q for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 15:04:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Glz-0000R1-Rk for sip@ietf.org; Fri, 14 Dec 2007 15:04:39 -0500 Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Gly-0007Rl-JK for sip@ietf.org; Fri, 14 Dec 2007 15:04:39 -0500 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA07.westchester.pa.mail.comcast.net with comcast id QexL1Y00D0EZKEL050bD00; Fri, 14 Dec 2007 20:04:38 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA01.westchester.pa.mail.comcast.net with comcast id Qk4d1Y00L0umElk3M00000; Fri, 14 Dec 2007 20:04:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=G2dL6reFpCcA:10 a=29npO9jLTnaJFMPXRVgA:9 a=_3BEVdpI-fnIrWAbHEyXgcuEiFoA:4 a=3FZX-ydVlcEA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lBEK4bPC008681 for ; Fri, 14 Dec 2007 15:04:37 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lBEK4bCP008677; Fri, 14 Dec 2007 15:04:37 -0500 Date: Fri, 14 Dec 2007 15:04:37 -0500 Message-Id: <200712142004.lBEK4bCP008677@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4761B755.60007@lucent.com> (vkg@alcatel-lucent.com) Subject: Re: [Sip] connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse" References: <4761B755.60007@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Vijay K. Gurbani" Connection Reuse: The process of using the same connection to send new requests in the backwards direction (i.e., A opens a connection to B to send requests, and B uses the same connection to send new requests to A.) Connection sharing: The process of using the same connection to send multiple requests on the same connection (and of course, receive multiple responses over the connection.) A shared connection will not be reused for requests in the backwards direction. Comments? Thoughts? Suggestions? Other terms to document? This is good, but I'd replace the sentence "A shared connection will not..." with "Connection sharing does not imply connection reuse." Once you get that straightened out, you can say "TCP connections are shared by default, but should not be reused except when the recipient has some way to authenticate the source." If "shared" *excludes* "reused", that straightforward statment requires awkward circumlocutions. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 15:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HKG-0005JO-HU; Fri, 14 Dec 2007 15:40:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3HKF-0005JH-6a for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 15:40:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HKE-0005J9-Q4 for sip@ietf.org; Fri, 14 Dec 2007 15:40:02 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3HKE-0001U1-CQ for sip@ietf.org; Fri, 14 Dec 2007 15:40:02 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lBEKdkPE018924; Fri, 14 Dec 2007 14:39:46 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lBEKdlj11459; Fri, 14 Dec 2007 14:39:47 -0600 (CST) Message-ID: <4762EA12.3070000@alcatel-lucent.com> Date: Fri, 14 Dec 2007 14:39:46 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse" References: <4761B755.60007@lucent.com> <200712142004.lBEK4bCP008677@dragon.ariadne.com> In-Reply-To: <200712142004.lBEK4bCP008677@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: "Vijay K. Gurbani" > > Connection Reuse: The process of using the same connection to send > new requests in the backwards direction (i.e., A opens a connection > to B to send requests, and B uses the same connection to send > new requests to A.) > > Connection sharing: The process of using the same connection to send > multiple requests on the same connection (and of course, receive > multiple responses over the connection.) A shared connection will > not be reused for requests in the backwards direction. > > Comments? Thoughts? Suggestions? Other terms to document? > > This is good, but I'd replace the sentence "A shared connection will > not..." with "Connection sharing does not imply connection reuse." Perfect; I'll make the change. Thanks, Dale. > Once you get that straightened out, you can say "TCP connections are > shared by default, but should not be reused except when the recipient > has some way to authenticate the source." I will say something to the following effect: ... Connection sharing does not imply connection reuse except when the recipient has some assurance of the authenticity of the source. Since this text that defines these terms will go in the beginning of the draft (probably in the terminology section), I will leave out the details of which connections can be shared by default (like TLS) and which ones (like TCP) should only be shared under certain circumstances. The reader will, in time, read the relevant sections and arrive at the requisite conclusion. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 16:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Hp0-0000gc-JM; Fri, 14 Dec 2007 16:11:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Hoz-0000gI-Ey for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 16:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Hoz-0000g7-4p for sip@ietf.org; Fri, 14 Dec 2007 16:11:49 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Hoy-00016g-3u for sip@ietf.org; Fri, 14 Dec 2007 16:11:49 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id lBELBh0H026597; Fri, 14 Dec 2007 15:11:43 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lBELBaj27424; Fri, 14 Dec 2007 15:11:43 -0600 (CST) Message-ID: <4762F188.4080409@alcatel-lucent.com> Date: Fri, 14 Dec 2007 15:11:36 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > I'd actually like to see us go beyond the batching of "essential > corrections" and start maintaining complete and fully-revised > versions of the normative behaviors as internet drafts, perhaps > occasionally publishing them as RFCs that replace the older versions. We are still talking the sip-essential-correction model here, right? Or is what you propose above a new model? > So for example with RFC 3261, we'd maintain a > "draft-ietf-sip-rfc3261-bis" that would start as a copy of RFC 3261 > (with current boilerplate, of course) and then be edited to reflect > the changes documented in each "essential correction" we agree to. > Then instead of telling implementors to go read RFC 3261 plus a dozen > more potentially conflicting revision documents, we could just say > "see draft-ietf-sip-rfc3261-bis-xx". Isn't that what we essentially did with rfc2543-bis set of drafts? Of course, the domain of influence of SIP back then was a bit more limited than it is now. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 16:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IUG-0005n0-U5; Fri, 14 Dec 2007 16:54:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3IUF-0005fa-Fr for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 16:54:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IUF-0005ck-3j for sip@ietf.org; Fri, 14 Dec 2007 16:54:27 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3IUE-0003is-NO for sip@ietf.org; Fri, 14 Dec 2007 16:54:27 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2007 16:54:26 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBELsQR7013545; Fri, 14 Dec 2007 16:54:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBELs9ZS027697; Fri, 14 Dec 2007 21:54:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 16:54:19 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 16:54:19 -0500 Message-ID: <4762FB8B.2020308@cisco.com> Date: Fri, 14 Dec 2007 16:54:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] MESSAGE for rendering References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 21:54:19.0555 (UTC) FILETIME=[E0FC6730:01C83E9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2022; t=1197669266; x=1198533266; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=wv6F/HPL3oiwiks0MKS8od1enqXRdZZtlL9V12YkEMA=; b=Gl4g0cjaBvgZ1W6bBHpa5z1zyhKzL0ND8jXZjCbYHAmyFYb91xe5c0hw5p TsLHOuFTYc6fCrUi1U1cHe1MK/X6nCBZTZO9WonmkGtsf8kfatrbSX0ELiqj 9oGWp7f5i0; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel, I am entirely with you if the *intent* of sending the vcard is to render it to the user in some human readable way. Its hardly any different from sending HTML. Its much more questionable if the intent is that the vcard be filed in the recipients address book without being rendered. Even so, I think it is an open question whether content-dispositions other than "render" are valid with MESSAGE. And if so, which ones? Paul Hadriel Kaplan wrote: > Regarding the INFO use-case discussion, one comment from people is MESSAGE is really for things to be rendered to the user, and not for such things as vcards or vcalendars. Not that I want to contradict myself on it being a valid use-case for INFO, but personally I'm not so sure that vcard/vcalendar is wrong for MESSAGE. I mean we can argue if sending that type of data is really justification for an "Instant Message" request, but I'm talking more about whether content that isn't directly rendered to the user can be put into MESSAGE. > > In some ways a vcard/vcalendar *is* being rendered to the user - it's just that by definition the content type is formatted in a vcard or vcalendar format and needs to be interpreted, if the app understands it. Just as, for example, a MESSAGE can contain message/cpim when we don't really expect to visibly render the message/cpim headers without interpretation. > > It just so happens that some applications know a vcard/vcalendar type content can be integrated into their contact or calendar program, and bypass "rendering" it directly to the user in visible form. From a SIP protocol perspective it is still user "data" for "rendering". > > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 17:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3J83-0002vU-Ey; Fri, 14 Dec 2007 17:35:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3J82-0002vP-CW for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 17:35:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3J81-0002vH-Uj for sip@ietf.org; Fri, 14 Dec 2007 17:35:34 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3J81-0004hI-77 for sip@ietf.org; Fri, 14 Dec 2007 17:35:33 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2007 14:35:30 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBEMZURP030597; Fri, 14 Dec 2007 14:35:30 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBEMZ2CR021982; Fri, 14 Dec 2007 22:35:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:35:26 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:35:25 -0800 Message-ID: <47630555.7090605@cisco.com> Date: Fri, 14 Dec 2007 17:36:05 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 22:35:25.0875 (UTC) FILETIME=[9F06F830:01C83EA1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3344; t=1197671730; x=1198535730; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20On=20The=20Essentialness=20of=2 0Corrections |Sender:=20; bh=YXFr7Li5qb1aurfd+kJa2Hi5yDmDxOzxBoKJ9L/yQO0=; b=0g1y73a4rkQF3OjB3auoTINeqnR5U/AMrFIbRkeoIgZvsOGNyEnd7dX5kv 9DR4SuDTgSIuvzDAkKThc/UO+VyqG8KrZI4+voLZDX9JPOfD6JYB62NXRgqx psjXcNKi/O; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline: Dean Willis wrote: > Here's a test I'd like to propose: If the change is such that if we were > re-writing the affected RFC we'd include the new behavior as normative > behavior, then we track it as a revision. This allows us to fully > deprecate the behavior that it replaces, such that we no longer have to > consider the old behavior when compliance testing. If we can't deprecate > the replaced behavior, then we really do have an extension (not a > revision), and we need an extension negotiation mechanism to know when > it can be used or is being used. I'm not sure I agree with this. I think we have some extensions which we'd arguably include as, 'things we'd make as new normative behavior that is core to sip'. I personally would have wished that nat traversal were an integral part of sip and if I could do it over, would not have it split out. But clearly ICE and outbound and all that are not essential corrections. In my mind, the right litmus test is that the new behavior: 1. cannot be negotiated using the standardized techniques, AND 2. represents a change that impacts interoperability with other implementations which might not implement this new behavior THEN its an essential correction. THings like BNF bugs are clearly in scope. Something like record-route fix doesn't meet this litmus test because of the second item. I can implement this and fully interoperate with existing implementations. > > I'd actually like to see us go beyond the batching of "essential > corrections" and start maintaining complete and fully-revised versions > of the normative behaviors as internet drafts, perhaps occasionally > publishing them as RFCs that replace the older versions. So for example > with RFC 3261, we'd maintain a "draft-ietf-sip-rfc3261-bis" that would > start as a copy of RFC 3261 (with current boilerplate, of course) and > then be edited to reflect the changes documented in each "essential > correction" we agree to. Then instead of telling implementors to go read > RFC 3261 plus a dozen more potentially conflicting revision documents, > we could just say "see draft-ietf-sip-rfc3261-bis-xx". I thought the idea is that there is just one revision document (essential corrections) and not seven. I promise you that once you open the floodgates to an rfc3261 revision spec, the temptation to do LOTS of other things to the document will be too great. Clarify this while we're at it? OK. Maybe we should pull that extension in. ANd so on. I don't want to do that. Segmenting this into an essential corrections document keeps pandoras box from opening. The amount of work that went into rfc2543 -> rfc3261 was astoundingly large, as any of the editors who basically did this as a full time job for like 6 months will tell you (my boss would ask me when I was coming back to work...). I do not think we as a working group have or want to spend the cycles on such a monumentally large task at this time. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 17:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JAn-0005qk-5t; Fri, 14 Dec 2007 17:38:25 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3JAm-0005qf-Gu for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 17:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JAm-0005qX-77 for sip@ietf.org; Fri, 14 Dec 2007 17:38:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JAl-00032s-Pi for sip@ietf.org; Fri, 14 Dec 2007 17:38:24 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Dec 2007 14:38:23 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBEMcNI3022241; Fri, 14 Dec 2007 14:38:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBEMcNCD024972; Fri, 14 Dec 2007 22:38:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:38:23 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 14:38:22 -0800 Message-ID: <47630606.1000908@cisco.com> Date: Fri, 14 Dec 2007 17:39:02 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Simon Flannery Subject: Re: [Sip] Early or Late media References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 22:38:22.0891 (UTC) FILETIME=[088977B0:01C83EA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1495; t=1197671903; x=1198535903; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Early=20or=20Late=20media |Sender:=20; bh=XUvnAMkq4Gv6SL1EFDfZCyy+Wx7zJRdNKvqdtuI08Zs=; b=mGBlP4Cn2klKiVgEdmPhWm3wnSpoq5abmTB1uLE8R0X4+b1duOtr2yNlnK IFb31KoCs5O/gMDG9J/Pvgh7D8Q1X6mRyyjZlHG6zzSg35k4l2WFknxYTWUv eF5DHWr7jg; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline: Simon Flannery wrote: > Hi all, > > I know this is a SIP dedicated mail list and not designed for IMS > related questions but I do not know where else I could post. > > I would like to check my understanding of Early and Late media also > know as Early (or Late) operating mode: > > - Using Early media, the inviting user may talk immediately, and the > core network should buffer the media before the invited user (or > users) accept the session buffer? as in, the network would hold the media and delivered to the called party only after 200 OK? No IETF spec makes that recommendation. > - The received media is buffered until at least the first invited user > accepts the invitation As above. > - The buffered media is also sent to all users that accept the invitation > - Conversely, Late media mimics a traditional phone call where the > inviting user must wait until at least one inviting user accepts the > session before being allowed to send media SIP says that the calling UA must be prepared to accept media after sending an offer. The called UA has to be prepared to receive after sending the answer. There is nothing about buffering. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 18:14:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JjO-0005Wt-IG; Fri, 14 Dec 2007 18:14:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3JjM-0005Wo-6f for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:14:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JjL-0005Wg-SR for sip@ietf.org; Fri, 14 Dec 2007 18:14:07 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3JjL-00067L-HC for sip@ietf.org; Fri, 14 Dec 2007 18:14:07 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 18:14:07 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 18:14:07 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 14 Dec 2007 18:09:22 -0500 Subject: RE: [Sip] MESSAGE for rendering Thread-Topic: [Sip] MESSAGE for rendering Thread-Index: Acg+m+WjXgBStFcCTsabr5d22PWf7QABT6cg Message-ID: References: <4762FB8B.2020308@cisco.com> In-Reply-To: <4762FB8B.2020308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, December 14, 2007 4:54 PM > To: Hadriel Kaplan > Cc: sip@ietf.org > Subject: Re: [Sip] MESSAGE for rendering > > Hadriel, > > I am entirely with you if the *intent* of sending the vcard is to render > it to the user in some human readable way. Its hardly any different from > sending HTML. > > Its much more questionable if the intent is that the vcard be filed in > the recipients address book without being rendered. > > Even so, I think it is an open question whether content-dispositions > other than "render" are valid with MESSAGE. And if so, which ones? I guess the question is if "render" is synonymous with "inline", as 3261 so= unds like it is? If so, then I think you're right "render" is wrong. How = is it done in email? I think content-disposition "attachment" vs. inline. = So yeah, the question is if MESSAGE can handle non-render ones. (clearly = "session" would NOT be valid :) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 18:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Jwd-00051C-1K; Fri, 14 Dec 2007 18:27:51 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Jwb-000516-98 for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:27:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Jwa-00050y-Vm for sip@ietf.org; Fri, 14 Dec 2007 18:27:48 -0500 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Jwa-00045K-IO for sip@ietf.org; Fri, 14 Dec 2007 18:27:48 -0500 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id QlY91Y00F0mlR8U0A09X00; Fri, 14 Dec 2007 23:27:53 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id QnTr1Y0070umElk8X00000; Fri, 14 Dec 2007 23:27:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=9BcAZO5vLVsiOuOlEw4A:9 a=dFAO3tKwpzy4TCXN6YAA:7 a=2ye5IWAOkg2fW1Te4Vr-3eAGJewA:4 a=JfD0Fch1gWkA:10 a=8y7tGHue6YMA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lBENRjPC023458 for ; Fri, 14 Dec 2007 18:27:45 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lBENRjRq023454; Fri, 14 Dec 2007 18:27:45 -0500 Date: Fri, 14 Dec 2007 18:27:45 -0500 Message-Id: <200712142327.lBENRjRq023454@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4762FB8B.2020308@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat I am entirely with you if the *intent* of sending the vcard is to render it to the user in some human readable way. Its hardly any different from sending HTML. Its much more questionable if the intent is that the vcard be filed in the recipients address book without being rendered. IMHO, filing information is as good as actually rendering it. The real question is layering -- "render" means "deliver to the layer above the SIP UA". Anything that partakes of media is "rendered" and is acceptable for MESSAGE, anything that partakes of signaling is not "rendered" and is acceptable for INFO. One criterion is "Would it make sense to let the user arbitrarily re-route where this information goes?" With a vcard, it makes sense. With the information INFO was intended to carry, it does not: RFC 2976 1.1 Example Uses The following are a few of the potential uses of the INFO message: - Carrying mid-call PSTN signaling messages between PSTN gateways. - Carrying DTMF digits generated during a SIP session. - Carrying wireless signal strength information in support of wireless mobility applications. - Carrying account balance information. [in a pay-as-you-go network -- DRW] Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 18:39:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3K7f-0008UJ-AY; Fri, 14 Dec 2007 18:39:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3K7d-0008UE-Mx for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 18:39:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3K7d-0008U6-BE for sip@ietf.org; Fri, 14 Dec 2007 18:39:13 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3K7c-0006hB-So for sip@ietf.org; Fri, 14 Dec 2007 18:39:13 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 18:39:12 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 18:39:12 -0500 From: Hadriel Kaplan To: "Dale.Worley@comcast.net" , "sip@ietf.org" Date: Fri, 14 Dec 2007 18:34:29 -0500 Subject: RE: [Sip] MESSAGE for rendering Thread-Topic: [Sip] MESSAGE for rendering Thread-Index: Acg+qPY4r2ZirmevQhuvCL41KY8J0gAAGwvQ Message-ID: References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> In-Reply-To: <200712142327.lBENRjRq023454@dragon.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org More importantly MESSAGE allows out-of-dialog requests. :) I was thinking the same as you, but I believe Paul's right in that render= =3Dinline and vcard/vcalendar are not inline. The question is if we want t= o let "attachment" disposition be allowed. I dread to do that, because peo= ple are already using MESSAGE to transfer 10MB images, but that's a separat= e ugly problem. :( -hadriel > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Friday, December 14, 2007 6:28 PM > To: sip@ietf.org > Subject: Re: [Sip] MESSAGE for rendering > > From: Paul Kyzivat > > I am entirely with you if the *intent* of sending the vcard is to > render > it to the user in some human readable way. Its hardly any different > from > sending HTML. > > Its much more questionable if the intent is that the vcard be filed in > the recipients address book without being rendered. > > IMHO, filing information is as good as actually rendering it. The > real question is layering -- "render" means "deliver to the layer > above the SIP UA". Anything that partakes of media is "rendered" and > is acceptable for MESSAGE, anything that partakes of signaling is not > "rendered" and is acceptable for INFO. > > One criterion is "Would it make sense to let the user arbitrarily > re-route where this information goes?" With a vcard, it makes sense. > With the information INFO was intended to carry, it does not: > > RFC 2976 1.1 Example Uses > > The following are a few of the potential uses of the INFO message: > > - Carrying mid-call PSTN signaling messages between PSTN > gateways. > > - Carrying DTMF digits generated during a SIP session. > > - Carrying wireless signal strength information in support of > wireless mobility applications. > > - Carrying account balance information. > [in a pay-as-you-go network -- DRW] > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 19:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KUw-0002YC-O5; Fri, 14 Dec 2007 19:03:18 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3KUv-0002Wg-OE for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 19:03:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KUv-0002WY-D5 for sip@ietf.org; Fri, 14 Dec 2007 19:03:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3KUu-00077Y-SE for sip@ietf.org; Fri, 14 Dec 2007 19:03:17 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2007 16:03:16 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBF03GS2003287; Fri, 14 Dec 2007 16:03:16 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBF03B9N009244; Sat, 15 Dec 2007 00:03:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:03:11 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:03:10 -0500 Message-ID: <476319BE.3050600@cisco.com> Date: Fri, 14 Dec 2007 19:03:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2007 00:03:10.0728 (UTC) FILETIME=[E11FC880:01C83EAD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3055; t=1197676996; x=1198540996; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20; bh=NxrrG5wbE+9LDcZJnPdKm4qcAS/FaRnMmofccspgvEg=; b=luo43aLqit3alRJPwdO4S++J/+7+UCDJ8ZxZIks+wtLMzkO0di1qFMwZG6 eSP1uZILvECqkR9cikU3BscteQmoaWWNNMSwDGG9wZSj32NNs/QdXn1lGYgL fv4LWOf5wM; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, December 14, 2007 4:54 PM >> To: Hadriel Kaplan >> Cc: sip@ietf.org >> Subject: Re: [Sip] MESSAGE for rendering >> >> Hadriel, >> >> I am entirely with you if the *intent* of sending the vcard is to render >> it to the user in some human readable way. Its hardly any different from >> sending HTML. >> >> Its much more questionable if the intent is that the vcard be filed in >> the recipients address book without being rendered. >> >> Even so, I think it is an open question whether content-dispositions >> other than "render" are valid with MESSAGE. And if so, which ones? > > I guess the question is if "render" is synonymous with "inline", as 3261 sounds like it is? I'm not very well informed of MIME, but I question whether "render" is synononymous with "inline". Rather I suspect "render" was chosen because "inline" didn't make sense for SIP. My impression is that with mail "inline" is used for "extra" body parts to indicate that they should be rendered "inline" with the rendering of the overall message, which makes sense since for mail the expectation is that the overall message *is* being rendered. So the headers of the message are rendered (usually not literally, but rather in a pretty way), and the body parts marked inline are rendered inline with that. In the case of sip, the overall message is *not* being rendered, at least not in the case of INVITE. (At the time this was being defined MESSAGE wasn't in the picture.) If "render" were used with a body part in an invite, then I think it makes sense to expect that the UA goes out of its way to present it to the user of the device in some way - unusual because most invites don't have this. If somebody had thought about it at the time, MESSAGE should probably have been handled just like mail, using "inline" and "attachment", etc. But I guess for purposes of MESSAGE we might be able to treat inline and render as synonymous. > If so, then I think you're right "render" is wrong. How is it done in email? I think content-disposition "attachment" vs. inline. So yeah, the question is if MESSAGE can handle non-render ones. (clearly "session" would NOT be valid :) Attachment could be good for a vcard in a MESSAGE. But it might be a bit strange without also having an inline or render part as well. (Just as it would be strange to get an email that only had "attachment" parts - there is nothing to attach them to.) So you might have a MESSAGE that says: "Here is my vcard." and has the vcard as an attachment. Paul > -hadriel > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 19:14:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Kem-0001gi-Df; Fri, 14 Dec 2007 19:13:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Kek-0001dq-Pg for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 19:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Kek-0001dZ-Fs for sip@ietf.org; Fri, 14 Dec 2007 19:13:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Kej-0004pc-W0 for sip@ietf.org; Fri, 14 Dec 2007 19:13:26 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2007 19:13:24 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBF0DN0s011476; Fri, 14 Dec 2007 19:13:23 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBF0AbZM005880; Sat, 15 Dec 2007 00:13:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:08:56 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:08:56 -0500 Message-ID: <47631B18.4070705@cisco.com> Date: Fri, 14 Dec 2007 19:08:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> In-Reply-To: <200712142327.lBENRjRq023454@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2007 00:08:56.0736 (UTC) FILETIME=[AF5C6A00:01C83EAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2387; t=1197677603; x=1198541603; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=AdGWCvq1epr1oGLtlX9HCZMxyIvXuQewLwQ/imBXwM8=; b=OP8cN369ShNGLT8Dyr3RPJhU9lVbYjFR4DQSG7DCFrcDd9NevuCAO+hVaN nInPVAxDnDuxZqHmjyiYZS49djWLKai1QMgFR7iQFM0Pkvbh1RRjBdTasTA6 IX7Eayu1uD; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > I am entirely with you if the *intent* of sending the vcard is to render > it to the user in some human readable way. Its hardly any different from > sending HTML. > > Its much more questionable if the intent is that the vcard be filed in > the recipients address book without being rendered. > > IMHO, filing information is as good as actually rendering it. The > real question is layering -- "render" means "deliver to the layer > above the SIP UA". Does it? Lots of things could mean that. E.g. "inline" and "attachment" could mean that too. If the "layer above the sip ua" can get these things with different dispositions then we have simply passed the buck on what it means. I *think* each different type of sip message needs to define the content dispositions that are valid with it and what they mean for it. > Anything that partakes of media is "rendered" and > is acceptable for MESSAGE, anything that partakes of signaling is not > "rendered" and is acceptable for INFO. I don't understand the above. > One criterion is "Would it make sense to let the user arbitrarily > re-route where this information goes?" With a vcard, it makes sense. > With the information INFO was intended to carry, it does not: I'm not certain I understand that either, or to the extent I do I don't know how to operationalize it. > RFC 2976 1.1 Example Uses > > The following are a few of the potential uses of the INFO message: > > - Carrying mid-call PSTN signaling messages between PSTN > gateways. > > - Carrying DTMF digits generated during a SIP session. > > - Carrying wireless signal strength information in support of > wireless mobility applications. > > - Carrying account balance information. > [in a pay-as-you-go network -- DRW] Balance, and maybe signal strength, could also be usefully rendered to the user. Paul > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 19:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Kes-0001mm-5M; Fri, 14 Dec 2007 19:13:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3Ker-0001kj-2g for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 19:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Keq-0001kT-NY for sip@ietf.org; Fri, 14 Dec 2007 19:13:32 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Keq-0004pk-8v for sip@ietf.org; Fri, 14 Dec 2007 19:13:32 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Dec 2007 19:13:32 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBF0DWao025248; Fri, 14 Dec 2007 19:13:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBF0AbZO005880; Sat, 15 Dec 2007 00:13:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:11:22 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 19:11:22 -0500 Message-ID: <47631BA9.5040904@cisco.com> Date: Fri, 14 Dec 2007 19:11:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2007 00:11:22.0097 (UTC) FILETIME=[0600BE10:01C83EAF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3037; t=1197677612; x=1198541612; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=nA0lW2C47dVxTJCrolCYgknGRQyw0LyarFoBEFOrwGA=; b=lduywLmvWDROurRJj090nuWxT9MylXIHKGVaxqUhG16HwNegsuXsPTeCrm hfmrA8W94nMvpZD92FPd+knQersetmHJ2OCwvDQvTA91YJ9Nz/f5NPPKurOx u+7Oge8zMj; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > More importantly MESSAGE allows out-of-dialog requests. :) > I was thinking the same as you, but I believe Paul's right in that render=inline and vcard/vcalendar are not inline. The question is if we want to let "attachment" disposition be allowed. I dread to do that, because people are already using MESSAGE to transfer 10MB images, but that's a separate ugly problem. :( I'm thinking that the body of a MESSAGE ought to allow almost all the same things, with the same meanings, as the body of an MSRP message. BUT it should be strictly limited in the overall size it can be. If what you want to send won't fit in a MESSAGE then switch to MSRP. Paul > -hadriel > > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Friday, December 14, 2007 6:28 PM >> To: sip@ietf.org >> Subject: Re: [Sip] MESSAGE for rendering >> >> From: Paul Kyzivat >> >> I am entirely with you if the *intent* of sending the vcard is to >> render >> it to the user in some human readable way. Its hardly any different >> from >> sending HTML. >> >> Its much more questionable if the intent is that the vcard be filed in >> the recipients address book without being rendered. >> >> IMHO, filing information is as good as actually rendering it. The >> real question is layering -- "render" means "deliver to the layer >> above the SIP UA". Anything that partakes of media is "rendered" and >> is acceptable for MESSAGE, anything that partakes of signaling is not >> "rendered" and is acceptable for INFO. >> >> One criterion is "Would it make sense to let the user arbitrarily >> re-route where this information goes?" With a vcard, it makes sense. >> With the information INFO was intended to carry, it does not: >> >> RFC 2976 1.1 Example Uses >> >> The following are a few of the potential uses of the INFO message: >> >> - Carrying mid-call PSTN signaling messages between PSTN >> gateways. >> >> - Carrying DTMF digits generated during a SIP session. >> >> - Carrying wireless signal strength information in support of >> wireless mobility applications. >> >> - Carrying account balance information. >> [in a pay-as-you-go network -- DRW] >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 14 19:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KzM-0006He-Dg; Fri, 14 Dec 2007 19:34:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3KzK-0006HW-E1 for sip-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 19:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KzK-0006HN-40 for sip@ietf.org; Fri, 14 Dec 2007 19:34:42 -0500 Received: from sacmail4.verizon.com ([192.76.84.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3KzJ-0005EC-F6 for sip@ietf.org; Fri, 14 Dec 2007 19:34:42 -0500 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id lBF0YS7d002372 for ; Fri, 14 Dec 2007 19:34:33 -0500 (EST) Received: from ftwccout01.verizon.com (ftwccout01.verizon.com [138.83.131.134]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id lBF0YSWO020279 for ; Fri, 14 Dec 2007 19:34:28 -0500 (EST) Received: from ftwccout01.verizon.com (unknown [127.0.0.1]) by ftwccout01.verizon.com (Symantec Mail Security) with ESMTP id 41487528003 for ; Fri, 14 Dec 2007 19:34:28 -0500 (EST) X-AuditID: 8a538386-a4beabb000000945-cd-47632113ab77 Received: from coregate2.verizon.com (unknown [138.83.34.48]) by ftwccout01.verizon.com (EMF) with ESMTP id D37C14E4003 for ; Fri, 14 Dec 2007 19:34:27 -0500 (EST) Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id lBF0b6Hj006631 for ; Fri, 14 Dec 2007 18:37:06 -0600 (CST) From: nabeel.2.cocker@verizon.com To: sip@ietf.org Message-ID: Date: Fri, 14 Dec 2007 19:34:20 -0500 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 7.0.2FP2HF294 | September 14, 2007) at 12/14/2007 18:34:21 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0403450169==" Errors-To: sip-bounces@ietf.org --===============0403450169== Content-type: multipart/alternative; Boundary="0__=0ABBF921DF90A2798f9e8a93df938690918c0ABBF921DF90A279" Content-Disposition: inline --0__=0ABBF921DF90A2798f9e8a93df938690918c0ABBF921DF90A279 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 12/14/2007 and will not return until 01/02/2008. I will respond to your message when I return. Regards, Nabeel --0__=0ABBF921DF90A2798f9e8a93df938690918c0ABBF921DF90A279 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 12/14/2007 and will not return until 01/02/2008.

I will respond to your message when I return.

Regards,
Nabeel --0__=0ABBF921DF90A2798f9e8a93df938690918c0ABBF921DF90A279-- --===============0403450169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0403450169==-- From sip-bounces@ietf.org Sat Dec 15 07:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WJT-0000RO-4j; Sat, 15 Dec 2007 07:40:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3WJQ-0000Q6-Hd for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 07:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WJQ-0000Py-7s for sip@ietf.org; Sat, 15 Dec 2007 07:40:12 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3WJO-0003Np-E4 for sip@ietf.org; Sat, 15 Dec 2007 07:40:12 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A6DDB20472; Sat, 15 Dec 2007 13:40:09 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-a2-4763cb2949a1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 771A42046D; Sat, 15 Dec 2007 13:40:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 13:40:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Sat, 15 Dec 2007 13:35:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: Acg9RcIPeJr0haUIToaZFrjQF+cTwAB0Tx3s References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> From: "Christer Holmberg" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 15 Dec 2007 12:40:09.0333 (UTC) FILETIME=[A0B8EA50:01C83F17] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >Correction, yes. Essential? Hardly. > >This is another question around essential corrections. I think they not >only need to clearly represent a bug or a fix, but need to be one that >is important enough to merit documenting. Just like software, sometimes >you don't ever bother fixing those sev 5s. Ever. So, who makes the decission whether a bug (I guess we all agree it IS a = bug) is "important enough"? My understanding is that this bug was found at SIPit, so it is not pure = "theoretical". I do agree with you that it shouldn't occur that often, because I see no = reason why one would need to use the affected characters.=20 But, never the less, the fix MAY be important from a parser = implementation perspective. Regards, Christer -Jonathan R. Christer Holmberg wrote: > Hi, >=20 > No matter how we'll fix this, I guess it would be a valid essential = correction? >=20 > Regards, >=20 > Christer > > ________________________________ > > L=E4hett=E4j=E4: Dale.Worley@comcast.net = [mailto:Dale.Worley@comcast.net] > L=E4hetetty: to 6.12.2007 21:09 > Vastaanottaja: sip@ietf.org > Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? > > > > From: Jonathan Rosenberg > > This strikes me as a problem in theory and not in practice. AFAICT, = the > only characters you can't use are ascii 0x00-0x19 (0x20 is space = and is > possible through the LWS construct as Christer pointed out). Is = there a > practical use case for any of these? They are: > > HT (horizontal tab) should be included, but that's also in LWS. As > for the remaining characters, I don't think that anyone has ever > *intended* that they be used in SIP headers, and their inclusion in > quoted-pair was a typographical error. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net = PHONE: (408) 902-3084 http://www.cisco.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 07:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WWz-0003Ee-1Y; Sat, 15 Dec 2007 07:54:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3WWy-0003EZ-7v for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 07:54:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WWx-0003ER-UW for sip@ietf.org; Sat, 15 Dec 2007 07:54:11 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J3WWx-0003eR-D8 for sip@ietf.org; Sat, 15 Dec 2007 07:54:11 -0500 X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1197723249!37916127!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7043 invoked from network); 15 Dec 2007 12:54:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 15 Dec 2007 12:54:10 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBFCs4wO024795 for ; Sat, 15 Dec 2007 05:54:09 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lBFCs4vL021118 for ; Sat, 15 Dec 2007 06:54:04 -0600 (CST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lBFCs2lo021115 for ; Sat, 15 Dec 2007 06:54:03 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: VS: [Sip] SIPit21: BNF future-proofing problem? Date: Sat, 15 Dec 2007 20:53:52 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E602A54197@ZMY16EXM67.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] SIPit21: BNF future-proofing problem? Thread-Index: Acg9RcIPeJr0haUIToaZFrjQF+cTwAB0Tx3sAAB0vsA= References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com><4760BDB4.5040107@cisco.com> From: "T Satyanarayana-A12694" To: "Christer Holmberg" , "Jonathan Rosenberg" X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to correct the context here : This bug was not FOUND at SIPit, in any test scenario. But, was rather = pointed out by me as an issue in the spec. While it is unlikely that we would face this issue in a "real" = situation, as Christer said, it will be helpful (and unambiguous) for = parser implementors. Regards Satya T -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Saturday, December 15, 2007 6:06 PM To: Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: VS: [Sip] SIPit21: BNF future-proofing problem? Hi, >Correction, yes. Essential? Hardly. > >This is another question around essential corrections. I think they not = >only need to clearly represent a bug or a fix, but need to be one that=20 >is important enough to merit documenting. Just like software, sometimes = >you don't ever bother fixing those sev 5s. Ever. So, who makes the decission whether a bug (I guess we all agree it IS a = bug) is "important enough"? My understanding is that this bug was found at SIPit, so it is not pure = "theoretical". I do agree with you that it shouldn't occur that often, because I see no = reason why one would need to use the affected characters.=20 But, never the less, the fix MAY be important from a parser = implementation perspective. Regards, Christer -Jonathan R. Christer Holmberg wrote: > Hi, >=20 > No matter how we'll fix this, I guess it would be a valid essential = correction? >=20 > Regards, >=20 > Christer > > ________________________________ > > L=E4hett=E4j=E4: Dale.Worley@comcast.net = [mailto:Dale.Worley@comcast.net] > L=E4hetetty: to 6.12.2007 21:09 > Vastaanottaja: sip@ietf.org > Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? > > > > From: Jonathan Rosenberg > > This strikes me as a problem in theory and not in practice. AFAICT, = the > only characters you can't use are ascii 0x00-0x19 (0x20 is space = and is > possible through the LWS construct as Christer pointed out). Is = there a > practical use case for any of these? They are: > > HT (horizontal tab) should be included, but that's also in LWS. As=20 > for the remaining characters, I don't think that anyone has ever > *intended* that they be used in SIP headers, and their inclusion in=20 > quoted-pair was a typographical error. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net = PHONE: (408) 902-3084 http://www.cisco.com =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 08:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WdN-0002QN-GF; Sat, 15 Dec 2007 08:00:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3WdM-0002QF-1k for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 08:00:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3WdL-0002Q7-N0 for sip@ietf.org; Sat, 15 Dec 2007 08:00:47 -0500 Received: from web94510.mail.in2.yahoo.com ([203.104.16.250]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3WdK-0001Gy-UW for sip@ietf.org; Sat, 15 Dec 2007 08:00:47 -0500 Received: (qmail 70584 invoked by uid 60001); 15 Dec 2007 13:00:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=osHCHh/xrpKtfoFAMSKISE7rJHAOIJKcBRNMFofaIBJr0WM0qU5hW2GXDaHprx2FLAFdFqJSsfgr/c+USBvOrPtXgV3Ds2HUPo+Pg89to4FzzX975pQFMgJUGP2aysVas5fMd3XUfGQUpPQTAMJ6JVpbeg0mUzFG8yF8htE9Fpo=; X-YMail-OSG: _4c2edUVM1mQNYQjqjt8N0nz1Ul_L_N_oQroOlOZbHyGEpZ2q4lASfHXgp4AnwD29SKiUx.rA0Qj3FB6RnEDidaAcnt.GXOb4enu2Yu9.QKMEMCwMcdkSKfc5HrtgQ-- Received: from [122.164.89.215] by web94510.mail.in2.yahoo.com via HTTP; Sat, 15 Dec 2007 18:30:43 IST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Sat, 15 Dec 2007 18:30:43 +0530 (IST) From: parasu raman To: sip@ietf.org MIME-Version: 1.0 Message-ID: <225352.70125.qm@web94510.mail.in2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Hi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1459187036==" Errors-To: sip-bounces@ietf.org --===============1459187036== Content-Type: multipart/alternative; boundary="0-1906890825-1197723643=:70125" --0-1906890825-1197723643=:70125 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable i had confussion with the SIP URI.=0A in the RFC 2396, says " This=0A "g= eneric URI" syntax consists of a sequence of four main components:=0A=0A = ://?=0A=0A each of which, except , may be absent from a particular URI".=0Ahere is my question, then the = URI Scheme is must be present is it right?. if i am wrong correct me..pls= =0Athanks in advance=0A=0A =0AWith Regard's & Thank's =0A=0AParasuraman Kum= arasami.=0A=0A=0A Unlimited freedom, unlimited storage. Get it now, on= http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ --0-1906890825-1197723643=:70125 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=0A
i had confussion with the SIP URI.
= =0A
  in the RFC 2396, says " This
   "generic U= RI" syntax consists of a sequence of four main components:

 &nb= sp;    <scheme>://<authority><path>?<qu= ery>

   each of which, except <scheme>, may be ab= sent from a particular URI".
=0A
here is my question, then the URI= Scheme is must be present is it right?. if i am wrong correct me..pls=
=0A
thanks in advance

 
With Regard's & Thank's

Parasuraman Kumarasami.<= /STRONG>=0A

=0A=0A=0A
= Unlimited freedom, unlimited storage. Get it now --0-1906890825-1197723643=:70125-- --===============1459187036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1459187036==-- From sip-bounces@ietf.org Sat Dec 15 08:39:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XDy-0004QT-9T; Sat, 15 Dec 2007 08:38:38 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3XDw-0004OB-OZ for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 08:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XDw-0004Lu-E8 for sip@ietf.org; Sat, 15 Dec 2007 08:38:36 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3XDv-0004Z4-V6 for sip@ietf.org; Sat, 15 Dec 2007 08:38:36 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Dec 2007 05:38:35 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBFDcZho032385; Sat, 15 Dec 2007 05:38:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBFDcVCD026931; Sat, 15 Dec 2007 13:38:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:38:30 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:38:30 -0800 Message-ID: <4763D8FC.5080905@cisco.com> Date: Sat, 15 Dec 2007 08:39:08 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Christer Holmberg Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2007 13:38:30.0763 (UTC) FILETIME=[C7BCBBB0:01C83F1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1162; t=1197725915; x=1198589915; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20SIPit21=3A=20BNF=20futu re-proofing=20problem? |Sender:=20; bh=QB5RL+Zq/m9S7Ftg5yfHZR7xyGlSMyfyOdPM2Biq1CU=; b=mJkqVRNDJUrL4FahVme9SuSjlCsV6LysNR5K/jTAVOUMpDXFL45cOq5I3b KNOwtWCVANrXlC+ewdvvOKCvX8P8flz5DR6N5Ghis7i+/kRHay0CD8xRb+D4 tdb7JujreA; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg wrote: > Hi, > >> Correction, yes. Essential? Hardly. >> >> This is another question around essential corrections. I think they >> not only need to clearly represent a bug or a fix, but need to be >> one that is important enough to merit documenting. Just like >> software, sometimes you don't ever bother fixing those sev 5s. >> Ever. > > So, who makes the decission whether a bug (I guess we all agree it IS > a bug) is "important enough"? The working group, by consensus. > I do agree with you that it shouldn't occur that often, because I see > no reason why one would need to use the affected characters. > > But, never the less, the fix MAY be important from a parser > implementation perspective. If you cannot think of a use case when this would come up, then how can you claim it may be important? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 08:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XF8-0005SW-Sp; Sat, 15 Dec 2007 08:39:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3XF7-0005SR-RM for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 08:39:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3XF7-0005SJ-Fl for sip@ietf.org; Sat, 15 Dec 2007 08:39:49 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3XF6-0002EZ-R9 for sip@ietf.org; Sat, 15 Dec 2007 08:39:49 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 15 Dec 2007 05:39:48 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id lBFDdmDk024747; Sat, 15 Dec 2007 05:39:48 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBFDdmms004112; Sat, 15 Dec 2007 13:39:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:39:48 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 05:39:47 -0800 Message-ID: <4763D94A.1010703@cisco.com> Date: Sat, 15 Dec 2007 08:40:26 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thomas Froment Subject: Re: VS: [Sip] SIPit21: BNF future-proofing problem? References: <316F9CB1-959B-4CB9-AED5-DCB46AC2741A@nostrum.com><475722EB.4030203@cisco.com> <200712062009.lB6K9LUw029177@dragon.ariadne.com> <4760BDB4.5040107@cisco.com> <4760F098.4060506@alcatel-lucent.fr> In-Reply-To: <4760F098.4060506@alcatel-lucent.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Dec 2007 13:39:47.0529 (UTC) FILETIME=[F57E4B90:01C83F1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3749; t=1197725988; x=1198589988; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20VS=3A=20[Sip]=20SIPit21=3A=20BNF=20futu re-proofing=20problem? |Sender:=20; bh=MRbd/yvh2rzREAWG+r3TTY5sLUdirCgrzEEkvsWFKeI=; b=a9/jtcCBNHzu/ukf9p7dUSYFdhFAHcUjcUjhmt3HZZF6PlmsfiKaxbuI4d V42MfwVi/o2Mt4rJwc8P0nxCiCA0jWSHc6YVJ7sjt+95blo+6qW2dGEbi0pp RFyOPNKgYZ; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org, Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You are confusing 'small' with 'non-essential'. I agree small bugs can be essential to fix, and the one you pointed out (which is not an rfc3261 bug) is small and essential. But this BNF problem that was raised is small but NON-ESSENTIAL, and its because I don't believe its essential, that I don't think it merits addressing. -Jonathan R. Thomas Froment wrote: > Jonathan Rosenberg wrote: >> Correction, yes. Essential? Hardly. >> >> This is another question around essential corrections. I think they >> not only need to clearly represent a bug or a fix, but need to be one >> that is important enough to merit documenting. Just like software, >> sometimes you don't ever bother fixing those sev 5s. Ever. > Just would like to raise a small warning with the "essential" vs > "non-essential" debate... Sometimes the most "costly" bugs (in terms of > interoperability problems) are the smallest stupid nits. > Just one example, the FIRST proxy example of the RFC 3665 is broken... > Contact of subsequent request is not correctly pushed in the Request URI > with transport parameter, so, at SIPIT, I already have seen many UAs > that behave incorrectly because of this... Ok this is clearly written in > 3261, but you know how developers do: "don't have time to read this long > RFC, I will just look at the example :p"... And > the place you generally look at is 3665, and then, it is broken (!)... > This is not "fixed" and I assume it will probably never be... By the way > this is a question: would it be interesting for somebody to > fix 3665 examples, and if yes, how to proceed? > + > Thomas > > >> >> -Jonathan R. >> >> Christer Holmberg wrote: >>> Hi, >>> >>> No matter how we'll fix this, I guess it would be a valid essential >>> correction? >>> >>> Regards, >>> >>> Christer >>> >>> ________________________________ >>> >>> Lähettäjä: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Lähetetty: to 6.12.2007 21:09 >>> Vastaanottaja: sip@ietf.org >>> Aihe: Re: [Sip] SIPit21: BNF future-proofing problem? >>> >>> >>> >>> From: Jonathan Rosenberg >>> >>> This strikes me as a problem in theory and not in practice. >>> AFAICT, the >>> only characters you can't use are ascii 0x00-0x19 (0x20 is space >>> and is >>> possible through the LWS construct as Christer pointed out). Is >>> there a >>> practical use case for any of these? They are: >>> >>> HT (horizontal tab) should be included, but that's also in LWS. As >>> for the remaining characters, I don't think that anyone has ever >>> *intended* that they be used in SIP headers, and their inclusion in >>> quoted-pair was a typographical error. >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 13:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3bjL-0005zf-2Q; Sat, 15 Dec 2007 13:27:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3bjJ-0005qz-LH for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 13:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3bjJ-0005oL-8s for sip@ietf.org; Sat, 15 Dec 2007 13:27:17 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3bjH-0005q7-Pn for sip@ietf.org; Sat, 15 Dec 2007 13:27:17 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBFIRDjR003057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Dec 2007 12:27:14 -0600 In-Reply-To: <4762F188.4080409@alcatel-lucent.com> References: <4762F188.4080409@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79ADF841-123A-4560-8B83-FB10D46D8C23@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections Date: Sat, 15 Dec 2007 12:27:07 -0600 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 14, 2007, at 3:11 PM, Vijay K. Gurbani wrote: > Dean Willis wrote: >> I'd actually like to see us go beyond the batching of "essential >> corrections" and start maintaining complete and fully-revised >> versions of the normative behaviors as internet drafts, perhaps >> occasionally publishing them as RFCs that replace the older versions. > > We are still talking the sip-essential-correction model here, right? > Or is what you propose above a new model? It's the "logical product" of the essential corrections process. Each draft in the essential corrections process has to specify line- by-line changes to the RFC it is correcting. If we were to extract those changes and apply them to the source, we would get the "tracking draft" I'm talking about. >> So for example with RFC 3261, we'd maintain a >> "draft-ietf-sip-rfc3261-bis" that would start as a copy of RFC 3261 >> (with current boilerplate, of course) and then be edited to reflect >> the changes documented in each "essential correction" we agree to. >> Then instead of telling implementors to go read RFC 3261 plus a dozen >> more potentially conflicting revision documents, we could just say >> "see draft-ietf-sip-rfc3261-bis-xx". > > Isn't that what we essentially did with rfc2543-bis set of drafts? > Of course, the domain of influence of SIP back then was a bit more > limited than it is now. > Not really. The 2543-bis work was more traditional draft editing. The various editors would get input, make changes to the draft, then we'd review the changes and maybe accept them or back them out or change them again. In the extended essential corrections process, we'd formally review and reach consensus on each change before committing the change into the -bis document. So every -bis document would reflect WG consensus on the changes at any given time. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 13:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3c8Q-0001M0-Qy; Sat, 15 Dec 2007 13:53:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3c8P-0001Lu-UL for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 13:53:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3c8P-0001Lm-KF for sip@ietf.org; Sat, 15 Dec 2007 13:53:13 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3c8N-0006nq-Rh for sip@ietf.org; Sat, 15 Dec 2007 13:53:13 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBFIr7JZ003276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Dec 2007 12:53:08 -0600 In-Reply-To: <47630555.7090605@cisco.com> References: <47630555.7090605@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections Date: Sat, 15 Dec 2007 12:53:01 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote: > inline: > > Dean Willis wrote: > >> Here's a test I'd like to propose: If the change is such that if >> we were re-writing the affected RFC we'd include the new behavior >> as normative behavior, then we track it as a revision. This allows >> us to fully deprecate the behavior that it replaces, such that we >> no longer have to consider the old behavior when compliance >> testing. If we can't deprecate the replaced behavior, then we >> really do have an extension (not a revision), and we need an >> extension negotiation mechanism to know when it can be used or is >> being used. > > I'm not sure I agree with this. I think we have some extensions > which we'd arguably include as, 'things we'd make as new normative > behavior that is core to sip'. I personally would have wished that > nat traversal were an integral part of sip and if I could do it > over, would not have it split out. But clearly ICE and outbound and > all that are not essential corrections. > > In my mind, the right litmus test is that the new behavior: > > 1. cannot be negotiated using the standardized techniques, AND > 2. represents a change that impacts interoperability with other > implementations which might not implement this new behavior > > THEN its an essential correction. > > THings like BNF bugs are clearly in scope. Something like record- > route fix doesn't meet this litmus test because of the second item. > I can implement this and fully interoperate with existing > implementations. Ok, there's probably a valid argument here. It's important to note also that if something is an "essential correction", we'd be willing to say that an implementation that does not conform to the correction is in violation of the specification and needs to be fixed. In other words, there is the same sort of justification for fixing it as there is for "MUST" in RFC 2119 -- failure to conform creates a failure to interoperate or function correctly. Now, it's arguable whether the record-route-fix falls into this category or not. Route rewriting, as opposed to double recording, prevents route signing. Is the ability to use route-signing important enough that we'd say that any implementation that precludes its use is "broken"? I'd say that this is the test. >> I'd actually like to see us go beyond the batching of "essential >> corrections" and start maintaining complete and fully-revised >> versions of the normative behaviors as internet drafts, perhaps >> occasionally publishing them as RFCs that replace the older >> versions. So for example with RFC 3261, we'd maintain a "draft- >> ietf-sip-rfc3261-bis" that would start as a copy of RFC 3261 (with >> current boilerplate, of course) and then be edited to reflect the >> changes documented in each "essential correction" we agree to. >> Then instead of telling implementors to go read RFC 3261 plus a >> dozen more potentially conflicting revision documents, we could >> just say "see draft-ietf-sip-rfc3261-bis-xx". > > I thought the idea is that there is just one revision document > (essential corrections) and not seven. Let's say we roll the 7 changes (I just made that number up, there may be more or less) for 2008 into the 2008 essential corrections RFC. What do we do in 2009? Copy all of the 2008 changes into the 2009 RFC? What happens when we've had overlapping changes, such that the same part of the spec has been touched twice? Does the second change need to write step-by-step edits against the base RFC, or against the base RFC as amended by the first change? This gets hairy, and it is made a lot easier if we write the first change against the RFC, apply the first change to the RFC to generate the -bis spec, and then make subsequent corrections bundles against the -bis spec. This gives us a "fully assembled" spec to work against. Reverse deltas as opposed to forward deltas, from a source-code-control perspective. > I promise you that once you open the floodgates to an rfc3261 > revision spec, the temptation to do LOTS of other things to the > document will be too great. Clarify this while we're at it? OK. > Maybe we should pull that extension in. ANd so on. I don't want to > do that. Segmenting this into an essential corrections document > keeps pandoras box from opening. I'll certainly agree that a substantial amount of discipline is required in either case. The question is: Do we want one document an implementor can go to, or do we want a base document plus many "diff" deltas? Looking at the bug tracker for RFC 3261, I can see that there have been 85 different bugs filed. While some may not meet the criteria of "essential" (is confusing "excepting" and "accepting" essential?), I'll bet you there are still a lot of things that need fixing in the doc. And RFC 3261 isn't the only spec that needs polishing -- there are over 200 bugs in that tracker. > The amount of work that went into rfc2543 -> rfc3261 was > astoundingly large, as any of the editors who basically did this as > a full time job for like 6 months will tell you (my boss would ask > me when I was coming back to work...). I do not think we as a > working group have or want to spend the cycles on such a > monumentally large task at this time. I'm not proposing SIP 3.0 here -- just proposing ways to correct the known bugs in our RFCs that produces a result usable by developers, students, other SDOs, and other readers of those RFCs. What we're doing now IS NOT WORKING. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 17:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3f5t-0001If-0j; Sat, 15 Dec 2007 17:02:49 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3f5r-0001IZ-O5 for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 17:02:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3f5r-0001Fg-CK for sip@ietf.org; Sat, 15 Dec 2007 17:02:47 -0500 Received: from harjus.tutpro.com ([192.98.100.3] helo=taimen.tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3f5q-0003rf-SJ for sip@ietf.org; Sat, 15 Dec 2007 17:02:47 -0500 Received: by taimen.tutpro.com (Postfix, from userid 1000) id 68C0433A8D8; Sun, 16 Dec 2007 00:03:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18276.20264.255130.99349@harjus.tutpro.com> Date: Sun, 16 Dec 2007 00:03:20 +0200 To: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections In-Reply-To: References: <47630555.7090605@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > The question is: Do we want one document an implementor can go to, or > do we want a base document plus many "diff" deltas? there should be one document that implementor needs to read, not a base plus corrections docs. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 17:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3fQL-0006d3-7H; Sat, 15 Dec 2007 17:23:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3fQJ-0006cw-KE for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 17:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3fQJ-0006co-AN for sip@ietf.org; Sat, 15 Dec 2007 17:23:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3fQJ-000325-1c for sip@ietf.org; Sat, 15 Dec 2007 17:23:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2007 17:23:52 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBFMNqf4011653; Sat, 15 Dec 2007 17:23:52 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBFMNka8009442; Sat, 15 Dec 2007 22:23:50 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 17:23:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Direction on Buddy List format for SIP Simple Date: Sat, 15 Dec 2007 17:23:49 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E046155DA@xmb-rtp-215.amer.cisco.com> In-Reply-To: <7bfdc29a0712122007od2fbb6w6c29b3ecc8b2402e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Direction on Buddy List format for SIP Simple Thread-Index: Acg9PcVIHbtAr/J6QUGZn0SrsQOXkQCK05Rw From: "Sanjay Sinha (sanjsinh)" To: , X-OriginalArrivalTime: 15 Dec 2007 22:23:46.0368 (UTC) FILETIME=[28806C00:01C83F69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=586; t=1197757432; x=1198621432; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Direction=20on=20Buddy=20List=2 0format=20for=20SIP=20Simple |Sender:=20 |To:=20,=20; bh=LIXh+eG39xQpSJqXrUo4PtWOBPF0kZtlKzQK0b7L8ZY=; b=n9v9Tk8SdbpyRwXQN3a4baCN/JH/ONElw+1KyC+X+J6nHzIbSgo9nMRPN+ dlU9Dk9jb/xar1nBMc887RMFntytLINJT7fwYfICP+GKW9htIIY7LNL4Lfaq JpqIsL6Tz0; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org XCAP (RFC 4825) >-----Original Message----- >From: Imran M Yousuf [mailto:imyousuf@gmail.com]=20 >Sent: Wednesday, December 12, 2007 11:08 PM >To: sip@ietf.org >Subject: [Sip] Direction on Buddy List format for SIP Simple > >Hi, > >I was wondering how is Buddy List be exchanged between SIP=20 >Server and SIP UA. Can someone please direct me to some=20 >document in relate to this. > >Thank you, > >-- >Imran M Yousuf >Entrepreneur & Software Engineer >Smart IT Engineering >Dhaka, Bangladesh >Email: imran@smartitengineering.com >Mobile: +880-1711402557=20 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 19:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3h6v-0005wz-IF; Sat, 15 Dec 2007 19:12:01 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3h6t-0005wf-Lj for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 19:11:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3h6t-0005sY-8G for sip@ietf.org; Sat, 15 Dec 2007 19:11:59 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3h6s-0006Xp-Rd for sip@ietf.org; Sat, 15 Dec 2007 19:11:59 -0500 Received: from [192.168.2.106] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBG0BuTK005317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Dec 2007 18:11:57 -0600 In-Reply-To: <18276.20264.255130.99349@harjus.tutpro.com> References: <47630555.7090605@cisco.com> <18276.20264.255130.99349@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <687DA641-A3DF-42CF-A478-7DAE44C63FBB@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections Date: Sat, 15 Dec 2007 18:11:49 -0600 To: Juha Heinanen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 15, 2007, at 4:03 PM, Juha Heinanen wrote: > Dean Willis writes: > >> The question is: Do we want one document an implementor can go to, or >> do we want a base document plus many "diff" deltas? > > there should be one document that implementor needs to read, not a > base > plus corrections docs. > > Thanks! I know when you agree with something that it's probably technically right. However, it's also usually a sign that I'm going to have a hard time convincing the other folks in the WG about it! Have a happy holiday season and new year. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 15 19:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3hEQ-00063L-80; Sat, 15 Dec 2007 19:19:46 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3hEO-00063G-O4 for sip-confirm+ok@megatron.ietf.org; Sat, 15 Dec 2007 19:19:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3hEO-00062v-DJ for sip@ietf.org; Sat, 15 Dec 2007 19:19:44 -0500 Received: from smtpauth03.csee.onr.siteprotect.com ([64.26.60.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3hEO-0006fE-35 for sip@ietf.org; Sat, 15 Dec 2007 19:19:44 -0500 Received: from [192.168.1.120] (unknown [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth03.csee.onr.siteprotect.com (Postfix) with ESMTP id A193B1038005; Sat, 15 Dec 2007 18:19:43 -0600 (CST) Subject: Re: [Sip] On The Essentialness of Corrections From: "Frank W. Miller" To: Dean Willis In-Reply-To: <687DA641-A3DF-42CF-A478-7DAE44C63FBB@softarmor.com> References: <47630555.7090605@cisco.com> <18276.20264.255130.99349@harjus.tutpro.com> <687DA641-A3DF-42CF-A478-7DAE44C63FBB@softarmor.com> Content-Type: text/plain Date: Sat, 15 Dec 2007 17:19:29 -0700 Message-Id: <1197764369.2662.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here's another indication. I think it should be one document too. FM On Sat, 2007-12-15 at 18:11 -0600, Dean Willis wrote: > On Dec 15, 2007, at 4:03 PM, Juha Heinanen wrote: > > > Dean Willis writes: > > > >> The question is: Do we want one document an implementor can go to, or > >> do we want a base document plus many "diff" deltas? > > > > there should be one document that implementor needs to read, not a > > base > > plus corrections docs. > > > > > > Thanks! I know when you agree with something that it's probably > technically right. However, it's also usually a sign that I'm going > to have a hard time convincing the other folks in the WG about it! > > Have a happy holiday season and new year. > > -- > dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 16 09:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3uaS-0001So-5c; Sun, 16 Dec 2007 09:35:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3uaQ-0001Si-Jc for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 09:35:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3uaQ-0001Sa-8f for sip@ietf.org; Sun, 16 Dec 2007 09:35:22 -0500 Received: from wa-out-1112.google.com ([209.85.146.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3uaP-0002Fg-KH for sip@ietf.org; Sun, 16 Dec 2007 09:35:22 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3449053wah.25 for ; Sun, 16 Dec 2007 06:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=wKp5kG7fS4XoZqwpPPViOvxjwweywLtTqFw3IB5dfok=; b=lS/jTkU7qvRiiKljVGAjNBHe5PRUVowLmQvwDSAIw5jnUs8uLEyfd3YrIPAyhduIAAEbB/9bF7o3eO7mDStqk0KIQF0BzM+2vpN9r89TDZO7Qqr46JRnpCM5UeyUfPPOgQlj7wIlIWv7C5991BHxTP3EqsE67VplKLCWZ/RC5RE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bcdGgN+ZsbqMdssJ+R40tl5lbVpHk5KYvxXmjbdkDUS1MCYWj9tqEql/dOehUNWkioe5zbKFw3KMEFWFF9oJ7HBMxsEHvbsIiYdR3m8RUd2OCygR5CACiCDaKgTMIzNMRrQC3JAlswOAWiKaqNGa9zUtI8l3vTj9x+hQ8s/51T0= Received: by 10.115.77.1 with SMTP id e1mr1711734wal.103.1197815720943; Sun, 16 Dec 2007 06:35:20 -0800 (PST) Received: by 10.114.27.13 with HTTP; Sun, 16 Dec 2007 06:35:20 -0800 (PST) Message-ID: Date: Sun, 16 Dec 2007 14:35:20 +0000 From: "Lee Dryburgh" To: "IETF SIP List" MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Sip] Chance to defend position that SIP has had poor consumer traction Etc. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0560943136==" Errors-To: sip-bounces@ietf.org --===============0560943136== Content-Type: multipart/alternative; boundary="----=_Part_2730_181386.1197815720931" ------=_Part_2730_181386.1197815720931 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is away to drive ahead with the messages which I give them. One of these messages is critical towards SIP. Before the marketing material is finalised, I'd like to first welcome responses. I'd love to copy all the messages but I may run the risk of getting accused of spamming the list so below I've just copied the section that relates to SIP: "Voice Industry Stagnancy Telcos still see themselves as masters of communications innovation and the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and IMS services are failing in the market place. At the same time consumer attention drifts increasingly towards Internet based applications such as Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which are becoming increasingly voice enabled. Yet within the Internet realms VoIP is still heralded as the communication revolution. But VoIP on it's own is nothing more than digital telephony and it will never be profitable. It has gained little consumer traction and can be announced as dead-on-arrival. SIP the VoIP signaling protocol even after a decade of development has had little consumer reach and the entire notion of a common signaling protocol is now under question. " Now it would seem stupid to ask people to call their baby ugly. BUT what I do hope for, is that there is enough people with a balanced view who if they feel strongly against this position and can provide clear rationale, then I will have it modified/changed accordingly. Otherwise it will be accepted as true. Seems fair? Thanks Lee ------=_Part_2730_181386.1197815720931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is away to drive ahead with the messages which I give them. One of these messages is critical towards SIP. Before the marketing material is finalised, I'd like to first welcome responses. I'd love to copy all the messages but I may run the risk of getting accused of spamming the list so below I've just copied the section that relates to SIP:

"Voice Industry Stagnancy
Telcos still see themselves as masters of communications innovation and the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and IMS services are failing in the market place. At the same time consumer attention drifts increasingly towards Internet based applications such as Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which are becoming increasingly voice enabled.

Yet within the Internet realms VoIP is still heralded as the communication revolution. But VoIP on it's own is nothing more than digital telephony and it will never be profitable. It has gained little consumer traction and can be announced as dead-on-arrival. SIP the VoIP signaling protocol even after a decade of development has had little consumer reach and the entire notion of a common signaling protocol is now under question. "

Now it would seem stupid to ask people to call their baby ugly. BUT what I do hope for, is that there is enough people with a balanced view who if they feel strongly against this position and can provide clear rationale, then I will have it modified/changed accordingly. Otherwise it will be accepted as true. Seems fair?

Thanks Lee
------=_Part_2730_181386.1197815720931-- --===============0560943136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0560943136==-- From sip-bounces@ietf.org Sun Dec 16 11:40:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3wXA-0003Hd-07; Sun, 16 Dec 2007 11:40:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J3wX8-0003HW-3b for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 11:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3wX7-0003HK-N2 for sip@ietf.org; Sun, 16 Dec 2007 11:40:05 -0500 Received: from kuber.nabble.com ([216.139.236.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3wX3-0000o1-Te for sip@ietf.org; Sun, 16 Dec 2007 11:40:05 -0500 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J3wWo-0000wL-Cb for sip@ietf.org; Sun, 16 Dec 2007 08:39:46 -0800 Message-ID: <14363324.post@talk.nabble.com> Date: Sun, 16 Dec 2007 08:39:46 -0800 (PST) From: Ari El To: sip@ietf.org Subject: Re: [Sip] Chance to defend position that SIP has had poor consumer traction Etc. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ari.reads@gmail.com References: X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Lee Dryburgh wrote: > > Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is > away to drive ahead with the messages which I give them. One of these > messages is critical towards SIP. Before the marketing material is > finalised, I'd like to first welcome responses. I'd love to copy all the > messages but I may run the risk of getting accused of spamming the list so > below I've just copied the section that relates to SIP: > > "Voice Industry Stagnancy > Telcos still see themselves as masters of communications innovation and > the > guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and IMS > services are failing in the market place. At the same time consumer > attention drifts increasingly towards Internet based applications such as > Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. > which > are becoming increasingly voice enabled. > > Yet within the Internet realms VoIP is still heralded as the communication > revolution. But VoIP on it's own is nothing more than digital telephony > and > it will never be profitable. It has gained little consumer traction and > can > be announced as dead-on-arrival. SIP the VoIP signaling protocol even > after > a decade of development has had little consumer reach and the entire > notion > of a common signaling protocol is now under question. " > > Now it would seem stupid to ask people to call their baby ugly. BUT what I > do hope for, is that there is enough people with a balanced view who if > they > feel strongly against this position and can provide clear rationale, then > I > will have it modified/changed accordingly. Otherwise it will be accepted > as > true. Seems fair? > > Thanks Lee > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > SIP is a protocol, not an application. Protocols don't have any "consumer traction". Now within the voice industry if you can tell me a single large wireline/wireless telco that hasn't done some work or planning in replacing class 4 and later class 5 switching equipment with a SIP/IMS core, you probably work in another industry. Same core we will use for 4G in wireless. >From my experience telco investment cycles have a 5 to 10 year period. All major telcos have started working towards the change just 2 or 3 years ago. It will take 2 or 3 more, at least, before we start. Once we do, it will be fun. Nobody is planning to deploy voip just because it sounds cool or because the "industry analysts" recommend it. What's more, in the way most telcos are planning it, it will go mostly unnoticed by customers. We sell voice or multimedia communications, not voip. Facebook might have a lot of consumer traction but it doesn't generate any net income. And they don't offer you any service you pay for. Telcos can complement facebook while the hype lasts, yes; many are working on that. BTW anyone remembers secondlife virtual stores? Just my $0.02 -- View this message in context: http://www.nabble.com/Chance-to-defend-position-that-SIP-has-had-poor-consumer-traction-Etc.-tp14362104p14363324.html Sent from the IETF - Sip mailing list archive at Nabble.com. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 16 18:23:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42p7-00052h-5l; Sun, 16 Dec 2007 18:23:05 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J42p6-00052V-1X for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 18:23:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42p5-00052N-Nf for sip@ietf.org; Sun, 16 Dec 2007 18:23:03 -0500 Received: from exprod6og104.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J42p2-0004ij-N8 for sip@ietf.org; Sun, 16 Dec 2007 18:23:03 -0500 Received: from source ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 15:22:59 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGNKZin007800; Sun, 16 Dec 2007 15:20:35 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBGNMkFZ004193; Sun, 16 Dec 2007 15:22:49 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Dec 2007 15:22:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Chance to defend position that SIP has had poor consumertraction Etc. Date: Sun, 16 Dec 2007 15:22:38 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE413@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Chance to defend position that SIP has had poor consumertraction Etc. Thread-Index: Acg/8PYlkcxt/uEjTZaF2N5UDFejKgASAnoQ References: From: "Henry Sinnreich" To: "Lee Dryburgh" , "IETF SIP List" X-OriginalArrivalTime: 16 Dec 2007 23:22:47.0664 (UTC) FILETIME=[91B10F00:01C8403A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0159630210==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0159630210== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8403A.901ABFB6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8403A.901ABFB6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Lee, =20 Sorry, but you have it all wrong and confused as email from others are also observing.=20 The half truths are even more confusing. This list is not the right place to argue your confusion.=20 =20 Henry =20 ________________________________ From: Lee Dryburgh [mailto:dryburghl@gmail.com]=20 Sent: Sunday, December 16, 2007 8:35 AM To: IETF SIP List Subject: [Sip] Chance to defend position that SIP has had poor consumertraction Etc. =20 Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is away to drive ahead with the messages which I give them. One of these messages is critical towards SIP. Before the marketing material is finalised, I'd like to first welcome responses. I'd love to copy all the messages but I may run the risk of getting accused of spamming the list so below I've just copied the section that relates to SIP:=20 "Voice Industry Stagnancy Telcos still see themselves as masters of communications innovation and the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and IMS services are failing in the market place. At the same time consumer attention drifts increasingly towards Internet based applications such as Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which are becoming increasingly voice enabled.=20 Yet within the Internet realms VoIP is still heralded as the communication revolution. But VoIP on it's own is nothing more than digital telephony and it will never be profitable. It has gained little consumer traction and can be announced as dead-on-arrival. SIP the VoIP signaling protocol even after a decade of development has had little consumer reach and the entire notion of a common signaling protocol is now under question. "=20 Now it would seem stupid to ask people to call their baby ugly. BUT what I do hope for, is that there is enough people with a balanced view who if they feel strongly against this position and can provide clear rationale, then I will have it modified/changed accordingly. Otherwise it will be accepted as true. Seems fair? Thanks Lee ------_=_NextPart_001_01C8403A.901ABFB6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Lee,

 

Sorry, but you have it all wrong = and confused as email from others are also observing. =

The half truths are even more = confusing.

This list is not the right place to = argue your confusion. =

 

Henry

 

From: Lee = Dryburgh [mailto:dryburghl@gmail.com]
Sent: Sunday, December = 16, 2007 8:35 AM
To: IETF SIP List
Subject: [Sip] Chance to = defend position that SIP has had poor consumertraction Etc.

 

Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is away to drive ahead with the messages which I give them. One of these = messages is critical towards SIP. Before the marketing material is finalised, I'd = like to first welcome responses. I'd love to copy all the messages but I may run = the risk of getting accused of spamming the list so below I've just copied = the section that relates to SIP:

"Voice Industry Stagnancy
Telcos still see themselves as masters of communications innovation and = the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and = IMS services are failing in the market place. At the same time consumer = attention drifts increasingly towards Internet based applications such as = Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which are = becoming increasingly voice enabled.

Yet within the Internet realms VoIP is still heralded as the = communication revolution. But VoIP on it's own is nothing more than digital telephony = and it will never be profitable. It has gained little consumer traction and can = be announced as dead-on-arrival. SIP the VoIP signaling protocol even after = a decade of development has had little consumer reach and the entire = notion of a common signaling protocol is now under question. "

Now it would seem stupid to ask people to call their baby ugly. BUT what = I do hope for, is that there is enough people with a balanced view who if = they feel strongly against this position and can provide clear rationale, then I = will have it modified/changed accordingly. Otherwise it will be accepted as = true. Seems fair?

Thanks Lee

------_=_NextPart_001_01C8403A.901ABFB6-- --===============0159630210== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0159630210==-- From sip-bounces@ietf.org Sun Dec 16 19:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43ii-0002dU-AM; Sun, 16 Dec 2007 19:20:32 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J43ig-0002a7-JV for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 19:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43ig-0002Zz-9Z for sip@ietf.org; Sun, 16 Dec 2007 19:20:30 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J43if-0005ef-1W for sip@ietf.org; Sun, 16 Dec 2007 19:20:30 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3762523wah.25 for ; Sun, 16 Dec 2007 16:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=s2NxtjNXZVVEG3OeXEHfJ94i06MGOQtfl5zwN25m6Wo=; b=Kkbt2ZLAnSzSEMpIddbronClpSYoBeHF9vP0NxVy/TEKV/q5fZQW47+y7oQekgGpi07H6iH5WHB6+HCqXi3/olxyFd0PdqFUInwfQ19gRRJbD3fsa3VO1bP1jjzQoKqKau5GM59gEpXdO2Tgl9QPUCeX0PRlLgo6oayS9Eg646A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=u/cuvAFVGK+6OKG0qzTQrlDXrhTe8r5VQI50MnGFom0M3uvxwb5LUDlBjC+S2NMXE+Gy7MXBf1ktCtxMFxB/39xoGe6vtFkKcxcBM0eM5XtuP0HR7ehrwWaatG+5wpHVLYksy5fHqDwsLMXRBke/EcdV+9GfnaWO63YSFWPz0LU= Received: by 10.114.27.20 with SMTP id a20mr1901195waa.101.1197850827411; Sun, 16 Dec 2007 16:20:27 -0800 (PST) Received: by 10.114.27.13 with HTTP; Sun, 16 Dec 2007 16:20:27 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 00:20:27 +0000 From: "Lee Dryburgh" To: sip@ietf.org Subject: Re: [Sip] Chance to defend position that SIP has had poor consumer traction Etc. In-Reply-To: <14363324.post@talk.nabble.com> MIME-Version: 1.0 References: <14363324.post@talk.nabble.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0731712129==" Errors-To: sip-bounces@ietf.org --===============0731712129== Content-Type: multipart/alternative; boundary="----=_Part_3950_431801.1197850827402" ------=_Part_3950_431801.1197850827402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > SIP is a protocol, not an application. Protocols don't have any "consume= r > traction". Ari - firstly thanks for you response. This is just semantics. Lets rephrase which keeps the line the same - there has been a lack of consumer traction with applications which use SIP. Now within the voice industry if you can tell me a single large > wireline/wireless telco that hasn't done some work or planning in > replacing > class 4 and later class 5 switching equipment with a SIP/IMS core, you > probably work in another industry. Same core we will use for 4G in > wireless. I'm aware of the plans and it seems to be getting a bit long in the tooth now; the last operator I did some consulting work for (Hutchinson 3G) evaluated packet based video (over the air interface) and decided to go circuit switched. At a greenfield 3G deployment (Orange) I watched in amazement that analogue signalling links (V35 based SS7) were put in place! My impression is that there is a large difference between any action on the ground and Powerpoint slides. But really this bypasses more fundamental points. The first question is whether any investment directly relates to any significant ROI? Customer behaviour is markedly different to the environment into which SIP was originally envisaged; is voice not pass=E9 now? Voice as a standalone offer= ing is not going to be profitable long term. The profits are to be chased in th= e ways into which voice can be combined into business processes, social networking Etc. (I really can't go into this here - more combinations are listed on the eCommMedia.com about page). A dark cloud is appearing over SIP/IMS in terms of being the technology underpinning such combinations. Fo= r IMS see: IMS: http://www.ss7.net/ss7-wiki/index.php/Ims-failure >From my experience telco investment cycles have a 5 to 10 year period. Al= l > major telcos have started working towards the change just 2 or 3 years > ago. > It will take 2 or 3 more, at least, before we start. Once we do, it will > be > fun. Nobody is planning to deploy voip just because it sounds cool or > because the "industry analysts" recommend it. What's more, in the way mos= t > telcos are planning it, it will go mostly unnoticed by customers. We sell > voice or multimedia communications, not voip. As said voice is dead as a standalone product long term. It needs to be looked at as an adjunct to ecommerce, social networking etc. Besides it is pass=E9, the kids are instant messaging given the chance. T-Mobile (States) where I did some work recently told me that if they offer a data plan with no voice= , the teenage market virtually only takes it and runs IM. Talking of which I don't even see SIMPLE playing in the IM field so late in the day. The kids are Twittering, Beboing and IMing - voice is rare for them (tweenagers). The direction of SIP is voice centric. Voice as a discrete service is dead long term in terms of profit (and high application use). When you say multimedia communications, operators can not name these. And there is no way they can compete in this direction with the innovation ecology of the Internet. Facebook might have a lot of consumer traction but it doesn't generate any > net income. And they don't offer you any service you pay for. Telcos can > complement facebook while the hype lasts, yes; many are working on that. > BTW > anyone remembers secondlife virtual stores? Facebook is still in the stage that Google was in, pre-AdSense and pre-IPO. Just my $0.02 As indicated before I am not after upsetting folks. I'm interested in a great conference; my understanding at this point is that telephones and mai= n stream media are being displaced. If I imagine how long role outs etc. take and note the changes in consumer behaviour since the advent of broadband an= d project forwards, it is hard to see SIP lining up with the market. It reminds me that in 1999 people started coming to SS7 training classes askin= g what is the point in learning SIP as it will replace SS7 within a few years= . Last year I did more SS7 training than any other year and AFAIK SS7 is stil= l used in 99% of networks. And if you want to do billable VoIP besides voice being passe long term, then every company I have dealt with uses H.323 quit= e simply because it integrates with existing billing systems (those setup for SS7). Strangely enough there is no money in free/low-cost VoIP and the appeal of such an offering decreases over time as people wish to drive a more "fused" application experience. Regards Lee ------=_Part_3950_431801.1197850827402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
SIP is a= protocol, not an application. Protocols don't have any  &quo= t;consumer
traction".

Ari - firstly thanks for you response.=

This is just semantics. Lets rephrase which keeps the line the same= - there has been a lack of consumer traction with applications which use S= IP.=20

Now= within the voice industry if you can tell me a single large
wireline/wi= reless telco that hasn't done some work or planning in replacing
class 4 and later class 5 switching equipment with a SIP/IMS core, you<= br>probably work in another industry. Same core we will use for 4G in wirel= ess.

I'm aware of the plans and it seems to be get= ting a bit long in the tooth now; the last operator I did some consulting w= ork for (Hutchinson 3G) evaluated packet based video (over the air interfac= e) and decided to go circuit switched. At a greenfield 3G deployment (Orang= e) I watched in amazement that analogue signalling links (V35 based SS7) we= re put in place! My impression is that there is a large difference between = any action on the ground and Powerpoint slides.

But really this bypasses more fundamental points. The first questio= n is whether any investment directly relates to any significant ROI? Custom= er behaviour is markedly different to the environment into which SIP was or= iginally envisaged; is voice not pass =E9 now? Voice as a standalone offering is not goi= ng to be profitable long term. The profits are to be chased in the ways int= o which voice can be combined into business processes, social networking Et= c. (I really can't go into this here - more combinations are listed on = the=20 eCommMedia.com about page). A dark cloud is appearing over SIP/IMS in terms= of being the technology underpinning such combinations. For IMS see:
IMS: http:/= /www.ss7.net/ss7-wiki/index.php/Ims-failure
 

>From my experience telco investment cycles  have a 5 t= o 10 year period. All
major telcos have started working towards the change just 2 or 3 years = ago.
It will take 2 or 3 more, at least, before we start. Once we do, it= will be
fun. Nobody is planning to deploy voip just because it sounds c= ool or
because the "industry analysts" recommend it. What's more= , in the way most
telcos are planning it, it will go mostly unnoticed by= customers. We sell
voice or multimedia communications, not voip.

As said voice is dead as a standalone product long term. It needs = to be looked at as an adjunct to ecommerce, social networking etc. Besides = it is p ass=E9, the kids are instant messaging given the chance. T-Mobile (States) = where I did some work recently told me that if they offer a data plan with = no voice, the teenage market virtually only takes it and runs IM. Talking o= f which I don't even see SIMPLE playing in the IM field so late in the = day. The kids are Twittering, Beboing and IMing - voice is rare for them (t= weenagers).

The direction of SIP is voice centric. Voice as a discrete service = is dead long term in terms of profit (and high application use).

Whe= n you say multimedia communications, operators can not name these. And ther= e is no way they can compete in this direction with the innovation ecology = of the Internet.

Facebook might have a lot of consumer traction but it doesn't gener= ate any
net income. And they don't offer you any service you pay for. Telco= s can
complement facebook while the hype lasts, yes; many are working on= that. BTW
anyone remembers secondlife virtual stores?

Facebook is still in the stage that Google was in, pre-AdSense and pre-= IPO.

Just my $0.02

As indicated before I am not after upset= ting folks. I'm interested in a great conference; my understanding at t= his point is that telephones and main stream media are being displaced. If = I imagine how long role outs etc. take and note the changes in consumer beh= aviour since the advent of broadband and project forwards, it is hard to se= e SIP lining up with the market. It reminds me that in 1999 people started = coming to SS7 training classes asking what is the point in learning SIP as = it will replace SS7 within a few years. Last year I did more SS7 training t= han any other year and AFAIK SS7 is still used in 99% of networks. And if y= ou want to do billable VoIP besides voice being passe long term, then every= company I have dealt with uses=20 H.323 quite simply because it integrates with existing billing systems (tho= se setup for SS7). Strangely enough there is no money in free/low-cost VoIP= and the appeal of such an offering decreases over time as people wish to d= rive a more "fused" application experience.

Regards

Lee


------=_Part_3950_431801.1197850827402-- --===============0731712129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0731712129==-- From sip-bounces@ietf.org Sun Dec 16 19:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43uw-0002PX-Ld; Sun, 16 Dec 2007 19:33:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J43uv-0002PK-Ia for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 19:33:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43uv-0002NS-6m for sip@ietf.org; Sun, 16 Dec 2007 19:33:09 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J43uu-0005sP-9p for sip@ietf.org; Sun, 16 Dec 2007 19:33:09 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3768964wah.25 for ; Sun, 16 Dec 2007 16:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=NG1gpglFcJcv1miLiYz1x10cTpedlLNc5B1milg7pYI=; b=o0ITvc77uQDQjaJXboTV5nHO3qGvxg9n6E8/NKokLvcBby7NPz3ADjoCqHs+682Z/Nj/c3C/maRrINT2668opUJqklatlYlIuHqDEGJoictz8AQPvYs2Q4EybQaRmLmm+8x/g1nsg3+9XgkAijGPTy0c3PH71DjUHmdi31JEFII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i4wL1r6e8MQFRArcTyp2oS7ABuOZwh+ifpS+2+76zCtu2tD20GbVfza/2gz9ZZ9EjRqmuMjPn/w7QMzI7AWMWkQC3DZh+8/7IAnR3NjL71GHy5mSkN7+vukOWIqLm9fSywOBmYZimIR4kSZDRhwEUOU3Rz/vEcdev2WHVpyPWG4= Received: by 10.114.169.2 with SMTP id r2mr1907049wae.76.1197851587624; Sun, 16 Dec 2007 16:33:07 -0800 (PST) Received: by 10.114.27.13 with HTTP; Sun, 16 Dec 2007 16:33:07 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 00:33:07 +0000 From: "Lee Dryburgh" To: sip@ietf.org Subject: Re: [Sip] Chance to defend position that SIP has had poor consumertraction Etc. In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE413@namail5.corp.adobe.com> MIME-Version: 1.0 References: <24CCCC428EFEA2469BF046DB3C7A8D223AE413@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1494366236==" Errors-To: sip-bounces@ietf.org --===============1494366236== Content-Type: multipart/alternative; boundary="----=_Part_3982_18746131.1197851587610" ------=_Part_3982_18746131.1197851587610 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Henry to make such affirmative statements is rather lofty of you. Having worked for most telecom vendors and many operators, in 30 countries, exclusively in the realms of signalling, it is rather staggering that you retort "confused" and leave it at that. That signalling work includes first NGN trials and 3G deployments. The "others" you refer to is "other" and I've just replied to that. As said I asked for a balanced view as far as possible and simply hitting reply, typing "confused"/"half-truth" is far from balanced. Regards Lee On 16/12/2007, Henry Sinnreich wrote: > > Lee, > > > > Sorry, but you have it all wrong and confused as email from others are > also observing. > > The half truths are even more confusing. > > This list is not the right place to argue your confusion. > > > > Henry > > > ------------------------------ > > *From:* Lee Dryburgh [mailto:dryburghl@gmail.com] > *Sent:* Sunday, December 16, 2007 8:35 AM > *To:* IETF SIP List > *Subject:* [Sip] Chance to defend position that SIP has had poor > consumertraction Etc. > > > > Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is > away to drive ahead with the messages which I give them. One of these > messages is critical towards SIP. Before the marketing material is > finalised, I'd like to first welcome responses. I'd love to copy all the > messages but I may run the risk of getting accused of spamming the list so > below I've just copied the section that relates to SIP: > > "Voice Industry Stagnancy > Telcos still see themselves as masters of communications innovation and > the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and > IMS services are failing in the market place. At the same time consumer > attention drifts increasingly towards Internet based applications such as > Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which > are becoming increasingly voice enabled. > > Yet within the Internet realms VoIP is still heralded as the communication > revolution. But VoIP on it's own is nothing more than digital telephony and > it will never be profitable. It has gained little consumer traction and can > be announced as dead-on-arrival. SIP the VoIP signaling protocol even after > a decade of development has had little consumer reach and the entire notion > of a common signaling protocol is now under question. " > > Now it would seem stupid to ask people to call their baby ugly. BUT what I > do hope for, is that there is enough people with a balanced view who if they > feel strongly against this position and can provide clear rationale, then I > will have it modified/changed accordingly. Otherwise it will be accepted as > true. Seems fair? > > Thanks Lee > ------=_Part_3982_18746131.1197851587610 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Henry to make such affirmative statements is rather lofty of you.

Having worked for most telecom vendors and many operators, in 30 countries, exclusively in the realms of signalling, it is rather staggering that you retort "confused" and leave it at that. That signalling work includes first NGN trials and 3G deployments.

The "others" you refer to is "other" and I've just replied to that.

As said I asked for a balanced view as far as possible and simply hitting reply, typing "confused"/"half-truth" is far from balanced.

Regards

Lee

On 16/12/2007, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Lee,

 

Sorry, but you have it all wrong and confused as email from others are also observing.

The half truths are even more confusing.

This list is not the right place to argue your confusion.

 

Henry

 

From: Lee Dryburgh [mailto: dryburghl@gmail.com]
Sent: Sunday, December 16, 2007 8:35 AM
To: IETF SIP List
Subject: [Sip] Chance to defend position that SIP has had poor consumertraction Etc.

 

Marketing for the eComm March 2008 conference (see www.eCommMedia.com) is away to drive ahead with the messages which I give them. One of these messages is critical towards SIP. Before the marketing material is finalised, I'd like to first welcome responses. I'd love to copy all the messages but I may run the risk of getting accused of spamming the list so below I've just copied the section that relates to SIP:

"Voice Industry Stagnancy
Telcos still see themselves as masters of communications innovation and the guardians to the creation of new services. Yet 3G, FMC, IPTV, NGN and IMS services are failing in the market place. At the same time consumer attention drifts increasingly towards Internet based applications such as Facebook, MySpace, YouTube, FlickR, SecondLife, World of Warcraft Etc. which are becoming increasingly voice enabled.

Yet within the Internet realms VoIP is still heralded as the communication revolution. But VoIP on it's own is nothing more than digital telephony and it will never be profitable. It has gained little consumer traction and can be announced as dead-on-arrival. SIP the VoIP signaling protocol even after a decade of development has had little consumer reach and the entire notion of a common signaling protocol is now under question. "

Now it would seem stupid to ask people to call their baby ugly. BUT what I do hope for, is that there is enough people with a balanced view who if they feel strongly against this position and can provide clear rationale, then I will have it modified/changed accordingly. Otherwise it will be accepted as true. Seems fair?

Thanks Lee


------=_Part_3982_18746131.1197851587610-- --===============1494366236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1494366236==-- From sip-bounces@ietf.org Sun Dec 16 20:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J44W3-0007Wf-1b; Sun, 16 Dec 2007 20:11:31 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J44W1-0007Wa-MF for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 20:11:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J44W1-0007WS-Bf for sip@ietf.org; Sun, 16 Dec 2007 20:11:29 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J44W1-0008TI-1T for sip@ietf.org; Sun, 16 Dec 2007 20:11:29 -0500 Received: from [192.168.2.106] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBH1BRVT013023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 16 Dec 2007 19:11:28 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FBF7E82-F903-4352-8B9D-A0C3B0FB9E27@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Chance to defend position that SIP has had poor consumer traction Etc. Date: Sun, 16 Dec 2007 19:11:20 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 16, 2007, at 8:35 AM, Lee Dryburgh wrote: > Marketing for the eComm March 2008 conference (see > www.eCommMedia.com) is away to drive ahead with the messages which > I give them. One of these messages is critical towards SIP. Before > the marketing material is finalised, I'd like to first welcome > responses. I'd love to copy all the messages but I may run the risk > of getting accused of spamming the list so below I've just copied > the section that relates to SIP: > Eek! This is sure to generate a major flamewar! Please respond directly to Lee, NOT THE LIST! Or, I'll make you guys a new list for the flamewar if needed. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Dec 16 20:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J44nX-0000LA-PC; Sun, 16 Dec 2007 20:29:35 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J44nW-0000Il-DL for sip-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 20:29:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J44nW-0000Id-3i for sip@ietf.org; Sun, 16 Dec 2007 20:29:34 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J44nV-0006eH-Kk for sip@ietf.org; Sun, 16 Dec 2007 20:29:34 -0500 Received: by wa-out-1112.google.com with SMTP id k40so3797740wah.25 for ; Sun, 16 Dec 2007 17:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QMiKqQVsGY53B1PJvwkvHjybX4lHZHHWIEQRCQE6K1A=; b=VWAZRm1fmEXyo6jmWD4rFqa7MNbiUuxcwo6iRvM/LwtJhMW36gBcADaEm9mfkKtaekrg799sp60Mjy201e/lhy89/9P62lvFz3PL5CD+5i1i2SAe3dvXwZZDHKCxfAC4h+TykwbgaMg1qEPyXqJnGuCPa/9MkdTidX0Yrv0pCy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XfhXzeDQlssv7TQhN4z7l8UQ4Ohc5jb1k8bmUtTaMjoVpiN2bwr9dVkiy5xSDM063/9PtyGXIo0fMLIPJgautsgEiLblIft07XhGNh4j18XYbMrYMetlYcblWWpyAVX5XXMe7bkOoHVT6qPSb9FM2e5VXSMZDeztiaFgS3T26FI= Received: by 10.114.92.2 with SMTP id p2mr1515697wab.90.1197854972813; Sun, 16 Dec 2007 17:29:32 -0800 (PST) Received: by 10.114.27.13 with HTTP; Sun, 16 Dec 2007 17:29:32 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 01:29:32 +0000 From: "Lee Dryburgh" To: "IETF SIP List" Subject: Re: [Sip] Chance to defend position that SIP has had poor consumer traction Etc. In-Reply-To: <6FBF7E82-F903-4352-8B9D-A0C3B0FB9E27@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6FBF7E82-F903-4352-8B9D-A0C3B0FB9E27@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sure that is probably best to avoid list flame wars that could ensure on this rather large list. I quickly setup a mailman private mailing list (no public archiving) for the purposes of continuing the discussion. Sign up here: http://ecommmedia.com/mailman/listinfo/sip_discussion_ecommmedia.com Once signed up, post using: sip_discussion@ecommmedia.com Now dropping off this list on this issue. Thanks Lee On 17/12/2007, Dean Willis wrote: > > On Dec 16, 2007, at 8:35 AM, Lee Dryburgh wrote: > > > Marketing for the eComm March 2008 conference (see > > www.eCommMedia.com) is away to drive ahead with the messages which > > I give them. One of these messages is critical towards SIP. Before > > the marketing material is finalised, I'd like to first welcome > > responses. I'd love to copy all the messages but I may run the risk > > of getting accused of spamming the list so below I've just copied > > the section that relates to SIP: > > > > Eek! This is sure to generate a major flamewar! > > Please respond directly to Lee, NOT THE LIST! Or, I'll make you guys > a new list for the flamewar if needed. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 03:43:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4BYX-0003eb-6G; Mon, 17 Dec 2007 03:42:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4BYW-0003dA-5Q for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 03:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4BYV-0003b9-Qs for sip@ietf.org; Mon, 17 Dec 2007 03:42:31 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4BYT-0004QH-O3 for sip@ietf.org; Mon, 17 Dec 2007 03:42:31 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JT600G2PQUSE8@siemenscomms.co.uk> for sip@ietf.org; Mon, 17 Dec 2007 08:42:28 +0000 (GMT) Date: Mon, 17 Dec 2007 08:42:27 +0000 From: "Elwell, John" Subject: RE: [Sip] On The Essentialness of Corrections In-reply-to: To: Dean Willis , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D04D8F4A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] On The Essentialness of Corrections Thread-Index: Acg/S9VPPQZjKGQNRfqcsWZwklhcGQBPKdGQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47630555.7090605@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As a further consideration, MMUSIC already seems to be taking an approach for SDP similar to Dean's proposal for SIP: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-00.txt John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 15 December 2007 18:53 > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] On The Essentialness of Corrections >=20 >=20 > On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote: >=20 > > inline: > > > > Dean Willis wrote: > > > >> Here's a test I'd like to propose: If the change is such that if =20 > >> we were re-writing the affected RFC we'd include the new behavior =20 > >> as normative behavior, then we track it as a revision.=20 > This allows =20 > >> us to fully deprecate the behavior that it replaces, such that we =20 > >> no longer have to consider the old behavior when compliance =20 > >> testing. If we can't deprecate the replaced behavior, then we =20 > >> really do have an extension (not a revision), and we need an =20 > >> extension negotiation mechanism to know when it can be used or is =20 > >> being used. > > > > I'm not sure I agree with this. I think we have some extensions =20 > > which we'd arguably include as, 'things we'd make as new normative =20 > > behavior that is core to sip'. I personally would have wished that =20 > > nat traversal were an integral part of sip and if I could do it =20 > > over, would not have it split out. But clearly ICE and=20 > outbound and =20 > > all that are not essential corrections. > > > > In my mind, the right litmus test is that the new behavior: > > > > 1. cannot be negotiated using the standardized techniques, AND > > 2. represents a change that impacts interoperability with other =20 > > implementations which might not implement this new behavior > > > > THEN its an essential correction. > > > > THings like BNF bugs are clearly in scope. Something like record-=20 > > route fix doesn't meet this litmus test because of the=20 > second item. =20 > > I can implement this and fully interoperate with existing =20 > > implementations. >=20 > Ok, there's probably a valid argument here. It's important to note =20 > also that if something is an "essential correction", we'd be willing =20 > to say that an implementation that does not conform to the=20 > correction =20 > is in violation of the specification and needs to be fixed. In other =20 > words, there is the same sort of justification for fixing it=20 > as there =20 > is for "MUST" in RFC 2119 -- failure to conform creates a failure to =20 > interoperate or function correctly. >=20 > Now, it's arguable whether the record-route-fix falls into this =20 > category or not. Route rewriting, as opposed to double recording, =20 > prevents route signing. Is the ability to use route-signing=20 > important =20 > enough that we'd say that any implementation that precludes its use =20 > is "broken"? I'd say that this is the test. >=20 >=20 > >> I'd actually like to see us go beyond the batching of "essential =20 > >> corrections" and start maintaining complete and fully-revised =20 > >> versions of the normative behaviors as internet drafts, perhaps =20 > >> occasionally publishing them as RFCs that replace the older =20 > >> versions. So for example with RFC 3261, we'd maintain a "draft-=20 > >> ietf-sip-rfc3261-bis" that would start as a copy of RFC=20 > 3261 (with =20 > >> current boilerplate, of course) and then be edited to reflect the =20 > >> changes documented in each "essential correction" we agree to. =20 > >> Then instead of telling implementors to go read RFC 3261 plus a =20 > >> dozen more potentially conflicting revision documents, we could =20 > >> just say "see draft-ietf-sip-rfc3261-bis-xx". > > > > I thought the idea is that there is just one revision document =20 > > (essential corrections) and not seven. >=20 > Let's say we roll the 7 changes (I just made that number up, there =20 > may be more or less) for 2008 into the 2008 essential corrections =20 > RFC. What do we do in 2009? Copy all of the 2008 changes into the =20 > 2009 RFC? What happens when we've had overlapping changes, such that =20 > the same part of the spec has been touched twice? Does the second =20 > change need to write step-by-step edits against the base RFC, or =20 > against the base RFC as amended by the first change? This=20 > gets hairy, =20 > and it is made a lot easier if we write the first change against the =20 > RFC, apply the first change to the RFC to generate the -bis=20 > spec, and =20 > then make subsequent corrections bundles against the -bis spec. This =20 > gives us a "fully assembled" spec to work against. Reverse deltas as =20 > opposed to forward deltas, from a source-code-control perspective. >=20 > > I promise you that once you open the floodgates to an rfc3261 =20 > > revision spec, the temptation to do LOTS of other things to the =20 > > document will be too great. Clarify this while we're at it? OK. =20 > > Maybe we should pull that extension in. ANd so on. I don't want to =20 > > do that. Segmenting this into an essential corrections document =20 > > keeps pandoras box from opening. >=20 > I'll certainly agree that a substantial amount of discipline is =20 > required in either case. >=20 > The question is: Do we want one document an implementor can=20 > go to, or =20 > do we want a base document plus many "diff" deltas? >=20 > Looking at the bug tracker for RFC 3261, I can see that there have =20 > been 85 different bugs filed. While some may not meet the=20 > criteria of =20 > "essential" (is confusing "excepting" and "accepting" essential?), =20 > I'll bet you there are still a lot of things that need fixing in the =20 > doc. And RFC 3261 isn't the only spec that needs polishing -- there =20 > are over 200 bugs in that tracker. >=20 > > The amount of work that went into rfc2543 -> rfc3261 was =20 > > astoundingly large, as any of the editors who basically did=20 > this as =20 > > a full time job for like 6 months will tell you (my boss would ask =20 > > me when I was coming back to work...). I do not think we as a =20 > > working group have or want to spend the cycles on such a =20 > > monumentally large task at this time. >=20 > I'm not proposing SIP 3.0 here -- just proposing ways to correct the =20 > known bugs in our RFCs that produces a result usable by developers, =20 > students, other SDOs, and other readers of those RFCs. What we're =20 > doing now IS NOT WORKING. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 11:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IP0-0000wZ-CT; Mon, 17 Dec 2007 11:01:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4IOy-0000vT-FT for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:01:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IOy-0000v2-2u for sip@ietf.org; Mon, 17 Dec 2007 11:01:08 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4IOx-0003hC-Ng for sip@ietf.org; Mon, 17 Dec 2007 11:01:07 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lBHG11FG010251; Mon, 17 Dec 2007 10:01:02 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lBHG0wj17176; Mon, 17 Dec 2007 10:01:02 -0600 (CST) Message-ID: <47669D3A.6040903@alcatel-lucent.com> Date: Mon, 17 Dec 2007 10:00:58 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections References: <4762F188.4080409@alcatel-lucent.com> <79ADF841-123A-4560-8B83-FB10D46D8C23@softarmor.com> In-Reply-To: <79ADF841-123A-4560-8B83-FB10D46D8C23@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > It's the "logical product" of the essential corrections process. > > Each draft in the essential corrections process has to specify > line-by-line changes to the RFC it is correcting. If we were to extract > those changes and apply them to the source, we would get the "tracking > draft" I'm talking about. OK; I am with you now. In that case, yes, maintaining one draft is preferable. This also means that -- as Jonathan said earlier -- we have to be careful as to what constitutes an essential correction vs. new functionality. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 11:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IZQ-0003gm-FS; Mon, 17 Dec 2007 11:11:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4IZO-0003gV-E1 for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:11:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IZO-0003gN-47 for sip@ietf.org; Mon, 17 Dec 2007 11:11:54 -0500 Received: from harjus.tutpro.com ([192.98.100.3] helo=taimen.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4IZM-0006ub-IE for sip@ietf.org; Mon, 17 Dec 2007 11:11:54 -0500 Received: by taimen.tutpro.com (Postfix, from userid 1000) id F061533A8AE; Mon, 17 Dec 2007 18:12:30 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18278.40942.924092.6577@harjus.tutpro.com> Date: Mon, 17 Dec 2007 18:12:30 +0200 To: "Vijay K. Gurbani" Subject: Re: [Sip] On The Essentialness of Corrections In-Reply-To: <47669D3A.6040903@alcatel-lucent.com> References: <4762F188.4080409@alcatel-lucent.com> <79ADF841-123A-4560-8B83-FB10D46D8C23@softarmor.com> <47669D3A.6040903@alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani writes: > OK; I am with you now. In that case, yes, maintaining one draft > is preferable. for the maintenance i suggest keeping the draft in subversion repository and each time a change is agreed, a commit will be made. this way it is easy keep the draft up to date. also, a change history is automatically visible. once in a while, editors can issue a new tag, which will become next rfc bis. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 12:31:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Jnc-0002y4-Ov; Mon, 17 Dec 2007 12:30:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4Jnb-0002xp-Le for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 12:30:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Jnb-0002xf-B8 for sip@ietf.org; Mon, 17 Dec 2007 12:30:39 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Jna-0000hi-7A for sip@ietf.org; Mon, 17 Dec 2007 12:30:39 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Dec 2007 09:30:37 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBHHUbc0002542; Mon, 17 Dec 2007 09:30:37 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBHHU80s016100; Mon, 17 Dec 2007 17:30:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 09:30:25 -0800 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 09:30:25 -0800 Message-ID: <4766B259.6000905@cisco.com> Date: Mon, 17 Dec 2007 12:31:05 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] On The Essentialness of Corrections References: <47630555.7090605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 17:30:25.0447 (UTC) FILETIME=[825C8370:01C840D2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7279; t=1197912637; x=1198776637; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20On=20The=20Essentialness=20of=2 0Corrections |Sender:=20; bh=BHTXtFvlskSvaTvQXwQiAehdW+3bzS9eTECxhQ+6f7I=; b=aMKormaPdLFUews+XWVMfdPIrPPXbQ7sxIJXaOLzyTL0KGbcxPwvUrR8/5 2Mhmajk/4G29Q7aiDKcyDuJpQDjit3Y2Nvn4YOdrXdafBZo3G0DbkUqC7VJD ACaDx7RPID; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline: Dean Willis wrote: > > On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote: > >> inline: >> >> Dean Willis wrote: >> >>> Here's a test I'd like to propose: If the change is such that if we >>> were re-writing the affected RFC we'd include the new behavior as >>> normative behavior, then we track it as a revision. This allows us to >>> fully deprecate the behavior that it replaces, such that we no longer >>> have to consider the old behavior when compliance testing. If we >>> can't deprecate the replaced behavior, then we really do have an >>> extension (not a revision), and we need an extension negotiation >>> mechanism to know when it can be used or is being used. >> >> I'm not sure I agree with this. I think we have some extensions which >> we'd arguably include as, 'things we'd make as new normative behavior >> that is core to sip'. I personally would have wished that nat >> traversal were an integral part of sip and if I could do it over, >> would not have it split out. But clearly ICE and outbound and all that >> are not essential corrections. >> >> In my mind, the right litmus test is that the new behavior: >> >> 1. cannot be negotiated using the standardized techniques, AND >> 2. represents a change that impacts interoperability with other >> implementations which might not implement this new behavior >> >> THEN its an essential correction. >> >> THings like BNF bugs are clearly in scope. Something like record-route >> fix doesn't meet this litmus test because of the second item. I can >> implement this and fully interoperate with existing implementations. > > Ok, there's probably a valid argument here. It's important to note also > that if something is an "essential correction", we'd be willing to say > that an implementation that does not conform to the correction is in > violation of the specification and needs to be fixed. In other words, > there is the same sort of justification for fixing it as there is for > "MUST" in RFC 2119 -- failure to conform creates a failure to > interoperate or function correctly. Right, and to be clear, 'violation of the specification' basically refers to 3261 itself. > > Now, it's arguable whether the record-route-fix falls into this category > or not. Route rewriting, as opposed to double recording, prevents route > signing. Is the ability to use route-signing important enough that we'd > say that any implementation that precludes its use is "broken"? I'd say > that this is the test. Clearly no. RFC3261 explicitly says you can't do it. I can't think of any reasonable use case for it. > > >>> I'd actually like to see us go beyond the batching of "essential >>> corrections" and start maintaining complete and fully-revised >>> versions of the normative behaviors as internet drafts, perhaps >>> occasionally publishing them as RFCs that replace the older versions. >>> So for example with RFC 3261, we'd maintain a >>> "draft-ietf-sip-rfc3261-bis" that would start as a copy of RFC 3261 >>> (with current boilerplate, of course) and then be edited to reflect >>> the changes documented in each "essential correction" we agree to. >>> Then instead of telling implementors to go read RFC 3261 plus a dozen >>> more potentially conflicting revision documents, we could just say >>> "see draft-ietf-sip-rfc3261-bis-xx". >> >> I thought the idea is that there is just one revision document >> (essential corrections) and not seven. > > Let's say we roll the 7 changes (I just made that number up, there may > be more or less) for 2008 into the 2008 essential corrections RFC. What > do we do in 2009? Copy all of the 2008 changes into the 2009 RFC? That was Keith's original proposal. > What > happens when we've had overlapping changes, such that the same part of > the spec has been touched twice? Does the second change need to write > step-by-step edits against the base RFC, or against the base RFC as > amended by the first change? Well, this may be a problem in theory only and not in practice. We don't have this problem AFAIK for any of the existing stuff. > This gets hairy, and it is made a lot > easier if we write the first change against the RFC, apply the first > change to the RFC to generate the -bis spec, and then make subsequent > corrections bundles against the -bis spec. This gives us a "fully > assembled" spec to work against. Reverse deltas as opposed to forward > deltas, from a source-code-control perspective. I agree that it is easier for someone, starting from scratch, to pick up a document which is all of sip including the corrections, all built in. However for folks who already implemented rfc3261 and want to know what has changed, a separate document that clearly states the new functionality is easier. > >> I promise you that once you open the floodgates to an rfc3261 revision >> spec, the temptation to do LOTS of other things to the document will >> be too great. Clarify this while we're at it? OK. Maybe we should pull >> that extension in. ANd so on. I don't want to do that. Segmenting this >> into an essential corrections document keeps pandoras box from opening. > > I'll certainly agree that a substantial amount of discipline is required > in either case. I think we'll find the discipline much harder to follow if we are actually producing an rfc3261bis. Would we indeed reject a one-line clarifying correction? > > The question is: Do we want one document an implementor can go to, or do > we want a base document plus many "diff" deltas? > > Looking at the bug tracker for RFC 3261, I can see that there have been > 85 different bugs filed. While some may not meet the criteria of > "essential" (is confusing "excepting" and "accepting" essential?), I'll > bet you there are still a lot of things that need fixing in the doc. And > RFC 3261 isn't the only spec that needs polishing -- there are over 200 > bugs in that tracker. OK - so that is more than just a few essential corrections, its a real revision. > >> The amount of work that went into rfc2543 -> rfc3261 was astoundingly >> large, as any of the editors who basically did this as a full time job >> for like 6 months will tell you (my boss would ask me when I was >> coming back to work...). I do not think we as a working group have or >> want to spend the cycles on such a monumentally large task at this time. > > I'm not proposing SIP 3.0 here -- just proposing ways to correct the > known bugs in our RFCs that produces a result usable by developers, > students, other SDOs, and other readers of those RFCs. What we're doing > now IS NOT WORKING. WELL, rfc2543->rfc3261 wasn't a sip3.0 either; it was meant to be only fixes, clarifications and elimination of unimplemented things. But it was still huge. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 15:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MdU-0006pB-1E; Mon, 17 Dec 2007 15:32:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4MdT-0006p5-2W for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 15:32:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MdS-0006ov-Lo for sip@ietf.org; Mon, 17 Dec 2007 15:32:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4MdR-0007MM-Ln for sip@ietf.org; Mon, 17 Dec 2007 15:32:22 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2007 15:32:21 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBHKWLPk013828; Mon, 17 Dec 2007 15:32:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBHKW4vB016167; Mon, 17 Dec 2007 20:32:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 15:32:01 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 15:32:01 -0500 Message-ID: <4766DCC6.3030708@cisco.com> Date: Mon, 17 Dec 2007 15:32:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis References: <3A12F8FF-8623-484C-ABD4-DE00FBD03B87@softarmor.com> In-Reply-To: <3A12F8FF-8623-484C-ABD4-DE00FBD03B87@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 20:32:01.0029 (UTC) FILETIME=[E0A26350:01C840EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7910; t=1197923541; x=1198787541; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Requested=20Expert=20Review=20Request=3A=20draf t-ietf-mediactrl-vxml-00 |Sender:=20 |To:=20Dean=20Willis=20; bh=oEni4JbKiFPKXGa5MXUBPAclJ1m/fuBXP1f8lihnyBQ=; b=M1ooPRSydsLvgGjA0pEQusTnVw1jF+JXwtxSxdlpGCpO543xey7G3cp2Lo YUInDBZjZRhoUqEI+ocyvsNO5iQijf9sN6pnX4GrMkwtXUz90AZouO5miAXL 6unOseu4fT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: sip-chairs@tools.ietf.org, SIP IETF , Mark Scott , David Burke Subject: [Sip] Requested Expert Review Request: draft-ietf-mediactrl-vxml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was asked by Dean to provide a SIP Expert Review of this draft, with special note to section 2.3. In general I like this draft. It begins to exploit the power of sip, and to unify it with other protocols. I did find some issues, all of which should be fairly straightforward to address. I've broken my comments down by section. In many cases I have includes snips from the draft for reference and followed those with pertinent comments. Thanks, Paul Section 2.1: The ABNF of the URI seems excessively rigid in the ordering of parameters - first the init-parameters, then the vxml-parameters, then then any other uri-parameters. It also doesn't note that 'uri-parameters' is defined in 3261. I would suggest something like: dialog-parameters = *(";" dialog-parameter) dialog-parameter = init-param / vxml-param / uri-parameter ; defined in RFC 3261 init-param = (dialog-param / maxage-param / maxstale-param / method-param / postbody-param) vxml-param = vxml-keyword "=" vxml-value That achieves the same effect but allows all the params in any order. This is almost a nit, but the rigid ordering is likely to be a source of interop problems. I'm confused about postbody: postbody: Used to set the application/x-www-form-urlencoded encoded [HTML4] HTTP body for "post" requests (or is otherwise ignored). The postbody value is the prepared application/ x-www-form-urlencoded content, subsequently URL-encoded (see note below). ... Note: Special characters in Request-URI parameter values need to be URL-encoded as required by the SIP URI syntax, for example '?' (%3f), '=' (%3d), and ';' (%3b). The VoiceXML Media Server MUST therefore unescape Request-URI parameter values before making use of them or exposing them to running VoiceXML applications. It is important that the VoiceXML Media Server only unescape the parameter values once since the desired VoiceXML URI value could itself be URL encoded, for example. When a postbody is included, its entire content including any line breaks (represented by a CR LF pair) is encoded as a single parameter value following the above rules (such that the line breaks would be replaced by '%0D%0A', for example). [HTML4] says: application/x-www-form-urlencoded This is the default content type. Forms submitted with this content type must be encoded as follows: 1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A'). 2. The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'. The interaction between these two escaping rules seems potentially confusing. I *think* when this is all put together it means that the body must first be encoded according to the [HTML4] section above. At that point it will already be almost conformant to the 3261 syntax of a token, except for the use of '&'. Then it needs to be encoded again, which will take care of the ampersands, but which will re-encode the '%' characters of the first encoding. Exactly what, if anything, I would recommend changing depends on whether I understood what is expected. I guess I might just recommend that you clarify further. (Perhaps I'm just being dense. If so please just tell me so.) Section 2.2: The Application Server SHOULD insert its own URI in the Record-Route header so that it remains in the signaling path for subsequent signaling related to the session. This is of particular importance for call transfers so that upstream Application Servers or proxy servers see signaling originating from the Application Server and not the VoiceXML Media Server itself. I don't understand the purpose of the above. The SHOULD strength of this requirement suggests to me an assumption of a particular operating environment. In the general case, why should this be more than MAY strength? Section 2.3: IMO the use of a media-less session is an entirely valid sip usage. The only concern I might potentially have is if it were to catch some UA unaware, because some UAs just aren't prepared to handle this case. But the recommended usage here always puts the choice of doing this in the hands of *other* UA, not the media server. So I see no problem. I do find it disconcerting that the initial invite and subsequent reinvites are handled in different ways. For the initial one you stall the VXML awaiting a media stream, but on subsequent ones you assume the absence of a stream is equivalent to having a stream that doesn't send anything. Why isn't the behavior consistent in these cases? If you need to support both behaviors, then it might be better to explicit and unique signaling for each. For instance, you might define that a media stream with a=inactive or a=sendonly (from the client's perspective - client putting media server "on hold") could be treated as the absence of input but the absence of the stream means you should wait for a stream to be negotiated. Section 2.4: I don't feel qualified to comment on the validity of the mappings of History-Info. It might be good to get somebody else who knows it well to comment on that. In addition, the array's toString() function returns the full SIP Request-URI. For example, assuming a Request-URI of sip:dialog@ example.com;voicexml=http://example.com;obj={"x":1,"y":true} then I don't believe the above URI is valid. The ',' '{' and '}' aren't syntactically correct in a URI pvalue. You would need to escape them. Section 2.6.2: IIUC, message (1) contains no offer, (5) contains an offer with media, and (6) accepts the call but rejects the media. If so, then (9) will most likely be invalid. To make it valid, the o-line from (8) needs to be replaced with one consistent to that used in (6), with the version number incremented. And if (5) has more m-lines than (8), then (9) needs to be padded with extra (rejected) m-lines. Section 5.2: On receipt of the REFER request, the VoiceXML Media Server MUST issue a provisional response, 100 Trying. The 202 Accepted response indicates that the VoiceXML document has been fetched and parsed correctly. The VoiceXML Media Server proceeds to place the outbound INVITE and will execute the application after the ACK is sent. The rules of RFC 4320 need to be followed here. REFER is a non-invite transaction and so the timing of the 100 must be as specified in 4320. In the call flow, the sending of the initial NOTIFY before the 202 for the REFER, and especially before determining if REFER is going to succeed or fail, is at best unusual and almost certainly incorrect. Sending the NOTIFY and then sending a failure response would certainly be incorrect. I think you have two choices: - wait until the get is complete before sending the NOTIFY, and probably send it after the 202. - send a 202 for the REFER before doing the GET. Inform of a GET failure via a NOTIFY. Section 6.3: In the call flow I think you probably need another NOTIFY between messages (6) and (7). Its potentially too long until (13). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 17 20:04:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qri-0000bC-6T; Mon, 17 Dec 2007 20:03:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4Qrf-0000WM-2d for sip-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 20:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qre-0000Vb-Ir; Mon, 17 Dec 2007 20:03:18 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Qre-0006BL-5i; Mon, 17 Dec 2007 20:03:18 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id D92D0100330; Mon, 17 Dec 2007 17:03:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071218010317.D92D0100330@bosco.isi.edu> Date: Mon, 17 Dec 2007 17:03:17 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 5079 on Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5079 Title: Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author: J. Rosenberg Status: Standards Track Date: December 2007 Mailbox: jdrosen@cisco.com Pages: 8 Characters: 15670 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-acr-code-05.txt URL: http://www.rfc-editor.org/rfc/rfc5079.txt The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 08:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4c3I-0001zI-4f; Tue, 18 Dec 2007 08:00:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4c3G-0001sx-91 for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 08:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4c3F-0001sM-Tw; Tue, 18 Dec 2007 08:00:01 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4c3F-0005Nq-Hh; Tue, 18 Dec 2007 08:00:01 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6A44426E77; Tue, 18 Dec 2007 13:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4c3F-0002pq-Ae; Tue, 18 Dec 2007 08:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 08:00:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-multiple-refer-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Referring to Multiple Resources in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sip-multiple-refer-03.txt Pages : 15 Date : 2007-12-18 This document defines extensions to the SIP REFER method so that this method can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-multiple-refer-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-multiple-refer-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18075722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-multiple-refer-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-multiple-refer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18075722.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Dec 18 08:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cD0-0005Gw-QO; Tue, 18 Dec 2007 08:10:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4cCy-000576-LT for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 08:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cCy-00056t-Am for sip@ietf.org; Tue, 18 Dec 2007 08:10:04 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4cCw-0005h2-G5 for sip@ietf.org; Tue, 18 Dec 2007 08:10:04 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBIDA0uu029322; Tue, 18 Dec 2007 07:10:23 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:09:45 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:09:45 +0200 Received: from [10.162.60.232] ([10.162.60.232]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:09:44 +0200 Message-ID: <4767C698.8080606@nsn.com> Date: Tue, 18 Dec 2007 15:09:44 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: sip@ietf.org, Cullen Jennings Subject: Re: [Sip] I-D Action:draft-ietf-sip-multiple-refer-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 13:09:45.0046 (UTC) FILETIME=[425E7760:01C84177] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Isomaki Markus \(Nokia-SIR/Espoo\)" , Gonzalo Camarillo , Niemi Aki X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just submitted a new version of the multiple REFER draft, as you can see in the announcement e-mail below. There is only one change, but it had impact in many places in the whole document. The change came from the Gen-ART reviewer Francis Dupont, who commented that the draft was hard to follow because of mixing terminology. In fact, the draft was using UAC, UAS, UA, REFER-Issuer, REFER-Recipient, REFER-Target, URI-List service, conference server, and server, in a mixed way. So, the effort in this revision has been to homogenize the terminology and use REFER-Issuer/Recipient/Target whenever possible. You can track the changes of the document in the following URL: http://people.nokia.net/~miguel/drafts/draft-ietf-sip-multiple-refer-03-from-2.html /Miguel sip-bounces@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 : Referring to Multiple Resources in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sip-multiple-refer-03.txt > Pages : 15 > Date : 2007-12-18 > > This document defines extensions to the SIP REFER method so that this > method can be used to refer to multiple resources in a single > request. These extensions include the use of pointers to Uniform > Resource Identifier (URI)-lists in the Refer-To header field and the > "multiple-refer" SIP option-tag. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-multiple-refer-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-sip-multiple-refer-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-multiple-refer-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 10:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eMa-0004yg-Vy; Tue, 18 Dec 2007 10:28:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4eMZ-0004yS-3R for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 10:28:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eMY-0004yK-Q4 for sip@ietf.org; Tue, 18 Dec 2007 10:28:06 -0500 Received: from itclus2.sea5.speakeasy.net ([72.1.141.56] helo=EXCHANGE-BE2.speakeasy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4eMY-0001SK-6d for sip@ietf.org; Tue, 18 Dec 2007 10:28:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Dec 2007 07:28:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: INVITE after a terminated dialog? Thread-Index: AchBipVjNYbfHG1LTa6urqa8eU6PiQ== From: "Jane Jiang" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Sip] INVITE after a terminated dialog? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2043015908==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2043015908== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8418A.959F8DE1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8418A.959F8DE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 There is a weird situation with us: (1) A Linksys phone sends an INVITE out with incorrect destination TN. As a result, our application server will set up a call between the Linksys phone and an IVR (2) A user incorrectly hits the on-hold key, which is basically sending a re-INVITE to the IVR (3) Our server seems to have answered the re-INVITE with a BYE (4) The Linksys phone responds to the BYE with a 200 (5) Afterwards, the Linksys phone still thinks that its original re-INVITE has not been responded. So, it will keep resend re-INVITE =20 The consequence of these re-INVITEs is a registration migration, which we don't like. We have been trying to figure out which side is not following RFC 3261, the phone, the SBCs are wrong, or the application servers. =20 I am wondering: (A) Is it legal for a server to ignore the re-INVITE and respond with a BYE and has nothing in between? =20 (B) If a UA has responded to a BYE with 200, is it supposed to forget about the re-INVITE request that it has sent out and not try to resend the re-INVITE, assuming a dialog has already been terminated with the BYE/200 transaction? Maybe in another sentence, is it legal to send our re-INVITEs outside an dialog, even if these re-INVITEs are the repeats of an original in-dialog re-INVITE? =20 Thanks! =20 Jane =20 ------_=_NextPart_001_01C8418A.959F8DE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
There = is a weird=20 situation with us:
(1) A = Linksys phone=20 sends an INVITE out with incorrect destination TN.  As a = result,=20 our application server will = set up a=20 call between the Linksys phone and an=20 IVR
(2) A user incorrectly hits the on-hold key, which is = basically sending a re-INVITE to the=20 IVR
(3) = Our=20 server seems to have = answered the re-INVITE with a = BYE
(4) = The Linksys=20 phone responds to the BYE = with a=20 200
(5) = Afterwards, the=20 Linksys phone still thinks that its original=20 re-INVITE has not been responded.  So, it will keep=20 resend re-INVITE
 
The = consequence of=20 these re-INVITEs is a registration = migration, which we don't like.  We have been trying to=20 figure out which side is not = following RFC=20 3261, the phone, the SBCs are wrong, or the application = servers.
 
I am=20 wondering:
(A) Is = it legal for=20 a server to ignore the re-INVITE = and=20 respond with a BYE and has nothing in = between?
 
(B) If = a UA has=20 responded to a BYE with 200, is it supposed to forget about the = re-INVITE=20 request that it has sent out and not try to resend the re-INVITE, = assuming a=20 dialog has already been terminated with the BYE/200 transaction?  = Maybe in=20 another sentence, is it legal to send our re-INVITEs outside an dialog, = even if=20 these re-INVITEs are the repeats of an original in-dialog=20 re-INVITE?
 
Thanks!
 
Jane
 
------_=_NextPart_001_01C8418A.959F8DE1-- --===============2043015908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2043015908==-- From sip-bounces@ietf.org Tue Dec 18 11:16:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4f79-0006O7-AE; Tue, 18 Dec 2007 11:16:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4f77-0006E9-O5 for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 11:16:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4f76-0006Ck-OS for sip@ietf.org; Tue, 18 Dec 2007 11:16:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4f76-0007tI-Bx for sip@ietf.org; Tue, 18 Dec 2007 11:16:12 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2007 11:16:12 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBIGGCjd020143; Tue, 18 Dec 2007 11:16:12 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBIGGBvP009478; Tue, 18 Dec 2007 16:16:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 11:16:10 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 11:16:10 -0500 Message-ID: <4767F24B.3040303@cisco.com> Date: Tue, 18 Dec 2007 11:16:11 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jane Jiang Subject: Re: [Sip] INVITE after a terminated dialog? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 16:16:10.0230 (UTC) FILETIME=[4D421960:01C84191] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2059; t=1197994572; x=1198858572; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INVITE=20after=20a=20terminated =20dialog? |Sender:=20 |To:=20Jane=20Jiang=20; bh=rCBpfwwoVOaBNlui4NKnKqnHVz0LwHDPEP2tTDInKJs=; b=z729SrIdQ40noTR2v2ZxGGq2RZwN7oG8kctnleIMaRzLWLX2Vl5f6NaGTE QsZDG8xpw2C+HxDYQx/rUtSYIekc7ceGZK07tfm9AkXTO0wLqsmarc5SMDZb v+ZGgSiCI7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jane, Can you provide a call flow for what is happening? Its a little hard to follow from the textual description. But in the meantime there is one fundamental principle of importance here: every transaction completes independently. Jane Jiang wrote: > Hi All, > > There is a weird situation with us: > (1) A Linksys phone sends an INVITE out with incorrect destination TN. > As a result, our application server will set up a call between the > Linksys phone and an IVR > (2) A user incorrectly hits the on-hold key, which is basically sending > a re-INVITE to the IVR > (3) Our server seems to have answered the re-INVITE with a BYE > (4) The Linksys phone responds to the BYE with a 200 > (5) Afterwards, the Linksys phone still thinks that its original > re-INVITE has not been responded. So, it will keep resend re-INVITE > > The consequence of these re-INVITEs is a registration migration, which > we don't like. We have been trying to figure out which side is not > following RFC 3261, the phone, the SBCs are wrong, or the application > servers. > > I am wondering: > (A) Is it legal for a server to ignore the re-INVITE and respond with a > BYE and has nothing in between? While the BYE may in some way have been provoked by the reINVITE, the two are distinct. The reINVITE still needs to be answered with some final response which then must be ACKed, and the BYE also needs to be responded to. > (B) If a UA has responded to a BYE with 200, is it supposed to forget > about the re-INVITE request that it has sent out and not try to resend > the re-INVITE, assuming a dialog has already been terminated with the > BYE/200 transaction? Maybe in another sentence, is it legal to send our > re-INVITEs outside an dialog, even if these re-INVITEs are the repeats > of an original in-dialog re-INVITE? It is not legal to send a *new* reINVITE after the dialog has been terminated. But it is appropriate to continue retransmissions if no response has been received. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 12:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fnY-0006Vr-Iw; Tue, 18 Dec 2007 12:00:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4fnX-0006Vh-7O for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 12:00:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fnW-0006VY-RS; Tue, 18 Dec 2007 12:00:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4fnW-00031E-DD; Tue, 18 Dec 2007 12:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 474E42AC66; Tue, 18 Dec 2007 17:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4fnV-0001Ex-Vr; Tue, 18 Dec 2007 12:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 12:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-xcapevent-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package Author(s) : J. Urpalainen Filename : draft-ietf-sip-xcapevent-00.txt Pages : 14 Date : 2007-12-18 This document describes an "xcap-diff" SIP event package, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-xcapevent-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-xcapevent-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18115748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-xcapevent-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-xcapevent-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18115748.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Dec 18 12:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4g4e-0002eV-R8; Tue, 18 Dec 2007 12:17:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4g4d-0002eO-3P for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 12:17:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4g4c-0002eG-OR for sip@ietf.org; Tue, 18 Dec 2007 12:17:42 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4g4c-0003ot-6y for sip@ietf.org; Tue, 18 Dec 2007 12:17:42 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBIHHb7S028845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Dec 2007 11:17:39 -0600 Message-ID: <476800AC.7090202@softarmor.com> Date: Tue, 18 Dec 2007 11:17:32 -0600 From: Dean Willis User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jane Jiang Subject: Re: [Sip] INVITE after a terminated dialog? References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jane Jiang wrote: > Hi All, > > There is a weird situation with us: > (1) A Linksys phone sends an INVITE out with incorrect destination TN. > As a result, our application server will set up a call between the > Linksys phone and an IVR > (2) A user incorrectly hits the on-hold key, which is basically sending > a re-INVITE to the IVR > (3) Our server seems to have answered the re-INVITE with a BYE > (4) The Linksys phone responds to the BYE with a 200 > (5) Afterwards, the Linksys phone still thinks that its original > re-INVITE has not been responded. So, it will keep resend re-INVITE > > The consequence of these re-INVITEs is a registration migration, which > we don't like. We have been trying to figure out which side is not > following RFC 3261, the phone, the SBCs are wrong, or the application > servers. > > I am wondering: > (A) Is it legal for a server to ignore the re-INVITE and respond with a > BYE and has nothing in between? > > (B) If a UA has responded to a BYE with 200, is it supposed to forget > about the re-INVITE request that it has sent out and not try to resend > the re-INVITE, assuming a dialog has already been terminated with the > BYE/200 transaction? Maybe in another sentence, is it legal to send our > re-INVITEs outside an dialog, even if these re-INVITEs are the repeats > of an original in-dialog re-INVITE? This is really off-target for this list, and possibly more appropriate for the sip-implementors list. It just occurred to me that we may also need something more like a sip-users list for people who are trying to make off-the-shelf stuff work. Perhaps there is such a list somewhere. My rather old-fashioned point of view suggests that every device in your chain is misbehaving. It seems a bit odd to me that the Linksys phone does a reinvite-to-hold before it completes the first INVITE transaction, but I'm perhaps misreading your report. Were there 200 (OK) and ACK messages completing the transaction of the initial INVITE? Or is the INVITE that the Linksys resends the reinvite-to-hold? What do the CSeq and SDP of the retransmitted INVITE look like? A) It is not reasonable to respond to an INVITE with a BYE. There needs to be a response message (like 200 or 404 or some other kind of response) as a result of the INVITE. B) No, every INVITE transaction needs to be completed by a final response. B part 2) A re-INVITE sent "outside a dialog" is a new dialog-establishing INVITE. It should have a new Call-ID. But there are possibly some odd conditions where not every node in the dialog realizes a dialog has ended. The dialog-uses doc would be a good thing to look at here. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 13:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gnU-0005dy-9Q; Tue, 18 Dec 2007 13:04:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4gnR-0005dk-SC for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 13:04:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gnR-0005dW-Hp for sip@ietf.org; Tue, 18 Dec 2007 13:04:01 -0500 Received: from mx5.inline.de ([193.19.137.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4gnP-0006fs-Og for sip@ietf.org; Tue, 18 Dec 2007 13:04:01 -0500 Received: from NATJA (p5098e507.dip0.t-ipconnect.de [80.152.229.7]) by mx5.inline.de (Postfix) with ESMTP id 005EB64029D for ; Tue, 18 Dec 2007 19:04:15 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: "Frank, Marc" To: sip@ietf.org Date: Tue, 18 Dec 2007 19:03:50 +0100 X-Mailer: KMail [version 1.4] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200712181903.50731.mf@dafuer.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Sip] Record-Route-Header ftag-field and routing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mf@dafuer.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi guys, because of some problems with my SIP-Client, I have traced the traffic of= a=20 snom SIP-phone. Now I'm a little confused about the Record-Route header. I've made two incoming testcalls with different providers. At the first test the snom-phone received an invite-message with record-r= oute=20 with ftag-field. When the phone hangup it sends it's BYE-Request to the=20 IP-address defined in the last route-header-field. At the second test (2nd provider) the snom-phone received an invite-messa= ge=20 with record-route and NO ftag-field. When the phone hangup it sends it's=20 BYE-Request to the IP-address of the registrar. Is it correct, that a SIP-application which receives a record-route with = ftag=20 must send the traffic depending on this call to that destination? Regards=20 Marc :-) Trace-Snapshot: Call 1 with re-routing -------------------------------------------------------------------------= ------- Received from udp:212.227.15.197:5060 at 18/12/2007 14:00:09:980 (1392 by= tes): INVITE sip:aaaaa at xx.xxx.229.7:2054;line=3Dj3eted9k SIP/2.0 Record-Route: Via: SIP/2.0/UDP 212.227.15.197;branch=3Dz9hG4bK59f8248d2c568739bc7dc8a7d= e9c4f82 Via: SIP/2.0/UDP 212.227.15.232;branch=3Dz9hG4bK589.5362a815.0 Via: SIP/2.0/UDP 212.227.15.197;branch=3Dz9hG4bK202ed21ce8126c48fd64f9f84= 58a705d Via: SIP/2.0/UDP sipgw01.bmcag.com:5060=20 ;received=3D62.206.6.140;branch=3Dz9hG4bKterm-2ab0b6-496151951416-4962142= 55114 From: caller ;tag=3D1937134= 676 To: called Contact: =2E.. Sent to udp:212.227.15.232:5060 at 18/12/2007 14:00:32:380 (695 bytes): BYE sip:caller at sipgw01.bmcag.com:5060 SIP/2.0 Via: SIP/2.0/UDP xx.xxx.229.7:2054;branch=3Dz9hG4bK-54bqxvq49o3d;rport Route: From: "called" ;tag=3Dckf1qvkl= vd To: "caller" ;tag=3D1937134= 676 Call-ID: 7e38a35-4274d41-7d136ce2-b115 at sipgw01.bmcag.com CSeq: 1 BYE -------------------------------------------------------------------------= ------- Call 2 without re-routing -------------------------------------------------------------------------= ------- Received from udp:213.218.28.202:5060 at 18/12/2007 18:02:31:170 (1422 by= tes): INVITE sip:user at xx.xxx.229.7:2060;line=3Di8vjxde1 SIP/2.0 Record-Route: Record-Route: Via: SIP/2.0/UDP 213.218.28.202;branch=3Dz9hG4bKbd69.7040b7b5.0 Via: SIP/2.0/UDP 213.218.28.102;branch=3Dz9hG4bKbd69.b2ae7011.0 Via: SIP/2.0/UDP 213.218.28.164:5060;branch=3Dz9hG4bK00E0F510055C3A From: "caller" ;tag=3D00E0F5100 To: Call-ID: 00E0F510055C3A11C0C5000025B9@213.218.28.164 CSeq: 34207 INVITE Contact: =2E.. Sent to udp:213.218.28.202:5060 at 18/12/2007 18:02:43:310 (731 bytes): BYE sip:called at ip SIP/2.0 Via: SIP/2.0/UDP 80.152.229.7:2060;branch=3Dz9hG4bK-t7jlwh3sb054;rport Route: Route: -------------------------------------------------------------------------= ------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 13:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gyz-0003yr-7v; Tue, 18 Dec 2007 13:15:57 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4gyx-0003yE-6E for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 13:15:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gyw-0003y1-EN for sip@ietf.org; Tue, 18 Dec 2007 13:15:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4gyv-00077D-UF for sip@ietf.org; Tue, 18 Dec 2007 13:15:54 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 18 Dec 2007 10:15:53 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBIIFrRW014102; Tue, 18 Dec 2007 10:15:53 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBIIFhLk012803; Tue, 18 Dec 2007 18:15:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 10:15:49 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.65.5]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 10:15:49 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Dec 2007 12:15:46 -0600 To: Paul Kyzivat , Jane Jiang From: "James M. Polk" Subject: Re: [Sip] INVITE after a terminated dialog? In-Reply-To: <4767F24B.3040303@cisco.com> References: <4767F24B.3040303@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Dec 2007 18:15:49.0175 (UTC) FILETIME=[043E2C70:01C841A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2756; t=1198001753; x=1198865753; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20INVITE=20after=20a=20terminated =20dialog? |Sender:=20; bh=rUFi4VnPt50ESlUfSII1A/wjuFxZz3H353l4AeOXdRU=; b=mG1e5BUN0QDHR1GgnJc0bUBJk/3JSAeF+bf/zGiZ/OlM3X5urmqq7i42ry xhFf+fIEjrSySJuwhr4++TNGehnvngzdmqJiqVbZQPBZn6alP4lQTf7LAWpG kqF8ZveNQQkDJxfw5Ylm2s1nrpCJb0Byl1RXDWq2uuxzuz97gDqN0=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:16 AM 12/18/2007, Paul Kyzivat wrote: >Jane, > >Can you provide a call flow for what is happening? Its a little hard >to follow from the textual description. > >But in the meantime there is one fundamental principle of importance >here: every transaction completes independently. I agree with Paul, and add to this that the CSeq value indicates which request a 200 OK response is for. Having the call flow would be better to diagnose this, and we might ask that you include some SIP headers of each message in the flow (Status line, To, From, CSeq, Route, ...) to help further. >Jane Jiang wrote: >>Hi All, >> >>There is a weird situation with us: >>(1) A Linksys phone sends an INVITE out with incorrect destination TN. >>As a result, our application server will set up a call between the >>Linksys phone and an IVR >>(2) A user incorrectly hits the on-hold key, which is basically >>sending a re-INVITE to the IVR >>(3) Our server seems to have answered the re-INVITE with a BYE >>(4) The Linksys phone responds to the BYE with a 200 >>(5) Afterwards, the Linksys phone still thinks that its original >>re-INVITE has not been responded. So, it will keep resend re-INVITE >> >>The consequence of these re-INVITEs is a registration migration, >>which we don't like. We have been trying to figure out which side >>is not following RFC 3261, the phone, the SBCs are wrong, or the >>application servers. >> >>I am wondering: >>(A) Is it legal for a server to ignore the re-INVITE and respond >>with a BYE and has nothing in between? > >While the BYE may in some way have been provoked by the reINVITE, >the two are distinct. The reINVITE still needs to be answered with >some final response which then must be ACKed, and the BYE also needs >to be responded to. > >>(B) If a UA has responded to a BYE with 200, is it supposed to >>forget about the re-INVITE request that it has sent out and not try >>to resend the re-INVITE, assuming a dialog has already been >>terminated with the BYE/200 transaction? Maybe in another >>sentence, is it legal to send our re-INVITEs outside an dialog, >>even if these re-INVITEs are the repeats of an original in-dialog re-INVITE? > >It is not legal to send a *new* reINVITE after the dialog has been >terminated. But it is appropriate to continue retransmissions if no >response has been received. > > Paul > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 14:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hl8-0008My-FK; Tue, 18 Dec 2007 14:05:42 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4hl6-0008Mq-UC for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 14:05:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hl6-0008Mi-K8 for sip@ietf.org; Tue, 18 Dec 2007 14:05:40 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4hl4-0008WS-D6 for sip@ietf.org; Tue, 18 Dec 2007 14:05:40 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E5C4821F27; Tue, 18 Dec 2007 20:05:37 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-d2-47681a015e98 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C645520424; Tue, 18 Dec 2007 20:05:37 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 20:05:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 20:05:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D7C2224A8; Tue, 18 Dec 2007 21:05:36 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 64CBB4DB1A; Tue, 18 Dec 2007 21:05:34 +0200 (EET) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 604B44DAE4; Tue, 18 Dec 2007 21:05:33 +0200 (EET) Message-ID: <476819FE.6060406@ericsson.com> Date: Tue, 18 Dec 2007 21:05:34 +0200 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> In-Reply-To: <47631BA9.5040904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 18 Dec 2007 19:05:37.0097 (UTC) FILETIME=[F92EE390:01C841A8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, just to add another example to this discussion (same as the vcard example): an application/im-iscomposing+xml content-type can be put in the body of a SIP MESSAGE and it is not (or it is not supposed to be) rendered as is to the recipient; an application that understood it would render it in whatever way it indicates that a user is in the process of composing a message. /Sal Paul Kyzivat wrote: > > > Hadriel Kaplan wrote: >> More importantly MESSAGE allows out-of-dialog requests. :) >> I was thinking the same as you, but I believe Paul's right in that >> render=inline and vcard/vcalendar are not inline. The question is if >> we want to let "attachment" disposition be allowed. I dread to do >> that, because people are already using MESSAGE to transfer 10MB >> images, but that's a separate ugly problem. :( > > I'm thinking that the body of a MESSAGE ought to allow almost all the > same things, with the same meanings, as the body of an MSRP message. > > BUT it should be strictly limited in the overall size it can be. If > what you want to send won't fit in a MESSAGE then switch to MSRP. > > Paul > >> -hadriel >> >> >>> -----Original Message----- >>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Sent: Friday, December 14, 2007 6:28 PM >>> To: sip@ietf.org >>> Subject: Re: [Sip] MESSAGE for rendering >>> >>> From: Paul Kyzivat >>> >>> I am entirely with you if the *intent* of sending the vcard is to >>> render >>> it to the user in some human readable way. Its hardly any different >>> from >>> sending HTML. >>> >>> Its much more questionable if the intent is that the vcard be >>> filed in >>> the recipients address book without being rendered. >>> >>> IMHO, filing information is as good as actually rendering it. The >>> real question is layering -- "render" means "deliver to the layer >>> above the SIP UA". Anything that partakes of media is "rendered" and >>> is acceptable for MESSAGE, anything that partakes of signaling is not >>> "rendered" and is acceptable for INFO. >>> >>> One criterion is "Would it make sense to let the user arbitrarily >>> re-route where this information goes?" With a vcard, it makes sense. >>> With the information INFO was intended to carry, it does not: >>> >>> RFC 2976 1.1 Example Uses >>> >>> The following are a few of the potential uses of the INFO >>> message: >>> >>> - Carrying mid-call PSTN signaling messages between PSTN >>> gateways. >>> >>> - Carrying DTMF digits generated during a SIP session. >>> >>> - Carrying wireless signal strength information in support of >>> wireless mobility applications. >>> >>> - Carrying account balance information. >>> [in a pay-as-you-go network -- DRW] >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 14:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hpX-0005gL-0r; Tue, 18 Dec 2007 14:10:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4hpV-0005g2-TT for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 14:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hpV-0005e8-G8 for sip@ietf.org; Tue, 18 Dec 2007 14:10:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4hpU-0000CV-Nw for sip@ietf.org; Tue, 18 Dec 2007 14:10:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2007 14:10:12 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBIJACcU022155; Tue, 18 Dec 2007 14:10:12 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBIJABij019896; Tue, 18 Dec 2007 19:10:12 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 14:10:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Record-Route-Header ftag-field and routing Date: Tue, 18 Dec 2007 14:10:11 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E04615EF9@xmb-rtp-215.amer.cisco.com> In-Reply-To: <200712181903.50731.mf@dafuer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Record-Route-Header ftag-field and routing Thread-Index: AchBoG/KoYClhXYoTNu33pPK6iTxhgABqhIg From: "Sanjay Sinha (sanjsinh)" To: , X-OriginalArrivalTime: 18 Dec 2007 19:10:11.0933 (UTC) FILETIME=[9CFF88D0:01C841A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4700; t=1198005012; x=1198869012; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Record-Route-Header=20ftag-fiel d=20and=20routing |Sender:=20 |To:=20,=20; bh=0AXF7/7/q4kFnURe2DPeQuZHCW+IMKJlz0z3LgUQ9uE=; b=hkWx8rTDcRjg0EnoGNKLcvNk5eGeEfN97Sj5G1/I/q3xEVrPYof8Ht0bu6 TfZSBr0hzo+wSxrvwgaxg6n7dewohE0LPWSr1AzyQQmaxsFXfOwLfStkJEqJ Ld3DCBzfIE; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -2.5 (--) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This would've been appropriate on sip-implementers mailer. The behavior below looks correct to me and has nothing to do with ftag field in RR header.=20 In the 1st case since UAS is getting a request with a RR header, next request on that dialog is sent to the address in RR header and since the proxy adding RR supports loose routing, request uri of BYE is contact address from previous request. In the 2nd case, since there are 2 RR headers, route set for UAS is: , .=20 And the next request on that dialog is correctly sent to 213.218.28.202. Sanjay >-----Original Message----- >From: Frank, Marc [mailto:mf@dafuer.com]=20 >Sent: Tuesday, December 18, 2007 1:04 PM >To: sip@ietf.org >Subject: [Sip] Record-Route-Header ftag-field and routing > >Hi guys, > >because of some problems with my SIP-Client, I have traced the=20 >traffic of a snom SIP-phone. Now I'm a little confused about=20 >the Record-Route header. > >I've made two incoming testcalls with different providers. > >At the first test the snom-phone received an invite-message=20 >with record-route with ftag-field. When the phone hangup it=20 >sends it's BYE-Request to the IP-address defined in the last=20 >route-header-field. > >At the second test (2nd provider) the snom-phone received an=20 >invite-message with record-route and NO ftag-field. When the=20 >phone hangup it sends it's BYE-Request to the IP-address of=20 >the registrar. > >Is it correct, that a SIP-application which receives a=20 >record-route with ftag must send the traffic depending on this=20 >call to that destination? > >Regards=20 > >Marc :-) > > >Trace-Snapshot: > > >Call 1 with re-routing >--------------------------------------------------------------- >----------------- >Received from udp:212.227.15.197:5060 at 18/12/2007=20 >14:00:09:980 (1392 bytes): > >INVITE sip:aaaaa at xx.xxx.229.7:2054;line=3Dj3eted9k SIP/2.0 >Record-Route: >Via: SIP/2.0/UDP=20 >212.227.15.197;branch=3Dz9hG4bK59f8248d2c568739bc7dc8a7de9c4f82 >Via: SIP/2.0/UDP 212.227.15.232;branch=3Dz9hG4bK589.5362a815.0 >Via: SIP/2.0/UDP=20 >212.227.15.197;branch=3Dz9hG4bK202ed21ce8126c48fd64f9f8458a705d >Via: SIP/2.0/UDP sipgw01.bmcag.com:5060 >;received=3D62.206.6.140;branch=3Dz9hG4bKterm-2ab0b6-496151951416-4 >96214255114 >From: caller sipgw01.bmcag.com;user=3Dphone>;tag=3D1937134676 >To: called >Contact: > >... > >Sent to udp:212.227.15.232:5060 at 18/12/2007 14:00:32:380 (695 bytes): > >BYE sip:caller at sipgw01.bmcag.com:5060 SIP/2.0 >Via: SIP/2.0/UDP xx.xxx.229.7:2054;branch=3Dz9hG4bK-54bqxvq49o3d;rport >Route: >From: "called" ;tag=3Dckf1qvklvd >To: "caller" sipgw01.bmcag.com;user=3Dphone>;tag=3D1937134676 >Call-ID: 7e38a35-4274d41-7d136ce2-b115 at sipgw01.bmcag.com >CSeq: 1 BYE >--------------------------------------------------------------- >----------------- > > > >Call 2 without re-routing >--------------------------------------------------------------- >----------------- > >Received from udp:213.218.28.202:5060 at 18/12/2007=20 >18:02:31:170 (1422 bytes): > >INVITE sip:user at xx.xxx.229.7:2060;line=3Di8vjxde1 SIP/2.0 >Record-Route: >Record-Route: >Via: SIP/2.0/UDP 213.218.28.202;branch=3Dz9hG4bKbd69.7040b7b5.0 >Via: SIP/2.0/UDP 213.218.28.102;branch=3Dz9hG4bKbd69.b2ae7011.0 >Via: SIP/2.0/UDP 213.218.28.164:5060;branch=3Dz9hG4bK00E0F510055C3A >From: "caller" ;tag=3D00E0F5100 >To: >Call-ID: 00E0F510055C3A11C0C5000025B9@213.218.28.164 >CSeq: 34207 INVITE >Contact: > >... > >Sent to udp:213.218.28.202:5060 at 18/12/2007 18:02:43:310 (731 bytes): > >BYE sip:called at ip SIP/2.0 >Via: SIP/2.0/UDP 80.152.229.7:2060;branch=3Dz9hG4bK-t7jlwh3sb054;rport >Route: >Route: >--------------------------------------------------------------- >----------------- > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 17:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kz0-0001K4-Ry; Tue, 18 Dec 2007 17:32:14 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4kyy-0001Jz-WF for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 17:32:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kyy-0001Jq-5J for sip@ietf.org; Tue, 18 Dec 2007 17:32:12 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4kyx-0001lQ-RB for sip@ietf.org; Tue, 18 Dec 2007 17:32:12 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBIMVtvc031318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Dec 2007 16:31:56 -0600 In-Reply-To: <476819FE.6060406@ericsson.com> References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] MESSAGE for rendering Date: Tue, 18 Dec 2007 16:31:48 -0600 To: Salvatore Loreto X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "sip@ietf.org" , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 18, 2007, at 1:05 PM, Salvatore Loreto wrote: > Hi Paul, > > just to add another example to this discussion (same as the vcard > example): > an application/im-iscomposing+xml content-type can be put in the > body of a SIP MESSAGE and it is not (or it is not supposed to be) > rendered > as is to the recipient; an application that understood it would > render it in whatever way it indicates that a user is in the > process of composing a message. > Okay, I'm now completely convinced that most uses of MESSAGE are really candidates for the new INFO events. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 18:33:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lvz-0000C4-1V; Tue, 18 Dec 2007 18:33:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4lvx-0000Bw-Du for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 18:33:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lvx-0000Bo-0y for sip@ietf.org; Tue, 18 Dec 2007 18:33:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4lvw-0002p9-Aw for sip@ietf.org; Tue, 18 Dec 2007 18:33:09 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2007 15:33:07 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBINX7gq010044; Tue, 18 Dec 2007 15:33:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBINX3LE026308; Tue, 18 Dec 2007 23:33:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:33:03 -0800 Received: from [64.101.76.25] ([64.101.76.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:33:02 -0800 Message-ID: <476858D7.9080209@cisco.com> Date: Tue, 18 Dec 2007 18:33:43 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> In-Reply-To: <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:33:02.0950 (UTC) FILETIME=[5541C060:01C841CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2050; t=1198020787; x=1198884787; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20; bh=0ijw3g8YPxLqWnS82zTvYmV6sb9ddp7ZwIxsLhWlSJc=; b=mPRs+YTpBP+x7AR7kJqeuXqLQyzm1dpfDj6YrmUCGtPUywJ14O4NQWlLkz Ze+AlL43k6Q/sN7j+p64sQeISU3EZOx857RYEysPbvcCtYMt3VWwOdqEumJ/ sz3BZPE5k0; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "sip@ietf.org" , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think application/im-iscomposing+xml IS rendered; and its rendering causes the UI to show that the user is typing. As a litmus test for this stuff, a question is whether it can reasonably be converted to a text/plain content and sent in a MESSAGE, and if it is rendered, is the resulting behavior reasonable. For the iscomposing indicators, I think you could. You could instead send a text IM like "Joe is typing a reply..." and render that, and this would achieve the same objective. Also, I would not want to send iscomposing over the SIP dialog - I think it should be on the media path. There will be a LOT of them, and there is a requirement for timeliness. See my other note on the criteria for sending something in dialog vs. along the media path. -Jonathan R. Dean Willis wrote: > > On Dec 18, 2007, at 1:05 PM, Salvatore Loreto wrote: > >> Hi Paul, >> >> just to add another example to this discussion (same as the vcard >> example): >> an application/im-iscomposing+xml content-type can be put in the body >> of a SIP MESSAGE and it is not (or it is not supposed to be) rendered >> as is to the recipient; an application that understood it would render >> it in whatever way it indicates that a user is in the process of >> composing a message. >> > > Okay, I'm now completely convinced that most uses of MESSAGE are really > candidates for the new INFO events. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 18:35:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lxs-0004Z0-Dm; Tue, 18 Dec 2007 18:35:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4lxq-0004Ju-1u for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 18:35:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4lxp-0004Hf-MT for sip@ietf.org; Tue, 18 Dec 2007 18:35:05 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4lxp-0003HT-9G for sip@ietf.org; Tue, 18 Dec 2007 18:35:05 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2007 15:35:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBINZ4Hp029251; Tue, 18 Dec 2007 15:35:04 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBINYq4J016860; Tue, 18 Dec 2007 23:35:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:34:57 -0800 Received: from [64.101.76.25] ([64.101.76.25]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 15:34:56 -0800 Message-ID: <47685949.7090708@cisco.com> Date: Tue, 18 Dec 2007 18:35:37 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" Subject: Re: [Sip] Direction on Buddy List format for SIP Simple References: <8983EC086A9D954BA74D9763E853CF3E046155DA@xmb-rtp-215.amer.cisco.com> In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E046155DA@xmb-rtp-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:34:56.0811 (UTC) FILETIME=[991F8FB0:01C841CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1386; t=1198020904; x=1198884904; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Direction=20on=20Buddy=20List=2 0format=20for=20SIP=20Simple |Sender:=20; bh=2NzjZcOsF9xGJ4znmy/Fpp2kXtzDEbxVMOcU9Q9Bh1k=; b=EVrWQpiOeS3chn7Eu5wR8r30aFKztq4CiCd6STgjWgpH7NrGhWfxqTC/r7 CtlWijxR0Tv2RfnGAoAk7w6TiBHzHQhjJySxPsaPCkABRv3VoIql1L9Z5gKu 0aBgBdr2v/; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sip@ietf.org, imran@smart-it-engineering.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 4826 specifies the XML format for representing the buddy list. XCAP is the transfer protocol for it. -Jonathan R. Sanjay Sinha (sanjsinh) wrote: > XCAP (RFC 4825) > >> -----Original Message----- >> From: Imran M Yousuf [mailto:imyousuf@gmail.com] >> Sent: Wednesday, December 12, 2007 11:08 PM >> To: sip@ietf.org >> Subject: [Sip] Direction on Buddy List format for SIP Simple >> >> Hi, >> >> I was wondering how is Buddy List be exchanged between SIP >> Server and SIP UA. Can someone please direct me to some >> document in relate to this. >> >> Thank you, >> >> -- >> Imran M Yousuf >> Entrepreneur & Software Engineer >> Smart IT Engineering >> Dhaka, Bangladesh >> Email: imran@smartitengineering.com >> Mobile: +880-1711402557 >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Dec 18 19:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mWm-0006pI-Ju; Tue, 18 Dec 2007 19:11:12 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4mWl-0006pD-Ao for sip-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 19:11:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4mWk-0006p4-VI for sip@ietf.org; Tue, 18 Dec 2007 19:11:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4mWk-00044d-HC for sip@ietf.org; Tue, 18 Dec 2007 19:11:10 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2007 19:11:10 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJ0B9EL001123; Tue, 18 Dec 2007 19:11:09 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBJ05Ril005824; Wed, 19 Dec 2007 00:11:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 19:07:18 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 19:07:18 -0500 Message-ID: <476860B7.1090603@cisco.com> Date: Tue, 18 Dec 2007 19:07:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> In-Reply-To: <476858D7.9080209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 00:07:18.0083 (UTC) FILETIME=[1E362930:01C841D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2491; t=1198023069; x=1198887069; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Jonathan=20Rosenberg=20; bh=bSIiLGr6jDO+TnZ7Xsm+w9ExbW5lusNuiNQao/R8ACM=; b=IYePJotkyw0LGkZ3SmJ3FaSFZgBub+RVrDZ16jFADjtkd8arH68HS3PZyU S8mTz6YmDhiZsWpOMfIjc4tTkEw5No4NMuq/31UpaQqQGgFqbFgmxRgmLQ/T 6AFtYw4HsR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Jonathan re the rendering. Regarding suitability of using MESSAGE in a sip dialog for this, I think its suitability for this is no better or worse than for sending the actual text itself. I suppose the is-typing functionality increases the number of messages used by roughly a factor of two. If you thought MESSAGE was suitable without this, then you might still think it is suitable with it. Its probably not a good example. The point is that rendering doesn't necessarily mean literal rendering of communicated text. E.g. you could send some MIDI encoding and have it rendered audibly. Paul Jonathan Rosenberg wrote: > I think application/im-iscomposing+xml IS rendered; and its rendering > causes the UI to show that the user is typing. > > As a litmus test for this stuff, a question is whether it can reasonably > be converted to a text/plain content and sent in a MESSAGE, and if it is > rendered, is the resulting behavior reasonable. For the iscomposing > indicators, I think you could. You could instead send a text IM like > "Joe is typing a reply..." and render that, and this would achieve the > same objective. > > Also, I would not want to send iscomposing over the SIP dialog - I think > it should be on the media path. There will be a LOT of them, and there > is a requirement for timeliness. See my other note on the criteria for > sending something in dialog vs. along the media path. > > -Jonathan R. > > Dean Willis wrote: >> >> On Dec 18, 2007, at 1:05 PM, Salvatore Loreto wrote: >> >>> Hi Paul, >>> >>> just to add another example to this discussion (same as the vcard >>> example): >>> an application/im-iscomposing+xml content-type can be put in the body >>> of a SIP MESSAGE and it is not (or it is not supposed to be) rendered >>> as is to the recipient; an application that understood it would >>> render it in whatever way it indicates that a user is in the process >>> of composing a message. >>> >> >> Okay, I'm now completely convinced that most uses of MESSAGE are >> really candidates for the new INFO events. >> >> -- >> Dean >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 19 00:22:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4rMv-0000yK-KM; Wed, 19 Dec 2007 00:21:21 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4rMt-0000y7-JT for sip-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 00:21:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4rMt-0000xy-9P for sip@ietf.org; Wed, 19 Dec 2007 00:21:19 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4rMr-0001u6-1E for sip@ietf.org; Wed, 19 Dec 2007 00:21:19 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBJ5LA8N001477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Dec 2007 23:21:11 -0600 In-Reply-To: <476858D7.9080209@cisco.com> References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] MESSAGE for rendering Date: Tue, 18 Dec 2007 23:21:02 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "sip@ietf.org" , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 18, 2007, at 5:33 PM, Jonathan Rosenberg wrote: > I think application/im-iscomposing+xml IS rendered; and its > rendering causes the UI to show that the user is typing. > I think INVITE is rendered, and its rendering causes the uses phone to make a ringing nose that causes the user to press a button that causes a new message to be sent. > As a litmus test for this stuff, a question is whether it can > reasonably be converted to a text/plain content and sent in a > MESSAGE, and if it is rendered, is the resulting behavior > reasonable. For the iscomposing indicators, I think you could. You > could instead send a text IM like "Joe is typing a reply..." and > render that, and this would achieve the same objective. If you displayed the current iscomposing object on the screen, I'm afraid you'd just confuse my mom. It's not just text. Before you send it, you really need to know that the other end understands what you mean. That's the crux of what is wrong with INFO today. > Also, I would not want to send iscomposing over the SIP dialog - I > think it should be on the media path. There will be a LOT of them, > and there is a requirement for timeliness. See my other note on the > criteria for sending something in dialog vs. along the media path. > Well, that's reasonable, but we have what we have, and that's a SIP message for iscomposing, and probably some IPR on that too. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 19 08:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yWV-00028H-Fa; Wed, 19 Dec 2007 07:59:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4yWU-00027Y-3J for sip-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 07:59:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yWT-00027P-OT for sip@ietf.org; Wed, 19 Dec 2007 07:59:41 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4yWT-0000jy-Da for sip@ietf.org; Wed, 19 Dec 2007 07:59:41 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Dec 2007 07:59:39 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJCxcpJ009804; Wed, 19 Dec 2007 07:59:38 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBJCxHil004945; Wed, 19 Dec 2007 12:59:38 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 07:59:22 -0500 Received: from [10.86.248.47] ([10.86.248.47]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 07:59:21 -0500 Message-ID: <476915A9.8090309@cisco.com> Date: Wed, 19 Dec 2007 07:59:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> In-Reply-To: <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 12:59:21.0861 (UTC) FILETIME=[F955BB50:01C8423E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1344; t=1198069179; x=1198933179; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20Dean=20Willis=20; bh=R7xwn02HxTFhdDhI4wkB30wkkB7pTNYIhV3Ai9Bpt0Q=; b=0Y/s7B+3y2mDbXDSAoc5moTJgHmIqeh51a2CI+60dwdDO3/TUOukAYquuY nnckgeR2LEU6F+bqKnmvg8SkrYMr2MKxwyYVVNnD3h6HGx49401QU+p+5AU/ BaGNLaX2/f; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Dec 18, 2007, at 5:33 PM, Jonathan Rosenberg wrote: > >> I think application/im-iscomposing+xml IS rendered; and its rendering >> causes the UI to show that the user is typing. >> > > I think INVITE is rendered, and its rendering causes the uses phone to > make a ringing nose that causes the user to press a button that causes a > new message to be sent. > >> As a litmus test for this stuff, a question is whether it can >> reasonably be converted to a text/plain content and sent in a MESSAGE, >> and if it is rendered, is the resulting behavior reasonable. For the >> iscomposing indicators, I think you could. You could instead send a >> text IM like "Joe is typing a reply..." and render that, and this >> would achieve the same objective. > > If you displayed the current iscomposing object on the screen, I'm > afraid you'd just confuse my mom. It's not just text. > > Before you send it, you really need to know that the other end > understands what you mean. That's the crux of what is wrong with INFO > today. Do you think its ok for the message to contain html? If you rendered html text directly it would also confuse your mom. Whatever is sent is just an *encoding* that must be translated into a meaningful rendering for the recipient. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 19 08:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zK4-0005y1-5D; Wed, 19 Dec 2007 08:50:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J4zK2-0005tc-1B for sip-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 08:50:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zK1-0005rN-LY for sip@ietf.org; Wed, 19 Dec 2007 08:50:53 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zK0-0005vz-7g for sip@ietf.org; Wed, 19 Dec 2007 08:50:53 -0500 Received: from [10.240.23.39] (m6e5f36d0.tmodns.net [208.54.95.110]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBJDoj24005243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Dec 2007 07:50:46 -0600 In-Reply-To: <476915A9.8090309@cisco.com> References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> <476915A9.8090309@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] MESSAGE for rendering Date: Wed, 19 Dec 2007 07:50:38 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Dec 19, 2007, at 6:59 AM, Paul Kyzivat wrote: > > Do you think its ok for the message to contain html? > That's actually debatable. HTML at least has relatively standard "rendering" -- XML, especially in the absence of some kind of style sheet, doesn't. > If you rendered html text directly it would also confuse your mom. True. It would be nice to make sue her UA supports HTML before sending it to her, wouldn't it? But at least here (this use of MESSAGE) we have an existing way to say "I don't support that MIME type in a render-to-user context", which may be adequate. That does put is in a better position than we were with INFO. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 19 23:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CgK-0004Ij-4O; Wed, 19 Dec 2007 23:06:48 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5CgI-0004Id-JF for sip-confirm+ok@megatron.ietf.org; Wed, 19 Dec 2007 23:06:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CgI-0004IS-0E for sip@ietf.org; Wed, 19 Dec 2007 23:06:46 -0500 Received: from web92205.mail.cnh.yahoo.com ([203.209.250.118]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5CgG-0007K9-Sg for sip@ietf.org; Wed, 19 Dec 2007 23:06:45 -0500 Received: (qmail 26782 invoked by uid 60001); 20 Dec 2007 04:06:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=vdGsRVPp92GP78b10MODsVa+jeAb/n0XjEe029mUy+JTviKerCdIYHwD5rmKWa4DFFMGncF+PBNpr28zmvInOu7vjV0wnejsFz49/B+K6jButSmrvm92dpYmRFBv9DTCctLJEk49D2PPUh/rbOpFZyy6cJnJOzWlKfXVk2LqjPY=; X-YMail-OSG: C5lVKAUVM1mbTPDE6d.kIv6tMDY9A1rUe7AZ2bdNdxIVoQ0CPLljBJUZ6.MFOBu.irzqDOTSjxoybfcefYzYKRKudqXs8cT_tEoZ Received: from [218.22.22.182] by web92205.mail.cnh.yahoo.com via HTTP; Thu, 20 Dec 2007 12:06:42 CST Date: Thu, 20 Dec 2007 12:06:42 +0800 (CST) From: =?gb2312?q?=C2=ED=E6=F7=20=20?= To: sip@ietf.org MIME-Version: 1.0 Message-ID: <660546.26704.qm@web92205.mail.cnh.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Some question about draft:A Framework for Session Initiation Protocol (SIP) Session Policies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1721524773==" Errors-To: sip-bounces@ietf.org --===============1721524773== Content-Type: multipart/alternative; boundary="0-1273213951-1198123602=:26704" Content-Transfer-Encoding: 8bit --0-1273213951-1198123602=:26704 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit I have some questions about the frame work proposed in the draft which defines a framework for SIP policy. See bellow: 1. What the advantage is in the proposed framework in which UA require its policy (which means it contacts policy server after contacts proxy) by itself? An alternative is, the proxy contacts the proxy server on behalf of the UA, and return or not return determined policies, which means UA need not involved in the procedure of contacting policy server. So why the one proposed in the draft is better? 2. If it retrieves policies according to call flow this draft, how a proxy knows that the policies in the resending request for the UA is genuine, especially for the specific ongoing request?(which means there should be security mechanism to avoid replay attacks).Can anyone give me some ideas or solutions? Thanks. --------------------------------- ÑÅ»¢ÓÊÏä´«µÝÐÂÄê×£¸££¬¸öÐԺؿ¨ËÍÇ×Åó£¡ --0-1273213951-1198123602=:26704 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
    I have some questions about the frame work proposed in the draft which defines a framework for SIP policy. See bellow:
    1. What the advantage is in the proposed framework in which UA require its policy (which means it contacts policy server after contacts proxy) by itself? An alternative is, the proxy contacts the proxy server on behalf of the UA, and return or not return determined policies, which means UA need not involved in the procedure of contacting policy server. So why the one proposed in the draft is better?
 
    2. If it retrieves policies according to call flow this draft, how a proxy knows that the policies in the resending request for the UA is genuine, especially for the specific ongoing request?(which means there should be security mechanism to avoid replay attacks).Can anyone give me some ideas or solutions?
 
Thanks.

ÑÅ»¢ÓÊÏä´«µÝÐÂÄê×£¸££¬¸öÐԺؿ¨ËÍÇ×Åó£¡ --0-1273213951-1198123602=:26704-- --===============1721524773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1721524773==-- From sip-bounces@ietf.org Thu Dec 20 00:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5E32-0002sU-QU; Thu, 20 Dec 2007 00:34:20 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5E31-0002jF-Kj for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 00:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5E31-0002j7-Au for sip@ietf.org; Thu, 20 Dec 2007 00:34:19 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5E2z-0008P4-M4 for sip@ietf.org; Thu, 20 Dec 2007 00:34:19 -0500 Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBK5YF1H010131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Dec 2007 23:34:17 -0600 Message-ID: <476A006B.4060802@softarmor.com> Date: Wed, 19 Dec 2007 23:40:59 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sip@ietf.org" Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> <476915A9.8090309@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Not that I like responding to my incoherent posts, but this one totally failed to make sense. I've got to stop posting after midnight and before noon. Dean Willis mumbled: > > On Dec 19, 2007, at 6:59 AM, Paul Kyzivat wrote: > >> >> Do you think its ok for the message to contain html? >> > > That's actually debatable. > > HTML at least has relatively standard "rendering" -- XML, especially > in the absence of some kind of style sheet, doesn't. > >> If you rendered html text directly it would also confuse your mom. > > > True. It would be nice to make sue her UA supports HTML before sending That's "make sure her UA supports HTML before sending it" . . . > it to her, wouldn't it? > > But at least here (this use of MESSAGE) we have an existing way to say > "I don't support that MIME type in a render-to-user context", which may > be adequate. That does put is in a better position than we were with INFO. That should have read "does put us in a batter position than we were with INFO". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 03:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5GzY-00035l-Rf; Thu, 20 Dec 2007 03:42:56 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5GzV-00035a-Vx for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 03:42:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5GzV-00035Q-FM for sip@ietf.org; Thu, 20 Dec 2007 03:42:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5GzU-00040N-HP for sip@ietf.org; Thu, 20 Dec 2007 03:42:52 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7524F20E34 for ; Thu, 20 Dec 2007 09:42:24 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-ac-476a2af03945 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 380E020A17 for ; Thu, 20 Dec 2007 09:42:24 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 09:42:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2007 09:42:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Editorial question on MIME example Thread-Index: AchC5DzADDOM9rrzTRaLkpP5dutlHg== From: "Christer Holmberg" To: X-OriginalArrivalTime: 20 Dec 2007 08:42:23.0726 (UTC) FILETIME=[3DD2C8E0:01C842E4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] Editorial question on MIME example X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have an editorial (?) question on the MIME message body example in chapter 23.4.3 of 3261. INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 To: Bob From: Anonymous ;tag=3D1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: Content-Type: multipart/signed;protocol=3D"application/pkcs7-signature";micalg=3Dsha1; boundary=3Dboundary42 Content-Length: 568 --boundary42 Content-Type: application/pkcs7-mime; smime-type=3Denveloped-data;name=3Dsmime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=3Dsmime.p7mhandling=3Drequired Content-Length: 231 *********************************************************** * Content-Type: message/sip * * * * INVITE sip:bob@biloxi.com SIP/2.0 * * Via: SIP/2.0/UDP pc33.atlanta.com;branch=3Dz9hG4bKnashds8 * * To: Bob * Etc etc etc Now, as far as I know (please correct me if I am wrong) Content-Length is NOT a MIME header. If so, I guess it shouldn't be used as a MIME header (together with Content-Type, Content-Transfer-Encoding etc)? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 04:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5HVy-0008ML-3K; Thu, 20 Dec 2007 04:16:26 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5HVw-0008Fh-CJ for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 04:16:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5HVv-0008AY-Hg for sip@ietf.org; Thu, 20 Dec 2007 04:16:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5HVv-0004u8-5m for sip@ietf.org; Thu, 20 Dec 2007 04:16:23 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Dec 2007 01:16:22 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBK9GMLq021783; Thu, 20 Dec 2007 01:16:22 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBK9GLP9003243; Thu, 20 Dec 2007 09:16:22 GMT From: "Dan Wing" To: "'Christer Holmberg'" , References: Subject: RE: [Sip] Editorial question on MIME example Date: Thu, 20 Dec 2007 01:16:21 -0800 Message-ID: <22c301c842e8$fcdb1040$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchC5DzADDOM9rrzTRaLkpP5dutlHgAAZ98g DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1250; t=1198142182; x=1199006182; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Editorial=20question=20on=20MIM E=20example |Sender:=20; bh=0GxmwMH9gUqJbSvPBEVR73XjUYUWegDBgySwB7dvBgM=; b=Xix29+s67NP/MAqVit5YhNUojJUXThugTD9FccpvfgDN8iKXd8doUMYdhW D2D0LKVyoEBOemZCL9tZKHI4AG0ctl5BK9DJqQeuwZtBvyiDoshoIMLOWIwo DjDAacm64p; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Now, as far as I know (please correct me if I am wrong) Content-Length > is NOT a MIME header. Right, it isn't. It could be argued that SIP's Content-Length was taken from HTTP (RFC1945) rather than MIME. It could be argued HTTP took the idea from email -- Content-Length used to be common in email headers a decade or two ago (but Content-Length didn't work too well for email for a variety of reasons). RFC2076 (February 1997) lists it, and says it was not a standard email header at the time. > If so, I guess it shouldn't be used as a MIME > header (together with Content-Type, Content-Transfer-Encoding etc)? RFC2045 does say: Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. but of course Content-Length doesn't have any meaning to MIME (neither would Content-Crayon). But neither of those headers do harm to a MIME parser, because a MIME parser ignores fields it doesn't understand. I guess you're saying SIP should have used something like "Length:" instead of "Content-Length:" to avoid collision with MIME's self-claimed ownership of all field names that begin with "Content-"? -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 04:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Hjv-0002VZ-Uk; Thu, 20 Dec 2007 04:30:51 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5Hju-0002VD-F9 for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 04:30:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Hju-0002V0-3r for sip@ietf.org; Thu, 20 Dec 2007 04:30:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Hjt-0005Ld-FD for sip@ietf.org; Thu, 20 Dec 2007 04:30:49 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81C7820BB3; Thu, 20 Dec 2007 10:30:21 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-ae-476a362d7921 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 585DD21243; Thu, 20 Dec 2007 10:30:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 10:30:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Editorial question on MIME example Date: Thu, 20 Dec 2007 10:30:20 +0100 Message-ID: In-Reply-To: <22c301c842e8$fcdb1040$c6f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Editorial question on MIME example Thread-Index: AchC5DzADDOM9rrzTRaLkpP5dutlHgAAZ98gAAE1sAA= References: <22c301c842e8$fcdb1040$c6f0200a@cisco.com> From: "Christer Holmberg" To: "Dan Wing" , X-OriginalArrivalTime: 20 Dec 2007 09:30:21.0126 (UTC) FILETIME=[F0E32E60:01C842EA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Now, as far as I know (please correct me if I am wrong) Content-Length >>is NOT a MIME header. >=20 >Right, it isn't. It could be argued that SIP's=20 >Content-Length was taken from HTTP (RFC1945) rather than=20 >MIME. It could be argued HTTP took the idea from email --=20 >Content-Length used to be common in email headers a decade or=20 >two ago (but Content-Length didn't work too well for email=20 >for a variety of reasons). >RFC2076 (February 1997) lists it, and says it was not a=20 >standard email header at the time. >=20 >>If so, I guess it shouldn't be used as a MIME header (together with=20 >>Content-Type, Content-Transfer-Encoding etc)? >=20 >RFC2045 does say: >=20 > Any sort of field may be present in the header of an entity, > but only those fields whose names begin with "content-"=20 > actually have any MIME-related meaning. >=20 >but of course Content-Length doesn't have any meaning to MIME=20 >(neither would Content-Crayon). But neither of those headers=20 >do harm to a MIME parser, because a MIME parser ignores=20 >fields it doesn't understand. >=20 >=20 >I guess you're saying SIP should have used something like=20 >"Length:" instead of "Content-Length:" to avoid collision=20 >with MIME's self-claimed ownership of all field names that=20 >begin with "Content-"? No no. I am not talking about the usage of Content-Lenght (or any other Content- header) in the SIP part of the message. I was referring to the usage of Content-Length in the MIME part of the message body. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 10:33:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5NNy-0006Fj-OH; Thu, 20 Dec 2007 10:32:34 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5NNx-0006FN-4u for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 10:32:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5NNw-0006Ez-Jy for sip@ietf.org; Thu, 20 Dec 2007 10:32:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5NNw-0003dd-5j for sip@ietf.org; Thu, 20 Dec 2007 10:32:32 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Dec 2007 07:32:31 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKFWVnH018737; Thu, 20 Dec 2007 07:32:31 -0800 Received: from stealth-10-32-245-154.cisco.com (stealth-10-32-245-154.cisco.com [10.32.245.154]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBKFWQ32021109; Thu, 20 Dec 2007 15:32:26 GMT Message-Id: From: David R Oran To: Dean Willis In-Reply-To: <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Sip] MESSAGE for rendering Date: Thu, 20 Dec 2007 10:32:26 -0500 References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> X-Mailer: Apple Mail (2.915) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2111; t=1198164751; x=1199028751; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20; bh=7c5AKeo+pqN2bUhODrs6WBrRiZ0DHDUvfqWfiU1P9P0=; b=hr+2tHN2QgNho+1/MvTc2k4Al9bQOl+7mY2tlTh3DXG8i89z15D9UdL/dV wE4urre7VaIeOFR4D0EfNs1mimyJVhKAOOXk3+kFe98txjc8WKx/vA9cNLFK JFef+GzV/u; Authentication-Results: sj-dkim-2; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "sip@ietf.org" , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Perhaps the salient difference isn't whether the contents are directly rendered (or indirectly rendered), but whether there are additional side-effects that alter an application-level state machine. On Dec 19, 2007, at 12:21 AM, Dean Willis wrote: > > On Dec 18, 2007, at 5:33 PM, Jonathan Rosenberg wrote: > >> I think application/im-iscomposing+xml IS rendered; and its >> rendering causes the UI to show that the user is typing. >> > > I think INVITE is rendered, and its rendering causes the uses phone > to make a ringing nose that causes the user to press a button that > causes a new message to be sent. > >> As a litmus test for this stuff, a question is whether it can >> reasonably be converted to a text/plain content and sent in a >> MESSAGE, and if it is rendered, is the resulting behavior >> reasonable. For the iscomposing indicators, I think you could. You >> could instead send a text IM like "Joe is typing a reply..." and >> render that, and this would achieve the same objective. > > If you displayed the current iscomposing object on the screen, I'm > afraid you'd just confuse my mom. It's not just text. > > Before you send it, you really need to know that the other end > understands what you mean. That's the crux of what is wrong with > INFO today. > >> Also, I would not want to send iscomposing over the SIP dialog - I >> think it should be on the media path. There will be a LOT of them, >> and there is a requirement for timeliness. See my other note on the >> criteria for sending something in dialog vs. along the media path. >> > > Well, that's reasonable, but we have what we have, and that's a SIP > message for iscomposing, and probably some IPR on that too. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 11:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5O30-0001jR-CK; Thu, 20 Dec 2007 11:14:58 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5O2y-0001jJ-TW for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 11:14:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5O2y-0001jB-I8 for sip@ietf.org; Thu, 20 Dec 2007 11:14:56 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5O2y-0001Cm-4N for sip@ietf.org; Thu, 20 Dec 2007 11:14:56 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2007 11:14:56 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBKGEtmF005019; Thu, 20 Dec 2007 11:14:55 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBKGEtLk018933; Thu, 20 Dec 2007 16:14:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 11:14:43 -0500 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 11:14:43 -0500 Message-ID: <476A94F3.3030507@cisco.com> Date: Thu, 20 Dec 2007 11:14:43 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David R Oran Subject: Re: [Sip] MESSAGE for rendering References: <4762FB8B.2020308@cisco.com> <200712142327.lBENRjRq023454@dragon.ariadne.com> <47631BA9.5040904@cisco.com> <476819FE.6060406@ericsson.com> <0EA88CBE-EE81-4AB4-9AD3-56B75B710485@softarmor.com> <476858D7.9080209@cisco.com> <9F8EAFA7-33E1-4C09-9014-22ECB462C127@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2007 16:14:43.0473 (UTC) FILETIME=[6E5F8810:01C84323] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2530; t=1198167295; x=1199031295; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MESSAGE=20for=20rendering |Sender:=20 |To:=20David=20R=20Oran=20; bh=QMub5tldmjKfPhyo1W00ECEG6vgyaAvtk6Zw68SJxp4=; b=w1ZDSH/jBnG0SNrqtYoMAqF0S6VxuCIDpJNIMjlahLIpF84A9RC1wY6iYb DJ0W5xOOXTPDFDFxyQY2QNTRmWox+l1eN9Ck7CtEP7OT4IceBFTtEqEX2jz8 g0eCWsAK68; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is an aspect of the ongoing attempt to nail down what the content dispositions mean, and whether they mean the same thing for all methods. Its especially pertinent for "render" because that is the default disposition code for sip body parts, and because its far from clear that "render" could mean the same thing for all methods. Paul David R Oran wrote: > Perhaps the salient difference isn't whether the contents are directly > rendered (or indirectly rendered), but whether there are additional > side-effects that alter an application-level state machine. > > On Dec 19, 2007, at 12:21 AM, Dean Willis wrote: > >> >> On Dec 18, 2007, at 5:33 PM, Jonathan Rosenberg wrote: >> >>> I think application/im-iscomposing+xml IS rendered; and its rendering >>> causes the UI to show that the user is typing. >>> >> >> I think INVITE is rendered, and its rendering causes the uses phone to >> make a ringing nose that causes the user to press a button that causes >> a new message to be sent. >> >>> As a litmus test for this stuff, a question is whether it can >>> reasonably be converted to a text/plain content and sent in a >>> MESSAGE, and if it is rendered, is the resulting behavior reasonable. >>> For the iscomposing indicators, I think you could. You could instead >>> send a text IM like "Joe is typing a reply..." and render that, and >>> this would achieve the same objective. >> >> If you displayed the current iscomposing object on the screen, I'm >> afraid you'd just confuse my mom. It's not just text. >> >> Before you send it, you really need to know that the other end >> understands what you mean. That's the crux of what is wrong with INFO >> today. >> >>> Also, I would not want to send iscomposing over the SIP dialog - I >>> think it should be on the media path. There will be a LOT of them, >>> and there is a requirement for timeliness. See my other note on the >>> criteria for sending something in dialog vs. along the media path. >>> >> >> Well, that's reasonable, but we have what we have, and that's a SIP >> message for iscomposing, and probably some IPR on that too. >> >> -- >> Dean >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 12:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5OrQ-0000Un-Nf; Thu, 20 Dec 2007 12:07:04 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5OrO-0000UQ-45 for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 12:07:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5OrN-0000UB-QU for sip@ietf.org; Thu, 20 Dec 2007 12:07:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5OrN-0005iG-FU for sip@ietf.org; Thu, 20 Dec 2007 12:07:01 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Dec 2007 09:07:01 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBKH70lW021713; Thu, 20 Dec 2007 09:07:00 -0800 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBKH7032027588; Thu, 20 Dec 2007 17:07:00 GMT From: "Dan Wing" To: "'Christer Holmberg'" , References: <22c301c842e8$fcdb1040$c6f0200a@cisco.com> Subject: RE: [Sip] Editorial question on MIME example Date: Thu, 20 Dec 2007 09:07:02 -0800 Message-ID: <2a2301c8432a$bdb65630$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AchC5DzADDOM9rrzTRaLkpP5dutlHgAAZ98gAAE1sAAAD+au4A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=757; t=1198170420; x=1199034420; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Editorial=20question=20on=20MIM E=20example |Sender:=20; bh=Kq+ULRkhQzQsIFw6eft4odUeoNERRP3Cry0Uqrm7Hhc=; b=rvn3hxvFARmz/MM4BObJn41akrTlM98SX34+S8PR41zqwJbleXjTXd9sNB +Twr5WjkIZV3ONfILGE7whu0qJD4i9sX6GXcjatMlfNmIlCt8bacq/ljSQs9 dX2Pg5MeCP; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >I guess you're saying SIP should have used something like > >"Length:" instead of "Content-Length:" to avoid collision > >with MIME's self-claimed ownership of all field names that > >begin with "Content-"? > > No no. > > I am not talking about the usage of Content-Lenght (or any other > Content- header) in the SIP part of the message. I was > referring to the > usage of Content-Length in the MIME part of the message body. Ah - thanks for clarifying. So you are referring to the second Content-Length field in the example at http://tools.ietf.org/html/rfc3261#page-212 -- the Content-Length field with the value 231. I agree it shouldn't be in that example. Looks like something to add to the Essential Corrections. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 20 15:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5RtX-00049F-3s; Thu, 20 Dec 2007 15:21:27 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5RtU-00044l-UT for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 15:21:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5RtU-000408-4D; Thu, 20 Dec 2007 15:21:24 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5RtT-0001J5-6W; Thu, 20 Dec 2007 15:21:24 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F16BB1805A; Fri, 21 Dec 2007 01:51:19 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id E0E7418051; Fri, 21 Dec 2007 01:51:19 +0530 (IST) Received: from KOL-SLK-MBX01.wipro.com ([10.141.1.182]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Dec 2007 01:51:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Dec 2007 01:46:22 +0530 Message-ID: <70B22B83C930694D9639F7496C17869201A66A10@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRACK/Offer Answer thread-index: AchDRTCB9BIquUXlRCCj7fouClkOBg== From: To: , X-OriginalArrivalTime: 20 Dec 2007 20:21:21.0544 (UTC) FILETIME=[E2B5F880:01C84345] X-Spam-Score: 1.8 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Sip] PRACK/Offer Answer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0903499766==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0903499766== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84345.E20EBB4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84345.E20EBB4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a call scenario, where UAC had sent an offer (not initial) in = PRACK and the UAS needs to refuse the offer. Can the UAS refuse the = offer using a 4xx response (e.g. 488) ? I don't find any specific = example in the currently available RFCs and/or drafts. =20 Cheers, Subhodeep =20 =20 ------_=_NextPart_001_01C84345.E20EBB4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
I have a call scenario, = where UAC had sent an offer (not initial) in PRACK and the UAS needs to = refuse the offer. Can the UAS refuse the offer using a 4xx response = (e.g. 488) ? I don't find any specific example in the currently = available RFCs and/or drafts.
=0A=
 
=0A=
Cheers,
=0A=
Subhodeep
=0A=
 
=0A=
=0A=
=0A=
 
------_=_NextPart_001_01C84345.E20EBB4A-- --===============0903499766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0903499766==-- From sip-bounces@ietf.org Thu Dec 20 16:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T80-0002HH-72; Thu, 20 Dec 2007 16:40:28 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5T7x-0001yP-K4 for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T7w-0001om-3p; Thu, 20 Dec 2007 16:40:24 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5T7v-0004TW-FB; Thu, 20 Dec 2007 16:40:23 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Dec 2007 16:40:21 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBKLeLUD021617; Thu, 20 Dec 2007 16:40:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBKLdwfv020703; Thu, 20 Dec 2007 21:40:12 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 16:40:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PRACK/Offer Answer Date: Thu, 20 Dec 2007 16:40:06 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E0467BDD6@xmb-rtp-215.amer.cisco.com> In-Reply-To: <70B22B83C930694D9639F7496C17869201A66A10@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] PRACK/Offer Answer Thread-Index: AchDRTCB9BIquUXlRCCj7fouClkOBgAC41pg From: "Sanjay Sinha (sanjsinh)" To: , , X-OriginalArrivalTime: 20 Dec 2007 21:40:06.0348 (UTC) FILETIME=[E2E9D8C0:01C84350] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2878; t=1198186821; x=1199050821; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20PRACK/Offer=20Answer |Sender:=20 |To:=20,=20,=20; bh=KNFHOOAXrizDx/+5KAj7mg4eYUpAFNjgvbc+5XnaObE=; b=iAn9scC99QHSiDgwEOSJVtDlbvRstm163YbZEiwr3VvKGD/obgG5+WbvyE aP/6hNNxupPmXObOxIxwkOF4JMwGL9JBQi66QFpJHnEbdE9YpDZWRhm4yoH8 7jpEPvANym; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0416623368==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0416623368== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84350.E2BE6D8A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84350.E2BE6D8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see sec. 2.2 of draft-ietf-sipping-sip-offeranswer-04.txt ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, December 20, 2007 3:16 PM To: sip@ietf.org; sipping@ietf.org Subject: [Sip] PRACK/Offer Answer =09 =09 Hi, =20 I have a call scenario, where UAC had sent an offer (not initial) in PRACK and the UAS needs to refuse the offer. Can the UAS refuse the offer using a 4xx response (e.g. 488) ? I don't find any specific example in the currently available RFCs and/or drafts. =20 Cheers, Subhodeep =20 =20 ------_=_NextPart_001_01C84350.E2BE6D8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please see sec. 2.2 of=20 draft-ietf-sipping-sip-offeranswer-04.txt

From: subhodeep.sarkar@wipro.com=20 [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, = December 20,=20 2007 3:16 PM
To: sip@ietf.org; = sipping@ietf.org
Subject:=20 [Sip] PRACK/Offer Answer

Hi,
 
I have a call scenario, = where UAC had=20 sent an offer (not initial) in PRACK and the UAS needs to refuse the = offer.=20 Can the UAS refuse the offer using a 4xx response (e.g. 488) ? I = don't=20 find any specific example in the currently available RFCs and/or=20 drafts.
 
Cheers,
Subhodeep
 
 
------_=_NextPart_001_01C84350.E2BE6D8A-- --===============0416623368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0416623368==-- From sip-bounces@ietf.org Thu Dec 20 23:21:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ZMr-0000Zo-BE; Thu, 20 Dec 2007 23:20:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5ZMp-0000Zj-A4 for sip-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 23:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ZMp-0000Zb-07 for sip@ietf.org; Thu, 20 Dec 2007 23:20:11 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ZMo-0003mo-P5 for sip@ietf.org; Thu, 20 Dec 2007 23:20:10 -0500 Received: by an-out-0708.google.com with SMTP id d11so41504and.122 for ; Thu, 20 Dec 2007 20:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=A2C8zxdW6rmMkZ8wsYheOB2210bah+v2hkPaOuSU0/g=; b=JzJLPVAZL5HzHkwPGuJBsOBa9nB7Ah+EPimyZO6gOeyB3xZYOKzxkevB/uKmSUx4bnznHfxxf8XutF2zl7vTRTvnYPhGsU1b+qsYK24iMPqq4vjZ0WLG2EqSmaIgFV36rDFx+0QiaDgG2N+7lRiPt+Vm/iEBzMMdolg6Wvr1YE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=xifAVr3ZfFCBK/+nIkp4f2UfoSdWW8wfSQdPL4aSGImR392NdeqaaqQ+/C6VczLaT/YVIirW5ebvUONWVLJFAIfucNsUNpU2OwCHB3zjBc0LNelK2I1p7p8K+GjGdnMASET4W6pYli8InSVKxHM1UN4vPv4Dum9cws/L/Ao62dU= Received: by 10.100.231.16 with SMTP id d16mr1650986anh.23.1198210810419; Thu, 20 Dec 2007 20:20:10 -0800 (PST) Received: by 10.70.62.1 with HTTP; Thu, 20 Dec 2007 20:20:10 -0800 (PST) Message-ID: <52db68bc0712202020s106bc26cv923b17613055c51c@mail.gmail.com> Date: Fri, 21 Dec 2007 09:50:10 +0530 From: "Sudhir Kumar Reddy" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] 200 OK in calling state for INVITE client transaction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0180521727==" Errors-To: sip-bounces@ietf.org --===============0180521727== Content-Type: multipart/alternative; boundary="----=_Part_9342_23508107.1198210810420" ------=_Part_9342_23508107.1198210810420 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, when an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE client transaction), the 2xx response MUST cause the client transaction to enter the "Terminated" state. But, I'm not sure what would be To_Tag in generating ACK for that 200 OK. Any response is highly appericated. Thanks, Sudhir ------=_Part_9342_23508107.1198210810420 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

when an INVITE client transaction is in the Calling state, on receipt of Success (200 OK) response. As per RFC 17.1.1.2(Figure 5: INVITE client transaction), the 2xx response MUST cause the client transaction to enter the "Terminated" state. But, I'm not sure what would be To_Tag in generating ACK for that 200 OK.

Any response is highly appericated.

Thanks,
Sudhir
------=_Part_9342_23508107.1198210810420-- --===============0180521727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0180521727==-- From sip-bounces@ietf.org Fri Dec 21 02:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ce3-00031W-8j; Fri, 21 Dec 2007 02:50:11 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5ce0-00031H-MQ for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 02:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5cdu-000313-MT; Fri, 21 Dec 2007 02:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5cdu-0000SF-9z; Fri, 21 Dec 2007 02:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 315532AB69; Fri, 21 Dec 2007 07:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5cdu-0000oM-3a; Fri, 21 Dec 2007 02:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 02:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-uri-list-message-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) Author(s) : M. Garcia-Martin, G. Camarillo Filename : draft-ietf-sip-uri-list-message-03.txt Pages : 19 Date : 2007-12-21 This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-uri-list-message-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-uri-list-message-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-21025001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-list-message-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-list-message-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21025001.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Dec 21 03:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5cwV-0001Mo-K0; Fri, 21 Dec 2007 03:09:15 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5cwT-0001Lc-8j for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 03:09:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5cwS-0001LJ-Ir; Fri, 21 Dec 2007 03:09:12 -0500 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5cwR-0001x1-Ge; Fri, 21 Dec 2007 03:09:12 -0500 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 27E841806B; Fri, 21 Dec 2007 13:39:08 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 170AE18056; Fri, 21 Dec 2007 13:39:08 +0530 (IST) Received: from KOL-SLK-MBX01.wipro.com ([10.141.1.182]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Dec 2007 13:39:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PRACK/Offer Answer Date: Fri, 21 Dec 2007 13:35:33 +0530 Message-ID: <70B22B83C930694D9639F7496C17869201A66A11@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] PRACK/Offer Answer thread-index: AchDRTCB9BIquUXlRCCj7fouClkOBgAC41pgABXhTZ8= References: <8983EC086A9D954BA74D9763E853CF3E0467BDD6@xmb-rtp-215.amer.cisco.com> From: To: , , X-OriginalArrivalTime: 21 Dec 2007 08:09:09.0761 (UTC) FILETIME=[C3BD9F10:01C843A8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1617889744==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1617889744== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C843A8.C2100F05" This is a multi-part message in MIME format. ------_=_NextPart_001_01C843A8.C2100F05 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK. But what should be the body of the 200 OK PRACK (Pattern 5) before = sending 488 to INVITE for termination of the dialog. ________________________________ From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] Sent: Thu 12/20/2007 10:40 PM To: Subhodeep Sarkar (WT01 - TES-Mobility & Carrier Infrastructure); = sip@ietf.org; sipping@ietf.org Subject: RE: [Sip] PRACK/Offer Answer Please see sec. 2.2 of draft-ietf-sipping-sip-offeranswer-04.txt ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, December 20, 2007 3:16 PM To: sip@ietf.org; sipping@ietf.org Subject: [Sip] PRACK/Offer Answer =09 =09 Hi, =20 I have a call scenario, where UAC had sent an offer (not initial) in = PRACK and the UAS needs to refuse the offer. Can the UAS refuse the = offer using a 4xx response (e.g. 488) ? I don't find any specific = example in the currently available RFCs and/or drafts. =20 Cheers, Subhodeep =20 =20 ------_=_NextPart_001_01C843A8.C2100F05 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
OK. But = what should be the body of the 200 OK PRACK (Pattern 5)  before = sending 488 to INVITE for termination of the dialog.
=0A=
=0A=
=0A=
=0A=
From: Sanjay Sinha = (sanjsinh) [mailto:sanjsinh@cisco.com]
Sent: Thu 12/20/2007 = 10:40 PM
To: Subhodeep Sarkar (WT01 - TES-Mobility & = Carrier Infrastructure); sip@ietf.org; = sipping@ietf.org
Subject: RE: [Sip] PRACK/Offer = Answer

=0A=
=0A=
Please see sec. 2.2 of = draft-ietf-sipping-sip-offeranswer-04.txt

=0A=
=0A=
=0A=
=0A= From: subhodeep.sarkar@wipro.com = [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, December = 20, 2007 3:16 PM
To: sip@ietf.org; = sipping@ietf.org
Subject: [Sip] PRACK/Offer = Answer

=0A=
=0A=
=0A=
Hi,
=0A=
 
=0A=
I have a call scenario, = where UAC had sent an offer (not initial) in PRACK and the UAS needs to = refuse the offer. Can the UAS refuse the offer using a 4xx response = (e.g. 488) ? I don't find any specific example in the currently = available RFCs and/or drafts.
=0A=
 
=0A=
Cheers,
=0A=
Subhodeep
=0A=
 
=0A=
=0A=
=0A=
 
------_=_NextPart_001_01C843A8.C2100F05-- --===============1617889744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1617889744==-- From sip-bounces@ietf.org Fri Dec 21 03:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5d5z-0001cH-OI; Fri, 21 Dec 2007 03:19:03 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5d5y-0001cC-LE for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 03:19:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5d5y-0001c4-BW for sip@ietf.org; Fri, 21 Dec 2007 03:19:02 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5d5w-00017C-Ni for sip@ietf.org; Fri, 21 Dec 2007 03:19:02 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBL8I403021607; Fri, 21 Dec 2007 10:18:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 10:18:16 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 10:18:15 +0200 Received: from [10.144.23.22] ([10.144.23.22]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 10:18:15 +0200 Message-ID: <476B76C7.4000200@nsn.com> Date: Fri, 21 Dec 2007 10:18:15 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2007 08:18:15.0724 (UTC) FILETIME=[0928F6C0:01C843AA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Cullen Jennings , Gonzalo.Camarillo@ericsson.com Subject: [Sip] New Version Notification for draft-ietf-sip-uri-list-message-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have just submitted a new version of the MESSAGE URI-list service draft, including the comments received by the Gen-ART review Spencer Dawwkins. These comments were mainly clarifications. http://people.nokia.net/~miguel/drafts/draft-ietf-sip-uri-list-message-03.html http://people.nokia.net/~miguel/drafts/draft-ietf-sip-uri-list-message-03.txt Track changes draft: http://people.nokia.net/~miguel/drafts/draft-ietf-sip-uri-list-message-03-from-2.html /Miguel A new version of I-D, draft-ietf-sip-uri-list-message-03.txt has been successfuly submitted by Miguel Garcia-Martin and posted to the IETF repository. Filename: draft-ietf-sip-uri-list-message Revision: 03 Title: Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) Creation_date: 2007-12-21 WG ID: sip Number_of_pages: 19 Abstract: This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. The IETF Secretariat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 21 05:53:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fUh-0004Xw-Iv; Fri, 21 Dec 2007 05:52:43 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5fUg-0004Xp-8b for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 05:52:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fUf-0004Xh-V6 for sip@ietf.org; Fri, 21 Dec 2007 05:52:41 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5fUf-0004VF-H5 for sip@ietf.org; Fri, 21 Dec 2007 05:52:41 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E62C720B42; Fri, 21 Dec 2007 11:52:40 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-a0-476b9af841d4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C239C20857; Fri, 21 Dec 2007 11:52:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 11:52:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Editorial question on MIME example Date: Fri, 21 Dec 2007 11:52:39 +0100 Message-ID: In-Reply-To: <2a2301c8432a$bdb65630$c6f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Editorial question on MIME example Thread-Index: AchC5DzADDOM9rrzTRaLkpP5dutlHgAAZ98gAAE1sAAAD+au4AAlSJDQ References: <22c301c842e8$fcdb1040$c6f0200a@cisco.com> <2a2301c8432a$bdb65630$c6f0200a@cisco.com> From: "Christer Holmberg" To: "Dan Wing" , X-OriginalArrivalTime: 21 Dec 2007 10:52:40.0645 (UTC) FILETIME=[9B7BB750:01C843BF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>I guess you're saying SIP should have used something like "Length:"=20 >>>instead of "Content-Length:" to avoid collision with MIME's=20 >>>self-claimed ownership of all field names that begin with "Content-"? >>=20 >>No no. >>=20 >>I am not talking about the usage of Content-Lenght (or any other >>Content- header) in the SIP part of the message. I was referring to=20 >>the usage of Content-Length in the MIME part of the message body. >=20 >Ah - thanks for clarifying. So you are referring to the=20 >second Content-Length field in the example at=20 >http://tools.ietf.org/html/rfc3261#page-212 -- the=20 >Content-Length field with the value 231.=20 Yes. >I agree it shouldn't be in that example. Looks like something to add to=20 >the Essential Corrections. Ok. Thanks! Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Dec 21 08:35:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5i1x-0007KA-TI; Fri, 21 Dec 2007 08:35:13 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J5i1v-0007Hy-Vz for sip-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 08:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5i1v-0007Hp-Ls for sip@ietf.org; Fri, 21 Dec 2007 08:35:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5i1t-0007fR-Oq for sip@ietf.org; Fri, 21 Dec 2007 08:35:11 -0500 X-IronPort-AV: E=Sophos;i="4.24,194,1196668800"; d="scan'208,217";a="4847442" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2007 05:35:09 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBLDZ9K1014236; Fri, 21 Dec 2007 05:35:09 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lBLDZ8vJ019322; Fri, 21 Dec 2007 13:35:08 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 08:35:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] PRACK/Offer Answer Date: Fri, 21 Dec 2007 08:35:06 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E0467BF0C@xmb-rtp-215.amer.cisco.com> In-Reply-To: <70B22B83C930694D9639F7496C17869201A66A11@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] PRACK/Offer Answer Thread-Index: AchDRTCB9BIquUXlRCCj7fouClkOBgAC41pgABXhTZ8AC3aaoA== From: "Sanjay Sinha (sanjsinh)" To: , X-OriginalArrivalTime: 21 Dec 2007 13:35:08.0182 (UTC) FILETIME=[4D77D360:01C843D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6919; t=1198244109; x=1199108109; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20PRACK/Offer=20Answer |Sender:=20; bh=+oC2xLV7pBuqK+o38pM3Tth3W9EY62F00wTrEXnBQXg=; b=nZqNXFfPogZBHHdq+1ofZwtehp4VvDhRmi8211S1qzk40TOHTFTvnbuO33 nfwigXbuvQjL7DO3uf2eR+blwVZmGv55dXAp15rzk7fi0RTqQUx+jxREB7sh RIRBohdmR1; Authentication-Results: sj-dkim-3; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985002021==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1985002021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C843D6.4D51FF7C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C843D6.4D51FF7C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The 200 Ok can have the port number in m line set to 0 to indicate that the media stream is not acceptable. ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Friday, December 21, 2007 3:06 AM To: Sanjay Sinha (sanjsinh); sip@ietf.org; sipping@ietf.org Subject: RE: [Sip] PRACK/Offer Answer =09 =09 OK. But what should be the body of the 200 OK PRACK (Pattern 5) before sending 488 to INVITE for termination of the dialog. ________________________________ From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] Sent: Thu 12/20/2007 10:40 PM To: Subhodeep Sarkar (WT01 - TES-Mobility & Carrier Infrastructure); sip@ietf.org; sipping@ietf.org Subject: RE: [Sip] PRACK/Offer Answer =09 =09 Please see sec. 2.2 of draft-ietf-sipping-sip-offeranswer-04.txt ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, December 20, 2007 3:16 PM To: sip@ietf.org; sipping@ietf.org Subject: [Sip] PRACK/Offer Answer =09 =09 Hi, =20 I have a call scenario, where UAC had sent an offer (not initial) in PRACK and the UAS needs to refuse the offer. Can the UAS refuse the offer using a 4xx response (e.g. 488) ? I don't find any specific example in the currently available RFCs and/or drafts. =20 Cheers, Subhodeep =20 =20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com =09 ------_=_NextPart_001_01C843D6.4D51FF7C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The 200 Ok can have the port number in m line = set to 0 to=20 indicate that the media stream is not = acceptable.

From: subhodeep.sarkar@wipro.com=20 [mailto:subhodeep.sarkar@wipro.com]
Sent: Friday, December = 21, 2007=20 3:06 AM
To: Sanjay Sinha (sanjsinh); sip@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sip] PRACK/Offer=20 Answer

OK. But = what should be=20 the body of the 200 OK PRACK (Pattern 5)  before sending 488 to = INVITE=20 for termination of the dialog.
From: Sanjay Sinha = (sanjsinh)=20 [mailto:sanjsinh@cisco.com]
Sent: Thu 12/20/2007 10:40=20 PM
To: Subhodeep Sarkar (WT01 - TES-Mobility & Carrier=20 Infrastructure); sip@ietf.org; sipping@ietf.org
Subject: RE: = [Sip]=20 PRACK/Offer Answer

Please see sec. 2.2 of=20 draft-ietf-sipping-sip-offeranswer-04.txt

From: subhodeep.sarkar@wipro.com = [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, = December 20,=20 2007 3:16 PM
To: sip@ietf.org; = sipping@ietf.org
Subject:=20 [Sip] PRACK/Offer Answer

Hi,
 
I have a call scenario, = where UAC had=20 sent an offer (not initial) in PRACK and the UAS needs to refuse the = offer.=20 Can the UAS refuse the offer using a 4xx response (e.g. 488) = ? I don't=20 find any specific example in the currently available RFCs and/or=20 drafts.
 
Cheers,
Subhodeep
 
 

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

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

www.wipro.com
------_=_NextPart_001_01C843D6.4D51FF7C-- --===============1985002021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1985002021==-- From sip-bounces@ietf.org Sat Dec 22 09:13:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J655S-0000HA-Rj; Sat, 22 Dec 2007 09:12:22 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J655Q-0008Pv-1l for sip-confirm+ok@megatron.ietf.org; Sat, 22 Dec 2007 09:12:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J655P-0008KA-HV; Sat, 22 Dec 2007 09:12:19 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J655O-0001LF-1z; Sat, 22 Dec 2007 09:12:19 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2f476d55d6; Sat, 22 Dec 2007 22:25:32 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd47688560; Wed, 19 Dec 2007 04:25:20 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 19 Dec 2007 04:25:20 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fna-0006Vy-Hd; Tue, 18 Dec 2007 12:00:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fnW-0006VY-RS; Tue, 18 Dec 2007 12:00:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4fnW-00031E-DD; Tue, 18 Dec 2007 12:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 474E42AC66; Tue, 18 Dec 2007 17:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4fnV-0001Ex-Vr; Tue, 18 Dec 2007 12:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 12:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-xcapevent-00.txt X-BeenThere: sip@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package Author(s) : J. Urpalainen Filename : draft-ietf-sip-xcapevent-00.txt Pages : 14 Date : 2007-12-18 This document describes an "xcap-diff" SIP event package, with the aid of which clients can receive notifications of the partial changes of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-xcapevent-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-xcapevent-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-18115748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-xcapevent-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-xcapevent-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18115748.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Dec 26 13:42:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bCj-0008Oa-WF; Wed, 26 Dec 2007 13:42:10 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J7bCi-0008OQ-Kc for sip-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 13:42:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bCi-0008OH-8l for sip@ietf.org; Wed, 26 Dec 2007 13:42:08 -0500 Received: from mmail.voxeo.com ([66.193.54.208] helo=voxeo.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7bCh-0002Kr-M2 for sip@ietf.org; Wed, 26 Dec 2007 13:42:08 -0500 Received: from [75.68.245.43] (account dyork HELO [172.20.12.144]) by voxeo.com (CommuniGate Pro SMTP 5.1.12) with ESMTPSA id 25997548; Wed, 26 Dec 2007 18:42:06 +0000 In-Reply-To: <476800AC.7090202@softarmor.com> References: <476800AC.7090202@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4C71551E-A917-4031-BA21-4AD58070AC10@voxeo.com> From: Dan York Subject: Re: [Sip] INVITE after a terminated dialog? Date: Wed, 26 Dec 2007 12:11:58 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898725703==" Errors-To: sip-bounces@ietf.org --===============1898725703== Content-Type: multipart/alternative; boundary=Apple-Mail-136--808897401 --Apple-Mail-136--808897401 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Getting caught up on list email, I thought I'd point out... On Dec 18, 2007, at 12:17 PM, Dean Willis wrote: > This is really off-target for this list, and possibly more appropriate > for the sip-implementors list. It just occurred to me that we may also > need something more like a sip-users list for people who are trying to > make off-the-shelf stuff work. Perhaps there is such a list somewhere. .... that the SIP Forum has a "discussion" mailing list which is for general discussion of items related to SIP and recently has had some of this type of traffic on the list: http://sipforum.org/mailman/listinfo/discussion Good to know about the "sip-implementors" list, too. I was not aware of that one. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com --Apple-Mail-136--808897401 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Getting caught up on list email, = I thought I'd point out...=A0

On Dec 18, 2007, at = 12:17 PM, Dean Willis wrote:

This is really off-target for this list, and = possibly more appropriate
for the = sip-implementors list. It just occurred to me that we may also
need something more like a sip-users list for people = who are trying to
make off-the-shelf stuff work. = Perhaps there is such a list = somewhere.

.... that the SIP Forum has = a "discussion" mailing list which is for general discussion of items = related to SIP and recently has had some of this type of traffic on the = list:


Good to know about the = "sip-implementors" list, too.=A0 I was not aware of that = one.

Regards,
Dan
<= DIV>
--=A0
Dan York, = CISSP, Director of Emerging Communication Technology
Office of the CTO=A0 =A0=A0Voxeo Corporation=A0=A0 =A0=A0dyork@voxeo.com
Phone: +1-407-455-5859=A0=A0Skype: danyork=A0=A0http://www.voxeo.com

Bring your web applications to the phone.



=
= --Apple-Mail-136--808897401-- --===============1898725703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1898725703==-- From sip-bounces@ietf.org Wed Dec 26 18:37:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7foC-0001ia-Ny; Wed, 26 Dec 2007 18:37:08 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J7foA-0001iB-UW for sip-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 18:37:06 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J7foA-0001i3-K9 for sip@ietf.org; Wed, 26 Dec 2007 18:37:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7fn2-0001Oq-Rm for sip@ietf.org; Wed, 26 Dec 2007 18:35:56 -0500 Received: from web62414.mail.re1.yahoo.com ([69.147.75.91]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7fn2-0001GQ-Fb for sip@ietf.org; Wed, 26 Dec 2007 18:35:56 -0500 Received: (qmail 16475 invoked by uid 60001); 26 Dec 2007 23:35:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Dx9ouijBRYTHGuCCLmgqqzYhe9TRRBb3CnZv83nwHkPUZxYXm8BROrGag/qg6haog+8vULUlFM71k2OG9XoqAQ6lC+Eaq/S+V5fP4FEdMLjToaj+aTaGnGfZK3hi/tty81Vcx1DWnGLguQzhMBF/rqc/stDTxUE5gfpQoHVlj9g=; X-YMail-OSG: lTQmuT0VM1n3Cx41mar.9Qpy5YHcd7I3W33BuM23eA7xK4smPD56nt6gahHFZMbWLSPyv1O_07q5w2aHbnFJFdS9yA-- Received: from [85.102.192.195] by web62414.mail.re1.yahoo.com via HTTP; Wed, 26 Dec 2007 15:35:51 PST Date: Wed, 26 Dec 2007 15:35:51 -0800 (PST) From: Pulat Ugan To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <930473.14432.qm@web62414.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-TMDA-Confirmed: Wed, 26 Dec 2007 18:37:06 -0500 Subject: [Sip] Processing Record Route Header in 200 OK For Further Requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, When a UA gets record-route header and contact header in 200 OK. like below ------------------------------------------------ contact:sip:{fqdn}:5060 Record-Route: What should be the uri in the re-invite message to put UAS on hold.. And if we use the record-route header as uri, should/may we put the contact header in 200 OK as route header? And the issue I am having for the end of above scenario; should uri of ACK message be contact header coming from UAS in 200 OK regardless of whatever record-route or contact header we previously got in initial call setup.? I will really appreciate if anyone can suggest any reference-document which is including sample flows about processing record-route headers on UAC side. Thanks.. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Dec 26 19:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7gIS-0008TG-EQ; Wed, 26 Dec 2007 19:08:24 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J7gIR-0008T9-Bo for sip-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 19:08:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7gIR-0008T1-0G for sip@ietf.org; Wed, 26 Dec 2007 19:08:23 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7gIQ-0001tQ-Hy for sip@ietf.org; Wed, 26 Dec 2007 19:08:22 -0500 X-IronPort-AV: E=Sophos;i="4.24,209,1196636400"; d="scan'208";a="1749076" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Dec 2007 01:08:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBR08FjW020299; Thu, 27 Dec 2007 01:08:15 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBR08FgE017961; Thu, 27 Dec 2007 00:08:15 GMT Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 01:08:15 +0100 Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 19:08:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Processing Record Route Header in 200 OK For Further Requests Date: Wed, 26 Dec 2007 19:08:13 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E0467C546@xmb-rtp-215.amer.cisco.com> In-Reply-To: <930473.14432.qm@web62414.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Processing Record Route Header in 200 OK For Further Requests thread-index: AchIGEt6u4J3bc1PTPmRQ/IFb+yu2gABAK/w From: "Sanjay Sinha (sanjsinh)" To: "Pulat Ugan" , X-OriginalArrivalTime: 27 Dec 2007 00:08:13.0942 (UTC) FILETIME=[92CF9160:01C8481C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1850; t=1198714095; x=1199578095; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Sip]=20Processing=20Record=20Route=20H eader=20in=20200=20OK=20For=20Further=20Requests |Sender:=20; bh=pO/KejvLvCcGoihN8D0aL2vXSD9Em1a21QvQFdsekhQ=; b=LeJKsZMviGzoGYGhdxEl5gO96y7669d6rOepx+1qhPZVD8V5IBKqCCHWDQ uCPseNT1TDLiLWj8QqIjpGudsk3+zhbhDlsBbRYovL6aO/g4gv3ifIj80vSN 2hrCeheMqk; Authentication-Results: ams-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Since the proxy supports loose routing, for subsequent requests on the dialog, the request-uri should be the Contact header uri and Record-Route header value should be put in Route header. Sanjay >-----Original Message----- >From: Pulat Ugan [mailto:p_ugan@yahoo.com]=20 >Sent: Wednesday, December 26, 2007 6:36 PM >To: sip@ietf.org >Subject: [Sip] Processing Record Route Header in 200 OK For=20 >Further Requests > >Hi, > >When a UA gets record-route header and contact header in 200=20 >OK. like below >------------------------------------------------ >contact:sip:{fqdn}:5060 >Record-Route:EChgLATU1Mzc3NkA2My4yNTEuMjIuODI-> > >What should be the uri in the re-invite message to put UAS on=20 >hold.. And if we use the record-route header as uri,=20 >should/may we put the contact header in 200 OK as route header? > >And the issue I am having for the end of above scenario;=20 >should uri of ACK message be contact header coming from UAS in=20 >200 OK regardless of whatever record-route or contact header =20 >we previously got in initial call setup.? > >I will really appreciate if anyone can suggest any=20 >reference-document which is including sample flows about=20 >processing record-route headers on UAC side. > >Thanks.. > > > > =20 >_______________________________________________________________ >_____________________ >Never miss a thing. Make Yahoo your home page.=20 >http://www.yahoo.com/r/hs > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Dec 27 23:44:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J873p-0004MV-DG; Thu, 27 Dec 2007 23:43:05 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J873n-0004GP-1L for sip-confirm+ok@megatron.ietf.org; Thu, 27 Dec 2007 23:43:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J873m-0004Fr-MQ for sip@ietf.org; Thu, 27 Dec 2007 23:43:02 -0500 Received: from b2.6.5d45.static.theplanet.com ([69.93.6.178] helo=mail.urlsoftware.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J873m-0000hN-Aj for sip@ietf.org; Thu, 27 Dec 2007 23:43:02 -0500 Received: from matrixindia ([220.224.203.162]) by mail.urlsoftware.net (Merak 8.0.3) with ASMTP id TT182176 for ; Thu, 27 Dec 2007 22:43:03 -0600 Received: from 192.168.50.26 by matrixindia ([192.168.50.100] running VPOP3) with ESMTP for ; Fri, 28 Dec 2007 10:13:03 +0530 From: "Dharmesh Desai" To: Date: Fri, 28 Dec 2007 10:12:29 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C8493A.274DCC80" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AchJDAzNH/+xxl5zR4KlMheADStQ8g== X-MS-TNEF-Correlator: 000000003F2A77807A153B44A7E6F5C86BCC45C5A41D2500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: X-Server: VPOP3 V1.4.0e - Registered to: Matrix India X-Cyberoam-Version: 9.5.0.29 X-Cyberoam-smtpxy-version: 0.0.2.8 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: None X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Sip] Why Proxy sends option to its client X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C8493A.274DCC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I have a quarry related to OPTION. I have seen that one of the proxies is sending OPTION to its client at some particular time interval. Is Proxy can send OPTION to its client? If yes, then what is purpose of doing so? Regards, Dharmesh Desai ------=_NextPart_000_0000_01C8493A.274DCC80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ih0EAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgC4CgAAHwAAAAsAAgABAAAAAwAmAAAAAAAeAHAAAQAAACUA AABXaHkgUHJveHkgc2VuZHMgb3B0aW9uIHRvIGl0cyBjbGllbnQAAAAAAgFxAAEAAAAWAAAAAchJ DAzNH/+xxl5zR4KlMheADStQ8gAACwABDgAAAAACAQoOAQAAABgAAAAAAAAAPyp3gHoVO0Sn5vXI a8xFxeKAAAADABQOAQAAAAIBCRABAAAArwcAAKsHAACWEgAATFpGdaMYOE4DAAoAcmNwZzEyNRoy DGBjAFABBHN0c+JoBXBiY2gO9QkAD4dmaA3gD5ZiaQFDC2BukQ4QMDMzEaZmZRIiPwH3AqQDYwIA D4AKwHNlQnQC0XBycTIAACrJCqFubxTgIDAB0AHQwjYSMDA1MDQWsQHQ+RagNH0HbQKDAFAD1BSP /RWbYhZxFuAWQhuEF2AHE4kCgzM2FB4yMzgZ5KIgB20gQ0UclDcdD6cW0B4/H0V5chyUORQeXDE2 GMEhjwOCRwnRa3cCgxbgI382DlAkvwNzVO8IcCZkGMEjnTcgISgvA4KQKEhlYglwdykmZP8n8So+ Hi8sRgcQAaAN4C0luxJQJu44HPEu/wOCQgdA/nQN4CZkIVEjnjEhMo8sc6JWCJB0bmEHgWUtJd8c 8Rj8HggHEx+WNCAhOJ33IUc6FSLlNCNhGPwkeDoUvyYYFsA9ryfnOhQpdjUYz38rGDoULLsOQUMf OZwwSzXfMSE9zTJHOhQz2TUhUT3OXzXGRKU3WwKRCOY7CW8w9U9PZQ4wNVB6UZFRT1JZ/1BkUoJQ 71S/VH1T/1IvUH/5EvAyOFpKW2FbH1wpUGR/XFJav16PXk1dz1v/X8Q5fw5QYxRkcVyTZHACgg8Q eapsB5BoCeB0AABxAyEebBGBBRABQAPwZGN09mwKsQBgcwqwZ7AZcGfyCG51bQIAYWF1dGJvAGBk anUPEAUQZ7xodGcRCgFm4AoBaQGQ9HAwA7IyIVAR5xKoCNDnCcBncGuDbnBr2W10AzDwc25leBnA B7AFsADAcwJzFaBjcxIgAzBpcGQ5atBpdhYQDwAZoG1p5xDAcGAJ8CBEARBpIDPwNCBQCsBhCcBq 8Ggg7kYCIW+UDyAxAFAPIANgTncLMGnAAYBzV2dwdLxoQhJQacAKsHBgbBIg+y7AdQRydXgQAHTm AYB258pidudydOJjYgqwJGCPeNIZ8HkzBPBlbGxnYf90sHRRAUAPIHCwACAz4XNh/yzgdgB7hglQ e6QMsXuzZ+C5e6RkZ3yGfgB9hmh7lf52AzBmr2e/aM9p32rng7H/EfNrZRLia2Fs3IVHhsRupX9z kHDcbzQ2MAGgZhBvlzW3cDpx8AjQZjYgDwBigVC/CYACIHASZeEZkIDAMTrggw5AFsA5IEh5cASQ 92qBJlNv0zaKzw4gi++M+/9y0HpAc/AJgI3PKxBwOhizfwwBeZCQ0pBacQkPAI3hc88CIDpBDwAF oG1wFfKQ//ZFAMADEFNl8isQTnMVoD0LYHQJ8A8gZfOAIHNk8w8QB3BheIqgHPCbIRARtmsJgAEB MG+jT2B2AlHYIHtVjjAV4HcYYZzE740BnUKeY402fYCic/CA4ON8cQGAbmJqAGAJ8HBgtRAgXBXg eJpRgpB5CfD6XG7gcA8wACALkBXgcfG/fHCBYADhAjACYACAYg9gb6FRgWF6IAIQcouBpIFtow8w gsBlXGgFsHqhIrN+AADAcmcLgX4AaKQz8zIwAUFndqbJpYGDMAuAnSsQMA6Rp2CoRTk4IVDbppKl gHeo06oEaqIhAHBfCzChIWXwjeAOUHYIkHf6awuAZFmwrAIE8AdAEvF3AUAOAH8DZYLArWUCEG/j g2CBYGx5dJ3gC4ClYP+gga73g1AAwIKAgWChUaOg/4NQgsEJMoLwejACUAdAC5D/sgECUaxRgCCv AKzxgOACYH90Aa7xAlEAIH6xo6As4GvvpKGlYBXgtIF3dRAJMm7Af2rwgpBs4guAeiKyMZIxZn0I kGxxcZtAejCAoHUQcP51tnCDYIFQBzC0d4zyA2D/rqCNNqFQB9ACUYzCcfAZMP8V4AnAc/CCcrcg BUIZshmg/YDgZIASbtEBQKDxsQAEkH+lYLxyvOJs4hzgvFVxxGM/taGgg51wFZIAgAWQbHb/dWDA YQ5wb1DAYgGQACDA8v+sUZqBAcHAYRlwEgDAIYIA8wzQAZAgLpn0wHYOUMES/6LhwX/Cj8OfwNAS UIIABYH/xV/Gb8d/wNAhUIIAszDFL/vJ/8sFKcPsWbDIz82/yuX+YiygApHO78CjHPDMj9Ff/9Jv 03/AwSAg1NLBX9Y/10//z10uwNTf2m/bf9yPwMEjYP/Zb98P4B/hJQr5f9+A74H//4MPasQKohmB jRlrP2xPbV//bmMYlZTEDEAAgIz7cbAKwZpBekAsCoUKhUkgGXATcLHLUHF1CsByeSAPT2CaUryw 6YAgT1BU8ElPTi4KhRiG8H+NZN/y7BmgcYF0sHkwIAIgFhD/u8D48RYQ9e/xDBoAoXAIkPZz+g/x DCAEAPihoQALgP/KwPUE9MJq0AQgv5AIkAIw//OwBUCXEAeA+f/7DuMhDeD/cfAKwADv/X0Df/EM m2EAz//w7uagmnB/sLMg9W8IT/eLXwqv8Qz/0A0f8QxQ/AF5/w8v/X2s8Oaw/pL/CRFvCM39/8c/ FJ8Lv/Kq+aCh4PxfvRg9LBpv/X35weawd/kS/xxvCM0aXwR/IS/7LCmAl8J/Ix/9ffmRkJD+0iV/ Di1v3xcvGD/ymiov8QxSvlDmMXpz8mZEPkE3sXKwcbBz/5lALP8iLzDfjQlv4D5BK08JLMJ9ADZQ AAMA3j+fTgAAAwAJWQMAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYA AAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAbgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABA AByACCAGAAAAAADAAAAAAAAARgAAAABghQAAANB25dH//x8LAEGACCAGAAAAAADAAAAAAAAARgAA AAAGhQAAAAAAAAsARYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBIgAggBgAAAAAAwAAA AAAAAEYAAAAAGIUAAAAAAAALAF2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAAAAAAsAHw4BAAAA AgH4DwEAAAAQAAAAPyp3gHoVO0Sn5vXIa8xFxQIB+g8BAAAAEAAAAD8qd4B6FTtEp+b1yGvMRcUD AP4PBQAAAAMADTT9PwUAAwAPNP0/BQACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEA AAAxAAAAMDAwMDAwMDAzRjJBNzc4MDdBMTUzQjQ0QTdFNkY1Qzg2QkNDNDVDNUE0MUQyNTAwAAAA AAMABhBY4LrOAwAHEMsAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAREVBUkFMTCxJSEFW RUFRVUFSUllSRUxBVEVEVE9PUFRJT05JSEFWRVNFRU5USEFUT05FT0ZUSEVQUk9YSUVTSVNTRU5E SU5HT1BUSU9OVE9JVFNDTElFTlRBVFNPTUVQQVJUSQAAAAAZuw== ------=_NextPart_000_0000_01C8493A.274DCC80 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_0000_01C8493A.274DCC80-- From sip-bounces@ietf.org Fri Dec 28 00:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J87WL-00019C-15; Fri, 28 Dec 2007 00:12:33 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J87WJ-000197-RP for sip-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 00:12:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J87WJ-00018z-GV for sip@ietf.org; Fri, 28 Dec 2007 00:12:31 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J87WJ-0001Wa-60 for sip@ietf.org; Fri, 28 Dec 2007 00:12:31 -0500 Received: by an-out-0708.google.com with SMTP id d11so664950and.122 for ; Thu, 27 Dec 2007 21:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=pUSM0YeqRQiWRgwAKBcJp1jFeIWYkeTSk7DK223UIHE=; b=MkrCUYTilel/fsAb7gNUdRI8BDisa3IAJITkI+etSNxxqC9xa/nga33Ug4gX7YCVlX/JHx1LqOrY2QcHQrqsEnDy3vx9ECVu7lBSprpPPsjbnTTYk1y3DB9Ep97UkKTejVizJkveiHbSmbTJOJ1dLZx0pGugtjSkzP2PqX9vaW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Jb32stG0hZeBT+ooowz1ANUKrNygeYPckZrO/+TbwFtUUXFh/oabgc6z8kJcOp+DhP7n6QU1pcDLd6W4nM82M+IiC3bqg/7L6PbJYKreTKocIlijDHdg/tkwoEI3Z/LaJEYEEJYvgCxK8ZK2EHTuCakKgjivJ657Kd67iedXNLg= Received: by 10.101.66.14 with SMTP id t14mr18221069ank.48.1198818750559; Thu, 27 Dec 2007 21:12:30 -0800 (PST) Received: by 10.100.109.12 with HTTP; Thu, 27 Dec 2007 21:12:30 -0800 (PST) Message-ID: <2374a5fb0712272112s5357890ay4e5687bf216456a8@mail.gmail.com> Date: Fri, 28 Dec 2007 13:12:30 +0800 From: "=?GB2312?B?y+/TwLni?=" To: "Dharmesh Desai" Subject: Re: [Sip] Why Proxy sends option to its client In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2144342422==" Errors-To: sip-bounces@ietf.org --===============2144342422== Content-Type: multipart/alternative; boundary="----=_Part_7090_18507249.1198818750554" ------=_Part_7090_18507249.1198818750554 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline please refer RFC3261 section 11 2007/12/28, Dharmesh Desai : > > Dear All, > > I have a quarry related to OPTION. > > I have seen that one of the proxies is sending OPTION to its client at > some > particular time interval. > > Is Proxy can send OPTION to its client? > > If yes, then what is purpose of doing so? > > Regards, > Dharmesh Desai > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > ------=_Part_7090_18507249.1198818750554 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline please refer RFC3261 section 11

2007/12/28, Dharmesh Desai <Dharmesh.Desai@matrixtelesol.com>:
Dear All,

I have a quarry related to OPTION.

I have seen that one of the proxies is sending OPTION to its client at some
particular time interval.

Is Proxy can send OPTION to its client?

If yes, then what is purpose of doing so?

Regards,
Dharmesh Desai

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


------=_Part_7090_18507249.1198818750554-- --===============2144342422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2144342422==-- From sip-bounces@ietf.org Fri Dec 28 01:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J88tY-0007a8-2Z; Fri, 28 Dec 2007 01:40:36 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J88tV-0007TO-M6 for sip-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 01:40:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J88tV-0007O5-4V for sip@ietf.org; Fri, 28 Dec 2007 01:40:33 -0500 Received: from fk-out-0910.google.com ([209.85.128.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J88tU-0003ve-La for sip@ietf.org; Fri, 28 Dec 2007 01:40:32 -0500 Received: by fk-out-0910.google.com with SMTP id z23so3706341fkz.5 for ; Thu, 27 Dec 2007 22:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8YO9IEKSIN22/PNiJcLHHcy0M2mjFTMhghC6i8r1gug=; b=BoI4UC3OBbobflA77X2ywEO5YFVhd0AqO7O0CkfMDaKDpaM+iJLth56bTXlQlwVI5nfdxOUSq1YuLGApwI2Pkd0z5l63LCBPHQU5haqQCzXQnpgAC8U9kzJYFlz0ZIdtBM20OM7xmx/Vb1E9KUiVnXHk0FBt3xJd0+7IdLuoS/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=u7yB5b8psLzmj9F9fhwuJWwsmZcaIJr491nAA01ZwRQCIh1Xz78MIkH4TtJ6Ctx1kbZufZDKN9Pk0OKJUrxSaZW2Zx/1Xpm3OVuCWF4kfdktW97raxwl16StrPDTW6lI/5DUF5RIV8Yco2LfBunEJ4HtiX6nowPAs2QSJdeBIAw= Received: by 10.78.146.11 with SMTP id t11mr10774627hud.2.1198824031466; Thu, 27 Dec 2007 22:40:31 -0800 (PST) Received: by 10.78.29.9 with HTTP; Thu, 27 Dec 2007 22:40:31 -0800 (PST) Message-ID: Date: Fri, 28 Dec 2007 14:40:31 +0800 From: "Donald Lee" To: "=?GB2312?B?y+/TwLni?=" Subject: Re: [Sip] Why Proxy sends option to its client In-Reply-To: <2374a5fb0712272112s5357890ay4e5687bf216456a8@mail.gmail.com> MIME-Version: 1.0 References: <2374a5fb0712272112s5357890ay4e5687bf216456a8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, Dharmesh Desai X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0655834281==" Errors-To: sip-bounces@ietf.org --===============0655834281== Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SW4gZmFjdCBzb21lIG9mIHRoZSBTZXJ2ZXIgdXNlcyB0aGlzIE9QVElPTiBtZXRob2QgYXMgYSBr ZWVwIGFsaXZlCm1lY2hhbmlzbS4gQXMgcGVyIHRvIHJmYzMyNjEsIE9QVElPTiBpcyB1c2VkIGZv ciBxdWVyeWluZyB0aGUKY2FwYWJpbGl0aWVzIG9mIHRoZSByZW1vdGUgZW5kcG9pbnQsIHNvIHRo ZSBjbGllbnQganVzdCBuZWVkIHJlcGx5IHRoZQpjb3JyZWN0IHJlc3BvbnNlIGFjY29yZGluZyB0 byB0aGUgUkZDLgoKT24gRGVjIDI4LCAyMDA3IDE6MTIgUE0sIMvv08C54iA8c2FtbWFuZW5naW5l ZXJAZ21haWwuY29tPiB3cm90ZToKPiBwbGVhc2UgcmVmZXIgUkZDMzI2MSBzZWN0aW9uIDExCj4K Pgo+IDIwMDcvMTIvMjgsIERoYXJtZXNoIERlc2FpIDxEaGFybWVzaC5EZXNhaUBtYXRyaXh0ZWxl c29sLmNvbT46Cj4gPgo+ID4KPiA+Cj4gPiBEZWFyIEFsbCwKPiA+Cj4gPiBJIGhhdmUgYSBxdWFy cnkgcmVsYXRlZCB0byBPUFRJT04uCj4gPgo+ID4gSSBoYXZlIHNlZW4gdGhhdCBvbmUgb2YgdGhl IHByb3hpZXMgaXMgc2VuZGluZyBPUFRJT04gdG8gaXRzIGNsaWVudCBhdAo+IHNvbWUKPiA+IHBh cnRpY3VsYXIgdGltZSBpbnRlcnZhbC4KPiA+Cj4gPiBJcyBQcm94eSBjYW4gc2VuZCBPUFRJT04g dG8gaXRzIGNsaWVudD8KPiA+Cj4gPiBJZiB5ZXMsIHRoZW4gd2hhdCBpcyBwdXJwb3NlIG9mIGRv aW5nIHNvPwo+ID4KPiA+IFJlZ2FyZHMsCj4gPiBEaGFybWVzaCBEZXNhaQo+ID4KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBTaXAgbWFpbGlu ZyBsaXN0ICAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwCj4gPiBU aGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wK PiA+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwCj4gPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50 cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwCj4gPgo+ID4KPgo+Cj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBTaXAgbWFpbGluZyBsaXN0ICBodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAKPiBUaGlzIGxpc3QgaXMgZm9y IE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wKPiBVc2Ugc2lwLWltcGxl bWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcAo+IFVz ZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlv biBvZiBzaXAKPgoKCgotLSAKQlIKRG9uYWxkCg== --===============0655834281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0655834281==-- From sip-bounces@ietf.org Fri Dec 28 12:36:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8J6a-000789-Pw; Fri, 28 Dec 2007 12:34:44 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J8J6Z-00077y-GB for sip-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 12:34:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8J6Z-00077q-60 for sip@ietf.org; Fri, 28 Dec 2007 12:34:43 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8J6Y-0005sB-Sn for sip@ietf.org; Fri, 28 Dec 2007 12:34:43 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lBSHYe9U010530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 28 Dec 2007 11:34:42 -0600 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org List" From: Dean Willis Date: Fri, 28 Dec 2007 11:34:28 -0600 X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] Anybody looking at draft-ietf-speechsc-mrcpv2-15? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The speechsc team has asked us to review draft-ietf-speechsc- mrcpv2-15, so I'm curious as to who here (outside of the speechsc chairs, of course) has been following this work. I confess, I haven't. I'd also like to hear from folks who might be interested in reviewing it from a SIP perspective. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Dec 29 22:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8okI-0007pX-Ju; Sat, 29 Dec 2007 22:21:50 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J8okH-0007pR-TF for sip-confirm+ok@megatron.ietf.org; Sat, 29 Dec 2007 22:21:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8okH-0007p5-6z; Sat, 29 Dec 2007 22:21:49 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8okG-0002He-5S; Sat, 29 Dec 2007 22:21:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2007 22:21:47 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBU3LltX026970; Sat, 29 Dec 2007 22:21:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBU3LKIU012776; Sun, 30 Dec 2007 03:21:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 22:21:20 -0500 Received: from [10.86.240.42] ([10.86.240.42]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 22:21:20 -0500 Message-ID: <47770EA9.3000403@cisco.com> Date: Sat, 29 Dec 2007 22:21:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dave Burke References: <3A12F8FF-8623-484C-ABD4-DE00FBD03B87@softarmor.com> <4766DCC6.3030708@cisco.com> <6e608abf0712211617s40a6f974k5d15256100b02130@mail.gmail.com> In-Reply-To: <6e608abf0712211617s40a6f974k5d15256100b02130@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Dec 2007 03:21:20.0364 (UTC) FILETIME=[0C1882C0:01C84A93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9630; t=1198984907; x=1199848907; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Requested=20Expert=20Review=20Request=3 A=20draft-ietf-mediactrl-vxml-00 |Sender:=20 |To:=20Dave=20Burke=20; bh=1BSHSlsZlG3dddNCVwfOTMgYtvuw6UfIBj7MeJzKqGg=; b=aermRPCSW9C+lLQbeUMsm03OSGJS6c2tTkPYCSYCeF85MHuOY9C8gYfIZF g/aREB+XeNICQ8vwmMqCIG/D5ZAxcj9KHyHkeTx/sRMomgtCRtlDkIzQij8G d5R0qKjona; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: sip-chairs@tools.ietf.org, SIP IETF , Dean Willis , mediactrl@ietf.org, Mark Scott Subject: [Sip] Re: Requested Expert Review Request: draft-ietf-mediactrl-vxml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think you are in good shape. I noted a couple of little things below. Paul Dave Burke wrote: > Hi Paul, > > Thanks a lot for the review. Mark and I have discussed each of these and > I've responded to the comments below. > > Cheers, > > Dave > > [snip] > > Section 2.1: > > The ABNF of the URI seems excessively rigid in the ordering of > parameters - first the init-parameters, then the vxml-parameters, then > then any other uri-parameters. It also doesn't note that > 'uri-parameters' is defined in 3261. > > > > DB> Good observation - ordering of the parameters was never intended. > Your proposal looks good. However, while looking over this again, we > found another issue which crept in late in the process related to the > addition of JSON support. Specifically, the problem is that it is > impossible to differentiate where vxml-params end and uri-parameters > begin and hence which parameter values to interpret as JSON values and > which as plain strings. We propose a change to limit JSON values to just > the named VoiceXML session variables 'ccxml' and 'aai' (these were the > two variables for which JSON support was originally sought). > > dialog-parameters = *(";" dialog-parameter) > > dialog-parameter = init-param / url-parameter ; defined in [RFC 3261] > > init-param = ";" (dialog-param / > maxage-param / > maxstale-param / > method-param / > postbody-param / > ccxml-param / > aai-param) You don't want ";" in the def of init-param because it is in the def of dialog-parameters. > dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI > ; syntax defined in [RFC3986] > maxage-param = "maxage=" 1*DIGIT > > maxstale-param = "maxstale=" 1*DIGIT > > method-param = "method=" ("get" / "post") > > postbody-param = "postbody=" token > > ccxml-param = "ccxml=" json-value > > aai-param = "aai=" json-value > > json-value = false / > null / > true / > object / > array / > number / > string ; see RFC4627 > > > > I'm confused about postbody: > > [snip] > > > The interaction between these two escaping rules seems potentially > confusing. I *think* when this is all put together it means that the > body must first be encoded according to the [HTML4] section above. At > that point it will already be almost conformant to the 3261 syntax of a > token, except for the use of '&'. Then it needs to be encoded again, > which will take care of the ampersands, but which will re-encode the > '%' > characters of the first encoding. > > > [snip] > > DB> Your interpretation of the intent is correct. The postbody value is > an application/x-www-form-urlencoded string which we subsequenty > re-encode (the latter step affecting each & and % character). We will > clarify the text that this is the case. Moreover, we'll be more specific > and call out which parameter values are subject to this encoding step , > namely vxml-url, the postbody token, and the json-value. > > > Section 2.2: > > The Application Server SHOULD insert its own URI in the Record-Route > header so that it remains in the signaling path for subsequent > signaling related to the session. This is of particular importance > for call transfers so that upstream Application Servers or proxy > servers see signaling originating from the Application Server and not > the VoiceXML Media Server itself. > > I don't understand the purpose of the above. The SHOULD strength of > this > requirement suggests to me an assumption of a particular operating > environment. In the general case, why should this be more than MAY > strength? > > > DB> Actually, this paragraph is quite problematic. We shoudn't be > mandating how the AS behaves (and indeed a B2BUA doesn't Record-Route > anyway). This paragraph is also a hang over from before we recommended > against using VoiceXML transfer features with application servers. We > propose to delete it. > > > Section 2.3: > > IMO the use of a media-less session is an entirely valid sip usage. The > only concern I might potentially have is if it were to catch some UA > unaware, because some UAs just aren't prepared to handle this case. But > the recommended usage here always puts the choice of doing this in the > hands of *other* UA, not the media server. So I see no problem. > > I do find it disconcerting that the initial invite and subsequent > reinvites are handled in different ways. For the initial one you stall > the VXML awaiting a media stream, but on subsequent ones you assume the > absence of a stream is equivalent to having a stream that doesn't send > anything. Why isn't the behavior consistent in these cases? If you need > to support both behaviors, then it might be better to explicit and > unique signaling for each. For instance, you might define that a media > stream with a=inactive or a=sendonly (from the client's perspective - > client putting media server "on hold") could be treated as the absence > of input but the absence of the stream means you should wait for a > stream to be negotiated. > > > DB> We're conscious of the inconsistency but we took a judgement call to > live with it. Preparing a session is hugely valuable for latency hiding. > However, to support this kind of pause/resume feature once the dialog is > executing is not practical since VoiceXML has no concept of such > semantics and it is difficult to implement especially when external > speech recognition and synthesis systems are used and operate on their > own timers without pausing capabilities. Well, as long as you have thought about it, it is your call. > [snip] > > In addition, the array's toString() function returns the full SIP > Request-URI. For example, assuming a Request-URI of sip:dialog@ > example.com > ;voicexml=http://example.com;obj={ > "x":1,"y":true} then > > I don't believe the above URI is valid. The ',' '{' and '}' aren't > syntactically correct in a URI pvalue. You would need to escape them. > > > DB> Good catch, will fix > > > Section 2.6.2: > > IIUC, message (1) contains no offer, (5) contains an offer with media, > and (6) accepts the call but rejects the media. If so, then (9) will > most likely be invalid. To make it valid, the o-line from (8) needs to > be replaced with one consistent to that used in (6), with the version > number incremented. And if (5) has more m-lines than (8), then (9) > needs > to be padded with extra (rejected) m-lines. > > > DB> Good catch. The intent here is to that the similarly SDP messages > share the same m- and a- lines only. We propose to update the diagram > and perhaps using a prime to denote a derivative SDP message, e.g. > [offer2'], and clarifying in the text. > > > > Section 5.2: > > On receipt of the REFER request, the VoiceXML Media Server MUST > issue > a provisional response, 100 Trying. The 202 Accepted response > indicates that the VoiceXML document has been fetched and parsed > correctly. The VoiceXML Media Server proceeds to place the outbound > INVITE and will execute the application after the ACK is sent. > > The rules of RFC 4320 need to be followed here. REFER is a non-invite > transaction and so the timing of the 100 must be as specified in 4320. > > > DB> Will fix > > > In the call flow, the sending of the initial NOTIFY before the 202 for > the REFER, and especially before determining if REFER is going to > succeed or fail, is at best unusual and almost certainly incorrect. > Sending the NOTIFY and then sending a failure response would certainly > be incorrect. > > I think you have two choices: > > - wait until the get is complete before sending the NOTIFY, and probably > send it after the 202. > > - send a 202 for the REFER before doing the GET. Inform of a GET > failure > via a NOTIFY. > > > DB> There is currently an ongoing thread on the list about whether we > remove this feature (and hence section) altogether. For the sake of > argument, I'll assume it stays, in which case we think option 2 is the > most conventional (especially since most systems responds to the REFER > instantaneously). A GET failure would be conveyed by a NOTIFY with a 500 > Server Internal Failure sipfrag message (same status used for the INVITE > case). > > > > Section 6.3: > > In the call flow I think you probably need another NOTIFY between > messages (6) and (7). Its potentially too long until (13). > > > DB> This is correct but we note in the text "(provisional responses and > NOTIFY > messages corresponding to provisional responses have been omitted for > clarity)" > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Dec 31 01:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9EAF-00023O-9v; Mon, 31 Dec 2007 01:30:19 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J9EAC-00023J-Tb for sip-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 01:30:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9EAC-00023B-I0 for sip@ietf.org; Mon, 31 Dec 2007 01:30:16 -0500 Received: from tapal.aricent.com ([59.165.248.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9EA9-0002XF-W7 for sip@ietf.org; Mon, 31 Dec 2007 01:30:16 -0500 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id lBV6TekP011247 for ; Mon, 31 Dec 2007 11:59:40 +0530 Received: from pragati.bgh.aricent.com (pragati.bgh.aricent.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id lBV6Tex3011244for ; Mon, 31 Dec 2007 11:59:40 +0530 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Ranjith.V@aricent.com Date: Mon, 31 Dec 2007 11:58:04 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at12/31/2007 11:57:29 AM,Serialize complete at 12/31/2007 11:57:29 AM X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-19.3461 TC:1F TRN:39 TV:5.0.1023(15638.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.8 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Sip] doubt regarding early session in sip RFC 3959/3960 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784828511==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0784828511== Content-Type: multipart/alternative; boundary="=_alternative 0023F69CE52573C2_=" This is a multipart message in MIME format. --=_alternative 0023F69CE52573C2_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpFeGFtcGxlIGV4cGxhaW5lZCBpbiB0aGUgU2VjdGlvbiA3IG9mIHRoZSBSRkMg Mzk1OSAsIFVBUyBpcyBleHBlY3RpbmcgIiANCmVhcmx5LWFuc3dlciAiIGluIFBSQUNLIGZyb20g dGhlIFVBQywgd2hhdCB3aWxsIGhhcHBlbiBpZiBVQUMgZG9lcyBub3QgDQpzdXBwb3J0ICIxMDBy ZWwiIChSRkMgMzI2MikuDQoNCkFuZCBSRkMgMzk1OSBpcyBub3QgbWFuZGF0aW5nIHRoZSAiMTAw cmVsIiBleHRyZW5zaW9uIGF0IFVBIGZvciB0aGUgc2FtZS4gDQpDYW4gYW55b25lIGdpdmUgYW4g ZXhhbXBsZSBvZiAgZWFybHkgc2Vzc2lvbiBmbG93IGluIGNhc2Ugb2YgIFVBQyBpcyBub3QgDQpz dXBwb3J0aW5nICIxMDByZWwiIC4gKFVQREFURS4uPykNCg0KSQ0KQmVzdCBSZWdhcmRzLA0KUmFu aml0aCBSZWRkeS4gVg0KU3IuIFNvZnR3YXJlIEVuZ2luZWVyDQpBcmljZW50LUJhbmdhbG9yZS4N Cg0KRWZmb3J0bGVzc25lc3MgaXMgYm9ybiBvdXQgb2YgZ3JlYXQgZWZmb3J0Lg0KDQoqKioqKioq KioqKioqKioqKioqKioqKiAgQXJpY2VudC1VbmNsYXNzaWZpZWQgICAqKioqKioqKioqKioqKioq KioqKioqKg0KDQoqKioqKioqKioqKioqKioqKioqKioqKiAgQXJpY2VudC1VbmNsYXNzaWZpZWQg ICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBw cm9wcmlldGFyeSB0byBBcmljZW50IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFp biBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBi ZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0 IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJy b3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFy ZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBk aXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBu byByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNl IG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBk YW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 0023F69CE52573C2_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkhpIGFsbCw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkV4YW1wbGUg ZXhwbGFpbmVkIGluIHRoZSBTZWN0aW9uIDcgb2YNCnRoZSBSRkMgMzk1OSAsIFVBUyBpcyBleHBl Y3RpbmcgJnF1b3Q7IGVhcmx5LWFuc3dlciAmcXVvdDsgaW4gUFJBQ0sgZnJvbQ0KdGhlIFVBQywg d2hhdCB3aWxsIGhhcHBlbiBpZiBVQUMgZG9lcyBub3Qgc3VwcG9ydCAmcXVvdDsxMDByZWwmcXVv dDsgKFJGQw0KMzI2MikuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5BbmQgUkZDIDM5NTkgaXMgbm90IG1hbmRhdGluZyB0aGUgJnF1b3Q7MTAwcmVsJnF1 b3Q7DQpleHRyZW5zaW9uIGF0IFVBIGZvciB0aGUgc2FtZS4gQ2FuIGFueW9uZSBnaXZlIGFuIGV4 YW1wbGUgb2YgJm5ic3A7ZWFybHkNCnNlc3Npb24gZmxvdyBpbiBjYXNlIG9mICZuYnNwO1VBQyBp cyBub3Qgc3VwcG9ydGluZyAmcXVvdDsxMDByZWwmcXVvdDsNCi4gKFVQREFURS4uPyk8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkk8YnI+DQpCZXN0IFJl Z2FyZHMsPGJyPg0KUmFuaml0aCBSZWRkeS4gVjxicj4NClNyLiBTb2Z0d2FyZSBFbmdpbmVlcjxi cj4NCkFyaWNlbnQtQmFuZ2Fsb3JlLjxicj4NCjxicj4NCkVmZm9ydGxlc3NuZXNzIGlzIGJvcm4g b3V0IG9mIGdyZWF0IGVmZm9ydC48YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAm bmJzcDtBcmljZW50LVVuY2xhc3NpZmllZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8 YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVVuY2xhc3Np ZmllZCAmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8dGFibGU+PHRyPjx0 ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQgY29sb3I9IzAwMDAwMD48cHJlPiJESVNDTEFJTUVSOiBU aGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCBhbmQgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3Nl ZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g YW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3Ro ZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlh dGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3Rp ZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5n LCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBB cmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlz aW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBl bWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3Ry PjwvdGFibGU+ --=_alternative 0023F69CE52573C2_=-- --===============0784828511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0784828511==--